Cowrie Research

decommissioning-authority-extinguishment-discipline

16 min read

Decommissioning Authority-Extinguishment Discipline

  • Name: decommissioning authority-extinguishment discipline
  • Category: lifecycle reference / decommissioning checklist / residual-authority control note / deprecation companion
  • Summary: Deprecation is a social statement; decommissioning is a technical state transition. Healthy retirement of a feature, deployment, bridge lane, vault, staking system, governor, or rollup path should end with explicit proof that the retired surface no longer mints, no longer defines solvency, no longer moves custody, and no longer governs production value. If deprecation-without-deauthorization preserves the failure pattern, this note preserves the positive-design companion: how operators should extinguish authority instead of merely attention.
  • Why this note exists:
    • deprecation-without-deauthorization already preserves the negative lesson that legacy, deprecated, and unsupported do not remove authority by themselves.
    • What still deserves a narrower positive-design note is the operational question: what should a real decommissioning runbook prove before a team is allowed to stop watching an old surface as if it were production?
    • The analytical win is to treat retirement as its own control object. A system is not decommissioned because the UI hid it or because governance said users should migrate. It is decommissioned when its authority has been inventory-checked, revoked, quarantined, or moved behind a consciously defended residual path.

The core design rule

A surface is only meaningfully deprecated once its authority has been extinguished, tightly quarantined, or transferred into a new explicitly defended control boundary.

Healthy systems should not let these remain equivalent:

  • we do not recommend using this anymore
  • this path still mints, withdraws, certifies balances, toggles collateral, or governs cash

The five separations healthy decommissioning should preserve

  1. Attention withdrawal versus authority withdrawal

    • Hiding a UI tab, removing docs prominence, or marking a feature unsupported is not a security control.
    • Decommissioning should revoke or constrain the old authority before the team lets monitoring, review intensity, or operator staffing decay.
    • The key question is not did users stop arriving? but what exact powers survive if one attacker still does arrive?

  2. User migration versus legacy-surface trust

    • Migrating users to a new system should not leave the old system authoritative for minting, reward certification, migration proofs, or emergency exits.
    • If the replacement still accepts the retiring system as proof of value, the old system is still part of production truth.
    • TempleDAO / STAX preserves this exact mistake: migration support kept the retired staking surface economically live.

  3. Residual custody versus residual administration

    • Old deployments often retain both money and the power to decide what happens to that money.
    • Healthy retirement separates these: ideally withdrawable value is drained, capped, or placed behind a smaller withdrawal-only boundary before governance, upgrade, or parameter authority is allowed to decay.
    • Moonwell Moonriver preserves the failure case where the old constitutional shell stayed powerful enough to matter.
    • Holograph preserves the control-plane cousin: the old v1 operator / proxy-admin surface was socially obsolete but still sat inside the mint-definition boundary for live HLG supply.
    • Tapioca DAO preserves the operator-path cousin: the old hot-wallet admin path was socially treated as superseded by multisig control, but it was never actually extinguished onchain and remained fully capable of mint-admission and vesting-rescue authority.

  4. Immutable withdrawal obligations versus full production semantics

    • Some systems cannot fully disappear because they still owe exits, withdrawals, or settlement completion.
    • In those cases, the right goal is not pretending the old system is dead. It is narrowing it to the smallest possible monitored residual function, with explicit caps and no sibling powers left attached.
    • Aztec Connect and Aztec 2.0 preserve the danger of treating still withdrawable as if it were equivalent to already decommissioned.

  5. Decommissioning completion versus open-ended transitional limbo

    • A healthy retirement needs a crisp end state: disabled, drained, migrated, quarantined, or retained as a named residual service with explicit owner and monitoring.
    • Transitional states that last indefinitely are where stale assumptions and residual authority accumulate.
    • The unsafe default is we will clean this up later while later never arrives.

