Cowrie Research

proof-to-effects-binding-failure

18 min read

Proof-to-Effects Binding Failure / Authenticated-Batch Side-Effect Divergence

  • Name: proof-to-effects binding failure / authenticated-batch side-effect divergence
  • Category: exploit pattern / proof-consumer boundary failure / rollup-settlement mismatch / batch-accounting divergence / unbacked internal-credit creation
  • Summary: This pattern appears when a proof system and the runtime consumer of that proof no longer authenticate the same economically authoritative effect set. The proof may be perfectly valid and still useless as a solvency guarantee if the contract that moves real assets, charges deposits, or settles withdrawals only executes a narrower, different, or differently indexed subset of the proven batch. The same structural mistake also matters one layer beyond cashflow whenever a proof-backed system treats some later consumer interpretation as canonical outcome truth. Once the proof says this batch is internally consistent drifts away from the runtime consumer honored those exact credited or settled effects, attackers can create internal balances or rights that look proven but were never backed by real incoming value.
  • What it is:
    • A protocol uses a proof system to authenticate a batch, state transition, or fixed-width group of operations.
    • A separate runtime consumer such as a settlement contract, bridge processor, or asset-moving adapter turns that authenticated batch into real economic effects.
    • The design implicitly assumes those two layers are talking about the same effect set.
    • In the vulnerable case, they are not: the proof authenticates more rows, different rows, or a different interpretation of those rows than the consumer actually settles.
    • An attacker places value-creating state transitions inside the authenticated region that the proof accepts but the asset-moving consumer skips, undercharges, or fails to validate.
    • Later, ordinary withdrawal, redemption, or release paths honor the resulting internal credit as if it were genuinely backed.
  • Typical preconditions:
    • The protocol splits responsibility between a proof-validity layer and a separate contract or runtime layer that moves real assets.
    • The proof and the consumer each derive batch boundaries, row counts, indexing, or effect semantics from different variables, assumptions, or fixed-width grouping rules.
    • The consumer trusts a declared subset such as numRealTxs, a runtime flag, or a local effect counter instead of reasserting that every credited proof-side effect was economically settled.
    • Proof-side commitments may also be chunked or padded more coarsely than the consumer’s loop bound, so processed rows = 1 does not necessarily mean proof-authenticated rows = 1.
    • A proved-but-unsettled row can still mutate internal balances, entitlements, or bridge positions that downstream code later honors.
    • There is a path to cash out fabricated credit through normal withdrawals, redemptions, or adapter unwinds.
  • Common vulnerable surfaces:
    • rollup settlement contracts where the proof authenticates a wider row group than the onchain settlement path processes
    • proof-driven batch processors that separate state transition validity from asset collection / asset release
    • zk or validity-proof systems where public inputs describe a narrower runtime subset than the circuit or proving logic actually reasons about
    • bridge or batching systems where a proof authenticates one side-effect set but the destination-side executor applies another
    • systems that use one set of rows for balance updates and a second set of rows for deposit collection, fee charging, or withdrawal settlement
    • proof-backed outcome systems where some downstream consumer treats a locally reconstructed subset as the canonical finalized effect set rather than the exact committed object the proof authorized
    • deprecated, governance-renounced, or exit-only legacy proof systems where old proof-created internal credit can still reach live withdrawals, wrapper unwinds, or bridge-release sidecars even after maintainers have walked away
  • Exploit sequence:
    1. The attacker finds a batch boundary mismatch between what the proof authenticates and what the runtime consumer economically settles.
    2. They craft a batch where one row or effect inside the proof-authenticated region creates internal balance, entitlement, or position state.
    3. The consumer processes only a narrower or differently indexed subset, so the checks that should have collected real assets or enforced backing never run for that credited row.
    4. The proof still verifies, because the proof system was never asked the same question as the settlement layer.
    5. The protocol now records internal credit backed by no real deposit or charge.
    6. The attacker later places an ordinary withdrawal, redemption, or unwind on a row the consumer does honor, cashing the fabricated credit out into real assets.
  • Variants:
    • Declared-subset divergence — the proof authenticates a full batch or fixed-size row group while the consumer executes only the first declared N rows, as in Aztec Connect’s numRealTxs bug.
    • Chunk-boundary mismatch — proof-side hashing or public-input commitment works in larger blocks than settlement-side accounting, so one extra state-changing row can still live inside the authenticated chunk even when the consumer thinks it stopped before that row.
    • Indexing or boundary mismatch — proof-side grouping, padding, or row numbering does not line up with the consumer’s runtime interpretation of which effects are economically real.
    • Charge-effects split — one subsystem updates balances or rights while another is supposed to collect deposits, fees, or burns, and the equivalence between the two is only assumed rather than enforced.
    • Authenticated-batch, narrowed-settlement consumer — the proof vouches for a whole transition object, but the consumer only executes a user-declared or runtime-derived projection of it.

Three proof-to-settlement promotions healthy systems should not collapse

  1. A proof-authenticated batch or transition object exists at all

    • The circuit verified, the public inputs matched, and some batched transition object was successfully authenticated.
    • This is only the cryptographic-validity question: some transition object satisfied the proof statement.

  2. That authenticated object is the canonical economic effect ledger for this batch

    • This is the step vulnerable systems skip over. They quietly promote a valid proved batch exists into this is the one exact row/effect set the consumer should treat as economically real.
    • Aztec Connect is the clean preserved case: a valid inner-rollup chunk had been authenticated, but the protocol had not proved that the same chunk and the narrower numRealTxs-governed settlement subset were one economic object.

  3. That accepted economic effect ledger still deserves asset-moving authority here

    • Even once a proved object looks like canonical batch truth, the protocol still has to decide which deposits must already be collected, which credits are withdrawable, and whether later redemption paths may spend against that accepted ledger right now.
    • Healthy systems do not let proof-backed credit exists stand in for proof-backed credit is already economically backed and safe to cash out unless those are already the same proved-and-settled object.
  • Detection heuristics:
    • Ask two separate questions: what exact effect set did the proof authenticate? and what exact effect set did the asset-moving or outcome-finalizing consumer execute, charge for, or treat as canonical?
    • Diff proof-side row-grouping, padding, and indexing rules against settlement-side loop bounds, counters, boundary variables, and any later finalization step that decides which proved effects are the ones that count.
    • Recompute the exact proof-side commitment granularity. If the proof commits in 32-row chunks, Merkle subtrees, or padded inner batches, test whether declared real rows = 1 still authenticates a larger state-changing region than the consumer settles.
    • Treat variables like numRealTxs, processedCount, effectiveRows, or subset length as custody-critical, not mere efficiency metadata.
    • Test adversarial batches where a harmless row sits inside the consumer’s processed subset and a value-creating row sits just beyond it but still inside the proof-authenticated region.
    • Review whether internal balance updates can occur before or without independent proof that the matching external asset movement happened.
    • When a system says the proof is valid, ask whether that statement alone implies all credited deposits were really collected, all executed withdrawals were backed, and the exact proved effect set is the one the protocol later treats as canonical. If not, the boundary is suspect.
    • If the system has already failed one layer earlier by proving a weaker relation about which indexed state objects each command touched, that is usually witness-public-input-binding-failure instead. If the sharper question is not reserve-backing drift but what exact proof-backed canonical result should everyone have had to publish?, that is usually proof-backed-outcome-integrity-failure instead. MACI is the useful boundary-setting contrast.
  • Defenses:
    • Bind one authenticated batch to one economically settled effect set: the proof consumer should not be free to reinterpret which rows count after proof verification.
    • Make batch boundaries explicit and shared between circuit and settlement code, with invariant tests that fail if the two layers ever accept different effect sets.
    • Reassert asset-backing conditions at the settlement boundary for every credited deposit, burn, or release that can change solvency.
    • Prefer APIs that pass an explicit proved effect set into the consumer rather than letting runtime metadata silently narrow it.
    • Add tests that mutate any proof-side row just outside the consumer’s current loop bound and assert that verification or settlement fails rather than creating credit.
    • Decommission deprecated proof systems as residual custody systems, not abandoned products: if the proof / settlement glue can no longer be patched, shrink wrapper sidecars, bridge unwinds, and ordinary withdrawal rights until the remaining surface is consciously bounded and genuinely exit-only.
    • Treat proof-consumer glue code as treasury code; the cryptography can be correct while the solvency boundary is still broken.

What sound design looks like

  • Healthy systems keep three facts separate on purpose: a proof-authenticated transition object exists, that object is the canonical economic effect ledger for this batch, and that accepted ledger is already allowed to move or promise real assets here.
  • The proof and the economic consumer should answer the same question about the same object. If the proof authenticates rows 0..31, the settlement layer should not later decide that only rows 0..k were the ones that mattered for real assets unless that same boundary was itself part of the authenticated object and proven safe. Proof effect truth as a single security object is the broader positive-design companion note for this one authenticated effect object, one settled effect object target, one committed settled-effects object is the narrower design companion on what exact committed consumer-facing object should force the two layers to stay aligned, and no ambient internal balance trust is the downstream companion on what later withdrawals or releases should still demand before they cash out any internally credited state.
  • Every internal balance increase that can later be withdrawn should have one corresponding, independently enforced backing event in the same authenticated effect set: assets received, claims burned, or value otherwise conserved.
  • Batch metadata that narrows execution should be treated as part of the security object, not as convenience data. If a counter or subset flag changes which rows are economically real, the proof must bind that choice and the consumer must enforce the same interpretation.
  • Proof-validity tests are not enough. Healthy systems also need equivalence tests across the proof consumer boundary: all proof-credited effects are settled and all settled effects were the ones the proof authenticated.
  • The clean design question is: if an attacker points to one credited row and one later withdrawal, where exactly did the system prove that the credited row’s backing asset really entered before that withdrawal could succeed? The same question generalizes one step beyond solvency too: if a system points to one final tally, batch result, or finalized outcome, where exactly did it prove that the consumer honored the same effect object the proof authorized?
  • High-signal incidents:
    • [[../../../incidents/proofs-verifiers/aztec-connect-processrollup-numrealtxs-proof-settlement-boundary-drain-2026-06-14|Aztec Connect processRollup() numRealTxs proof-settlement boundary drain (2026-06-14)]] — the current canonical exemplar: the proof authenticated fixed-size inner-rollup chunks while onchain settlement trusted numRealTxs and processed only a narrower subset, letting row 1 remain inside the first authenticated 32-row chunk, create balance without real deposits, and later fund counted row-0 withdrawals.
    • Useful near-boundary contrast: [[../../../incidents/proofs-verifiers/aztec-2-escapehatch-old-data-root-decoupling-unsound-proof-withdrawal-2026-06-17|Aztec 2.0 escapeHatch() old_data_root decoupling / unsound proof withdrawal (2026-06-17)]] — similar proof-family intuition, but that incident belongs primarily to witness-public-input-binding-failure because the proof statement itself split one supposedly shared root into separately satisfiable public-input and witness-side claims before any downstream settlement-consumer mismatch entered the story.

Failure-prevention checklist

  • Define one canonical proved effect object per batch and make both circuit and settlement code consume that exact object: row count, chunk boundaries, ordering, effect typing, and any subset metadata should all be part of the same authenticated security object.
  • Treat numRealTxs, processedCount, padding flags, batch-mode selectors, and similar counters as custody-critical inputs. If changing one of them changes which deposits are charged or which withdrawals are honored, it must be authenticated and tested like a treasury variable.
  • Keep credited balance creation coupled to backing-value recognition. A batch row should not be able to increase withdrawable internal balances unless the same authenticated effect set also proves the matching deposit, burn, fee payment, or reserve movement.
  • Prefer settlement paths that recompute or verify per-row backing conditions rather than trusting ambient proof already passed state. Proof validity, canonical ledger identity, and asset-moving authority should be treated as separate questions that only collapse once the protocol has actually proved they are the same object.
  • Commit to the settlement-facing ledger itself when possible: hash or otherwise bind the exact consumer-visible effect list, not just an upstream transition object from which the consumer later derives a narrower interpretation.
  • Add adversarial tests around every boundary: last counted row, first padded row, first row in next chunk, subset length = 0/1, and mixed batches where an uncharged deposit or release-producing row sits just beyond the consumer loop bound.
  • Force later withdrawal and redemption paths to re-check provenance assumptions. Internal credit should not become cash-out authority merely because some earlier proof-updated state variable says the balance exists.
  • Instrument reconciliation that compares proof-credited deposits, settled asset inflows, and resulting liabilities so mismatches surface before fabricated credit is widely withdrawn or rehypothecated.
  • Fail closed on boundary ambiguity during upgrades or migrations. If a new circuit version, padding rule, or settlement adapter changes batch interpretation, the system should pause rather than silently letting proof and consumer semantics drift.
  • Make cross-team ownership explicit. When proving logic and settlement logic live in different repositories or teams, someone still needs a single artifact that states the exact equivalence invariant both sides are required to preserve.

Audit prompts

  • What exact rows or effects did the proof authenticate, and where is that object serialized or committed?
  • What exact rows or effects did the runtime consumer actually charge for, settle, or release against real assets?
  • Can one credited row exist in proof-authenticated state while the asset-collection path for that row never runs because of a narrower runtime subset, padding rule, or chunk boundary?
  • Which variables decide these are the economically real rows, and are those variables themselves authenticated by the proof or merely supplied by runtime metadata?
  • Does any later withdrawal, redemption, or bridge release trust internal balances without independently proving that the originating row’s backing asset really entered the system?
  • Are state-transition tests and asset-settlement tests written separately in a way that would miss a divergence between proof-valid transition and economically settled transition?
  • If the batch includes padded rows, virtual rows, fee-only rows, or deferred-settlement rows, can any of them still mutate balances or entitlements that downstream code treats as withdrawable value?
  • During upgrades, where is the assertion that old and new circuits, adapters, and settlement loops still agree on batch width, row ordering, and effect semantics?
  • Can monitoring explain, per batch, why total credited deposits, total debits, and net liability movement match the externally observed asset flow?
  • If an attacker points to one later withdrawal, what exact earlier authenticated artifact proves the corresponding deposit or burn happened for that same credited balance?

Lessons that should already be standard

  • Proof verified is not a solvency statement by itself. The protocol is only safe when proof verification and asset settlement still refer to the same economically relevant effect set.
  • A valid proved batch exists is weaker than this proved batch is the canonical economic ledger, which is weaker than this accepted ledger already deserves withdrawal, release, or redemption authority.
  • Batch-boundary metadata is treasury logic. Counters, padding rules, and subset declarations deserve the same review intensity as withdrawal authorization code.
  • Internal balances are not harmless intermediate state. If later code lets them exit into real assets, then every path that can create them is a custody surface.
  • No admin is not a defense. Governance-renounced or deprecated proof systems are still live treasury surfaces while old proof-created state can still reach ordinary withdrawals, wrapper redemptions, or bridge-release sidecars.
  • Circuit correctness cannot rescue a settlement consumer that asks a different question. Many teams overinvest in proving soundness and underinvest in the glue code that turns proven state into money movement.
  • Equivalence tests across layers should be standard: every credited effect was settled, every settled effect was authenticated, and no runtime projection can narrow the proved batch without an explicit proven reason.
  • The safest design is usually the least interpretive one: settle the exact committed effect ledger rather than deriving a second execution subset after proof verification.
  • Upgrades that change row grouping, padding, or consumer adapters are not routine refactors. They are balance-sheet migrations and should be treated with pause plans, reconciliation, and shadow checks.

Where this pattern stops

  • Use proof-to-message-binding-failure when the decisive failure is that a verifier checked a trusted root or header without proving the specific message being executed actually lived under it. That family is about forged message membership under an authenticated commitment. This family is about a proof and its runtime consumer authenticating different effect sets even though the proof itself stayed valid.
  • Use bridge-verification-failure when the only safe claim is still the broad one that forged bridge truth became release authority and you cannot yet localize whether the break was message membership, source provenance, verifier independence, or some other subfamily.
  • Use witness-public-input-binding-failure when the proof statement itself was already too weak about which indexed state object, root, or command relation was being proven, before any later settlement or finalization consumer drifted. [[../../../incidents/proofs-verifiers/maci-1-0-processmessages-under-constrained-message-state-binding-coordinator-censorship-near-miss-2021-12-01|MACI 1.0 ProcessMessages]] is the useful boundary-setting contrast: it preserves the same proof-backed canonical outcome drifted from the public promise intuition, but the break began inside the proof statement rather than in a later proof-valid settlement consumer.
  • Use shared-standard-entrypoint-invariant-drift when the core issue is that inherited or sibling public entrypoints stopped sharing the same backing boundary after a standard-shaped call graph changed. There the mismatch is between public API surfaces and the moved invariant; here it is between a proof-authenticated transition and the separate asset-moving consumer of that transition.
  • Use issuance-redemption-solvency-asymmetry when claims are already being printed under arithmetic or reserve fiction even without any proof / settlement split. That family preserves issuance-side solvency asymmetry in general; this family preserves the narrower lesson that proof valid did not mean economically settled.
  • In short: this pattern begins once the proof system and the settlement consumer no longer bind the same economically relevant side effects, and it stops once the more precise story is instead about forged message membership, a weaker proof statement, broader bridge-truth failure, or a non-proof issuance bug.

Internal linkages

  • Best current incident exemplar: aztec-connect-processrollup-numrealtxs-proof-settlement-boundary-drain-2026-06-14.
  • Near-boundary contrast: witness-public-input-binding-failure — useful when the proof statement itself was already underbound because public-input truth and witness-side truth were never forced to be one object, as in Aztec 2.0, rather than the proof staying valid while the consumer settled a different effect set.
  • Adjacent proof-backed outcome family: proof-backed-outcome-integrity-failure — use it when the same proof accepted but the publicly authoritative result still drifted intuition is present, but the sharper preserved object is the canonical tally / command-result set rather than an economically settled effect ledger.
  • Boundary-setting outcome-integrity contrast: [[../../../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 same proof-backed canonical result can still be false intuition, but the decisive bug lived in the proof statement’s message-to-state binding rather than in a later proof-valid settlement consumer.
  • Adjacent authenticated-object family: proof-to-message-binding-failure — there the verifier fails to prove one specific message belonged under a trusted root; here the proof may be perfectly sound but the runtime consumer executes or charges for a different effect set than the proof authenticated.
  • Adjacent broad bridge family: bridge-verification-failure — useful when the same authenticated object detached from executable effect intuition appears in cross-chain verification paths.
  • Adjacent solvency family: issuance-redemption-solvency-asymmetry — useful when the exploitation theme is unbacked issuance later redeemed against real reserves, but without the specific proof-consumer split.
  • Positive-design companion: Proof effect truth as a single security object — what healthy proof-driven settlement should keep fused together before any credited balance becomes withdrawable.
  • Narrower committed-object companion: one committed settled-effects object — what exact committed ledger or consumer-facing object should keep proof-valid rows, state diffs, logs, and settlement-side interpretation from drifting apart.
  • Downstream exit-rail companion: no ambient internal balance trust — what later withdrawal, redemption, release, or claim paths should still require before treating internal state as redeemable value.
  • Residual-service companion: exit-only-residual-surface-discipline — use when the sharper healthy-side question is how a deprecated or sunset proof system should have narrowed its remaining withdrawals, wrapper sidecars, and bridge unwinds into a consciously bounded exit-only surface before governance walked away.
  • Decommissioning companion: decommissioning-authority-extinguishment-discipline — use when the next lifecycle question is how authority extinguishment and value-surface reduction should have been staged so an immutable legacy proof path did not retain funded liability semantics after support ended.
  • Useful contrast: shared-standard-entrypoint-invariant-drift — another system looks like one invariant but actually has two family, though the split there is between standard entrypoints and backing logic rather than between proof and settlement.

Control surface

Graph View

Backlinks