Exchanges and custodians

This is the draft protocol’s proposed custody model. Node endpoints and SDK packages must be verified against an actual release before use.

Identify and credit deposits

Allow-list assets by AssetID. Any account can receive an asset, so an unfamiliar balance must not automatically become a credited customer deposit.

The draft offers two account models:

• Tagged deposits: one deposit account with a per-customer memo tag.
• Address pool: per-customer addresses generated offline, using hardened derivation.

Credit only when the matching transaction is final. In the proposed node API, that means finalized: true. Confirmations count progress; they do not replace finality.

Prepare withdrawals

The draft transfer has one memo for the entire transaction. Tagged recipients therefore need separate transactions. Untagged recipients can be batched within the protocol’s recipient limit, proposed as 256.

Read these values from the selected node before signing:

• Account nonce.
• Required fee.
• Public-key registration state.
• Transaction format version.

Preserve integer amounts and asset precision throughout construction, signing, and accounting.

Integration surfaces

Proposed service	Responsibility
Relay REST API	State, fees, configuration, individual records, broadcast
Indexer	Historical search and saved-event notifications through SSE
Mesh gateway	Data API plus Construction submit, hash, and parse
Shared Rust SDK core	Encoding and signing, with TypeScript and Go bindings

The proposed Mesh gateway exposes finalized history as its tip. Transaction construction and signing belong to the SDK; the gateway does not offer every Mesh Construction operation.

What can be tried now

The explorer API provides a local read-only sample ledger, and the wallet provider supports the portal’s devnet signed login. Neither is a deposit-crediting or withdrawal service.