This guide walks through the complete lifecycle of a Delivery vs. Payment (DvP) settlement, from instruction submission to autonomous on-chain finalization.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.
What we are building
A tokenized private credit settlement where:- Seller delivers 100 tokens of a private credit fund
- Buyer pays 50,000 USDC
- Both legs settle atomically - either both complete or neither does
1. Browse available templates
Templates define the settlement workflow and are pre-configured by KeyStone. Browse the available templates to find the right one for your use case.dvp-standard template. Note the slug field - you will reference it when submitting instructions.
Templates are managed by KeyStone admins. If you need a custom template for your use case, contact your KeyStone representative.
2. Submit the seller instruction
The seller’s platform submits their side of the trade:trade_reference (e.g. KS-abc123...).
3. Submit the buyer instruction
The buyer’s platform submits the matching instruction:The
idempotency_key ensures safe retries. If you send the same key twice, the API returns the existing instruction instead of creating a duplicate.status: "matched" and a settlement_id. The settlement is created automatically on-chain.
4. Watch compliance run
After matching, the settlement engine screens all parties through LSEG World-Check (entity) and CipherOwl (wallet). Results are attested to the ComplianceRegistry on-chain, and the contract enforces that compliance must pass before the settlement can advance. If a party is flagged, the settlement pauses atCOMPLIANCE_CHECKING. A compliance officer reviews and submits a decision:
ROLLED_BACK.
5. Deposit to escrow
When the settlement reachesAWAITING_DEPOSITS, both parties deposit their assets directly to the escrow smart contract on-chain. Each leg in the settlement response includes a deposit_secret and deposit_key. Your platform calls depositLeg(settlementId, legIndex, depositSecret) on the escrow contract using its custody provider (such as MPC wallets or any signing infrastructure) to sign the transaction.
KeyStone is not involved in the deposit step. The escrow contract verifies keccak256(depositSecret) == depositKey to authorize the deposit - no address-based validation.
6. Contracts handle the rest
Once all deposits are confirmed, the contracts take over autonomously:- The escrow contract detects all deposits are complete and notifies the SettlementCoordinator
- The coordinator verifies the atomicity gate (all legs deposited on all chains)
- The coordinator calls
executeSettlement(settlementId, recipients[])on the escrow - revealing recipient addresses only at this point - Tokens go to the buyer’s wallet, USDC goes to the seller’s wallet
- Settlement transitions to
FINALIZED
7. Check the result
Track progress in the KeyStone Dashboard under Settlements, or via the API:What if something goes wrong?
- Compliance rejection - Settlement rolls back. No deposits affected.
- Deposit timeout - If deposits are not received by
timeout_at, the settlement transitions toTIMED_OUTand the escrow contract returns any partial deposits. Anyone can trigger this timeout permissionlessly on-chain. - Execution failure - The escrow contract rolls back, returning all deposits to their original owners.
Core Concepts
Deep dive into settlements, templates, and the state machine.
Bilateral Instructions
Full guide to instruction submission, matching, and cancellation.