Cowrie Research

verification-key-statement-inventory-and-asset-reachability-discipline

24 min read

Verification-Key Statement Inventory and Asset-Reachability Discipline

  • Name: verification-key statement inventory and asset-reachability discipline
  • Category: proof-system lifecycle reference / verification-key inventory checklist / live-statement ownership note / residual-verifier risk map
  • Summary: Healthy zk systems do not treat deployed verification keys as passive build leftovers. Each live key is an authorization object with four properties that must stay explicit together: what exact statement it proves, what artifact lineage produced it, which contracts and entrypoints trust it, and what balances or rights remain reachable through that trust. The recurring review mistake this note tries to stop is flattening three different verifier-authority promotions into one vague the verifier is still deployed: some verifier artifact still exists, that artifact deserves to count as canonical live statement truth for this exact relation, and that accepted statement truth still deserves this much reachable withdrawal, exit, release, or governance authority. This note exists to preserve the positive-design companion for incidents like Veil Cash, Foom Cash, and Aztec 2.0, where teams either shipped an unsound key, left a stale statement live, or lost track of which deprecated verifier still controlled real money.
  • Why this note exists:
    • verification-key-independence-collapse preserves the failure mode where the deployed key itself destroys soundness.
    • witness-public-input-binding-failure preserves the different failure mode where the deployed key still proves the wrong statement even though the verifier is behaving as encoded.
    • The missing positive-design question is operational and architectural at once: what should a healthy team know, publish, and continuously check about every verification key that still has any path to money, claims, exits, or governance authority?
    • This note keeps that answer explicit instead of forcing readers to reconstruct it only by inverting exploit writeups.

Fast classifier: what kind of verification-key inventory failure are you trying to avoid?

  • the repo is fixed, but the chain still trusts the old statement — the current code no longer contains the bug, but an older deployed verification key still authorizes withdrawals or exits. Aztec 2.0 is the clean exemplar.
  • the key itself is malformed, and nobody noticed before funding it — the verification key never represented a sound proof system, but the application still treated verifyProof() as direct payout authority. Veil Cash and Foom Cash are the clean exemplars.
  • artifact provenance exists on paper, but it still resolves to a quarantined family — operators can point to a verifier JSON, deploy log, or generated Solidity file, yet the lineage still terminates in a zero-contribution *_0000.zkey, placeholder constants, or other pre-finalization artifact class that should never protect funded value. Veil Cash and Foom Cash are again the clean exemplars.
  • one verifier artifact quietly controls many deployments — the same malformed or stale statement is reused across chains, products, or legacy exit paths, so one discovery becomes a fleet-wide solvency event. Foom Cash is the clean multi-chain exemplar.
  • the product is deprecated, but the verifier still reaches value — the verifier no longer matters to growth or normal UX, yet it still controls withdrawals, claims, or rescue paths against funded contracts. Aztec 2.0 is the clean residual-service exemplar.
  • Use this note when the sharper design question is how should a protocol inventory live proving statements and the assets they can still reach before a stale or malformed verifier turns into a surprise payout path?

What this note means by verification-key statement inventory

  • Verification-key statement inventory means the protocol can answer, for every deployed verifier or verification key that still matters:
    • what exact relation the key proves
    • which circuit / ceremony / export artifacts produced it
    • which contracts, functions, and downstream adapters trust it
    • which balances, assets, claims, or governance rights remain reachable through that trust
    • whether the key is active production authority, bounded residual-exit authority, or fully decommissioned
  • The important design target is not merely we know the verifier address. It is we know what this key means, where it came from, what still trusts it, and how much damage follows if it is wrong.
  • This is the verification-key analogue of keeping a signer set, bridge release authority, or upgrade admin map legible as one security object instead of scattered operational folklore.

Three verifier-authority promotions live systems should keep separate

  1. A verifier artifact or verification key still exists
  • A verifier contract remains deployed, a key hash still sits in storage, a legacy escape hatch still references the old statement, or a downstream consumer can still call into the old proof path.
  • This is only the existence question: there is still some proof-side object the system might trust.
  1. That artifact deserves to count as canonical live statement truth for this exact relation
  • The artifact lineage, ceremony finalization, exported key material, public-input semantics, and deployed statement all still have to line up strongly enough that the chain is actually enforcing the relation operators think it is enforcing.
  • This is the statement-truth question: the live verifier still means what the protocol thinks it means.
  1. That accepted statement truth still deserves this much reachable authority
  • Even a real verifier for a real statement should not automatically retain full withdrawal, release, mint, claim, or governance reach forever.
  • This is the authority-budget question: why does this live statement still get to matter this much here and now?

Healthy verifier operations keep those promotions distinct instead of collapsing them into the old verifier is still there.

The seven joints a healthy live-verifier inventory should keep fused

1. Statement identity

  • A team should be able to name the exact relation each deployed key proves: withdrawal ownership, nullifier consumption, batch settlement validity, escape-hatch membership, bridge message authenticity, prize claim eligibility, or some narrower statement.
  • This is the old verifier is not enough. Reviewers need to know what claim becomes true when that verifier returns true.
  • If the statement changed in source later, the inventory should still preserve what the onchain key continues to authorize today.

2. Artifact lineage

  • The system should track the exact circuit version, ceremony artifact, finalized zkey or equivalent proof artifact, exported verification key, generated verifier contract, and deployed address or constant set.
  • This is the joint that prevents we audited the repo from being confused with the live chain is enforcing that audited statement.
  • Healthy lineage should also be classifiable, not just replayable. Operators should know whether a verifier came from a finalized ceremony output or from a quarantined artifact family such as a zero-contribution *_0000.zkey, placeholder verification_key.json, copied test constants, or other pre-finalization build outputs that should never back funded deployments.
  • exact-production-artifact-attestation-and-rollback-discipline is the adjacent release-integrity companion when the sharper question becomes source-to-artifact lineage rather than live statement ownership.

3. Trust edges and consumer map

  • Inventory should record which contracts and functions actually trust the verifier: withdraw(), collect(), escapeHatch(), batch settlement, bridge release, migration claim, or governance-gated rescue flow.
  • It should also record whether those consumers treat verifier success as direct economic authority or only as one input to a second provenance check.
  • A verifier with no live consumer is historical debris; a verifier with one funded consumer is still production risk.

4. Asset and right reachability

  • Every live verifier should have a reachability map: what assets, wrappers, notes, claims, or governance rights can still be reached if this key is unsound or stale?
  • Reachability is wider than current wallet balances. It includes residual bridge positions, wrapped claims redeemable elsewhere, sweepable dust, and downstream contracts that still honor credits or releases originating from the verifier’s statement.
  • This is the joint teams most often under-document in deprecated systems: the contract looks old, but the reachable value surface is still real.

5. Lifecycle state and residual status

  • The inventory should classify each key as one of a few legible states:
    • active production authority
    • migration-only or exit-only residual authority
    • paused / quarantined authority
    • decommissioned authority with zero reachable value
  • Deprecated is not a lifecycle state unless it answers what the key can still do.
  • exit-only-residual-surface-discipline is the narrower companion when a verifier must survive only to honor bounded residual exits.

6. Operational owner and response path

  • Each live verifier needs a named owner, alerting path, review cadence, and response plan.
  • If the key is found unsound or stale, the inventory should already say what can happen next: pause, throttle, rescue, migrate, delist, or publicly mark the path as unsafe.
  • The dangerous anti-pattern is immutable, deprecated, unsupported while a verifier still authorizes money movement and nobody can even say who watches it.

7. Ongoing equivalence checks

  • Healthy systems do not inventory the verifier once and forget it.
  • They keep proving that statement identity, artifact lineage, trust edges, and asset reachability still match reality after upgrades, migrations, cross-chain copies, and decommissioning steps.
  • The useful invariant is the live verifier registry still tells the truth about what each key can authorize right now.

