Skip to main content

​
Parties

A party represents an entity in a settlement with a specific role. Party details are provided inline when creating a settlement - there is no separate registration step.

​
Party fields

FieldDescription
roleThe party’s role in the settlement (e.g. buyer, seller, lender, borrower)
external_referenceYour platform’s identifier for this entity (e.g. user ID, account number)
nameOptional display name for the entity
wallet_addressThe blockchain wallet used for on-chain operations
chain_idBlockchain network ID (optional)
asset_providerOptional custody provider override
statusconfirmed or pending_confirmation (cross-platform)

​
Roles

Roles are defined by the template’s required_roles field. Every settlement must include parties covering all required roles. Role names are flexible - the template defines what roles are needed. Common role patterns:
  • DvP: buyer, seller
  • Repo: cash_provider, securities_provider
  • Lending: lender, borrower

​
Example: providing parties at settlement creation

{
  "parties": [
    {
      "role": "seller",
      "external_reference": "seller-acct-001",
      "name": "Acme Securities",
      "wallet_address": "0xSellerWallet...",
      "chain_id": 11155111
    },
    {
      "role": "buyer",
      "external_reference": "buyer-acct-002",
      "name": "Beta Capital",
      "wallet_address": "0xBuyerWallet...",
      "chain_id": 11155111
    }
  ]
}

​
Cross-platform parties

In cross-platform settlements, counterparty parties start as placeholders. The initiating platform specifies the counterparty by platform slug: 
{
  "counterparty_parties": [
    {
      "platform_slug": "platform-b",
      "role": "buyer",
      "wallet_address_hint": "0xBuyerHint...",
      "counterparty_reference": "Acme Fund LLC"
    }
  ]
}
The counterparty platform fills in the actual party details (external_reference, wallet_address, etc.) when they confirm. See Cross-Platform Settlements for the full flow.

​
Legs

A leg represents a single obligation within a settlement - something that needs to move from one party to another.

​
Leg fields

FieldDescription
leg_typeType of obligation: asset, payment, collateral, fee
instrument_idWhat is being transferred (token address, currency code)
quantityHow much
directiondeliver or receive from the party_role’s perspective
party_roleWhich party owns this obligation
chain_idBlockchain network (optional)
token_standardToken standard like ERC-20 (optional)
statusCurrent status: pending, locked, released, rolled_back
external_referenceOptional reference for this leg (e.g. trade ID)

​
How legs relate to parties

Legs reference parties by role, not by ID. This means: 
{
  "leg_type": "asset",
  "instrument_id": "0xTokenAddress",
  "quantity": "100",
  "direction": "deliver",
  "party_role": "seller"
}
This reads as: “The party with role seller delivers 100 units of token 0xTokenAddress.”

​
Multiple legs

A settlement can have any number of legs. The template’s required_leg_types ensures the minimum set is present:
Settlement TypeTypical Legs
DvP1 asset leg + 1 payment leg
RepoSecurities + cash + return leg
LendingSecurities + collateral + fee
NettingN legs across multiple parties
The escrow contract registers expected deposits based on the legs, ensuring all obligations are tracked on-chain.