Cowrie Research

canonical-outcome-commitment-and-finalization-discipline

14 min read

Canonical Outcome Commitment and Finalization Discipline / One Committed Finalized-Command Set

  • Name: canonical outcome commitment and finalization discipline / one committed finalized-command set
  • Category: proof-system reference / outcome-integrity design note / tally-finalization checklist / proof-backed governance and voting reference
  • Summary: Proof-backed voting, tallying, allocation, and command-processing systems are only as trustworthy as the exact outcome object they force every layer to share. A healthy design does not stop at the proof verified. It commits one canonical set of command applications, justified invalidations, intermediate state updates, and final published results, then forces coordinators, decoders, and finalization code to honor that same object. This note exists to make the non-cashflow sibling of proof effect truth as a single security object explicit: when the thing at risk is canonical outcome truth rather than immediate reserve solvency, the protocol still needs one committed object that says which commands counted, which commands were excluded, why they were excluded, and which indexed state objects those decisions were allowed to touch.
  • Why this note exists:
    • Proof-backed systems can fail catastrophically without draining a treasury. If a coordinator can stay inside a valid proof while censoring votes, reclassifying commands, or mutating the wrong indexed state objects, the system’s public guarantee is already broken.
    • The recurring design mistake is to commit some batch was processed while leaving the meaning of which commands really counted or which exclusions were legitimate to coordinator-selected witness pairing, decoder folklore, or finalizer-side reconstruction.
    • The analytical question is narrower than the broad proof effect truth note and cleaner than a raw incident postmortem: what exact committed outcome object keeps proof validity, command semantics, and published final result fused together?

Three canonical-outcome promotions healthy systems should keep separate

  1. Some proof-backed batch or command-result artifact exists at all

    • A coordinator processed a batch, a verifier accepted a proof, some invalidation list was produced, or a tally publisher has an artifact that looks like a completed round.
    • This is only the existence question: some proof-adjacent outcome artifact exists.

  2. That artifact deserves to count as canonical command-result truth for this exact round

    • The harder question is whether the artifact already commits which commands were present, which indexed objects they were allowed to touch, which commands were excluded, why those exclusions were legitimate, and how intermediate state moved from one step to the next.
    • This is the semantic-truth question: the accepted artifact really is the one canonical command-result object the public promise names.

  3. That accepted command-result truth deserves downstream tally, publication, or finalization authority

    • Even a proof-valid batch should not automatically mean publish this tally, treat these commands as canonical, or let this coordinator's interpretation become constitutional truth unless finalization is forced to consume that same committed object.
    • This is the finalization-authority question: why is this accepted outcome artifact allowed to become the one public result everyone must honor?

Healthy review gets much better once teams stop flattening those three promotions into one vague event called the proof verified or the tally was processed.

What this note is trying to preserve

  • A proof-backed outcome system should be able to point to one canonical finalized-command object.
  • That object should identify:
    • which commands, messages, votes, or actions were processed
    • which exact indexed state objects they were allowed to touch
    • which commands were accepted, rejected, or invalidated
    • the reason each rejection or invalidation was allowed to happen
    • the final published outcome derived from those per-command decisions
  • The finalizer, coordinator, tally publisher, or downstream consumer should not be free to rebuild a narrower or different interpretation after proof verification.

What a committed canonical outcome object usually needs to contain

1. Command identity and ordering

  • The object should make clear which commands were present and in what order or batch position they were processed.
  • If ordering, deduplication, replay handling, or latest message wins semantics matter, those rules belong inside the committed object rather than in offchain coordinator etiquette.

2. Indexed target-object binding

  • Every command that claims to act on voter state leaf i, account j, note k, or another indexed object should be bound to that exact object before validity branching or classification can weaken the relationship.
  • A command should not become invalid because the coordinator first paired it with the wrong leaf and then proved the resulting invalidity.
  • Proof-state object unification and indexed-binding discipline is the sharper companion when the real question is how to force this identity at the statement level.

3. Justified invalidation / exclusion reasons

  • If a command is excluded, invalidated, or treated as non-canonical, the outcome object should commit the rule that allowed that classification.
  • This message was invalid is too weak if the proof does not also force that invalidity to arise from the right object’s signature failure, nonce failure, epoch mismatch, voice-credit limit, or other intrinsic reason.
  • Systems are safer when invalidity is a committed outcome attribute, not a coordinator narrative about why the command did not count.

