[Proposal] A lifecycle for Redeemable + reference Flow D (redemption for cash)

[SergeevDmitry]

Summary

Redeemable appears in §5.2 as a servicing behavior, and §6.5 names redemptions as one of the places "where most operational risk lives", but the draft gives settlement a lifecycle (SettlementProposed → Committed → Settled | Aborted) and gives redemption none. I'd like to propose one, plus a reference flow.

Why it matters: for held-to-yield products (tokenized MMFs, T-bill funds, private credit), issuer redemption is the main exit, not secondary trading. Pantera's September 2026 State of Tokenization makes the same point: low spot volume does not mean holders can't exit. Today that exit is usually an off-chain promise. A standard lifecycle would make it observable and comparable across rails.

Proposed lifecycle

Requested → Funded → Claimed, with Requested → Rejected and Requested → Cancelled as terminal alternatives.

Transition	Who	Effect
request	eligible holder	asset tokens move into escrow; the quote is fixed at request time
fund	issuer / treasurer	the exact cash amount moves into escrow; irreversible
reject	issuer (with reason code)	escrowed tokens return to the holder; no cash moves
cancel	holder, after a declared timeout	escrowed tokens return if the request was never funded
claim	anyone (permissionless)	cash goes to the recorded beneficiary; tokens return to issuer inventory or are burned

Properties worth standardizing, independent of rail:

• Funded cash is ring-fenced. Once funded, no role can withdraw it; it pays only the recorded beneficiary, exactly once.
• Holder-side liveness. An unfunded request can always be unwound by the holder after a timeout declared in the manifest, so a silent issuer cannot trap tokens indefinitely.
• Pause semantics are explicit. For example, an emergency pause blocks payouts (claim) but not the holder's own unwind (cancel). Whatever a rail chooses, it should be declared, not implicit.
• Where compliance is checked. At request and at funding, versus again at claim. This interacts with Flow C (eligibility revoked mid-redemption) and should be stated.
• Events. RedemptionRequested / Funded / Rejected(reason) / Cancelled / Claimed, which fit under the existing ServicingEvent(type) umbrella and reuse the reason-code vocabulary from [Open Question] Machine-readable compliance reason-code taxonomy #10.

Draft Flow D: Redemption of a tokenized fund unit for cash

1. Holder calls request; canTransfer (pre-check) passes; tokens are escrowed; RedemptionRequested with the quoted amount.
2. Issuer funds in the declared settlement asset (trust tier per [Open Question] Settlement-asset tiering — a normative vocabulary for cash-leg trust tiers #13); RedemptionFunded.
3. Anyone triggers claim; cash goes to the beneficiary and tokens return to inventory or are burned; RedemptionClaimed.
4. Alternatives: issuer rejects with a reason code, or the holder cancels after the timeout; tokens return in both cases.

Prior implementation (EVM)

We run exactly this state machine in an open-source permissioned RWA stack, with invariant and adversarial tests (no partial funding, no fees, funding irreversible, cancel succeeds while paused while claim does not, timeout immutable per deployment within factory bounds).

Spec: https://github.com/devlab-group/rwa-platform-evm/blob/master/docs/spec/redemption-state-machine.md

Open questions

1. Partial redemption and batching (we chose none, for simpler invariants). Should the standard allow both?
2. Should the quote be fixed at request time, or at funding time for NAV-priced products with a dealing cut-off?
3. Burn on claim versus return to inventory: two declared variants, or one?
4. Should the timeout and pause behavior be required manifest fields for anything declaring Redeemable?

Happy to turn this into PR text for §5.2 / §6.5 / §8 if there's interest.