Cowrie Research

proof-effect-truth-security-object

17 min read

Proof Effect Truth as a Single Security Object

  • Name: Proof effect truth as a single security object
  • Category: proof-system reference / settlement-boundary checklist / batch-accounting equivalence note / rollup solvency and tally-integrity reference
  • Summary: Healthy proof-driven settlement is not just the cryptography verified. It is the stronger condition that one security object stays intact from witness rows and public inputs all the way through the consumer that collects deposits, credits balances, authorizes withdrawals, or finalizes outcome-critical state like tallies. A system is sound only when the exact effects the proof authenticates are the same effects the settlement or outcome layer economically or politically honors. The recurring review mistake this note tries to stop is flattening three different promotions into one vague proof passed moment: some proof-shaped object or batch artifact exists, that object deserves to count as canonical proof truth for this exact effect set, and that accepted truth deserves downstream withdrawal, release, or finalization authority. This note exists to keep that positive design target explicit instead of making readers reconstruct it only by inverting proof / settlement mismatch incidents like Aztec Connect or outcome-integrity failures like MACI.
  • Why this note exists:
    • Proof-driven failures often get narrated as zk bug, batch parser bug, decoder mismatch, or settlement contract bug, but those are often different ways the same economically or politically authoritative object got split apart.
    • A healthy proving stack does not merely verify one transition and then hope the runtime consumer applies the same rows, the same boundaries, the same backing events, or the same tally semantics.
    • The analytical win is to ask what exact effect set is this system claiming to authenticate? before asking whether the implementation bug lived in the circuit, the public inputs, the loop bounds, the decoder, the tally processor, or the withdrawal path.

Three proof-authority promotions settlement reviewers should keep separate

  1. A proof-shaped object or batch artifact exists

    • A batch was constructed, a verifier returned true, a decoder emitted rows, internal credit was recorded, or a tally processor produced an intermediate result.
    • This is only the existence question: there is some proof-adjacent object the runtime may later trust.

  2. That object deserves to count as canonical proof truth for this exact effect set

    • The batch boundaries, row counts, indexed objects, public inputs, decoder interpretation, and backing-event semantics all have to align strongly enough that the runtime is still looking at the same thing the proving system authenticated.
    • This is the proof-truth question: the accepted object really is the canonical authenticated effect ledger or outcome object.

  3. That accepted truth deserves downstream withdrawal, release, or finalization authority

    • Even a real proof-valid batch result should not automatically mean credit withdrawable balance, release escrow, or publish the canonical tally unless the downstream consumer is honoring the same settled object and the exit path still remembers provenance.
    • This is the cash-out question: why is this proof-truth object allowed to matter this much here and now?

Healthy proof-driven systems keep those promotions distinct instead of collapsing them into verifyProof() returned true.

The five joints a healthy proof-settlement system should keep fused

  1. Canonical effect ledger

    • The system needs one unambiguous list of economically or outcome-relevant effects: deposits credited, fees charged, burns consumed, withdrawals authorized, tally updates applied, justified invalidations recorded, and balances or voter state updated.
    • The circuit proved some batch is not enough if the runtime consumer and downstream accounting can disagree about which rows inside that batch were economically real, or if an outcome system can disagree about which commands were actually entitled to mutate canonical state.
    • This is the joint that breaks in proof-to-effects-binding-failure and is the healthy-side question sitting just beside witness-public-input-binding-failure when a proof-backed tally or vote-processing system drifts away from the public semantics it claims.

  2. Shared batch boundaries and row indexing

    • Proof generation, verification, and settlement must agree on row counts, padding rules, batch grouping, and which indices are allowed to create or consume value.
    • Declared counters like numRealTxs are custody-critical if they narrow the economically honored subset.
    • This is where fixed-width proof batches, runtime-derived loop bounds, or off-by-one grouping rules quietly become solvency bugs.

  3. Backing events tied to credited state

    • Any row that increases a withdrawable balance, spendable note, or later redeemable claim needs one corresponding backing event in the same authenticated effect set: assets received, liabilities burned, or some other conserved source of value.
    • If a batch can update internal credit first and leave deposit collection, burn consumption, or fee charging to a narrower secondary pass, the system has already split the security object.
    • This is the credited row existed, but no same-object proof showed its backing asset entered failure that makes later ordinary withdrawals dangerous.

  4. Settlement consumer interpretation

    • The consumer that moves real assets should not be free to reinterpret the proof after verification.
    • Decoder outputs, loop bounds, runtime flags, and internal subset projections all belong inside the same security boundary once they decide which effects are actually settled.
    • A valid proof over one object is not a solvency proof for another object that merely looks related.

  5. Downstream withdrawable truth

    • Later withdrawal, redemption, or bridge-release code should distrust naked internal credits unless the creation path already proved the matching backing event.
    • The safest systems make credited balance and economically settled balance the same thing by construction, not by convention.
    • This is the final joint that turns a batch-boundary mismatch into real losses: an ordinary exit path honors state that should never have become withdrawable.

