Cowrie Research

partial-successor-independence-and-graduated-residual-policy-lifting

13 min read

Partial Successor Independence and Graduated Residual-Policy Lifting

  • Name: partial successor independence and graduated residual-policy lifting
  • Category: lifecycle reference / successor-review note / residual-policy graduation checklist / decommissioning companion
  • Summary: Residual status should not disappear just because a wrapper, migration target, bridge alias, or successor product cut some dependency edges to an old surface. But residual treatment also should not stay all-or-nothing when a successor really does become partly independent in ways that matter for some downstream decisions and not others. This note exists to preserve the narrower design question that sits after residual-status inheritance: when a successor object is only partially independent from a residual surface, how should route scoring, treasury deployment, collateral admission, and discovery policy lift restrictions gradually without accidentally treating less coupled as fully healthy?
  • Why this note exists:
    • residual-status-inheritance-across-aliases-and-successors already preserves the default propagation rule: residual status should follow the dependency graph rather than stopping at the original object name.
    • machine-readable-residual-status-publication already preserves the policy-distribution question: how should residual treatment be published once as a canonical structured object?
    • residual-liquidity-segregation-and-active-tvl-hygiene already preserves the accounting-side question: how should balances tied to residual surfaces stop being mistaken for active TVL or healthy venue depth?
    • What still deserves its own note is the graduation layer between inherits full residual restrictions and fully healthy successor. A successor may sever one dependency edge while still relying on the old system for others. In that state, a binary legacy versus normal label is too coarse.
    • The analytical win is to separate some dependence disappeared from all downstream policies should now trust this object equally.

The core design rule

Residual-policy lifting should be edge-specific and decision-specific. A successor only escapes the restrictions tied to the dependency it actually severed.

Healthy systems should not let these remain equivalent:

  • this successor is no longer identical to the old residual surface
  • this successor is fully safe for routing, treasury deployment, collateral recognition, incentives, and default discovery

The main separations healthy policy graduation should preserve

  1. Brand-new object identity versus full economic independence

    • A new address, wrapper, route id, market key, or UI label is evidence of replacement, not evidence of independence.
    • Healthy systems ask which trust edges are gone, not whether the branding changed.

  2. Custody independence versus solvency independence

    • A successor may no longer share the old custody path while still inheriting the old redemption queue, accounting source, oracle path, migration certifier, or governance root.
    • Healthy systems avoid collapsing assets moved somewhere else into all downstream economic trust is now fresh.

  3. Exit compatibility versus fresh routing endorsement

    • A partially independent successor may deserve a narrower exit path or low-priority compatibility route before it deserves top-level route discovery.
    • Healthy systems keep can still help unwind legacy exposure separate from should absorb new default flow.

  4. Route eligibility versus treasury deployment eligibility

    • The fact that a successor can safely process small user exits does not mean treasury inventory, reserve management, or market-making capital should be deployed there at normal size.
    • Healthy systems treat treasury deployment as a stronger trust decision than mere user accessibility.

  5. Collateral eligibility versus venue discoverability

    • A successor might be discoverable for bounded swaps or redemptions long before it is safe as collateral or liquidation truth.
    • Healthy systems avoid one global supported bit that implicitly grants every stronger downstream privilege.

  6. Residual inheritance versus residual graduation

    • Default propagation should still fail closed.
    • Graduation should be explicit, scoped, and reversible as each dependency edge is retired or rediscovered.

What sound design looks like

1. Decompose successor independence by dependency edge

  • Review should not ask only is this successor independent yet?
  • It should ask at least:
    • does it still rely on the old surface for custody?
    • for withdrawal or redemption completion?
    • for accounting or oracle truth?
    • for migration certification or receipt validation?
    • for governance, pause, or operator authority?
    • for route settlement, inventory sourcing, or bridge release?
  • Policy should lift only along the edges that are actually gone.