What sound design looks like

  • Verifier authority stays staged rather than collapsing into one deployment fact
    • Healthy systems keep verifier artifact exists, artifact is canonical live statement truth, and that statement truth still deserves reachable authority as separate promotions with explicit lineage, lifecycle, and reachability checks at each step.
    • The fastest way to miss a stale-verifier disaster is to narrate all three promotions as one bland the verifier is still deployed fact.
  • Every live verifier is treated as a first-class authorization object
    • Teams should know the same facts about verification keys that mature custody systems know about signer sets: what they authorize, who owns them, where they are used, and how much value they can reach.
  • Statement identity survives repository churn
    • Removing or patching a circuit in source does not erase the older statement if an onchain key still proves it. Healthy systems inventory the live statement, not only the latest repo intent.
  • Artifact provenance and economic reachability stay joined
    • A verifier record should not stop at this address came from commit X. It should continue to and these contracts still trust it for these assets and these residual rights.
  • Residual verifiers are explicitly narrower than production verifiers
    • If a verifier survives only for exits or migration cleanup, the surrounding system should make that narrow role legible in code, monitoring, and downstream policy rather than treating it like an ordinary production proof gate.
  • Cross-chain copies are inventory-coupled by default
    • If one verifier artifact was reused across siblings, the inventory should expose that shared blast radius immediately instead of letting each deployment pretend it is independent.
  • The clean reviewer question is: if this verifier were wrong today, exactly which entrypoints and balances would become reachable before humans could react?

Useful positive design shapes

1. A machine-readable live verifier registry

  • Keep one canonical registry of deployed verifiers and verification keys that records statement type, artifact hashes, deployment addresses, trusted consumer functions, lifecycle state, and reachable-asset estimates.
  • The point is not bureaucracy. It is making live proof authority legible enough that audits, migrations, and incident response are speaking about the same object.

2. Per-key statement cards in reviews and decommissioning plans

  • A review artifact for a new or legacy verifier should fit on one page:
    • statement proved
    • artifact lineage
    • trusted consumers
    • reachable balances / rights
    • whether pause or rescue exists
    • intended terminal state
  • This is the clean positive-design answer to nobody realized the old escape hatch still mattered.

3. Reachability-first deprecation

  • Before calling a verifier deprecated, reduce what it can still reach:
    • drain or segregate funds
    • disable downstream recognition
    • narrow consumers to exit-only paths
    • quarantine wrappers or bridge lanes sourced from that proof path
  • A verifier should become socially unimportant only after it becomes economically unimportant.

4. Shared-blast-radius grouping across chains and products

  • If one circuit or key artifact was copied across Base, Ethereum, testnet-derived forks, or sibling products, inventory them as one risk family.
  • The safe assumption is not different deployment, separate risk. It is shared key lineage, shared failure mode until proven otherwise.

5. Continuous stale-statement detection

  • When source code, repo history, or formal spec changes a statement, the verifier inventory should flag every live key still proving an older relation.
  • That is the positive-design answer to Aztec-style the codebase moved on, but the chain still trusts the old statement failures.

6. Artifact-family fingerprints and quarantine

  • Healthy teams keep a small denylist of verifier artifact families that should never graduate into funded environments: zero-contribution *_0000.zkey outputs, known placeholder verifier constants, test-fixture keys, or any artifact lineage that still resolves to pre-finalization ceremony material.
  • The point is not only to catch one malformed deployment. It is to collapse fleet-wide triage fast when one unsafe family fingerprint appears across multiple chains or sibling products.
  • This is the inventory-side answer to Veil Cash / Foom Cash style we had files and contracts, but they all came from the wrong artifact family failures.

7. One emergency family-quarantine sheet per shared artifact lineage

  • When one funded verifier fingerprints as unsafe, incident response should open one shared response object keyed by artifact family rather than separate chain-by-chain tickets.
  • That sheet should enumerate the artifact fingerprint or lineage, every verifier address or constant hash carrying it, every consumer function that still trusts it, every chain or product surface involved, each reachable balance or right, the current lifecycle state, and the pause / rescue owner for that slice.
  • Rescue order should follow reachable value, exit speed, and downstream contagion risk rather than whichever deployment happened to be noticed first in public.
  • Incident closure should mean every sibling deployment is either proven distinct and sound or has been quarantined, rescued, de-recognized, or reduced to effectively zero reachability.

8. Minimum live-verifier registry fields that should already exist

  • The registry should have one stable row or object per live verifier family and per concrete deployed verifier, not one blended note that forces responders to guess which level of reuse matters.
  • At the family / lineage level, keep: proof system, circuit or statement name, artifact-family fingerprint, finalized artifact hash, exported verification-key hash, known sibling deployments, and the classification (active-safe, residual, quarantined, test-only, unknown-lineage, etc.).
  • At the deployment level, keep: chain, verifier address or embedded-constant location, trusted consumer contracts and functions, lifecycle state, last reviewed timestamp, operational owner, pause / rescue capability, and whether verifier success is direct payout authority or only one input to a second check.
  • At the reachability level, keep more than current token balances: direct escrowed assets, withdrawable claim rights, bridge liabilities, wrappers another protocol still treats as money-good, migration or escape-hatch surfaces, and any downstream venue still honoring state produced by this verifier.
  • At the incident-response level, keep precomputed sibling grouping, severity or queue rank, fastest cash-out path, downstream contagion candidates, and the exact runbook or sheet link responders should open first if the family later fingerprints as unsafe.
  • The test for adequacy is blunt: if one verifier is reported unsound, can the team answer what else shares this lineage, what still trusts it, and what value can leave first? without fresh archaeology.

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

  • What exact fingerprint or lineage triggered this response? Record the unsafe constant tuple, exported verification-key hash, finalized-artifact mismatch, stale statement id, or other family discriminator so responders are not grouping siblings by folklore or frontend branding.
  • Which deployments are already in scope before new research starts? List every known sibling verifier by chain, address, consumer contract, lifecycle state, and whether it is active production authority, residual exit-only authority, or already paused.
  • Where is the fastest cash-out path? For each in-scope deployment, note whether verifier success is direct payout authority, bridge release authority, claim authority, or only a precursor to a second provenance check, and rank the surfaces by time-to-loss rather than by TVL alone.
  • What value and downstream trust does each deployment still reach? Include not just escrowed balances but residual withdrawals, wrapper redeemability, migration claims, bridge liabilities, and any other venue still treating state from this verifier as money-good.
  • Who can still intervene, and how? The sheet should name the pause, throttle, rescue, delist, de-recognition, or warning path for each deployment plus the actual owner who can trigger it.
  • What public statements need to happen immediately? 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 warned to stop honoring those outputs as fresh truth.
  • What does closure mean for each sibling? Investigated is not enough. The sheet should track whether each deployment has been proven distinct and sound, quarantined, rescued, reduced to bounded residual authority, or driven to effectively zero reachability.

This screen-level view is the operational bridge between the registry and the exploit corpus. Veil Cash and Foom Cash show why a recognizable malformed-key fingerprint should immediately widen into sibling-deployment triage, while Aztec 2.0 shows why an old, deprecated verifier still belongs on that same screen if it can cash out through a residual exit path.

Failure-prevention checklist

  • Keep one canonical live-verifier registry that records, for every deployed verification key or verifier address, the exact statement proved, artifact lineage, trusted consumers, lifecycle state, current reachable-asset surface, sibling-lineage grouping, and incident owner / pause / rescue path.
  • Make the three verifier-authority promotions explicit in that registry and in decommissioning review: artifact still exists, artifact still means the intended live statement, and that statement still deserves this much reachable authority should each have their own evidence rather than one inherited legacy verifier label.
  • Treat what the live chain trusts as the primary truth, not what the current repo contains. If source changed, migration happened, or a circuit was removed, explicitly inventory every older deployed key that still survives as production, migration, escape-hatch, or rescue authority.
  • Make artifact lineage reproducible end to end: ceremony transcript or setup artifact, finalized proof artifact, exported verification key, generated verifier contract or constants, and deployed address should reconcile automatically rather than through memory or screenshots.
  • Record artifact-family fingerprints and quarantine rules alongside lineage: zero-contribution *_0000.zkey files, placeholder verifier constants, test fixtures, and similar pre-finalization artifacts should be machine-identifiable and banned from funded deployment paths.
  • Pre-build an emergency family-quarantine template and lineage-grouping script so one bad funded verifier fingerprint can immediately expand into a full sibling-deployment sweep instead of ad hoc chain-by-chain archaeology.
  • Attach each live verifier to its concrete economic consumers. A key record should name the exact withdraw, collect, exit, claim, bridge release, settlement, or governance rescue entrypoints that still treat verifier success as authority.
  • Maintain a reachability map, not just a balance snapshot. Include residual wrappers, downstream redeemability, bridge liabilities, sibling contracts, legacy escrows, and any rights another protocol still honors if the verifier is wrong.
  • Force lifecycle states to mean something operational: active, residual exit-only, paused/quarantined, and decommissioned with zero reachable value should each have explicit downstream and monitoring consequences.
  • Group shared artifacts as one blast radius. If the same verification key, ceremony output, or generated verifier was copied across chains or products, inventory and review them together until distinct lineage is proven.
  • Assign a named operational owner, review cadence, alert path, and emergency response plan to every verifier that can still reach value. Deprecated and immutable is not an ownership model.
  • Run continuous stale-statement checks whenever the circuit, spec, or source semantics change. The review question is not did we patch the repo? but which live keys still enforce the old statement anyway?
  • Make decommissioning reachability-first: drain balances, disable downstream recognition, quarantine wrappers, narrow consumers, and only then call the verifier retired.
  • Test inventory truth with live-chain drills or scripted reviews: if a verifier were discovered unsound today, operators should already know which contracts, chains, balances, sibling deployments, and downstream redemption paths would be in scope before doing new research during the incident.
  • Publish enough verifier metadata that outside reviewers can independently answer what does this key still authorize? instead of relying on protocol folklore.

Audit prompts

  • What exact statement does each funded deployed verifier prove today, in onchain terms rather than repo shorthand or product naming?
  • Which contracts and entrypoints still trust that verifier, and does any one of them convert verifier success directly into withdrawals, claims, releases, minting, or governance authority?
  • What exact artifact chain links the live verifier constants back to a finalized ceremony or build output, and can an outside reviewer independently recompute it?
  • Does that lineage terminate in a funded-safe artifact family, or does it still fingerprint as a zero-contribution *_0000.zkey, placeholder verifier file, copied test constant set, or other pre-finalization class that should have been quarantined?
  • If source or specification changed after deployment, which live keys still encode the older statement and how is that divergence surfaced operationally?
  • What balances, wrappers, residual exits, rescue rights, bridge claims, or downstream redemption paths remain reachable if this verifier is malformed, stale, or underbound?
  • Are sibling deployments or legacy products reusing the same verifier artifact, and if so where is the grouped blast-radius analysis that treats them as one risk family rather than separate incidents waiting to happen?
  • If one funded verifier fingerprints as unsafe today, what single emergency sheet or registry view would immediately list every sibling deployment, consumer entrypoint, reachable balance, and response owner in scope?
  • What lifecycle state is each verifier actually in, and what concrete code or policy makes exit-only or deprecated narrower than ordinary production authority?
  • Who owns review and incident response for each live verifier, and what can that owner actually do if the key is later found unsound: pause, throttle, rescue, delist, quarantine, or only publish a warning?
  • Where is the proof that decommissioning reduced economic reachability as well as user-facing prominence? Old contracts being out of the product UI is not the same thing as dead authority.
  • If a reviewer asked what still becomes reachable if this verifier is wrong today?, what single registry or runbook would answer without fresh archaeology?

