Cowrie Research

effect-ledger-commitment

14 min read

Effect-Ledger Commitment / One Committed Settled-Effects Object

  • Name: effect-ledger commitment / one committed settled-effects object
  • Category: proof-system reference / settlement-object design note / batch-commitment checklist / rollup solvency reference
  • Summary: Healthy proof-driven settlement should not make the runtime consumer reconstruct for itself which rows, logs, messages, or state deltas were the economically real part of a proved batch. The safer shape is to commit one explicit effect ledger and make every later consumer settle, release, or withdraw against that same object. The recurring review mistake this note tries to stop is flattening three different promotions into one vague the batch commitment exists moment: some committed batch object exists, that committed object already fixes settlement truth for this exact effect set, and that settled object still deserves later cash-out or release authority. This note exists to make the what exact thing got committed? layer more concrete than the broader proof effect truth note, and to give the corpus a cleaner positive-design answer to Aztec-style proof/settlement drift.
  • Why this note exists:
    • Proof valid is still too hand-wavy unless the system can point to one committed object that both the prover and the money-moving consumer are forced to interpret the same way.
    • Many systems have commitments, roots, logs, state diffs, or metadata hashes, but only some of those commitments actually bind the exact economically relevant effects later honored by settlement and withdrawal paths.
    • The useful analytical question is often narrower than is the proving system sound? and sharper than is the consumer buggy?: what committed effect object prevents those two layers from drifting apart?

What this note is trying to preserve

  • A proof system is healthiest when it does not merely prove some batch happened.
  • It should also leave one machine-readable commitment to the exact settled-effects object: the rows, state diffs, messages, logs, deposit consumptions, and balance creations that later count as economic truth.
  • The runtime consumer should settle against that object directly, or against a canonical commitment to it, instead of rebuilding a narrower interpretation from convenience counters, local decoding, or operator-supplied side data.

Three settled-effects promotions healthy systems should not collapse

  1. Was there one canonical committed batch or effect object at all?

    • Many systems stop too early at the proof committed something.
    • That is only the existence question. A batch root, transition hash, or DA commitment is not yet a settlement answer unless reviewers can say what exact consumer-facing effect object it commits.

  2. Did that committed object already define which outputs were economically settled?

    • The batch was committed is weaker than the committed object already fixed which credits, debits, burns, logs, messages, and row boundaries count as real settlement truth.
    • This is the settlement-truth question, and it is where subset counters, padding flags, grouping hints, and backing-side events stop being metadata and become treasury logic.

  3. Can later consumers and exits still point back to that same settled object?

    • Even a clean committed effect ledger is not enough if later settlement adapters, withdrawal paths, or bridge-release rails only trust ambient balances or a reconstructed local projection.
    • This is the cash-out question: healthy systems keep committed effect object, economically settled object, and later cashable object fused tightly enough that they never become three different stories.

What a committed settled-effects object usually needs to contain

1. Credited state changes

  • Any row that creates withdrawable balance, spendable note state, redeemable claim, or bridge-release authority belongs inside the committed effect object.
  • If a state transition can later cash out, it cannot live only in prover-local witness logic or transient runtime memory.

2. Backing-side effects

  • The same object should also bind the backing event for any credited value: deposit receipt, burn consumption, fee charge, reserve debit, or another conserved source of value.
  • A ledger that commits only to credits while leaving backing events to a different pass is already split at the solvency boundary.

3. Ordering and boundaries

  • The committed object should make row order, grouping, and boundaries explicit enough that a later consumer cannot silently say only the first k rows were economically real unless that same subset rule is itself committed and proven safe.
  • Indexing, padding, and subgroup semantics are part of custody truth once they affect what gets settled.

4. Consumer-relevant outputs

  • If downstream consumers act on state diffs, L2→L1 logs, withdrawal leaves, bridge messages, or batch metadata, those exact outputs should be committed in the same object or in tightly coupled commitments that the proof binds together.
  • The safe pattern is not the consumer can probably reconstruct it; it is the consumer is forced to consume the committed version.

5. Withdrawal-facing truth

  • Exit rails should either consume the same committed effect object directly or consume balances whose creation path was already inseparable from that committed object.
  • The system is safer when credited and cashable are two names for the same proved object, not two stages humans assume stay aligned.

What sound design looks like

  • Committed-object authority stays staged instead of collapsing into one batch root.
    • Healthy systems keep committed effect object exists, that object already fixes settlement truth, and that settled object still deserves later withdrawal or release authority as separate promotions with explicit provenance at each step.
    • The fastest way to hide proof / settlement drift is to narrate all three as one the batch was committed fact.
  • One canonical commitment travels across layers.
    • Prover, verifier, DA publication, settlement consumer, and withdrawal path all point back to one committed settled-effects object or to a small set of commitments whose equivalence is itself enforced.
  • Consumers do not narrow by folklore.
    • Counters, metadata, or local decoder heuristics cannot silently shrink the economically honored subset after proof verification.
  • Backing and credit stay in the same object.
    • If a row can mint balance, the committed ledger already binds the asset intake or liability consumption that makes that balance real.
  • Consumer inputs are commitment-first, not reconstruction-first.
    • The settlement layer should prefer consume this committed effect root / hash / log root / state-diff object over recompute what we think the meaningful rows were.
  • Withdrawal paths inherit committed truth instead of re-trusting ambient state.
    • The cleanest systems make later exits depend on objects whose backing was already fused to their creation.

Useful positive design shapes

1. Batch commitments that explicitly include consumer-relevant outputs

  • ZKsync’s pubdata documentation is useful here because it says out loud that batch commitments include consumer-relevant data like state diffs and L2→L1 log roots, rather than treating those as merely off-to-the-side implementation detail.
  • The reusable point is not copy ZKsync; it is make the economically relevant outputs first-class commitment material.
  • A system is easier to reason about when state diffs, message roots, and other settlement-facing objects are explicitly hashed into what the batch commits to.

2. Proof-covered handoff from one validator layer to another

  • ZK Stack validium docs are useful because they describe a proof-covered handoff from L2DAValidator to L1DAValidator via L2→L1 logs, instead of pretending the DA commitment can remain an informal side channel.
  • The important design move is that the commitment to pubdata is itself passed through a proof-covered path before later inclusion checks happen on L1.
  • That does not make every possible consumer bug disappear, but it is the right architectural instinct: move the handoff object into the authenticated path.

3. Canonical state commitments as the baseline discipline

  • Starknet’s state-commitment docs are useful as a baseline contrast because they make the canonical committed state object legible: one state commitment built from the contract trie root and class trie root.
  • The reusable lesson is broader than Starknet itself: once a protocol can point to one canonical committed state object, downstream reasoning gets cleaner about what later transitions, messages, and withdrawals are supposed to inherit.
  • A state commitment alone is not enough to solve all proof-to-effects problems, but the absence of a crisp canonical committed object usually makes those problems worse.

Design questions worth asking first

  • What exact object can the protocol point to when it says these are the settled economic effects of this batch?
  • Is that object explicitly committed, or merely reconstructed from witness logic, counters, and consumer-side interpretation?
  • Does the committed object include both credited value creation and the backing events that justify it?
  • Is the protocol quietly collapsing batch committed, economically settled, and later cashable into one phrase without proving those are actually the same object?
  • Can the runtime consumer honor a narrower subset than the commitment without that narrowing rule being part of the committed object itself?
  • If a later withdrawal succeeds, what committed object proves the balance it consumes was already economically settled?
  • If one row just outside the consumer’s current loop bound becomes value-creating, does the architecture fail closed because the commitment no longer matches, or does the consumer simply ignore the discrepancy?

Red flags

  • The proof authenticates the batch, and the consumer knows what part matters
  • That subset counter is only metadata
  • The DA commitment is separate, but trust us the rows line up
  • Withdrawals just use ordinary balances, so they do not need to care how those balances were committed
  • commitments exist, but only to a broader object while the economic consumer still acts on a narrower local interpretation
  • logs, messages, or state diffs that drive settlement are published, but not clearly bound to the exact object the proof authenticated

