Cowrie Research

exit-only-residual-surface-discipline

14 min read

Exit-Only Residual-Surface Discipline

  • Name: exit-only residual-surface discipline
  • Category: lifecycle reference / residual-service checklist / immutable-system decommissioning note / withdrawal-surface control note
  • Summary: Some systems cannot be fully shut down the moment a team wants to move on, because they still owe withdrawals, settlement completion, bridge redemption, or escape-hatch exits. In those cases, deprecated is still the wrong mental model. The surviving code path is a residual production service, and it should be narrowed, monitored, bounded, and communicated as such. Just as importantly, teams need to inventory not only the obvious balance sheet still sitting on the old contract, but also the sidecar positions, helper routes, operator-path permissions, and default accounts that can still turn legacy state into cash. This note exists to preserve the positive-design companion for that narrower case: when full decommissioning cannot happen yet, what should a healthy exit-only residual surface look like before operators stop treating the old system like an active product?
  • Why this note exists:
    • decommissioning-authority-extinguishment-discipline covers the broader retirement question: what powers should disappear before a system stops being treated as live production risk?
    • Some high-signal failures are narrower: the old system could not disappear completely because it still owed exits, but teams still let it fade into a half-owned, weakly monitored residual surface.
    • The analytical win is to separate users still need a withdrawal path from the old product still deserves broad runtime authority. A healthy residual service keeps the first while aggressively killing the second.

The core design rule

If a retired system must survive for exits, it should survive only as an explicitly owned, tightly bounded, exit-only service.

Healthy operators should not let these remain equivalent:

  • withdrawals are still possible
  • the old product surface is still broadly live

The main separations healthy residual-surface design should preserve

  1. Residual exit obligation versus full product semantics

    • A system that still owes withdrawals does not therefore need new deposits, fresh issuance, collateral listing, reward logic, governance over siblings, or broad operator powers.
    • The residual path should do the minimum necessary to honor old claims and nothing more.

  2. Immutable code versus ownerless risk

    • We cannot upgrade this anymore does not mean nobody owns the risk anymore.
    • Immutable residual systems still need named monitoring, explicit alerting, user messaging, and downstream risk treatment while value remains exposed.

  3. Residual solvency versus downstream composability

    • If an old withdrawal path is still live, downstream systems should not keep treating that surface as fresh collateral, new migration authority, or ordinary production liquidity.
    • The exit path should settle legacy obligations, not seed new leverage.

  4. Withdrawal rights versus sibling authorities

    • Exit rights are often coupled accidentally to pause rights, upgrade rights, bridge lanes, migration certifiers, oracle publishers, treasury control, helper adapters, or operator-path permissions that were originally meant only to keep the system serviceable.
    • Healthy narrowing removes those sibling powers before the old system is allowed to persist.
    • The practical lesson from late-stage rollup and bridge incidents is that withdraw-only is false if an old operator path, bridge adapter, or helper account can still unwrap, sweep, or redirect sidecar value on behalf of the legacy system.

  5. Open-ended limbo versus named terminal state

    • Exit-only for now is only safe if for now ends in a defined terminal event: funds drained, claim window expired, bridge lane retired, or explicit residual-custody transfer complete.
    • Permanent ambiguity is how old systems stay dangerous for years.

What sound design looks like

1. Kill every non-exit path first

  • Disable new deposits, minting, collateral admission, reward accrual, governance proposal power, and upgrade-side reach before declaring the system residual-only.
  • If the system cannot technically disable a path, document it as still-live authority and keep it inside active monitoring and response assumptions.
  • Exit-only should be a technical state transition, not a blog-post adjective.

2. Narrow residual authority to one legible service

  • The remaining live surface should have one explicit job:
    • withdraw legacy balances
    • settle already-committed bridge or rollup exits
    • redeem old wrappers into underlying assets
    • complete a bounded migration unwind
  • A residual surface that still performs multiple unrelated product functions is not really residual.

3. Bound value and throughput where possible

  • Residual paths should usually be smaller, slower, and more capped than full production paths.
  • Useful controls include:
    • per-asset or per-epoch withdrawal caps
    • queueing or settlement delays
    • lane-local throttles for old bridge or rollup paths
    • explicit dust sweeps or treasury evacuation to shrink the residual balance sheet
  • If one residual bug can still empty the whole remaining pool immediately, the old system is still carrying production-scale risk.