4. Intermediate-state continuity

  • Batch-processing systems often update intermediate roots, tallies, or local command state step by step.
  • The outcome object should preserve how each accepted or rejected command transformed the prior committed state into the next committed state.
  • If intermediate-root handling is informal, final published outcome can drift away from the actual per-command semantics the proof was supposed to enforce.

5. Published final result

  • The thing users and contracts ultimately honor — tally totals, winning option, accepted command set, allocation output, or canonical final state — should either be part of the committed outcome object or be mechanically and uniquely derived from it.
  • The safe pattern is not the coordinator can explain how we got here; it is the final published outcome is the unavoidable projection of the committed command-result object.

What sound design looks like

  • One committed command-result object travels end to end.
    • Witness construction, proof generation, verification, tally publication, and finalization all inherit the same command/result object or a tight commitment to it.
    • If one layer only knows batch succeeded while another locally decides which commands really counted, the design is already brittle.
  • Per-command target binding happens before branching.
    • A command should first prove this is the indexed state object I am allowed to touch, then prove whether it succeeds or fails against that object.
    • This blocks the classic coordinator trick of substituting a convenient sibling object and turning the resulting mismatch into a supposedly legitimate exclusion.
  • Invalidity reasons are canonical, not ambient.
    • The published outcome should distinguish command was invalid for an allowed reason from command was made to look invalid by witness-side substitution or local reinterpretation.
    • Exclusion is only legitimate when the exact invalidity condition was already inside the authenticated outcome object.
  • Finalization is commitment-first, not interpretation-first.
    • The contract, coordinator, or downstream application should finalize one committed result object rather than reconstructing the canonical outcome from logs, local arrays, or decoder folklore.
    • one committed settled-effects object is the money-moving sibling; this note keeps the same discipline for politically or semantically authoritative outcomes.
  • Outcome publication should be uniquely derivable.
    • If two coordinators can publish different plausible tallies or command sets from the same accepted proof, the proof did not commit enough outcome truth.

Useful positive design shapes

1. Command-first, object-first processing

  • Prove command c acts on indexed object o under committed root r, then apply the command, then commit the next root and the resulting classification.
  • The important move is chronological: object identity becomes statement truth before success/failure classification becomes branch truth.
  • MACI issue #320 is useful precisely because it sketches this healthier shape in concrete terms: prove membership of the leaf to operate on against the current or prior intermediate root, then apply the command to that exact leaf.

2. Committed invalidation ledger

  • Outcome systems are healthier when the proof commits not just accepted commands, but also rejected commands and the specific rejection code or semantic bucket that made them non-canonical.
  • The reusable lesson is that exclusion semantics are part of canonical outcome truth, not mere debugging metadata.
  • A committed invalidation ledger makes it harder for coordinators to hide arbitrary censorship inside an opaque invalid bucket.

3. Final result as a deterministic projection

  • Tally totals, accepted recipient sets, and other final published results should be deterministic projections of the committed per-command outcome object.
  • The clean question is: if a user disputes the final published result, what committed command-result object can they point to that leaves no room for finalizer-side reinterpretation?

Design questions worth asking first

  • What exact object does the protocol mean when it says this is the canonical outcome of the batch / poll / round?
  • Does that object already identify which commands counted, which commands did not count, and why?
  • Where is the proof forcing each command onto the exact indexed object the public semantics name before any invalidity branch or exclusion decision can fire?
  • Is the published final tally or accepted command set uniquely derivable from the committed outcome object, or is some later coordinator interpretation still needed?
  • Can a command become non-canonical because of witness-side substitution, local array pairing, or decoder-side reconstruction rather than because of an intrinsic rule violation?
  • If the same proof is replayed through a different coordinator or finalizer implementation, do users necessarily get the same canonical published result?

Red flags

  • The proof shows the batch is consistent, and the coordinator knows which messages really count
  • Invalid commands are just an implementation detail
  • The final tally is derived offchain, but everyone honest will derive the same result
  • That leaf / account array is only witness plumbing
  • The proof verifies, so exclusion semantics are automatically correct
  • We can explain why this command did not count without one committed object showing that explanation was the only permitted one

Failure-prevention checklist

  • Commit one canonical command-result object for every proof-backed tally, allocation, or batch-finalization flow. Reviewers should be able to point to the exact committed object that records command identity, target-object identity, classification, and resulting outcome.
  • Bind each command to the exact indexed object it is allowed to touch before any invalidity, replay, or exclusion branch can classify it. If a message carries stateIndex, prove that leaf membership and identity first.
  • Treat witness ordering, decoder ordering, and command pairing arrays as authority surfaces. Any array whose ordering decides which state object a command is evaluated against belongs inside the same review boundary as the circuit.
  • Make rejection and exclusion reasons explicit in the authenticated outcome object. A coordinator should not be able to hide censorship inside an undifferentiated invalid bucket.
  • Require published final results to be deterministic projections of the committed command-result object. Finalization code should not improvise extra interpretation layers after proof verification.
  • Add negative tests that hold public messages and roots fixed while permuting witness-side target objects, path elements, or per-command arrays. Proof generation should fail rather than silently produce a different canonical result.
  • Add same proof, same final result tests across multiple decoders, coordinators, or finalizer implementations. If one accepted proof can lead to multiple plausible outcomes, the commitment is too weak.
  • Re-audit outcome semantics after batching refactors, performance optimizations, and intermediate-root changes. Proof-backed censorship bugs often enter through transport detail assumptions rather than flashy cryptographic rewrites.
  • Keep human-facing promises machine-mapped. Claims like uncensorable, correct execution, or every valid vote counts should each correspond to concrete constraints on command/object binding and exclusion semantics.
  • Publish enough outcome artifact detail that external reviewers can recompute the final result from the committed object rather than trusting coordinator prose.

Audit prompts

  • What exact committed object records which commands counted and why any excluded commands were allowed to be excluded?
  • Where is the proof forcing each command onto the exact indexed object the public semantics promise, and does that binding happen before invalidity or exclusion branching?
  • Can a coordinator permute witness-side leaves, accounts, or paths while keeping public roots and commands fixed and still obtain a proof with a different final outcome?
  • If a command becomes invalid, what proves that the invalidity arose from that command’s intrinsic rule violation rather than from being compared against the wrong state object?
  • Is the published final tally or accepted-command set uniquely derivable from the committed outcome object, or does some decoder or operator still supply uncommitted interpretation?
  • Do rejection categories exist as explicit committed semantics, or are excluded commands all collapsed into one opaque bucket that can hide arbitrary censorship?
  • What test proves same committed batch => same published final result across implementations and edge-case ordering?
  • Are intermediate roots and per-step state updates part of the authenticated outcome story, or can later finalization quietly forget which exact path produced the final root or tally?
  • If a user disputes the result, what concrete artifact can they inspect to verify that their command was evaluated against the right indexed object and excluded only for an allowed reason?
  • Which social guarantees are still aspirational prose rather than constraint-level facts inside the proof and finalization pipeline?

Lessons that should already be standard

  • A proof-backed outcome can be wrong without the cryptography being broken. If the committed outcome object is underbound, the verifier can accept a result that violates the system’s public promise.
  • Exclusion semantics are security semantics. This vote did not count or this command was invalid should be treated with the same rigor teams apply to this withdrawal was authorized.
  • Witness arrays and decoder orderings are often hidden control planes. The moment they decide which indexed object a command is tested against, they become outcome-critical authority.
  • Valid proof and correct canonical result are not synonyms unless the protocol forces finalization to consume one committed command-result object.
  • Governance and tally systems need the same design discipline as balance-sheet systems: one authenticated object, one deterministic consumer interpretation, and no room for local folklore at the last mile.
  • Human-facing guarantees like uncensorability only become real when command/object binding and justified invalidation are explicit statement truth.
  • The safest outcome systems are boring at finalization time: one proof, one committed outcome object, one published result.

How to use this note with the exploit corpus

  • Start here when the question is what exact committed object should force a proof-backed tally, vote-processing, or canonical-result system to publish one unambiguous outcome?
  • Pair it with Proof effect truth as a single security object when the broader question is how proof-backed systems keep economically or politically authoritative effects fused across proof, consumer, and finalization layers.
  • Pair it with one committed settled-effects object when the sharper sibling question is the money-moving version: what exact committed ledger should bind proof and settlement for balances and withdrawals.
  • Pair it with Proof-state object unification and indexed-binding discipline when the sharper statement-level question is how one command should have been forced onto one exact indexed object before any branch could weaken that identity.
  • Use public-input binding failure when the decisive failure lived inside the proof statement itself because public-state truth and witness-side state or object identity were never forced to match.
  • Use Proof-backed outcome-integrity failure when the sharper negative-family question is the same one this note answers positively: the system never committed one exact command-result object that uniquely determined what the proof-backed canonical result had to be.
  • Use Proof-to-effects binding failure when the proof may have been sound, but a downstream consumer still finalized or settled a different effect set than the proof authenticated.

Internal linkages

Control surface

Graph View

Backlinks