Documentation

Setra is the canonical settlement layer for tokenized equities on Robinhood Chain. Trading venues — DEXs, RFQ desks, and lending markets — match trades on top; Setra settles them through one canonical core. This page is the developer overview: architecture, the settlement interface, the sEquity standard, and how to integrate a venue.

1. Overview

Setra is infrastructure, not a venue. It does not match orders or quote prices. It provides atomic delivery-versus-payment (DVP) settlement, a canonical asset registry, multilateral net settlement, corporate-actions propagation, and proof-of-reserves attestation. One integration covers every canonical asset.

2. Architecture

A matched trade flows from a venue into the settlement engine, which validates both legs against the canonical registry and settles atomically. Reserve attestations and corporate actions are handled at the settlement layer, so every venue reads from one source of truth.

• Venue — matches the trade and submits a signed settlement intent.
• Settlement engine — validates the token leg and the payment leg; executes atomic DVP.
• Canonical registry — maps each sEquity to its underlying share, custodian, and supply.
• Attestation — posts continuous proof-of-reserves on-chain.

3. The ISettlement interface

Venues integrate through a single interface. A settlement intent describes the buyer, seller, sEquity asset, quantity, payment token and amount; it is signed and submitted to settle(). The engine checks the deadline, prevents replay, verifies the asset is canonical, and moves both legs together — or reverts.

settle(SettlementIntent intent, bytes signature) → bytes32 id

Batches settle net through settleBatch(): offsetting positions are netted and only the difference is transferred.

4. The sEquity standard

An sEquity token represents one real share held in attested custody — sAAPL = one AAPL share, sTSLA = one TSLA share. Tokens are minted and redeemed only by authorized participants against custody, ETF-style. Transfers are permissioned (allowlist / lockups), and corporate actions — dividends, splits, mergers — propagate to holders automatically.

5. Core primitives

• Atomic settlement (DVP) — token leg and payment leg settle together or not at all. No half-fills, no failed-leg exposure.
• Canonical registry — one token per real share; ISIN/CUSIP mapping; one fungible asset across every venue.
• Net settlement — multilateral netting; settle net, not gross; less on-chain load, lower counterparty risk.
• Corporate actions — dividends, splits and mergers applied at the settlement layer.
• Proof-of-reserves — continuous custody attestation; supply provably matches reserves.

6. Integrate a venue

• Connect — point your DEX, RFQ desk, or lending market at Setra through the ISettlement interface.
• Submit — route matched trades to Setra; the engine validates both legs.
• Settle — atomic DVP, net positions, deterministic finality, reconciled to custody.

7. $SETRA and security

Settlers stake $SETRA to guarantee finality and are slashed for settlement faults; a guarantee fund backs settlement risk. $SETRA also governs the canonical registry. You do not need $SETRA to settle — fees are paid in the settled asset. $SETRA is not launched yet.

8. Status

• Testnet — live.
• SDK — shipped.
• Audit — in progress.
• Mainnet — not yet.
• Token — not yet.

9. Contact

Integration questions: reach the team through the community channels linked in the footer.