Cowrie Research

proof-backed-outcome-integrity-failure

12 min read

Proof-Backed Outcome-Integrity Failure / Canonical-Result Divergence

  • Name: proof-backed outcome-integrity failure / canonical-result divergence
  • Category: exploit pattern / proof-backed tally failure / canonical-result divergence / coordinator-censorship and finalization-integrity failure
  • Summary: This pattern appears when a proof-backed system verifies some batch, state transition, or command-processing relation, but the protocol never commits one exact canonical outcome object that says which commands counted, which indexed objects they were allowed to touch, why any commands were excluded, and what final published result those per-command decisions imply. The verifier can remain cryptographically correct while the public guarantee still fails, because the accepted proof only fixes a weaker relation than this is the one canonical tally / command-result set everyone must honor. In the sharpest cases, a coordinator can stay entirely inside the formal proof system while censoring valid votes, reclassifying commands as invalid, or publishing a proof-backed result whose political or semantic meaning was never uniquely bound.
  • What it is:
    • A protocol uses proofs to justify a tally, vote-processing round, allocation result, or other canonical outcome rather than a direct reserve-moving effect.
    • The system publicly promises something like every valid vote counts, the tally is uncensorable, the canonical command set is proof-backed, or this published result is the deterministic outcome of the proved batch.
    • The proof and the final published outcome are assumed to refer to the same command-result object.
    • In the vulnerable design, they do not: witness-side pairing, invalidation semantics, decoder assumptions, or finalization logic still leave room for more than one plausible what really counted story.
    • The verifier accepts a proof, but the protocol has only proved a weaker relation than the social or constitutional guarantee users think they bought.
  • Typical preconditions:
    • The protocol has a proof-backed tally, voting, allocation, batch-command, or canonical-result pipeline.
    • A coordinator, witness generator, or finalizer still controls some uncommitted pairing, ordering, invalidation bucket, or outcome reconstruction step.
    • Public semantics depend on per-command target-object identity, justified exclusion reasons, or deterministic finalization, but those facts are not all part of one authenticated outcome object.
    • Downstream users or contracts trust the final published result as authoritative even though the proof did not uniquely bind that exact result.
    • The thing at risk is politically, constitutionally, or semantically valuable even if it is not an immediate asset withdrawal.
  • Common vulnerable surfaces:
    • zk voting or anti-collusion tally systems
    • proof-backed batch command processors whose final result is a canonical recipient set, tally, or accepted-command list
    • offchain coordinator systems where witness-side arrays decide which indexed state object each command is actually evaluated against
    • proof-backed finalization code that treats batch verified as enough, then locally reconstructs which commands counted
    • systems with opaque invalid or rejected buckets that do not commit why exclusion was legitimate
    • proofs whose public promise is about canonical outcome integrity rather than direct reserve solvency
  • Exploit sequence:
    1. The attacker or malicious coordinator finds a place where the proof-backed system does not commit one exact command-result object.
    2. They use witness-side pairing, object substitution, ordering freedom, or ambiguous invalidation semantics to make a target command or vote look legitimately excludable.
    3. The proof still verifies, because it is only proving the weaker relation the system actually encoded.
    4. The finalizer or publisher outputs a tally, accepted-command set, or canonical result consistent with that weaker proved relation.
    5. Users observe a proof-backed result that appears authoritative, even though valid commands may have been censored or reinterpreted.
    6. The system’s headline guarantee fails without any need to break cryptography or bypass verifier code.
  • Variants:
    • Coordinator-censorship through object substitution — the coordinator pairs a real command with the wrong indexed object, making it fail a seemingly legitimate invalidity branch, as in MACI.
    • Opaque invalidation bucket drift — the system proves that some commands were invalid or excluded, but not the exact semantic reason those exclusions were allowed.
    • Finalizer-side canonical-result reconstruction — the proof authenticates a batch, but the final published result still depends on a decoder or finalizer choosing one interpretation after verification.
    • Outcome-publication ambiguity — two plausible final tallies or command-result sets can still be argued from one accepted proof because the committed outcome object is underbound.
    • Proof-backed constitutional failure — no funds move immediately, but governance, voting, or other canon-forming authority is still corrupted because the proof did not force the promised command semantics.