Failure-prevention checklist

  • Commit one explicit settled-effects object that already contains every economically relevant credit, debit, fee, burn, withdrawal authorization, and backing-side event the runtime will honor. If humans still need to explain which proved rows were the real ones, the commitment is not yet doing enough.
  • Review three separate promotions every time: the batch commitment exists, that commitment already fixed settlement truth, and later exits still consume that same settled object. Healthy systems prove all three instead of assuming one implies the next.
  • Bind subset-defining metadata into the same committed object. Row counts, padding markers, grouping hints, chunk boundaries, and real versus non-real classifiers are custody-critical once they can change what the consumer settles.
  • Include consumer-facing outputs directly in the committed object or in tightly coupled commitments whose equivalence is enforced: state diffs, withdrawal leaves, bridge messages, DA roots, and log roots should not live as merely parallel artifacts.
  • Keep credit and backing inseparable inside commitment material. A row that creates cashable state must be committed alongside the deposit receipt, burn consumption, reserve movement, or other conserved source that makes the credit solvent.
  • Make settlement APIs commitment-first. Consumers should ingest a committed effect root, committed diff object, or another canonical settled-effects artifact rather than rebuilding meaning from operator-supplied side data and local decoder assumptions.
  • Refuse consumer-only narrowing rules unless the same rule is itself committed and proven safe. If the runtime wants to ignore padded rows or stop at k entries, that bound belongs inside the authenticated object.
  • Ensure later exit rails can still point back to the same committed effect object or to balances whose creation path was already inseparable from it. A withdrawal should never depend on ambient internal credit whose committed provenance has been lost.
  • Add equivalence tests that mutate allegedly irrelevant rows, counters, grouping metadata, and downstream withdrawal preconditions; require the commitment mismatch or downstream invariant failure to trigger before any cashable state appears.
  • Re-run those tests across prover upgrades, decoder rewrites, batch-format changes, DA-path swaps, compression tweaks, and migration tooling. Commitment drift often appears when teams optimize plumbing rather than changing the visible proving claim.
  • Keep one review artifact that states the full joined invariant explicitly: prover, verifier, DA publication, settlement consumer, and exit path all inherit one committed settled-effects object.

Audit prompts

  • What exact object is the protocol claiming to commit when it says these are the economically settled effects of this batch?
  • Where does the design prove the stronger step from committed object exists to that object already fixes settlement truth, rather than leaving the consumer to improvise which rows and outputs really count?
  • Does that committed object already contain both value-creating rows and the backing-side events that justify them, or are those truths split across parallel artifacts?
  • Which fields can narrow, reorder, or classify the subset the runtime treats as economically real after proof verification, and are those fields themselves committed as custody truth?
  • If the consumer settles state diffs, messages, withdrawal leaves, or DA data, where is the assertion that those exact outputs are bound to the same committed effect object the proof authenticated?
  • Can the consumer reconstruct a narrower local interpretation from counters, padding rules, or decoder heuristics without any commitment mismatch firing?
  • If a later withdrawal succeeds, what committed object proves the consumed balance was already part of the settled-effects ledger rather than an ambient internal credit?
  • During upgrades, where is the assertion that prover semantics, batch commitments, decoder semantics, DA publication, settlement semantics, and exit semantics still describe the same effect object?
  • What test proves that mutating one supposedly non-economic row, log, grouping field, or downstream cash-out precondition cannot create cashable value while the commitment still appears valid?
  • Are there any published logs, roots, or messages that operators or indexers treat as settlement truth even though they are not clearly bound to the same object the verifier authenticated?
  • If reviewers asked why proof valid, consumer settled, and later exit cashable mean the same thing here, what single committed object would you point to?

Lessons that should already be standard

  • A batch commitment is only protective if it commits the object the money-moving consumer actually honors. Commitments to broader computation are weak comfort when settlement still acts on a narrower folklore subset.
  • Teams should keep three claims separate: the batch commitment exists, that commitment already fixed settlement truth, and later exits still consume that same settled object. Most proof/settlement incidents happen when one of those promotions was assumed instead of proved.
  • Metadata stops being metadata once it can change who gets credited, debited, or paid out. Row counts, padding flags, and grouping boundaries become treasury policy the moment they can narrow settlement.
  • Credit-side commitments without backing-side commitments are not solvency artifacts. They are just organized ways to remember unproven liabilities.
  • The consumer can reconstruct it is one of the most dangerous sentences in proof-driven architecture. Reconstruction is exactly where proof truth and money truth start to fork.
  • Exit safety depends on commitment reachability. If later withdrawals cannot still point back to the committed settled-effects object, the protocol is trusting ambient state and invisible history again.
  • The healthiest systems make the commitment boringly legible: one object, one economic interpretation, one consumer story, and no room for a local runtime to improvise what the proof must have meant.

How to use this note with the exploit corpus

  • Start here when the design question is what exact committed object should force proof and settlement to talk about the same economically relevant effects?
  • Pair it with Proof effect truth as a single security object when the broader question is what a healthy proof-driven settlement architecture should keep fused together.
  • Pair it with no ambient internal balance trust when the sharper downstream question is what later withdrawal, redemption, or release paths should still consume before they cash out internally credited state.
  • Drop into Proof-to-effects binding failure when the failure mode is that the proof and the runtime consumer did not end up bound to the same settled-effects object.
  • Compare against proof-to-message-binding-failure when the sharper issue is not wrong settled-effects object but wrong message membership under a committed root.
  • Compare against shared-standard-entrypoint-invariant-drift when the same architectural smell appears outside proving systems: one public surface still looks canonical after the real backing boundary moved elsewhere.

Internal linkages

Control surface

Graph View

Backlinks