Basket impairment and recovery
A basket can be healthy but hard to sell, or it can have an actual component-transfer or backing problem. Those states require different responses.
The PRD defines required holder outcomes, but the recovery algorithm and its interaction with pool-held basket tokens remain unproven. The design below is not a verified recovery guarantee or live claims interface.
Identify the failure
| Situation | Intended treatment |
|---|---|
| Healthy backing and transfers | Complete in-kind mint/redeem remains available; trading additionally needs liquidity |
| Illiquid component market | Suspend affected new-launch admission when depth fails; preserve executable swaps and in-kind operations |
| Stale/missing dollar reference | Mark values stale/unavailable; stop price-dependent creation without a valid fallback |
| Verified transfer restriction or shortfall | Restrict affected issuance, launches and routes that cannot settle; investigate scope |
| Temporary impairment resolves | Resume only after transfers and full backing verify, before claims or distributions begin |
| Persistent impairment enters recovery | Preserve per-component healthy and later-recovery entitlements; recovery becomes permanent once claims or payouts begin |
An issuer API outage or stale feed is not proof of an onchain freeze. A restriction affecting one recipient is not by itself proof the entire basket is impaired. Controls and entitlements must follow the verified affected scope.
Recovery requires authorization and evidence
A timer cannot activate recovery. The approved 2-of-3 operations wallet authorizes incident state transitions with a reason, affected scope and supporting evidence.
A verified recovery state is different from a temporary issuance restriction. Before recovery claims or distributions begin, a resolved impairment can permit a validated restart. Once they begin, that basket remains permanently in recovery: normal issuance and full-basket redemption cannot resume.
What a basket holder keeps
Converting basket tokens to recovery entitlements consumes or escrows those tokens exactly once. The entitled wallet keeps its proportional rights to healthy components and to any later recoveries from impaired components.
Receiving the healthy portion must not surrender the impaired portion. Early and late conversion must preserve equivalent rights, without double claiming, first-exit priority or discretionary allocation to preferred wallets.
After conversion, recovery claims are non-transferable and paid to the entitled wallet. There is no claim marketplace, automatic component replacement, compulsory dollar payout or guaranteed amount or timeline.
Unconverted basket tokens retain their entitlements and existing transfer rules. Converting is not intended to create new rights at the expense of holders who convert later.
An illustrative incident
Suppose a basket contains X, Y and Z, and Z becomes persistently restricted. The product requirement is to let an entitled holder receive their available X and Y without losing their proportional claim to any later Z proceeds.
This example does not assign a payout amount or deadline. Engineering must still validate the activation denominator, component deficits, seizure, rounding, distribution history and subsequent recoveries. The simple healthy-redemption formula is not a complete recovery algorithm.
The holdings view should distinguish eligible unconverted receipts, issued wallet-bound claims, available healthy distributions, retained impaired claims and prior payment receipts.
Basket tokens inside locked meme liquidity
The current engineering direction leaves pool-held basket tokens unconverted under the principal lock while reserving their share of healthy assets and every later recovery.
A meme holder may obtain basket tokens through an executable sale and then convert those receipts. They do not receive a direct meme redemption right. Operators cannot convert or withdraw pool reserves on their behalf by bypassing the lock.
Conserving the entitlements of pool-held and wallet-held tokens through v4 settlement remains a specific unresolved validation requirement. If that cannot be proven, the implementation remains blocked; the approved direction alone is insufficient.
What to do when an action fails
Inspect the actual state, affected component and transaction receipt before treating a failed ETH route as lost backing. If ordinary redemption cannot transfer all components, it must revert rather than silently distribute a partial basket.
Use only a verified release's incident and claim surfaces when available. These initial docs provide no approved recovery-contract address, live claim action or promised support channel. Keep your wallet and receipts secure; a converted claim is bound to its entitled wallet.