Cowrie Research

trusted-setup-finalization-and-verifier-family-quarantine

17 min read

Trusted-Setup Finalization and Verifier-Family Quarantine Discipline

  • Name: trusted-setup finalization and verifier-family quarantine discipline
  • Category: proof-system release reference / trusted-setup hygiene checklist / verifier-family quarantine note / zk deployment gating discipline
  • Summary: Healthy zk teams do not treat trusted setup as one ceremony happened somewhere or we exported a verifier JSON and deployed it. They keep one explicit finalization discipline from circuit-specific setup through funded rollout: prove the verifier came from a completed setup, prove the deployed constants match that finalized artifact, classify unsafe artifact families before funding, and treat one malformed verifier fingerprint as one fleet-level quarantine object rather than as a one-contract postmortem. This note exists to preserve the positive-design target behind Veil Cash and Foom Cash: the moment a verifier smells like a zero-contribution placeholder family, the response should already know how to block release, sweep siblings, and bound reachable value.
  • Why this note exists:
    • Verification-key independence collapse preserves the exploit family where the deployed verification key already destroyed soundness.
    • Verification-key statement inventory and asset-reachability discipline preserves the live-authority map question: which verifiers, consumers, and balances are still in scope once a key is known bad.
    • Exact production artifact attestation and rollback discipline preserves the broader source-to-runtime release-integrity discipline across many software families.
    • What deserves its own proof-specific note is the narrower release-and-response layer between those ideas: how trusted-setup completion becomes a hard funded-deploy gate, how known-bad verifier artifact families are fingerprinted early, and how one live malformed-key discovery should automatically widen into one sibling-deployment quarantine and rescue exercise.

Fast classifier: which setup-hygiene failure are you trying to make impossible?

  • we have a verifier file, but not proof of finalized setup — operators can point to a verifier JSON or Solidity verifier, but not to the exact completed circuit-specific contribution sequence that made the key safe. Veil Cash is the clean funded exploit.
  • the artifact lineage exists, but it still ends in a quarantined family — teams can narrate a build path, yet the live verifier still fingerprints as a zero-contribution *_0000.zkey, placeholder constants, identical ceremony outputs, or another never fund this family. Foom Cash is the clean multi-chain near miss.
  • one malformed fingerprint should widen into many contracts immediately — the first discovery is not the first loss surface. The real question is which sibling deployments share the same verifier family and which reachable balances need rescue first.
  • the ceremony was done once, but nobody encoded what funded rollout depends on — there is no machine-checkable handoff from finalized setup artifact to deployed verifier constants to funded-environment approval.
  • Use this note when the sharper design question is what should healthy zk deployment gating and family-level quarantine look like between trusted setup and live funded verifier authority?

What this note means by finalization discipline and verifier-family quarantine

  • Trusted-setup finalization discipline means a funded verifier cannot ship until the team can prove the exact circuit-specific setup reached its completed state and that the deployed verification key or constants were derived from that finalized artifact rather than from an intermediate or placeholder output.
  • Verifier-family quarantine means unsafe verifier fingerprints are treated as classes, not anecdotes. Zero-contribution *_0000.zkey outputs, placeholder verification_key.json exports, copied test constants, or obvious parameter-degeneracy shapes like gamma == delta == G2 generator are all family labels that should block rollout and later drive emergency sibling sweeps.
  • Discipline means these are not just blog-post lessons. CI, deployment, funding approval, live inventory, and incident response all know the same artifact families and the same release gates.
  • The core rule is simple: no verifier should become funded authority until its finalization state is machine-checkable, and no malformed verifier fingerprint should ever be triaged as a one-address problem first.

Three setup-authority promotions healthy zk release flows should keep separate

  1. A setup or verifier artifact exists at all
  • A circuit-specific zkey, exported verification key, generated Solidity verifier, or copied verifier JSON exists somewhere in the build and deployment pipeline.
  • This is only the existence question: there is some proof-side artifact people could try to fund or reuse.
  1. That artifact deserves to count as finalized-safe verifier truth for this exact statement
  • The artifact still has to prove it came from the completed setup state the proof system requires, rather than from a placeholder, pre-finalization, copied-fixture, or otherwise quarantined family.
  • This is the finalized-truth question: this artifact really is the finalized verifier lineage for the statement we think it encodes.
  1. That finalized-safe verifier truth deserves funded authority and non-quarantined status here
  • Even a finalized verifier should not automatically inherit unbounded production authority. The funded rollout still has to decide how much value this verifier can guard, which sibling deployments share its blast radius, and what should happen if its family is later reclassified as unsafe.
  • This is the authority-budget question: this finalized verifier really deserves this much live economic reach and this family really is cleared to carry it.

Healthy zk release operations keep those promotions distinct instead of collapsing them into one vague the verifier artifact exists, so production can ship story.

The six joints a healthy trusted-setup release flow should keep fused

1. Finalized setup state, not just setup participation

  • The team should be able to show the exact circuit-specific setup lifecycle: prepared phase input, initial circuit zkey or equivalent starting artifact, each required contribution or randomization step, and the finalized proving / verification artifact actually used for export.
  • We ran a ceremony is not a release object.
  • The key question is whether the verifier-bearing artifact was exported before or after the step that makes the critical parameters independent.

2. Unsafe artifact-family fingerprinting before deployment

  • Known-bad artifact classes should be machine-identifiable before anything is funded.
  • In the Groth16 / snarkjs cases, a zero-contribution *_0000.zkey and the corresponding gamma == delta == G2 generator verifier shape are not things reviewers might notice later; they are release blockers.
  • Healthy teams maintain a small denylist of proof-system-specific artifact families and recognizable constant fingerprints that should never pass funded-deploy review.

3. Deployed-constant equivalence to finalized artifact

  • A finalized artifact is not enough if deployed verifier constants can still drift through copy-paste, stale export directories, manual edits, or sibling-project reuse.
  • The release object has to prove that the onchain verifier contract or embedded constants match the finalized artifact exactly.
  • This is the proof-system-specific bridge between ceremony hygiene and real custody authority.

4. Funded rollout gating

  • A verifier should not move from cryptography artifact to funded authority implicitly.
  • There should be an explicit gate where the team answers: what statement does this verifier prove, what finalized artifact produced it, what fingerprint family does it belong to, who verified that lineage, and what balances are allowed behind it at first.
  • If any of those answers are missing, the correct funded state is not yet or bounded canary only, not production but we can revisit later.

5. Family-level blast-radius grouping

  • Once one funded verifier fingerprints as unsafe, incident response should widen instantly to every sibling deployment, copied constant set, reused verifier JSON, or same-family exported artifact.
  • The first question should be what else shares this family fingerprint?, not how do we patch this contract in isolation?
  • Veil and Foom are worth preserving together because the repeated lesson was not merely Groth16 can fail; it was one recognizable malformed-key family can hop chains and application surfaces faster than teams can write isolated postmortems.

6. Reachability-aware rescue order

  • Family quarantine is only useful if it drives action in value order.
  • Response should rank sibling deployments by reachable balance, exit speed, downstream contagion, and pause / rescue feasibility rather than by discovery order or branding prominence.
  • This is where verifier-family quarantine hands off cleanly to verification-key-statement-inventory-and-asset-reachability-discipline.

What sound design looks like

  • Release review keeps three promotions explicit instead of inheriting them from artifact existence alone
    • Healthy teams keep artifact exists, artifact is finalized-safe verifier truth for this statement, and that verifier truth deserves this much funded authority as separate promotions with separate evidence.
    • The fastest way to ship a malformed family is to narrate all three as one bland the verifier file was generated fact.
  • A funded verifier release can point to one completed trusted-setup lineage and one exact constant-equivalence proof, not a pile of build artifacts and hope.
  • Unsafe verifier artifact families are named, fingerprinted, and blocked in tooling before anyone deposits value behind them.
  • Funding approval is a separate decision from cryptography export. A verifier may exist, compile, and even test locally without yet being eligible to guard live balances.
  • Live discovery of one malformed verifier fingerprint opens one shared quarantine sheet across chains, products, and residual deployments that inherit that family, with rescue order driven by reachable value rather than by which app is loudest on social media.
  • Proof-system release hygiene is treated as a treasury-control problem. The same seriousness applied to signer sets, bridge verifiers, and upgrade admins is applied to verification-key provenance, family classification, and authority budget.
  • The clean reviewer question is: what exact evidence proves this verifier crossed from intermediate setup state into finalized funded authority, and what single response object would light up if we later discovered its family was unsafe?

Useful positive design shapes

1. Finalization certificate per verifier family

  • Keep a machine-readable release card for every funded verifier family:
    • circuit or statement identifier
    • setup / ceremony artifact hashes
    • finalized proof artifact hash
    • exported verification-key hash
    • deployed constant hash or verifier address
    • family classification (finalized-safe, test-only, quarantined, legacy-residual, etc.)
  • This is the clean handoff object between cryptography work and funded deployment review.

2. Proof-system-specific denylist and fingerprint library

  • Maintain explicit fingerprints for known-bad artifact families: zero-contribution *_0000.zkey, placeholder verifier JSON, copied fixture constants, generator-valued parameters where independence is required, or other proof-system-specific degenerate shapes.
  • The important property is not just we know the bug after reading a postmortem; it is our tooling can classify it before or during deployment and our responders can search for it fleet-wide later.

3. Canary funding with family-aware escalation

  • New proof-authorized systems should begin with bounded balances and pre-written escalation rules.
  • If later review or monitoring identifies an unsafe family fingerprint, the system should already know how to freeze funding growth, pause consumers, and start sibling sweeps immediately.
  • We had only a little TVL is not the design goal; we encoded small initial blast radius until family hygiene was independently revalidated is.

4. One emergency sibling-sweep sheet per unsafe fingerprint

  • Incident response should open one shared sheet keyed by the artifact fingerprint or family label.
  • That sheet should enumerate the fingerprint, all matching verifier addresses or constant hashes, trusted consumer functions, lifecycle states, reachable balances, rescue owners, pause status, and proof that each sibling deployment is either distinct and sound or already quarantined.
  • Chain-by-chain tickets can hang off that object, but they should not replace it.

5. Funded-versus-test environment segregation

  • Test and bounty deployments often normalize placeholder artifacts and sloppy export paths.
  • Healthy teams make it impossible for test-only verifier families to graduate into funded environments without an explicit reclassification step, not just a different frontend label or a TODO in a launch checklist.

6. Minimum verifier-family release card fields that should already exist

  • The release object should exist at both the family level and the concrete deployment level, not as one blended note that forces responders to rediscover reuse during an incident.
  • At the family / lineage level, keep:
    • proof system and circuit / statement name
    • setup or ceremony artifact hashes
    • finalized proof-artifact hash
    • exported verification-key hash
    • known bad-family fingerprints that were explicitly checked and found absent
    • family classification (finalized-safe, test-only, quarantined, legacy-residual, unknown-lineage, etc.)
  • At the deployment level, keep:
    • chain, verifier address, and any embedded-constant location
    • trusted consumer contracts and functions
    • current lifecycle state and funding status
    • who signed off on finalization equivalence for that deployment
    • current pause / rescue owner and whether verifier success is direct payout authority
  • At the authority-budget level, keep:
    • intended balance cap or funding tier
    • sibling deployments sharing the family lineage
    • expected blast radius if the family is reclassified as unsafe
    • the exact runbook or sibling-sweep sheet responders must open first
  • The blunt adequacy test is: if a reviewer asks what exact finalized verifier family is this, where is it funded, and what else shares it?, the answer should already exist without repo archaeology.

First-response questions a sibling-quarantine sheet should answer in one screen

  • What exact unsafe fingerprint or lineage triggered this response? Record the malformed constant tuple, exported-key hash, zero-contribution artifact name, finalized-artifact mismatch, or other reproducible family discriminator so responders are grouping siblings by evidence rather than by product branding.
  • Which deployments are already in scope before new research starts? List every known sibling verifier by chain, verifier address, consumer contract, lifecycle state, funding status, and whether it is active production authority, bounded canary authority, or already residual / quarantined.
  • Where is the fastest loss path? For each in-scope deployment, note whether verifier success is direct withdrawal, claim, bridge release, lottery payout, or only one input to a second provenance check, then rank by time-to-loss, not just current TVL.
  • What value and downstream trust does each deployment still reach? Include not just current balances but residual exits, wrappers, bridge liabilities, downstream redemption paths, and any venue still honoring outputs from the unsafe verifier family as money-good.
  • Who can still intervene, and how? The sheet should name the pause, throttle, rescue, de-recognition, delist, or warning path for each deployment plus the actual owner who can trigger it.
  • What proves a sibling is distinct and safe rather than merely unexplored? Incident closure should require either lineage evidence showing the deployment came from a different finalized family or explicit quarantine / rescue evidence, not we looked and did not immediately see the same frontend.
  • What public statements or partner warnings need to happen now? If downstream integrators, wrapper markets, or bridge partners still trust outputs from the unsafe verifier family, the response object should already show who must be told to stop recognizing those outputs as fresh truth.
  • What does closure mean for each sibling? Investigated is not enough; each deployment should land in proven distinct, rescued, quarantined, reduced to bounded residual authority, or driven to effectively zero reachability.

This one-screen view is the operational bridge between trusted-setup hygiene and live-asset containment. Veil Cash and Foom Cash matter not only because malformed keys existed, but because a recognizable malformed family should have widened immediately into one shared response object with one rescue order and one closure standard.

Failure-prevention checklist

  • Treat circuit-specific setup completion as a hard funded-deploy gate. If the team cannot show the finalized artifact that introduces the required independent parameters, the verifier is not ready to secure value.
  • Record and verify exact lineage from prepared setup input through finalized proof artifact, exported verification key, generated verifier code, and deployed constants or address.
  • Teach CI and deployment tooling proof-system-specific bad families explicitly: zero-contribution *_0000.zkey outputs, placeholder verifier JSON, copied fixture constants, generator-valued independent parameters, or any known malformed-key fingerprint should fail release automatically.
  • Require constant-equivalence checks between the finalized artifact and the deployed verifier. Same repo or same script is not enough once manual export, copy-paste, or sibling-project reuse is possible.
  • Separate verifier exists from verifier may guard funded balances. Use bounded canary balances, explicit approval, and clear lifecycle labels until independent review signs off on finalization and family classification.
  • Maintain a small machine-readable family-classification registry for every funded verifier: safe family, residual legacy family, test-only family, or quarantined family.
  • Pre-build one sibling-sweep response template keyed by artifact fingerprint so responders can immediately enumerate every deployment, consumer, and reachable balance sharing a bad family.
  • Order family-level rescue and quarantine by reachable value, downstream contagion, and withdrawal speed rather than by chain prestige or user-interface visibility.
  • Treat copied verifier artifacts as shared failure domains by default. If a verifier JSON, constant set, or generated contract was reused across chains or products, the burden is to prove distinct lineage before assuming independence.
  • Keep proof-system release review separate from product-launch optimism. Marketing deadlines, bug-bounty challenge launches, or low initial TVL should not waive finalization proofs.
  • Preserve forensic artifacts at the family layer: bad verifier JSON, constant hashes, exported Solidity, and matching onchain addresses should all be archived so later sweeps can detect siblings quickly.
  • Rehearse the discovery-to-quarantine path: if a researcher reports one malformed verifier fingerprint today, who can classify it, search siblings, pause funding, and prioritize rescues before public disclosure widens the race?

Audit prompts

  • What exact artifact proves this verifier was exported after the setup step that randomizes or finalizes the parameters the proof system needs to keep independent?
  • Which known-bad verifier families does deployment tooling already know how to classify, and where are those fingerprints encoded?
  • Can the team prove that the onchain verifier constants match the finalized artifact exactly, rather than just the same repository or the same generation script in principle?
  • What explicit gate separated verifier generated from verifier allowed to secure funded balances, and what evidence was required at that gate?
  • If this verifier were found malformed today, what single sibling-sweep view would enumerate every copied deployment, consumer function, reachable balance, and response owner sharing its artifact family?
  • Are test, bounty, staging, and production environments cleanly separated at the artifact-family level, or can test-only verifier families migrate into funded environments through convenience reuse?
  • Which live deployments share exported verifier JSON, generated Solidity, constant hashes, or recognizable family fingerprints even if they live on different chains or behind different product names?
  • What bounded-loss controls remain if a malformed family is discovered after funding but before full migration or rescue?
  • Does incident response know how to rank sibling deployments by reachable value and exit speed, or would the team still default to chain-by-chain narrative triage?
  • If a reviewer asked why do you believe this verifier is finalized-safe rather than an intermediate-family artifact?, what exact reproducible evidence would answer without hand-waving?

Lessons that should already be standard

  • Trusted setup is not complete when the command prints a file. It is complete when the funded verifier can prove it came from the finalized state the proof system actually requires.
  • Intermediate proof artifacts are not harmless build debris. Once exported into verifier constants, they become direct custody risk.
  • Bad verifier fingerprints are family names, not anecdotes. The first confirmed malformed-key deployment should trigger suspicion across siblings immediately.
  • Low TVL and bug bounty challenge are not release controls. Placeholder-family verifiers still become real authority the moment they guard a funded contract.
  • Proof-system release hygiene is not fully captured by generic software supply-chain language. zk systems need proof-specific family classification and proof-specific funded-deploy gates.
  • A verifier that is safe in theory but unproven in lineage is not yet safe enough to guard balances.
  • Family-level quarantine beats contract-level storytelling. Attackers exploit the time between we found one bad verifier and we realized three more deployments shared it.
  • The right postmortem question is often not how did this one contract break? but why did this verifier family ever become fundable, and why was sibling blast radius not already precomputed?

Where this note helps most

Internal linkages

Control surface

Graph View

Backlinks