Skip to main content
Not yet released. The packages on this page are not published to npm yet, so the install commands below will not resolve. The documented interface is stable and the code exists; only publication is outstanding. To use KeyStone from a frontend today, call the REST API or the TypeScript SDK, which is published. Contact us if you need early access.
This guide walks through building the instruction flow - where a seller submits their side of a trade, shares a trade reference with the buyer, and the buyer submits the counterpart instruction to create a settlement.

Prerequisites

  • @keystoneos/react installed
  • KeystoneProvider configured with a session token that has settlements:write and templates:read scopes, and no settlementIds restriction (an instruction has no settlement yet)
  • A React project with TypeScript

How settlement works

In a paired flow, two independent parties agree on a trade off-platform (via phone, email, or OMS). Each party submits their side of the pre-agreed trade to KeyStone. KeyStone compares the two sides on instrument, direction and quantity, and creates the settlement only if they agree. It does not bring together buying and selling interests: the parties selected each other upstream and both present a shared trade reference. KeyStone does not price, net, allocate, or take custody. The key points:
  • The first party to submit gets status: "pending_match" and a trade reference
  • The second party submits with that trade reference and gets status: "matched" plus a settlement ID
  • Either party can be the first to submit - there is no required order
The pending_match / matched statuses describe reference correlation of a pre-agreed trade, not order matching - see what “matched” means.

Understanding legs

A DvP (Delivery vs Payment) settlement involves two legs: Each party submits both legs in their instruction. The direction is derived automatically from the role:
Each leg specifies its own chain_id and instrument_id (the token contract address).

Building the instruction form

Template selector

Start by letting the user pick a settlement template. Templates define the structure of the settlement (roles, leg types, state machine).

Trade reference input

When confirming against an existing instruction, the user provides the trade reference they received from the counterparty.

The complete instruction form

This form collects role, party details, template-driven legs, and optional trade reference. Each template defines which leg types are required - for DvP, that is asset_delivery and payment.

Handling results

Pending counterparty (pending_match) - share the trade reference

When the submission returns pending_match, the counterparty has not submitted yet. Show the trade reference prominently so the user can share it.

Matched - navigate to settlement

When the submission returns matched, both sides are in. Navigate directly to the settlement detail page.

Realistic example flow

Here is how a real trade looks end-to-end: 1. Seller at Securitize submits both legs:
2. Seller shares KS-abc12345 with buyer via email or OMS. 3. Buyer at Ondo Capital submits with the trade reference:
4. Settlement is created automatically. The confirmation response carries the new settlement_id; the settlement starts at INSTRUCTED and the engine begins compliance checks. The first webhook both platforms receive is settlement.state.awaiting_deposits once compliance clears (or settlement.state.compliance_checking if a party is flagged).

Error handling

Next steps

Settlement Dashboard

Build a dashboard to monitor all your settlements.

Real-time Tracking

Track settlement progress with live updates after confirmation.

useSubmitInstruction Reference

Full API reference for the useSubmitInstruction hook.

Submitting Instructions Guide

Server-side guide for instruction flow using the SDK.