4. Exhaust sidecar positions and helper routes

  • Residual reachability is usually wider than the direct token balances still visible on the old contract.
  • Teams should inventory and intentionally unwind or quarantine:
    • wrapper tokens, bridge positions, lending adapters, and vault shares still redeemable from the residual surface
    • operator paths that can still settle, unwind, or sweep positions on behalf of the old system
    • helper contracts, relayers, and queue processors that retain authority to complete legacy flows
    • default or test accounts that were granted residual roles during decommissioning work and then forgotten
  • Aztec Connect’s second wave is the clean reminder that leftover DeFi bridge positions can still be monetized after the headline drain, while Aztec 2.0’s copycat sweep shows that even tiny dust balances remain exploitable if a decommissioned operator path or default dev account still survives.
  • Review sidecars by redeemability class, not by token symbol alone: some leftover wrappers may still unwind cleanly into ETH, WETH, DAI, or other liquid assets, while others are already economically stranded. The former belong inside the exploitable residual balance sheet; the latter are still worth tracking, but they are a different incident-response priority.
  • A residual service is not truly bounded until these sidecars and helper rails are either dead, drained, or explicitly carried inside the residual-service risk budget.

5. Remove downstream recognition of the old surface as fresh truth

  • Downstream systems should stop treating the residual path as ordinary collateral, normal bridge inventory, or a live migration certifier.
  • machine-readable-residual-status-publication is the narrower policy-distribution companion when the next question becomes what exact structured residual-status object should tell downstream systems that the old path is now exit-only.
  • residual-liquidity-segregation-and-active-tvl-hygiene is the narrower accounting-side companion when the next question becomes how the balances left behind should be shown, routed, and risk-scored while the residual path remains live.
  • Healthy retirement often means:
    • delisting wrappers or bridge lanes
    • disabling borrow-side recognition
    • rejecting new proofs or certificates from the old system except for the narrow exit flow
    • stopping integrators from routing new user activity into the residual path
  • The old surface may still owe money, but it should stop authoring new economic meaning.

6. Keep explicit operational ownership

  • Exit-only systems still need:
    • a named owner
    • monitoring and alerting
    • clear user-facing status
    • a response plan for abnormal withdrawals or exploit signals
    • a review cadence while funds remain
  • The dangerous anti-pattern is renounced, deprecated, unsupported while real balances are still there.

7. Make the terminal event explicit

  • The residual service should have a known end condition:
    • all funds withdrawn
    • claim window elapsed and remaining balances swept or quarantined
    • bridge lane retired and wrappers burned
    • residual balances migrated into a defended custodian
  • Without a terminal event, exit-only easily degrades into forgotten but still funded.

What sound residual-surface discipline should prove

A strong residual-service record should be able to answer:

  • What exact exit obligation still remains?
  • Which non-exit authorities were removed before the residual path stayed live?
  • How much value is still exposed on the residual surface?
  • What caps, delays, or throttles bound one exploit attempt?
  • Which downstream integrations stopped treating the old system as fresh production truth?
  • Who still owns monitoring and incident response while the path remains funded?
  • What event will let operators finally stop treating the residual path as a live production risk?

Failure-prevention checklist

  • Force a technical exit-only state before attention decays: disable new deposits, minting, collateral admission, reward accrual, bridge ingress, migration certification, and any other path that can create fresh obligations.
  • Separate residual exit rights from broader authority. A withdrawal surface should not still carry upgrade power, oracle publication rights, governance reach, signer rotation, bridge lane management, or treasury control unless that power is explicitly still needed and actively defended.
  • Shrink the residual balance sheet aggressively. Drain treasury-owned balances, segregate user-liability reserves, and move anything not required for legacy exits out of the old surface.
  • Put hard blast-radius limits under the residual path: per-asset caps, per-epoch throughput limits, queues, settlement delays, lane-local throttles, and fast pauses should all assume the exit rail can still fail.
  • Inventory and remove residual helper authority: operator allowlists, relayer roles, queue processors, bridge adapters, and any default or test accounts used during migration or decommissioning should be treated as live production power until explicitly revoked.
  • Account for sidecar reachability, not just direct balances. Residual wrappers, redeemable bridge positions, adapter-held claims, and helper-controlled unwind paths belong in the same exit-only risk budget as the obvious on-contract assets, and should be triaged by whether they still unwind into liquid underlying versus merely persisting as stranded receipt tokens.
  • Remove downstream recognition of the residual surface as fresh truth. Delist wrappers, disable collateral usage, block new routing, reject new migration proofs, and stop counting residual liquidity as normal venue depth or active TVL.
  • Publish residual status in a machine-readable and user-visible way so integrators, dashboards, and operators all understand that the path is for legacy exits only.
  • Keep named ownership and incident response live while balances remain. Residual services still need oncall coverage, alerting, escalation rules, and a rehearsed plan for abnormal outflows.
  • Reconcile remaining liabilities against remaining assets on a schedule tight enough to catch residual-surface exploitation before losses are socialized elsewhere.
  • Define the terminal event up front: full withdrawal, claim-window expiry, bridge-lane retirement, residual-balance migration, or another concrete end state that actually lets the service die.
  • Test the forbidden paths continuously: prove the residual surface cannot mint, cannot certify new balances, cannot reopen ingress, and cannot regain production semantics through helper routes or downstream aliases.