2. Publish a per-successor policy vector, not one binary health label

  • A strong residual-policy object should let downstream systems evaluate separate decisions such as:
    • default routing
    • route ranking or score caps
    • treasury deployment eligibility
    • collateral eligibility
    • liquidation eligibility
    • incentive eligibility
    • default UI listing versus hidden/manual-only access
  • The useful object is not supported yes/no, but supported for which actions under which residual dependencies.

3. Make stronger privileges require stronger independence proofs

  • A successor that severed only one edge should not inherit all privileges automatically.
  • A useful rule of thumb is:
    • UI discoverability requires the weakest proof
    • bounded user routing requires stronger proof
    • treasury deployment and incentives require stronger still
    • collateral and liquidation truth require the strongest proof
  • The deeper the protocol relies on the object as balance-sheet truth, the less partial independence should count.

4. Use graduated successor states instead of legacy versus normal

  • Useful intermediate states often look like:
    • exit-only alias
    • bounded successor / limited fresh flow
    • discoverable but not treasury-eligible
    • treasury-eligible but not collateral-eligible
    • fully independent
  • The point is not label proliferation. The point is preventing teams from using one vague supported state to hide materially different trust assumptions.

5. Bind route scoring and treasury policy to the same graduation map

  • Route scorers, treasury managers, dashboards, and collateral engines should not each reinterpret partial independence locally.
  • Healthy systems share one graduation object so that:
    • route ranking stays capped while residual dependencies remain
    • treasury deployment stays bounded or prohibited when residual release or operator edges survive
    • venue-quality metrics do not silently normalize successor objects ahead of formal review
  • Otherwise one system starts acting as if the successor is healthy before the others are even reviewing the same dependency edges.

6. Keep downgrade and reversion paths explicit

  • Partial independence is not monotonic. New alias discovery, emergency fallback, shared operator overlap, or migration rollback can reintroduce old dependencies.
  • Healthy systems make graduated permissions revocable and publish what evidence would force a downgrade back toward residual treatment.

What sound graduated policy lifting should prove

A strong successor-graduation regime should be able to answer:

  • Which exact dependency edges to the residual surface still remain for this successor?
  • Which downstream permissions have been lifted already, and which remain withheld?
  • Why is this object eligible for routing, treasury deployment, or collateral treatment specifically?
  • Which privileges are still capped because some old trust boundary survives?
  • What evidence would downgrade the successor back toward stricter residual treatment?
  • Which systems consume the same graduation object instead of interpreting partial independence separately?

Failure-prevention checklist

  • Start from inherited residual treatment, then lift privileges one decision at a time. Successors should not jump from legacy-dependent to one global supported flag just because they severed one edge.
  • Review successor independence by dependency edge: custody, redemption completion, accounting truth, oracle path, migration certification, route settlement, governance control, and emergency authority should each be assessed explicitly.
  • Publish a machine-readable permission vector for the successor. Routing, ranking caps, treasury deployment, collateral eligibility, liquidation eligibility, incentives, and UI discoverability should be separate policy bits rather than one health label.
  • Tie stronger privileges to stronger proofs. Bounded manual access may be acceptable before treasury seeding, and treasury seeding may be acceptable before collateral or liquidation truth; downstream rights should not all unlock at once.
  • Keep route scoring, treasury policy, dashboards, collateral engines, and governance monitors on the same graduation map so one system cannot silently normalize a successor ahead of formal review.
  • Preserve conservative caps while any material edge survives. Score ceilings, flow limits, inventory caps, collateral denial, or incentive quarantine should remain until the specific residual dependency behind that restriction is actually gone.
  • Make downgrade paths real. If fallback routes, shared operators, hidden aliases, emergency-mode dependencies, or migration rollback reintroduce old trust edges, the successor should drop back toward stricter residual treatment automatically or via explicit review.
  • Distinguish user-unwind support from protocol endorsement. A successor that helps users escape legacy exposure may still be inappropriate for default discovery, liquidity mining, treasury inventory, or solvency-critical uses.
  • Record the evidence for each lifted privilege. Every permission increase should point to the concrete change that justified it so future reviewers can tell whether the supporting independence claim is still true.
  • Treat full graduation as a separate terminal state, not a vibes-based conclusion. The final step should require proof that the old residual surface no longer matters for any stronger downstream decision that remains enabled.

Audit prompts

  • Which exact dependency edges to the residual surface are still live for this successor today, and which ones are already gone?
  • What privileges has the successor already regained: UI listing, bounded routing, higher route ranking, treasury deployment, incentive eligibility, collateral recognition, or liquidation authority?
  • For each lifted privilege, what concrete evidence justified it, and where is that evidence recorded?
  • Which downstream systems still apply the strictest residual treatment, and are any other systems getting ahead of them by narrating the successor as fully healthy?
  • If the old residual surface failed tomorrow, which parts of the successor would still stop working economically or operationally?
  • Are there any hidden fallback paths, shared operators, migration certifiers, or emergency controls that could force the successor back into old dependencies under stress?
  • What caps remain in place on flow, inventory, venue ranking, incentives, or collateral treatment, and which residual edge is each cap meant to cover?
  • Could a user or integrator mistake discoverable or bounded access for a claim that the successor is safe for treasury, collateral, or liquidation use?
  • What exact event or review would let the next privilege tier unlock, and what evidence would force a downgrade instead?
  • Do route scorers, treasury managers, collateral engines, and dashboards all consume the same per-successor graduation object, or are they still improvising local judgments?

Lessons that should already be standard

  • Partial independence is not the same as broad safety. Cutting one legacy edge does not magically clean every downstream trust assumption.
  • Supported is too coarse for transitional successors. Systems need to know supported for what, at what cap, and under which remaining dependencies.
  • The most dangerous graduation errors happen when weak privileges and strong privileges move together. UI discoverability, treasury deployment, and collateral truth should almost never unlock on the same evidence.
  • A successor can be useful for unwinding legacy exposure before it is worthy of growth capital or solvency-critical roles.
  • Shared policy state matters as much as shared technical state. If routers, treasuries, and dashboards disagree on graduation, the ecosystem will drift toward the most permissive interpretation.
  • Downgrade logic is part of healthy graduation. Transitional systems should expect rediscovered dependencies, emergency fallback, and rollback scenarios instead of assuming independence is monotonic.
  • Evidence should travel with the privilege. If reviewers cannot say why a cap was lifted, the lift was governance folklore rather than a durable control.
  • Full independence should be a proved terminal state, not the default story teams tell once the successor feels socially normal.

High-signal contrast cases

  • residual-status-inheritance-across-aliases-and-successors is the immediate upstream companion because the right first move is still to inherit residual restrictions by default until independence is proven.
  • residual-liquidity-segregation-and-active-tvl-hygiene is the accounting companion when the next question becomes how partially independent successors should keep residual balances out of ordinary venue-quality and TVL narratives.
  • bridge-bounded-release-design is a useful custody-side analogue because it also separates some path is live from that path should control uncapped value; partial successor independence should likewise lift exposure gradually rather than all at once.
  • STAX preserves the migration-certification cousin where the replacement flow still trusted an old staking surface, so any notion of a fresh successor would have needed to stay narrow until that certifier edge disappeared.
  • Aztec Connect preserves the residual-withdrawal cousin where a conceptually old product still authored live withdrawal truth, showing why successor ecosystems should not lift route or solvency trust globally just because the main product direction moved on.
  • Moonwell Moonriver preserves the remnant-deployment cousin where a market can be socially secondary yet still too live for treasury, collateral, or governance systems to treat with ordinary confidence.

Red flags that usually mean policy graduation is fake

  • a successor gets one global supported flag immediately after any single dependency edge disappears
  • route ranking, treasury deployment, and collateral admission all flip at the same time despite different risk stakes
  • no one can say which exact dependency edges still remain
  • dashboards present a successor as healthy depth while treasury or collateral reviewers still privately consider it transitional
  • residual policy is inherited transitively, but lifted ad hoc through branding or governance announcements
  • there is no downgrade rule if hidden shared operators, route aliases, or fallback dependencies are rediscovered

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks