Skip to main content
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

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; 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.
  • Does a common settlement identity need separate execution attempts and storage records?
Unknown external behavior stays unknown here rather than being filled in.