Three retirement-authority questions healthy systems should not collapse

  1. Does the old surface still technically exist?

    • This is the narrow deployment-presence question.
    • It only answers the contracts, signers, bridge lane, governor, or helper path are still there somewhere.

  2. Does that surviving surface still sit inside live money-good or constitutional truth?

    • This is the residual-authority question.
    • It asks whether the old surface can still mint, certify balances, release custody, repoint implementation, admit collateral, rescue vesting inventory, set rates, or otherwise tell the current balance sheet or governance system what reality is.

  3. Do downstream systems still honor that old surface as if it were active production infrastructure?

    • This is the downstream-recognition question.
    • It asks whether wrappers, migration helpers, collateral engines, route registries, exchanges, dashboards, or operators still trust the retiring surface enough that its surviving authority can become spendable or constitutional power.

Healthy decommissioning answers those three questions separately. It does not let old system still exists silently imply old system still deserves live authority, and it does not let some residual authority must survive for exits or migration silently imply downstream systems may keep treating that authority like ordinary production truth.

What sound design looks like

1. An explicit authority inventory

  • Before retirement, enumerate every power the old surface still has:
    • mint / issuance authority
    • collateral or solvency publication authority
    • custody release or withdrawal authority
    • governance, timelock, upgrade, or pause authority
    • migration certification authority
    • parameter-setting authority
  • The decommissioning checklist should fail closed if any authority remains unclassified.
  • The reusable design target is simple: teams should be able to answer what truths can this retired surface still publish to the balance sheet or root-control plane?

2. One explicit extinguishment state transition

  • Retirement should have an onchain or operationally provable transition, not just a forum post.
  • Good examples include revoking minter roles, zeroing rate publishers, disabling entrypoints, removing bridge-lane admission, burning upgrade admin, draining treasuries, or forcing the old system into exit-only mode.
  • If a feature cannot be fully disabled, its residual powers should be named explicitly rather than left implicit.

3. Residual-path narrowing before monitoring decays

  • If a deprecated surface must stay live for withdrawals, refunds, or settlement completion, narrow it before attention fades.
  • Healthy narrowing often means:
    • withdrawal-only mode
    • capped per-epoch or per-lane outflows
    • no new deposits or minting
    • no governance, upgrade, or collateral-listing rights
    • no new migration issuance from the retired surface
  • Residual service is a safer mental model than deprecated product.

4. Value evacuation or explicit quarantine

  • The cleanest decommissioning is often to move value away from the old surface entirely.
  • If value cannot be evacuated immediately, quarantine should make the remaining risk legible:
    • cap exposure
    • isolate the old deployment from broader treasury rights
    • pause non-exit paths
    • document who still watches it and what alerting remains active
  • A retired surface with large uncapped custody is still a production system, whatever the docs say.

5. Downstream trust removal

  • Other systems may still trust the retired surface even after the core team moved on.
  • Healthy retirement treats old surface still deployed, old surface still authoritative, and old surface still downstream-honored as three separate states that must each be narrowed on purpose.
  • Healthy decommissioning removes or narrows downstream recognition too:
    • disable collateral usage
    • reject old migration proofs
    • delist old bridge lanes or wrappers
    • remove residual admin inheritance
    • rotate signer or verifier dependencies away from the retired path
  • Decommissioning is incomplete if integrators still treat the old system as authoritative.
  • machine-readable-residual-status-publication is the narrower policy-distribution companion when the sharper follow-up becomes what exact structured residual-status object should tell downstream systems that a surface is no longer active production infrastructure.
  • residual-liquidity-segregation-and-active-tvl-hygiene is the narrower accounting-side companion when the sharper follow-up becomes how any balances left behind should stop counting as active TVL, route-worthy venue depth, or fresh solvency support.

6. A named residual owner and review cadence

  • If anything survives, someone still owns it.
  • A residual surface should have:
    • an explicit owner
    • a bounded mandate
    • live monitoring
    • a defined review cadence
    • a target end state if full shutdown is still pending
  • The dangerous pattern is nobody really owns this anymore while the code still owns money.

What sound decommissioning should prove before operators relax

A strong decommissioning record should be able to answer:

  • What exact authorities were removed?
  • Which authorities remain, if any, and why?
  • What value is still exposed on the old surface?
  • Can the retired path still mint, certify balances, move custody, or govern another system?
  • What downstream integrations stopped trusting it?
  • Who still monitors the residual path, and what event ends even that residual obligation?

High-signal contrast cases

  • Acala shows why a deprecated rewards branch cannot keep mint authority just because the main product path moved on.
  • Sturdy shows why safety retrofits must cover the whole authority surface, not only the preferred path.
  • STAX shows that a retiring system still counts as production if the replacement accepts it as balance-certifying truth.
  • Holograph shows the operator-admin cousin: an old proxy / operator rail can look historically obsolete while still retaining live mint-definition authority.
  • Aztec Connect and Aztec 2.0 show the immutable-system cousin: deprecation without exit-path narrowing leaves old settlement bugs economically alive.
  • Moonwell Moonriver shows the constitutional cousin: social abandonment plus retained treasury and admin rights is still a live protocol-seizure surface.
  • Tapioca DAO shows the admin-migration cousin: moved to multisig is not a decommissioning fact until the old hot wallet can no longer originate production admin actions.

Design questions worth asking first

  • What exact powers does the retiring surface still have today?
  • Is the current problem merely the old thing still exists, or does that surviving thing still sit inside live mint, custody, solvency, or governance truth?
  • Which of those powers can be removed immediately, and which must survive for exits or migration?
  • If some authority must survive, can it be narrowed to one residual function instead of a full product surface?
  • Which downstream systems, wrappers, route registries, or dashboards still honor the retiring surface as if it were ordinary production infrastructure?
  • How much value remains exposed while the old path stays live?
  • Which other systems still trust the old path for collateral, migration, custody, governance, or settlement?
  • Who still owns the residual surface operationally?
  • What event will let us say the surface is actually gone rather than merely ignored?

Red flags that usually mean decommissioning is fake

  • We removed it from the UI
  • Users should migrate soon
  • Governance renounced so nobody can touch it now when the system still owes large withdrawals or still holds cash
  • The old contract is immutable, so there is nothing to do even though it still exposes broad exit or settlement semantics
  • Only power users know this path exists while it still mints, certifies value, or moves custody
  • We paused the main path but left sibling helpers or migration certifiers alive
  • The old deployment is basically dead while it still has a timelock, treasury, minter, or market-admin role

Failure-prevention checklist

  • Maintain a retirement inventory that names every deprecated contract, deployment, bridge lane, helper, migration source, admin role, reward rail, signer dependency, and residual balance together with the exact authority each still holds.
  • Convert deprecated into a provable state transition: disable public entrypoints, revoke mint and admin roles, zero stale publishers, delist old lanes or wrappers, and remove old surfaces from downstream solvency, collateral, and routing assumptions.
  • Require every decommissioning plan to answer three separate questions: does the old surface still exist, does it still retain live authority, and do downstream systems still honor it as production truth? Then prove which authorities disappear immediately, which survive temporarily for exits or migration, and what technical property makes that narrower residual state real.
  • Shrink the old balance sheet before shrinking attention. Drain treasury-owned funds, segregate user-liability reserves, and isolate any remaining legacy custody behind the smallest possible withdrawal-only or lane-local boundary.
  • Remove sibling powers before leaving a residual path alive. Exit compatibility should not still carry governance reach, oracle publication, parameter setting, bridge admission, migration certification, or upgrade authority unless that power is explicitly still needed and actively defended.
  • Treat downstream trust removal as part of retirement, not a later cleanup task. Collateral engines, route registries, migration helpers, wrappers, dashboards, and governance tooling should stop treating the old surface as fresh production truth the moment retirement begins.
  • Keep deprecated surfaces inside first-class monitoring, code ownership, and incident response until their live authority is truly gone; low traffic, old branding, or user migration are not reasons to downgrade operational coverage.
  • Rehearse residual-path assumptions explicitly: if some authority survives for withdrawals or settlement, test that the old surface cannot mint, cannot admit fresh activity, cannot certify new balances for a successor, and cannot regain broader semantics through sibling helpers or aliases.
  • Bind decommissioning to a terminal event with evidence: funds drained, claim window elapsed, governance powers burned, lane retired, or residual balances transferred into a new defended custodian.
  • Re-run the inventory after upgrades, migrations, governance changes, or emergency patches so retirement drift does not quietly recreate authority the team already assumed was gone.
  • Treat internal completion claims as untrusted until they have a role diff, transaction hash, and post-change privilege check proving the retiring signer, deployer, or vendor path really lost its authority.

Audit prompts

  • What exact powers does this supposedly retired surface still retain today: minting, withdrawals, governance, oracle publication, migration certification, signer control, bridge release, collateral admission, or parameter setting?
  • Is the current retirement state merely the old system still exists, or does that surviving system still define live money-good or constitutional truth somewhere?
  • Which of those powers were removed in a provable state transition, and which remain only because the team still owes exits, refunds, settlement, or migration support?
  • If the old path were exploited right now, what value could it still create, release, certify, or govern before any cap, queue, or operator response intervened?
  • Has the team actually removed downstream trust in the old surface, or do routers, wrappers, collateral engines, dashboards, and migration helpers still treat it as an ordinary authority source?
  • Are residual balances segregated from treasury, active liquidity, and production collateral accounting, or are they still being presented as if they were healthy live inventory?
  • Which owner, signer set, multisig, or operational team still covers the deprecated surface, and what alert or review cadence proves that ownership is real rather than assumed?
  • Did recent hardening work cover every legacy sibling entrypoint and deployment, or only the currently preferred product path?
  • If the system is immutable, what narrower technical boundary now limits the old surface to exits only instead of leaving broad economic semantics live forever?
  • What exact event will let operators declare the old surface actually gone, and what evidence will prove that end state was reached?
  • If an attacker arrived through the least-used legacy path tomorrow, would responders immediately recognize it as a live authority incident, or would the first reaction still be but that system was deprecated?
  • Which authority migrations are currently trusted because a ticket says done, and what exact onchain or operational evidence proves the old signer, deployer, service role, or vendor console really cannot still act?

Lessons that should already be standard

  • Deprecation is a communication label; decommissioning is an authority transition. The first without the second usually creates an under-watched live risk surface.
  • Attention should decay only after authority does. Pulling docs, UI visibility, or staffing first is how legacy paths become high-leverage exploit routes.
  • Migration support is still production truth if the replacement keeps accepting the old system’s balances, proofs, or permissions as authoritative.
  • Residual custody and residual administration should almost never survive together. If old money is still there, the old control plane needs to be drastically narrower than the active product’s.
  • Immutable systems still need retirement design. We cannot upgrade it is not an argument for leaving broad exit, settlement, or custody semantics socially abandoned but economically live.
  • Downstream de-recognition is part of decommissioning. A surface is not retired if the rest of the stack still routes to it, collateralizes it, inherits admin trust from it, or otherwise keeps converting residual authority into ordinary production meaning.
  • Named residual ownership is a security control. Nobody really uses this anymore is not compatible with someone still needs to wake up when it moves money.
  • Every retirement needs a terminal condition. Without one, temporary compatibility drifts into permanent, weakly owned sovereign infrastructure.

How to use this note with the exploit corpus

  • Start here when the sharper question is what should a real decommissioning runbook prove before a retired surface stops being treated as production risk?
  • Pair with deprecation-without-deauthorization when the sharper question is the exploit family itself.
  • Pair with governance-decay-remnant-authority-capture when the narrower question is specifically that the electorate died before the governor did.
  • Pair with migration-trust-boundary-failure when the narrower question is the exact cutover-authentication bug in a replacement flow.
  • Pair with fresh-market-initialization-failure when the lifecycle mistake is unsafe activation rather than unsafe retirement.
  • Pair with exit-only-residual-surface-discipline when the old system cannot yet disappear because it still owes withdrawals or settlement, and the immediate design task is narrowing that legacy path into a bounded residual service.
  • Pair with exit-only-status-signaling-and-downstream-de-recognition when the residual service is already understood technically and the sharper design question becomes how users, routers, dashboards, and governance operators should keep treating it as withdraw only, still monitored instead of ordinary production liquidity.
  • Pair with machine-readable-residual-status-publication when the next design question becomes what exact structured residual-status object those downstream systems should consume.
  • Pair with residual-liquidity-segregation-and-active-tvl-hygiene when the next design question becomes how legacy balances should stop being presented as active TVL, healthy venue depth, or fresh collateral support while retirement is still being completed.
  • Pair with bridge-bounded-release-design when an old bridge lane or verifier path cannot yet be removed entirely and the immediate design task is bounding residual custody exposure.

Internal linkages

Control surface

Graph View

Backlinks