Three proof-backed outcome promotions reviewers should not collapse

  1. A proof-backed batch or state transition exists at all

    • A verifier returned success for some command-processing or tally-related object.
    • This is only the existence question: a proof-backed batch exists.

  2. That accepted proof fixes one canonical command-result object

    • The harder question is whether the proof uniquely binds which commands counted, which indexed objects they were matched against, which commands were excluded, and why those exclusions were legitimate.
    • This is where many proof-backed outcome systems quietly fail: they promote proof accepted into canonical result is now uniquely determined without ever proving that equivalence.

  3. That canonical command-result object deserves to become public final truth

    • Even once a proof-backed command-result object exists, the system still has to decide whether publication, tally finalization, governance effect, or downstream consumer interpretation is forced to use that exact object.
    • This is the finalization-authority question: the only result the system may publish is the one this committed object implies.

Healthy review gets much better once teams stop flattening those three promotions into one fuzzy event called the proof verified.

  • Detection heuristics:
    • Ask what exact committed object the protocol means when it says this is the canonical result of the batch / poll / round.
    • Diff commands present, commands paired to indexed objects, commands treated as invalid, and published final result as separate layers instead of assuming proof success fuses them.
    • Trace invalidity branches in order. If a command can already be marked invalid before target-object identity is fixed, exclusion semantics are suspect.
    • Treat witness-side ordering and per-command object arrays as authority surfaces, not just serialization details.
    • Test whether same public batch, same roots, different witness pairing can still yield a valid proof with a different tally or accepted-command set.
    • Ask whether the published result is a deterministic projection of the authenticated command-result object, or whether a coordinator still supplies interpretation after verification.
    • If the real problem is still inside the proof statement’s object binding rather than at the level of canonical result publication, the sharper note may be witness-public-input-binding-failure instead. If the proof is sound but a money-moving consumer settles a different effect ledger, the sharper note may be proof-to-effects-binding-failure instead.
  • Defenses:
    • Commit one canonical command-result object that includes command identity, indexed target-object identity, classification, and the resulting final published outcome or a uniquely determined projection of it.
    • Bind each command to the exact indexed object it is allowed to touch before any invalidity or exclusion branch can fire.
    • Make rejection and exclusion reasons explicit in the authenticated outcome object rather than leaving them as coordinator prose or finalizer folklore.
    • Treat witness ordering, decoder ordering, and finalization logic as part of the proof-security boundary.
    • Add cross-implementation tests for same proof, same final result so decoders and finalizers cannot invent their own canonical interpretation.
    • Treat proof-backed governance and tally integrity as seriously as solvency: no direct treasury drain is required for the security promise to be broken.