Lessons that should already be standard

  • Verification keys are not passive cryptography debris; they are live authorization objects. Teams should inventory them with the same seriousness they reserve for signer sets, upgrade admins, and bridge release authorities.
  • Still deployed is not one security fact. Presence, canonical statement truth, and retained economic authority are separate claims, and incidents happen when teams inherit the second and third just because the first remained true.
  • The repo is fixed is not a security state. If an older onchain key still proves the old relation against funded contracts, the old bug is still live policy.
  • Deprecated is often a story about user attention, not economic reachability. Residual exits, migration helpers, and escape hatches regularly remain the real blast radius after a product is supposedly gone.
  • Artifact provenance and asset reachability belong in the same review object. A perfect lineage story that omits who still trusts the key is incomplete, and a consumer map without artifact lineage misses the root of trust.
  • Artifact-family names should trigger immediate fleet-wide suspicion. If *_0000.zkey, placeholder verifier constants, or other pre-finalization fingerprints show up in one funded deployment, operators should assume sibling deployments sharing that lineage are part of the same blast radius until proven otherwise.
  • Shared artifact lineage means shared incident until proven otherwise. Once one funded verifier fingerprints as a quarantined family, the burden shifts from is another deployment also bad? to which sibling deployments have already been proven distinct and safe?
  • Cross-chain or cross-product verifier reuse should be assumed correlated until proven otherwise. Shared proof artifacts create shared failure domains whether or not the frontend branding is different.
  • Operational ownership matters even for immutable systems. If a verifier can still reach value, someone needs to watch it, model its blast radius, and own the response path when new cryptographic or lifecycle facts surface.
  • Decommissioning is successful only when the verifier’s reachable value surface is close to zero, not when the protocol stops marketing the feature.
  • The clean question for proof-system operations is not do we still use this verifier? but what can this verifier still authorize right now, and how quickly would we know if that answer changed?

Design questions worth asking first

  • What exact statement does each funded deployed verifier prove today, in onchain terms rather than repository shorthand?
  • Which contracts and functions trust each verifier, and do any of them turn verifier success directly into withdrawals, claims, or releases?
  • What balances, wrappers, residual rights, or downstream redemption paths are still reachable through each verifier if it is malformed or stale?
  • Which of the three verifier-authority promotions is actually being claimed for each live key right now: mere continued deployment, canonical live-statement truth, or retained withdrawal / exit / release authority?
  • Which verifiers are active production authority, which are residual exit-only authority, and which are truly dead?
  • Can one malformed or stale artifact be reused across multiple chains or sibling products without the inventory surfacing that shared blast radius?
  • If the source circuit was patched later, what exact deployed keys still preserve the old statement as live policy?
  • Who owns response for each live verifier, and what response actually exists if the issue is discovered after funding?
  • During decommissioning, where is the proof that the verifier’s reachable value surface shrank along with its intended role?

Red flags that usually mean verifier inventory truth is still split

  • That verifier is old used as if age proved irrelevance
  • The repo removed that circuit years ago with no evidence about what the live onchain key still proves
  • It is just an escape hatch / migration helper without a reachability map for the assets that helper can still release
  • The same verifier was reused for convenience with no grouped blast-radius analysis across deployments
  • We know the verifier address but not the statement, artifact lineage, trusted consumers, or reachable balances
  • There are no admin keys anymore used as if lack of intervention also removed the verifier’s economic authority
  • This path is deprecated while downstream protocols still recognize credits, wrappers, or exits originating from it as fresh truth

Negative exemplar cluster: what no live-verifier inventory looks like

  • Aztec 2.0 preserves the stale-statement version: the repository had moved on, but an old deployed escape-hatch verification key still proved the wrong relation against funded contracts.
  • Veil Cash preserves the malformed-key version: the live verifier never represented a sound proof system, yet still sat directly on the withdrawal path.
  • Foom Cash preserves the shared-blast-radius version: the same malformed verifier pattern reached multiple chains and a different payout surface before whitehats intervened.
  • The preserved common lesson is not only zk systems had bugs. It is that teams did not keep one explicit map from live verification keys to live statements, trusted consumers, and reachable value.

How this note complements the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks