What is the TBook RWA Platform
The TBook RWA Platform lets fintechs and corporates offer tokenized real-world-asset products — stablecoin yield, tokenized gold — to their users, or invest their own treasury, through one REST API plus webhooks.
You integrate once. Your users (or your treasury desk) deposit USDC, hold yield-bearing or asset-backed positions, and redeem on a published settlement schedule. You keep full control of the user experience and of signing keys: TBook never holds funds or keys. Every money movement is an unsigned transaction that the API builds and your wallet infrastructure signs.
Core concepts
| Concept | Meaning |
|---|---|
| Organization | The legal entity that contracts with TBook and owns API keys — a fintech, a corporate treasury client, an asset manager. Everything (accounts, webhooks, analytics, limits) is scoped to your organization through your API key. There is no orgId parameter anywhere: the key is the identity. |
| Account | An investment principal under your organization. Four types — individual, omnibus, treasury, business — explained in Account Models. Every position belongs to exactly one account. |
| Asset | An RWA product: rcusdp (USD yield backed by tokenized T-bill / money-market strategies) or xaua (tokenized gold, 1 token = 1 gram). Assets are native on Sui. |
| Rail | How funds reach the asset. The primary rail is sui:direct — the account's USDC is on Sui, the same chain as the asset, so there is no bridge. A legacy solana:gateway rail exists but is frozen (see below). |
| Vault | An investable instance of an asset on a rail: rcusdp-sui and xaua-sui are active; rcusdp-sol is a legacy vault that is paused. The API shape is identical on every rail; only settlement timing differs. |
| Transaction model | Build → sign → submit → confirm. The API returns unsigned transactions; a wallet-as-a-service provider (e.g. Crossmint), your multisig, or your own keys sign and submit them. |
Settlement is asynchronous
Deposits and redemptions are processed in settlement cycles (T+1 for rcUSDP, T+3 for XAUa). You never manage cycles — you observe them through settlementCycle fields and vault.cycle.* webhooks. Webhooks are the primary integration surface; no polling is required.
See Core Flows for the normative lifecycle of every operation.
:::note Legacy Solana rail (frozen)
The rcusdp-sol vault (solana:gateway rail) is paused: deposit and redeem builds return 409 vault_paused, while claim and cancel-deposit stay open so existing balances can always exit. New integrations should target the Sui vaults.
:::
Key properties
| Property | Description |
|---|---|
| Non-custodial | Unsigned-transaction API; your keys, your custody choices. Claims can only pay out to the account's own wallet — enforced on-chain. |
| Chain-agnostic by design | Assets, rails, and funding currency are decoupled. New chains and assets slot into the same API without changing your integration. |
| Multisig protected | Vault operations require on-chain multisig approval. |
| Audited | The Sui rcUSDP vault contract is third-party audited (ScaleBit/MoveBit) and live on mainnet. |
| On-chain verifiable | Vault state, share balances, and settlements are independently verifiable on-chain; the contract addresses are published in the open-source SDK configuration (@tbookdev/vault-sdk-sui). |
Where to go next
- Account Models — pick the right structure for your product. Read this first.
- How It Works — assets, rails, and settlement cycles.
- Quickstart — first deposit on sandbox in ~30 minutes.
- API Reference — every endpoint, field by field.