What sound design looks like

  • Proof authority stays staged rather than collapsing into one verifier event

    • The design should keep proof-shaped object exists, object counts as canonical effect truth, and that truth deserves settlement or finalization authority as separate promotions with explicit checks and provenance at each step.
    • The fastest way to hide a proof / consumer bug is to narrate all three promotions as one proof passed fact.

  • One authenticated effect set, one economically or outcome-critically honored effect set

    • The same rows that the proof authenticates should be the rows the settlement layer charges, credits, and later allows users to withdraw against — or, in a tally system, the rows the protocol ultimately treats as the canonical valid or invalid command set.
    • If runtime metadata, witness-side substitutions, or operator-controlled batch interpretation can silently narrow or reinterpret the set after verification, the design is already leaning on folklore.

  • Batch metadata should be proven, not trusted

    • Counters, subset lengths, padding markers, or row-class flags that decide which effects are economically real belong inside the authenticated object.
    • The consumer should treat them as part of custody truth, not as harmless efficiency hints.

  • Credit creation should be impossible without same-object backing proof

    • Internal balances should not become spendable merely because one pass updated state.
    • A clean design forces the same authenticated object to prove both this credit exists and the matching asset or burn event happened before that credit can escape through ordinary exit rails.

  • Decoders and consumers should inherit one canonical effect ledger

    • The runtime layer should consume an explicit proved effect ledger, not reconstruct its own narrower version from convenience counters or local interpretations.
    • The safest shape is that proving code, verifier, decoder, and asset-moving consumer all refer to one canonical commitment rather than parallel representations that humans assume are equivalent.

  • Withdrawals should consume only economically settled state

    • Exit paths should not trust internal credit just because it was once proof-adjacent.
    • If the creation path did not already bind that credit to real asset intake or liability consumption, the withdrawal path should still have a way to reject it.

Useful positive design shapes

1. One canonical effect commitment shared across prover and consumer

  • The reusable point is not just commit the batch root; it is that the commitment must describe the exact economically relevant effect ledger the consumer will honor.
  • Healthy systems avoid letting one layer reason about padded rows, decoded actions, or subgroup counts while another layer independently decides which of those rows matter for money movement.
  • If a row can create withdrawable state, that row should live inside the same canonical commitment the consumer settles.
  • one committed settled-effects object is the narrower companion note when the important design question becomes what exact committed object forces those layers to stay aligned?

2. Credited rows cannot outpace backing rows

  • The key design move is to make credit creation and backing verification inseparable.
  • A deposit-like row should not become withdrawable unless the same authenticated object already established that matching assets entered or matching liabilities were consumed.
  • This is the cleaner positive-design answer to Aztec-style proof valid, settlement narrower incidents.

3. Declared subset variables are advisory at most

  • If a field like numRealTxs exists for efficiency, proving, or compression reasons, healthy systems either bind it tightly into the authenticated object or refuse to let it narrow which rows receive economic settlement.
  • The reusable lesson is that any variable capable of shrinking the consumer’s loop is part of custody truth whether engineers meant it that way or not.

4. Exit rails distrust unaudited internal balances

  • A robust withdrawal or redemption path does not assume every internal balance was created soundly just because it sits in protocol state.
  • Where practical, downstream exits should consume explicit settled effects, spent nullifiers, or balances whose creation path already proved backing under the same object.
  • The positive design target is not more checks later; it is no state becomes cashable until the right proof-backed backing event already happened.

5. Equivalence testing across the proof-consumer boundary

  • Proof-validity tests alone are too weak.
  • Healthy systems also test the stronger invariants: all proof-credited effects are settled, all settled effects were proof-authenticated, and mutating any supposedly ignored row cannot create withdrawable value.
  • For proof-backed outcome systems, the sibling invariant is all proof-processed commands mutated the exact indexed state objects the public semantics named, and every command the protocol later treats as invalid or excluded became so for reasons that were already inside the authenticated batch semantics.
  • The best fuzz cases are exactly the awkward boundary states engineers are tempted to dismiss as padding, metadata, or non-real rows.

Design questions worth asking first

  • What exact effect ledger does the proof authenticate?
  • What exact effect ledger does the settlement or outcome consumer charge, credit, release against, or treat as canonical tally truth?
  • Which variables can narrow the consumer’s economically or outcome-critically honored subset after proof verification?
  • Does every row that creates withdrawable state also prove its own backing event inside the same authenticated object?
  • If the system is tally-like rather than balance-sheet-like, what exact proved object shows that each included, excluded, or invalidated command was processed against the same indexed state object the public semantics claimed?
  • Can a later withdrawal, redemption, bridge-release path, or outcome-finalization path honor internal state whose creation path was never economically or semantically settled?
  • If one row just outside the consumer’s current loop bound mutates from harmless to value-creating or outcome-changing, does the system fail closed or quietly accept the drift?

Red flags that usually mean proof and settlement are being held together by convention

  • The proof is valid, so the batch is safe without showing that the consumer settled or honored the same rows
  • That counter is only metadata even though it changes loop bounds or row classification
  • Only some rows are economically real or the coordinator knows which commands really count when the proof authenticates a wider object but the narrowing rule is not itself bound and enforced
  • Internal balances are fine because withdrawals are ordinary even though the credit-creation path never proved matching asset intake
  • The decoder reconstructs the same thing anyway without equivalence tests across padding, grouping, or edge-index cases
  • Padding rows cannot matter or invalidity is obvious from context stated as an assumption rather than an invariant enforced by proof and consumer together

Failure-prevention checklist

  • Define one canonical economically or outcome-relevant effect object for every proof-driven batch before writing verifier or settlement code. If reviewers cannot point to the exact list of credits, debits, burns, fees, exits, command applications, and justified invalidations that count as protocol truth, the design is already too loose.
  • Bind subset-defining metadata into the authenticated object. Counters like numRealTxs, padding markers, chunk sizes, row classes, and end-of-batch boundaries are custody-critical once they decide which rows the consumer will honor.
  • Make credit creation inseparable from backing creation. A row that increases withdrawable balance, spendable note state, or later redeemable claim should already prove the corresponding asset intake, burn consumption, fee charge, or reserve movement inside the same authenticated object.
  • Prefer consumer inputs that are commitment-first rather than interpretation-first. The runtime layer should settle an explicit proved effect ledger or a commitment to it, not rebuild a narrower local view from convenience flags or decoder folklore.
  • Treat decoder outputs, batch slicing, and handoff objects as part of the proof boundary. If an intermediate parser, bridge adapter, or settlement loop can reinterpret which effects are real, it belongs inside the same security review as the circuit and verifier.
  • Keep exit rails provenance-aware. Later withdrawals, redemptions, and bridge releases should only honor balances whose creation path was already economically settled under the same authenticated object.
  • Add boundary-equivalence tests, not just proof-validity tests. Prove that every proof-credited effect is settled, every settled effect was proof-authenticated, and mutating a supposedly non-real row cannot create cashable state.
  • Re-run those equivalence tests across upgrades, compression changes, batch-size changes, decoder refactors, and migration paths. Proof / consumer drift often appears when teams change performance plumbing rather than the proving logic itself.
  • Monitor live systems for credited state outpaced backing state signals: unexplained balance growth, unexplained pending-deposit drift, or withdrawal rights that can increase without matching reserve movement.
  • Keep one review artifact that states the joined invariant explicitly: the proof, the consumer, and the exit path all honor one settled-effects object rather than adjacent approximations.

Audit prompts

  • What exact economically or outcome-relevant effect object does the proof authenticate, and where is that object explicitly committed or reconstructed?
  • Which fields can narrow, reorder, or classify the subset the consumer treats as real after proof verification, and are those fields themselves authenticated as custody or outcome truth?
  • Does every row that creates withdrawable state also prove its own backing event inside the same authenticated object?
  • For tally-style systems, what proves that each command touched the exact indexed state object the public semantics named before any invalidity or exclusion decision was allowed to stick?
  • Can the runtime consumer, decoder, or adapter honor a narrower local interpretation than the proof covered without any commitment mismatch or invariant failure firing?
  • If a later withdrawal or tally finalization succeeds, what exact proved object shows that the consumed balance or accepted exclusion was already economically or semantically settled rather than merely proof-adjacent internal state?
  • Are there any rows, logs, state diffs, or messages that can affect balances or canonical outcomes even though the consumer calls them padding, metadata, non-real, or just internal?
  • During upgrades, where is the assertion that verifier semantics, decoder semantics, settlement semantics, outcome semantics, and exit semantics still describe the same effect set?
  • What test proves that mutating a row just outside the consumer’s declared subset cannot create cashable value or change canonical outcome truth?
  • If an operator or reviewer says the proof is valid, what additional artifact shows that the runtime layer settled the same economically relevant rows or outcome-changing commands the proof authenticated?
  • If this system failed once at the proof-consumer seam, what independent control would still prevent fabricated internal state from becoming a real withdrawal, bridge release, or canonical tally result?

Lessons that should already be standard

  • Proof verified is never the whole solvency or outcome-integrity claim. The real claim is that the exact effect set the proof authenticated is the same effect set the consumer charged, credited, later allowed users to exit against, or treated as canonical outcome truth.
  • Subset metadata is not operational trivia once it changes money movement. Row counts, padding flags, and chunk boundaries become treasury policy the moment they can narrow settlement.
  • Internal balances are not neutral bookkeeping. If a system can create proof-adjacent credit without same-object backing proof, later ordinary withdrawals will eventually monetize the gap.
  • Consumer-side reconstruction is one of the most dangerous places to hide trust. The more the runtime has to infer what the proof must have meant, the easier it is for proof truth and money truth to drift apart.
  • Deprecated or low-touch systems are still live if old proof paths can create or cash out balances. Immutability does not shrink the need for one committed settled-effects object.
  • The healthiest proof-driven systems are boring at the seam: one committed effect object, one consumer interpretation, and one exit story that never forgets backing provenance.

How to use this note with the exploit corpus

  • Start here when the question is what should one healthy proof-driven settlement or outcome object keep bound together?
  • Pair it with Canonical outcome commitment and finalization discipline when the sharper non-cashflow follow-up is what exact committed command-result object should make one proof-backed tally or canonical-result system publish one unambiguous outcome?
  • Pair it with one committed settled-effects object when the sharper money-moving follow-up is what exact committed ledger or consumer-facing object should make that binding concrete?
  • Pair it with no ambient internal balance trust when the sharper downstream question is what later withdrawals, redemptions, or releases should still require before treating internal state as real money.
  • Drop into Proof-to-effects binding failure when the decisive failure is that a valid proof and its runtime consumer authenticated different economically relevant effect sets.
  • Narrow into:
  • Pair with Bridge truth as a single security object when the same protocol also needs a stronger answer to what exactly counts as one authentic bridge action?.

Internal linkages

Negative exemplar cluster: what split proof effect truth looks like

  • Aztec Connect preserves the clean fixed-width-proof / narrower-settlement-consumer cousin: the proof authenticated row groups that could credit balances, while processRollup() trusted numRealTxs and failed to settle the same economically relevant rows.
  • [[../incidents/proofs-verifiers/maci-1-0-processmessages-under-constrained-message-state-binding-coordinator-censorship-near-miss-2021-12-01|MACI 1.0 ProcessMessages]] preserves the outcome-integrity cousin: the proof-backed tally system claimed to process each message against its indexed voter state, but the authenticated batch semantics still let the coordinator substitute the per-message state object before invalidity branching, so the protocol could honor a weaker canonical outcome than users thought the proof guaranteed.
  • The useful preserved lesson is not merely Aztec had a bug in a zk system or MACI had a coordinator bug; it is that proof-validity and economically or politically real effect truth had become two different objects.

Control surface

Graph View

Backlinks