| Atomic settlement | All legs settle or none do. No partial execution risk. |
| Bilateral instructions | Each counterparty submits their side of a trade independently. The system matches them by trade reference. |
| Chain ID | A unique integer identifying a blockchain network (e.g., 1 = Ethereum mainnet, 11155111 = Sepolia testnet, 84532 = Base Sepolia). |
| CipherOwl | On-chain wallet risk scoring provider used for compliance screening of blockchain addresses. |
| Commitment scheme | Privacy mechanism where deposit authorization uses a secret/hash pair instead of wallet addresses, preventing pre-execution information leakage on public chains. |
| Counterparty | The other party in a bilateral trade. In a DvP, if you are the seller, your counterparty is the buyer. |
| Custody provider | A service that securely stores private keys and signs blockchain transactions on behalf of institutional clients (e.g., Fireblocks, BitGo). |
| DvP (Delivery vs. Payment) | A settlement mechanism where the delivery of an asset and the payment happen simultaneously. Both legs settle or neither does. |
| Environment | An isolated workspace within a platform (e.g., development, staging, production). Each environment has its own settlements, webhooks, and API credentials. |
| ERC-20 | The standard interface for fungible tokens on Ethereum and EVM-compatible chains. Used for stablecoins (USDC), security tokens, and other transferable assets. |
| ERC-3643 | A permissioned token standard (also called T-REX) that adds compliance controls to ERC-20. Used for regulated security tokens. |
| Escrow | A smart contract that holds assets during settlement. Parties deposit tokens into escrow, and the contract releases them atomically when all conditions are met. |
| Idempotency key | A unique identifier included in create/submit requests to ensure the same request can be safely retried without creating duplicates. |
| Instruction | One side of a bilateral settlement submission. Contains the party’s details, their legs, and the template to use. |
| keccak256 | A cryptographic hash function used in Ethereum. In KeyStone, it is used for the commitment-based deposit scheme (deposit_key = keccak256(deposit_secret)). |
| LayerZero | A cross-chain messaging protocol that enables KeyStone to coordinate settlements across different blockchains without bridging assets. |
| Leg | A single obligation within a settlement. For example, a DvP has two legs: an asset delivery leg and a payment leg. |
| LSEG World-Check | An entity screening service by the London Stock Exchange Group used for KYC/AML/sanctions compliance checks. |
| M2M (Machine-to-Machine) | Server-to-server authentication using client credentials (client_id + client_secret) with no human user involved. |
| Party | An entity participating in a settlement with a specific role (e.g., buyer, seller, lender, borrower). |
| RWA (Real-World Assets) | Traditional financial assets (bonds, equities, real estate, etc.) represented as tokens on a blockchain. |
| Session token | A short-lived, scoped JWT created by a platform’s backend for browser-safe API access. Used by frontend integration packages. |
| Settlement | The complete lifecycle of a trade, from instruction matching through compliance, deposits, atomic execution, and finalization. |
| Template | A reusable configuration that defines the settlement state machine, required roles, leg types, compliance providers, and action handlers. |
| Trade reference | A unique identifier that links bilateral instructions together. The first instruction generates it, the counterparty uses it to match. |
| Wallet address | A blockchain account identifier (e.g., 0x1234...abcd on Ethereum). Used for depositing to escrow and receiving assets after settlement. |