What sound design looks like

  • One proof-backed command-result object should survive end to end: witness construction, proof generation, verification, publication, and finalization should all inherit the same object or an unambiguous commitment to it.
  • One command should first be bound to one exact indexed target object before the system is allowed to ask whether the command succeeds, fails, or is invalid. If object identity is not fixed first, exclusion semantics are already too soft.
  • One invalidation story should exist. A command should be non-canonical only for an explicit allowed reason that is itself part of the authenticated outcome object, not because a coordinator found a witness-side pairing that made invalid convenient.
  • One published result should be the deterministic projection of the committed command-result object. A proof-backed tally or canonical result should not require coordinator-side reconstruction after verification.
  • One valid proof should imply one valid published result. If two honest-looking finalizers can derive two different canonical outcomes from the same accepted proof, the commitment is too weak.
  • One proof-backed constitutional promise should be machine-real. Claims like uncensorable, correct execution, or every valid vote counts should correspond to concrete constraints on command/object binding and finalization semantics rather than to operator etiquette.
  • One bad proof-backed outcome event should still be visible operationally: systems should publish enough committed artifact detail that outside reviewers can recompute why a command counted or failed, not just accept the coordinator’s summary.
  • High-signal incident:
    • [[../../../incidents/proofs-verifiers/maci-1-0-processmessages-under-constrained-message-state-binding-coordinator-censorship-near-miss-2021-12-01|MACI 1.0 ProcessMessages]] — the clean canonical exemplar: the coordinator could pair a real message with the wrong state leaf, drive it into an earlier invalidity branch, and still obtain a valid proof for a censored batch result, because the system had not committed one exact this message acted on this indexed voter object for this allowed reason outcome object.

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 authenticated object that records command identity, target-object identity, classification, and resulting canonical outcome.
  • Bind each command to the exact indexed object it is allowed to touch before any invalidity, replay, or exclusion branch classifies it.
  • Treat witness ordering, decoder ordering, and command-pairing arrays as authority surfaces. If ordering decides which object a command is evaluated against, it is part of the proof-security boundary.
  • Make exclusion reasons explicit and machine-checkable. A command should not disappear into one opaque invalid bucket that can hide coordinator censorship.
  • Require published final results to be deterministic projections of the committed command-result object. Finalization code should not improvise extra interpretation after proof verification.
  • Add negative tests for same public batch, different witness pairing, same proof, different finalizer, and same commands, different invalidity explanation.
  • Re-audit outcome semantics after batching refactors, witness-layout optimizations, and intermediate-root changes. Proof-backed censorship bugs often re-enter through transport-detail assumptions.
  • Keep human-facing guarantees machine-mapped. If the product promises uncensorable or correct execution, reviewers should be able to name the exact constraints and committed artifacts that make those promises true.
  • 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 authenticated object records which commands counted and why any excluded commands were allowed to be excluded?
  • Where is each command forced 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 valid proof with a different final result?
  • If a command becomes invalid, what proves that the invalidity arose from the command’s intrinsic rule violation rather than from object substitution or array pairing drift?
  • Is the published final tally or accepted-command set uniquely derivable from the committed command-result object, or does some finalizer still supply interpretation after verification?
  • Do rejection categories exist as explicit authenticated semantics, or are excluded commands collapsed into one opaque bucket that can hide arbitrary censorship?
  • What test proves same accepted proof => same published result across implementations and edge-case ordering?
  • If a user disputes the result, what exact artifact can they inspect to verify that their command was evaluated against the right indexed object and excluded only for an allowed reason?

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.
  • Proof verified is weaker than canonical command-result object is fixed, which is weaker than the final published result is uniquely determined by that object.
  • Exclusion semantics are security semantics. This vote did not count deserves the same rigor as 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.
  • Governance and tally systems need the same design discipline as money-moving 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, justified invalidation, and finalization semantics are explicit proof truth.
  • The safest proof-backed outcome systems are boring at finalization time: one proof, one committed command-result object, one published result.

Where this pattern stops

  • Use witness-public-input-binding-failure when the decisive failure is still primarily inside the proof statement itself because public-state truth and witness-side object identity were never forced to match. MACI still belongs there as the sharper statement-level family.
  • Use this note when the preserved lesson is one layer broader: the system failed to commit one canonical command-result object that uniquely determined what the proof-backed published result had to be.
  • Use proof-to-effects-binding-failure when the proof may have been sound but a downstream money-moving consumer settled a different effect ledger than the proof authenticated. That family is about economic settlement drift; this family is about proof-backed canonical outcome drift.
  • Use canonical-outcome-commitment-and-finalization-discipline when the question is no longer what went wrong? but what exact committed canonical-result object should a healthy tally or finalization system have used instead.

Internal linkages

Control surface

Graph View

Backlinks