Audit prompts

  • What exact non-exit powers still remain callable on this supposedly residual surface today?
  • Can the old path still create new liabilities, publish solvency truth, certify balances for a successor, or move custody beyond honoring already-existing exit rights?
  • If the residual verifier, bridge lane, wrapper redeem path, or withdrawal queue is wrong today, how much value is reachable before a human or automatic control can intervene?
  • What sidecar positions, helper contracts, operator paths, relayer roles, or forgotten default accounts can still turn residual state into cash even if the obvious contract balance looks nearly empty?
  • Are caps, queues, delays, and throttles enforced in code, or are they only operator promises?
  • Which downstream systems still treat this path as fresh collateral, route-worthy liquidity, migration authority, or canonical asset backing?
  • Has the team actually removed ingress and sibling helper paths, or only hidden them in the primary UI?
  • Who owns monitoring and response for the residual surface, and what alert would wake them before the whole remaining balance sheet is gone?
  • What exact event ends the residual service, and what evidence will prove that end state was actually reached?
  • Are residual balances segregated from treasury or active-liquidity balances so dashboards and integrators cannot accidentally normalize them back into production usage?
  • If the path is called deprecated, what technical property justifies that word beyond reduced attention or lower user traffic?

Lessons that should already be standard

  • Deprecated is a communication label, not a control state. If old code can still release value, it is still production security scope.
  • Exit-only is not a free pass to stop operating the system. It is a narrower production service that often deserves more explicit ownership because fewer people are watching.
  • Immutable residual paths are often riskier than upgradeable ones because teams are tempted to stop caring before the money is gone.
  • Residual reachability includes sidecars and permissions, not just balances. A nearly empty contract can still hide meaningful value in redeemable wrappers, bridge adapters, downstream positions, or forgotten operator roles, while other leftover tokens may be economically stranded and therefore should not distract responders from the actually cashable surfaces.
  • Residual liquidity should stop being treated as active TVL, healthy market depth, or fresh collateral support the moment the path becomes legacy-only.
  • User compatibility is not a reason to keep sibling authorities alive. The right question is always which exact powers are still necessary to honor existing claims and which can die now.
  • If one residual bug can still empty the whole pool quickly, the system was not meaningfully narrowed; it was merely neglected.
  • Sunset criteria are part of the security model. A service without a real terminal condition tends to drift from temporary residual path into forgotten funded surface.
  • The safest retirement flow removes recognition first where possible: old exits may still need to work, but the rest of the ecosystem should stop building new leverage on top of them.
  • A team that cannot name the owner, caps, remaining liabilities, and termination condition of an exit-only path does not actually have a residual-service design yet.

High-signal contrast cases

  • Aztec Connect shows the failure mode where a deprecated immutable rollup still owed withdrawals, but the residual service remained broad enough and funded enough that one proof/settlement mismatch drained millions.
  • Aztec 2.0 shows the narrower escape-hatch cousin: the codebase had moved on, but the old verifier and withdrawal path still controlled real funds, and even residual permissions remained meaningful after the main drain.
  • bridge-bounded-release-design is the useful custody-side companion when an old bridge lane or release path cannot yet disappear and the immediate design task is bounding how much damage one bad residual release can still do.

Red flags that usually mean exit-only is theater

  • The front end is gone, so nobody will use it
  • We renounced ownership, so there is nothing left to manage while the contract still holds funds
  • Only withdrawals remain but the same system can still mint, admit collateral, or certify migration balances
  • Users have plenty of time to exit with no residual owner, no alerting, and no clear end state
  • It is immutable anyway used as an excuse not to cap, quarantine, or communicate residual risk
  • The old path is still there for compatibility while integrators continue routing fresh activity into it

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks