Cowrie Research

residual-status-inheritance-across-aliases-and-successors

13 min read

Residual-Status Inheritance Across Aliases and Successors

  • Name: residual-status inheritance across aliases and successors
  • Category: lifecycle reference / residual-policy propagation note / alias-graph de-recognition checklist / decommissioning companion
  • Summary: Marking one legacy contract or product label as withdraw only is not enough if wrappers, route registries, pool listings, migration helpers, market aliases, bridge-denom aliases, successor front ends, or governance views still point to that same residual dependency as if it were fresh infrastructure. Residual status has to follow the economic dependency graph, not just the original object name. This note exists to preserve the narrower design question that sits after machine-readable residual publication: once one surface is truly residual, how should that status propagate across aliases, wrappers, successor labels, and integration registries so downstream systems do not quietly reintroduce the old risk under a different name?
  • Why this note exists:
    • exit-only-status-signaling-and-downstream-de-recognition already preserves the communication-side question: how should users and integrators be told that a surface is withdraw only, still monitored?
    • machine-readable-residual-status-publication already preserves the policy-distribution question: what canonical structured status object should downstream systems consume?
    • residual-liquidity-segregation-and-active-tvl-hygiene already preserves the accounting-side question: how should residual balances stop counting as active TVL or healthy venue depth?
    • What still deserves its own note is the propagation layer between those answers and the actual dependency graph. A residual system often survives under more than one name: wrapped positions, route ids, migration adapters, bridge aliases, successor UIs, treasury inventories, market listings, and governance metadata can all keep treating legacy but still live as if it were merely a cosmetic rebrand.
    • The analytical win is to separate the old surface was marked residual from every alias and successor representation that still depends on it inherited the same restrictions until it proved real independence.

The core design rule

Residual status should attach to the dependency graph of a surface, not just to the surface’s original address, ticker, or brand string.

Healthy systems do not let these remain equivalent:

  • the old contract was marked withdraw-only
  • every wrapper, registry entry, pool alias, route, market label, migration helper, and successor-facing abstraction that still depends on it is safe to treat as normal production infrastructure

The main separations healthy residual-status inheritance should preserve

  1. Canonical object identity versus dependency alias identity

    • The original contract, bridge lane, market, or vault is not the only thing downstream systems see.
    • Wrappers, route ids, bridge-denom aliases, migration receipts, dashboard listings, and successor product labels can all become fresh-looking handles for the same residual dependency.
    • Healthy policy propagation tracks both the root object and the alias set that still resolves to it economically.

  2. Successor branding versus successor independence

    • A new front end, replacement wrapper, or renamed market is not automatically independent just because the UI says v2, new, migrated, or supported.
    • Healthy systems demand an explicit answer to does this successor still rely on the old path for custody, exits, accounting truth, migration certification, or governance?

  3. Residual support versus fresh route admission

    • A legacy dependency may need to remain reachable for exits, redemptions, or reconciliation.
    • That does not mean aliases pointing to it should stay eligible for default routing, collateral recognition, incentive programs, venue rankings, or treasury deployment.
    • Healthy inheritance keeps may still exit through this dependency separate from should still be discovered or promoted as fresh capacity.

  4. Alias inheritance versus explicit override

    • Default safety should be transitive: if a wrapper, route, or successor object still depends on a residual path, it inherits residual restrictions unless an explicit review proves otherwise.
    • Healthy systems make independence the thing that must be proven, not residuality the thing that must be rediscovered from scratch for every alias.

  5. Static deprecation labels versus live graph maintenance

    • Alias graphs change. New wrappers, dashboards, route adapters, and migration helpers appear after the original deprecation event.
    • Healthy systems treat residual propagation as a maintained dependency graph, not a one-time announcement.

What sound design looks like

1. Publish alias and successor coverage alongside the canonical residual object

  • A residual-status record should describe not only the root surface, but also the known aliases and successor-facing representations that still depend on it.
  • Useful coverage fields often include:
    • wrapper or receipt-token addresses
    • route ids, pool ids, registry keys, venue ids, bridge-denom aliases, or market ids
    • migration helper contracts and successor wrappers
    • UI or API identifiers that downstream systems use for discovery
    • explicit successor objects that still settle through, redeem against, or certify through the residual path
  • If downstream consumers cannot tell which aliases inherit the residual state, publication is incomplete.

2. Make inheritance transitive by default

  • If object B depends on residual object A for exits, redemption value, migration certification, route settlement, or governance authority, B should inherit residual restrictions until reviewed otherwise.
  • Healthy defaults often mean:
    • exclude inherited aliases from default routing
    • deny inherited aliases fresh collateral eligibility
    • classify inherited balances as residual rather than active TVL
    • suppress inherited aliases from best venue, healthy market, or supported default path lists
  • The burden should be on proving separation, not on remembering to copy deprecation flags manually.

3. Require an explicit independence proof before lifting inherited restrictions

  • A successor wrapper, route, or market should not escape residual treatment merely because it has a new address or label.
  • Healthy review asks whether the successor has actually severed:
    • custody dependence
    • withdrawal / redemption dependence
    • migration-certification dependence
    • oracle / accounting dependence
    • governance / emergency-control dependence
  • Until those edges are gone, the successor is a residual alias in practice.

4. Bind registries, dashboards, and route scorers to the same inheritance graph

  • Route registries, collateral engines, discovery APIs, dashboards, and governance monitors should consume one shared alias-propagation view.
  • Healthy systems do not let a dashboard say legacy, a router say eligible, and a collateral engine say supported about the same dependency chain.
  • If different downstream systems see different alias coverage, residual status has not actually propagated.

5. Publish how inheritance ends

  • Residual inheritance should have a terminal condition.
  • Healthy publication explains what event lets an alias stop inheriting residual treatment, such as:
    • the old path is fully drained and retired
    • migration certification no longer trusts the legacy contract
    • successor custody is independent
    • governance and emergency controls no longer share the old authority surface
  • Without a terminal rule, successor objects accumulate stale restrictions or, worse, drop them ad hoc.

6. Give consumers a safe unknown-alias rule

  • Downstream systems should have a deterministic answer for what if we discover a wrapper, route, or market alias that appears to depend on a residual surface but is missing from the published alias list?
  • Healthy defaults usually look like:
    • do not route fresh flow there by default
    • do not admit it as collateral
    • classify balances conservatively
    • alert maintainers to extend the alias graph
  • Unknown dependency aliases should fail closed relative to fresh production treatment.

What sound residual-status inheritance should prove

A strong residual-propagation regime should be able to answer:

  • Which wrappers, registry entries, route ids, pool listings, migration helpers, bridge aliases, and successor products still depend on the residual surface?
  • Which restrictions inherit automatically across those aliases?
  • What exact proof lets a successor stop inheriting residual treatment?
  • Which downstream systems consume the same alias graph for routing, collateral, dashboards, and governance monitoring?
  • What happens when a new alias appears after the original deprecation event?
  • What terminal event collapses the alias graph because the residual dependency is truly gone?

Failure-prevention checklist

  • Publish residual status on the root object together with the alias graph that still resolves to it economically: wrappers, receipt tokens, route ids, pool listings, migration helpers, bridge denoms, successor UIs, and governance metadata should all be in scope.
  • Make inheritance fail closed. If an alias still depends on a residual surface for exits, redemption, accounting truth, migration certification, or emergency authority, default it to residual treatment until independence is explicitly reviewed.
  • Separate new name from new trust boundary. A rebrand, new wrapper address, new route key, or successor front end should not lift residual restrictions by itself.
  • Feed one shared alias graph into routers, collateral engines, dashboards, treasury inventory, venue-ranking systems, and governance monitoring so downstream surfaces cannot disagree about whether a dependency is still legacy.
  • Define the override test in advance. Publish what evidence proves an alias or successor is actually independent enough to regain fresh routing, collateral, incentive, or discovery privileges.
  • Give unknown aliases a conservative policy. Newly discovered wrappers or route surfaces that appear to depend on the residual object should be blocked from fresh dependence until maintainers extend the published graph.
  • Track graph updates as ongoing operations work. New wrappers, migration helpers, registries, and successor products created after deprecation should trigger the same residual-propagation review instead of quietly escaping the old policy.
  • Distinguish inherited residual balances from active capacity. If an alias still points at legacy exit liquidity, those balances should not automatically count as active TVL, healthy venue depth, or fresh collateral support.
  • Keep terminal conditions machine-legible. Downstream systems should know what event ends inheritance: drained custody, severed migration certification, independent custody launch, removed shared governance, or explicit retirement of the old dependency edge.
  • Treat policy lifting as a new risk admission. Reclassifying an inherited alias back to active should require a deliberate review that the dependency graph really changed rather than a cosmetic metadata cleanup.

Audit prompts

  • What exact aliases, wrappers, registry keys, route ids, successor labels, migration helpers, and bridge denoms still resolve economically to the residual surface today?
  • Which dependency edges actually matter for inheritance here: custody, redemption path, accounting truth, migration certification, oracle dependence, governance control, or emergency authority?
  • If a successor claims independence, what concrete dependency edge disappeared, and where is that proof recorded?
  • Do routers, collateral engines, dashboards, treasury systems, and governance monitors all consume the same alias graph, or can one surface still treat the dependency as fresh while another treats it as residual?
  • What happens if a new alias is discovered tomorrow that is not yet in the published graph? Which systems fail closed, and which ones would accidentally admit it as active infrastructure?
  • Are any inherited aliases still receiving routing, incentives, collateral status, default discovery, or healthy-liquidity treatment because only the root object was tagged legacy?
  • Which balances or venue metrics still count inherited aliases as active TVL or live capacity even though the economic dependency is residual-only?
  • What exact event ends inheritance for each major alias family, and how will downstream systems learn that the terminal condition happened?
  • Could a migration helper, wrapper, or successor UI still certify value using the old path even though the product is socially narrated as v2 or migrated?
  • If the residual root object failed tomorrow, which supposedly fresh aliases would still break economically, and would current users or operators understand that ahead of time?

Lessons that should already be standard

  • Residuality is a graph property, not a naming property. Old risk almost never stays confined to the original address or brand string.
  • A successor label is not evidence of successor independence. v2, new, migrated, and supported are marketing or UX states until dependency edges are actually severed.
  • The most dangerous alias is often the one operators forgot to classify because it looked like a wrapper, helper, or route key instead of the legacy object itself.
  • Policy propagation has to be transitive by default. If teams must rediscover residual status manually for every alias, fresh dependence will eventually slip back in.
  • Residual exit support and fresh production endorsement are different products. Systems that keep those categories blurry quietly re-legitimize old trust boundaries.
  • Dashboards and registries are part of the control surface. If one discovery layer still treats an inherited alias as healthy, the retirement story is incomplete.
  • Unknown aliases should be treated as suspicious dependencies, not as proof that the old policy no longer matters.
  • The clean end state is not merely legacy root tagged. It is every economically equivalent handle inherits the right restrictions until real independence is proven, then the graph has an explicit terminal event.

High-signal contrast cases

  • STAX is the migration-path cousin where the replacement flow still trusted a legacy staking contract to certify redeemable balances, showing why successor labels must inherit residual suspicion until the old certifier is truly out of the trust boundary.
  • Aztec Connect shows the residual-rollup cousin where a product the ecosystem had conceptually moved past still authored live withdrawal truth.
  • Aztec 2.0 shows the exit-hatch cousin where residual withdrawal machinery needed to stay legible as a live dependency boundary after the main system direction had changed.
  • Moonwell Moonriver shows the governance-side cousin where a sleepy deployment needed machine-legible residual treatment across discovery and monitoring surfaces, not just social awareness that the market was effectively legacy.

Red flags that usually mean residual inheritance is fake

  • only the original contract address is marked residual, while wrappers, route ids, pool listings, or successor labels remain supported
  • a migration helper still trusts legacy certification, but downstream systems treat the new flow as fully fresh infrastructure
  • dashboards classify balances as active TVL because the alias object was not tagged even though the root dependency was
  • route registries and collateral engines each maintain their own local deprecation lists
  • there is no rule for newly discovered aliases or successor wrappers
  • a successor object loses residual restrictions because its branding changed, not because its dependency edges disappeared

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks