Architecture

toda has five components: clients, APIs, the anchor service, Solana programs, and Postgres.

Clients

The SDK, dashboard, and browser extension write and read memory.

• The SDK uses API keys.
• The dashboard uses Sign-In With Solana.
• The extension uses a short-lived wallet session.

Clients can verify commitments against a Solana RPC without trusting a root returned by toda.

APIs

The APIs authenticate requests, encrypt and decrypt content, append leaves, and assemble proofs.

The API sees plaintext while processing a request. It does not store plaintext memory bodies.

Anchor service

The anchor service finds pending leaves, advances the Merkle tree, and submits the new root to Solana.

It holds the anchoring authority keypair. API processes do not.

Commitment program

toda-commit stores one fixed-size account per wallet.

Field	Purpose
owner	Wallet associated with the log
authority	Key allowed to submit roots
merkle_root	Current root
memory_count	Number of committed leaves
nonce	Commit ordering
last_updated	Last commit time

The program checks authorization, nonce order, and non-decreasing memory count. Root computation happens offchain.

Chain

Solana stores the root, count, nonce, and account ownership. Memory content and metadata are not written to the chain.

Data boundary

Data	Postgres	Solana
Memory content	Encrypted	No
Metadata	Plain JSON	No
Leaf hash	Yes	No
Merkle root	Yes	Yes
Memory count	Yes	Yes

Metadata is not encrypted. Do not store secrets in metadata.

API surfaces

Service	Port	Used by
Core API	3001	SDK and dashboard
Extension API	3002	Extension and capability grants

Both use the same database and leaf encoding.

Deployment

core API          :3001
extension API     :3002
anchor service    one active process
dashboard         :3000
postgres          :5432

Run one active anchor service per deployment. Nonce checks reject concurrent commits, but duplicate workers add unnecessary transactions.

Next: toda fundamentals.