> ## Documentation Index > Fetch the complete documentation index at: https://docs.keystoneos.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Proposed Custody Architecture > A clearly labelled future design for settlement over custodial holds. Nothing on this page is available; every settlement today runs on escrow. **Proposed architecture, not an available feature.** No endpoint, field, state or webhook on this page exists. `GET /v1/platforms/me/capabilities` reports `chains.mechanisms: ["escrow"]`, every settlement read reports `execution.mechanism: "escrow"`, and the guides describe that mechanism only. Applied Blockchain may revise this design and its endpoint shape before anything is built; a partner integrating today should build against the escrow journeys and nothing here. ## Why a separate page The escrow mechanism deposits assets into the KeystoneSettlement contract and pays every leg out atomically. A custody mechanism would leave assets under each party's custodian and settle by coordinating holds and transfers there. The two are not the same lifecycle with different words: what a state proves, what a deadline means, and what recovery is are different in each. Keeping them apart is what stops a future custody rule from being read back onto escrow, and an escrow habit from being assumed of custody. ## The proposed flow, and how it differs ```mermaid theme={null} %%{init: {'theme': 'base', 'themeVariables': {'actorBkg': '#1a3a35', 'actorBorder': '#2DD4A8', 'actorTextColor': '#e0f2ef', 'actorLineColor': '#2DD4A8', 'signalColor': '#2DD4A8', 'signalTextColor': '#e0f2ef', 'noteBkgColor': '#162e2a', 'noteTextColor': '#e0f2ef', 'noteBorderColor': '#1AAF8B'}}}%% sequenceDiagram participant P as Each payer participant K as KeyStone (proposed) participant C as Custody provider Note over P,C: Proposed only. No route below is mounted. P->>K: Authorize the exact bundle (signed, per payer) K->>K: Register the settlement against the authorizations K->>C: Reserve each payer's assets (native, enforceable hold) C-->>K: Reservation evidence, expiry K->>K: Durable, immutable decision: SETTLE or ABORT K->>C: Deliver per ledger after SETTLE C-->>K: Delivery evidence per delivery group Note over K: After SETTLE: reservations are retained until delivery completes; recovery is delivery recovery Note over K: Only a proven ABORT releases a reservation ``` | Step | Escrow today | Proposed custody | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Agreement | Paired instructions or one direct create; the terms are the settlement | Each payer signs an exact-bundle authorization; a bundle nobody authorized cannot register | | Commitment of assets | A deposit into the contract, from the wallet the deposit key binds, before `timeout_at` | A reservation under the payer's custodian, with provider evidence and its own expiry | | Decision | None as a separate fact: the last deposit executes when the compliance gate is clear | A durable, immutable SETTLE or ABORT decision, recorded before any delivery | | Delivery | Atomic: every leg or none, in one transaction | Per ledger, after SETTLE; delivery may be partial across ledgers for a time and is completed by recovery, never reversed | | Release on failure | After the contract aborts or times out, deposits stay held until each deposited leg is refunded by a pull claim paying its recorded depositor; a timeout opens that recovery and releases nothing by itself | Only a proven ABORT releases a reservation. After SETTLE a reservation is retained until its delivery completes | | What `SETTLED` means | KeyStone observed the contract's execution event | A verified durable decision, not delivery complete on every ledger | None of the proposed rules on the right-hand side apply today. An escrow timeout changes only the contract's status: it opens pull-refund recovery and every deposited leg stays held in the escrow until its own `claimRefund` succeeds, which the recovery report shows as `funds: held_in_escrow` after `TIMED_OUT` and `refunded` only once the contract reports each leg refunded. Escrow has no decision record, and its recovery is that per-leg refund described in the [state machine](/concepts/state-machine#what-each-state-proves); nothing is retained for a later delivery and nothing is released automatically. ## What might be shared with escrow The settlement remains the business resource in both designs: its id, `trade_type`, pinned template, parties, ordered legs with stable ids, participant access, event trail and links. What the proposal adds would sit beside it, not replace it. The names under review are `/authorizations`, `/reservations`, `/decision`, `/delivery-groups` and `/recovery-package` as subresources of a settlement; they are review material, not an approved schema. Escrow funding instructions and custody preparation may turn out to need different endpoints rather than one shared command, and a custody execution may merit a linked resource of its own where one settlement can have several attempts. ## Unresolved questions These must be answered with provider evidence before any custody promise is made: * Who may submit the bundle, and how does that differ from each payer's exact-bundle authorization? * Does a durable draft precede registration, and what does abandoning an unregistered draft mean? * Which provider supports a native enforceable hold, with what evidence, expiry and recovery guarantees? * Which evidence proves registration, reservation, the immutable decision and final delivery, and at what finality? * Which confidentiality and token-transfer restrictions the proposed profile can satisfy? * Can escrow funding instructions and custody preparation share a useful endpoint, or are distinct commands clearer? * What constitutes a complete local delivery group, and how is partial delivery after SETTLE exposed? * How does a participant retain a usable recovery package before reserving assets? * Does a repo closing need fresh exact-bundle authorization at maturity, and who can provide it? Today's escrow closing is derived by KeyStone from the opening and funded like any settlement; no authorization step exists or is required. See [execute a tokenised repo](/guides/tokenised-repo#what-is-proposed-not-available). * Does a common settlement identity need separate execution attempts and storage records? Unknown external behavior stays unknown here rather than being filled in.