Integration guide

Redacted is built to be embedded. The same engine behind our interface, with its private accounts, browser proofs and relayed execution, is available to wallets, frontends and protocols that want privacy as a feature.

The model in one minute

• The Reserve holds everyone's notes in one shared, shielded space. User ownership is note-based and reconstructed client-side from public chain data, and no server holds account state.
• Spending is the user's private smart account. Use its address for product balances and positions while Private Mode is active, and never the connected public wallet's.
• Every action is authorized client-side by a proof that is bound to its exact intent, which covers the operation, amounts, destination or calls, fee, relayer and expiry.
• The relayer submits the outer transaction and pays gas, and what it charges is part of the quoted fee. With the node network, relaying is done by bonded nodes, which governance admits at first and which anyone who posts the bond can run once admission opens (see Running a node).

Execution lifecycle

1. Build the product intent, with its destination, messages, amounts and limits.
2. Fetch the current fee quote and show the user the full economic effect before confirmation.
3. Generate the proof in the client, bound to the active private identity and the exact intent.
4. Submit to the relayer, and keep the request id and transaction hash.
5. Resolve the on-chain outcome from the chain itself, then refresh notes, balances and positions from confirmed state.

The golden rule is that secrets stay in the client. Root keys, passphrases and proof witnesses never travel, and the relayer only ever receives sealed, proof-bound actions.

Funding flow

Funding is explicit. Funds go from the public wallet to the Reserve and from the Reserve to Spending, and they act from Spending and come back the same way. A pattern that works well in the interface is to open the right funding dialog automatically when an action is underfunded, so the user never hits a dead end.

Practical notes

• Treat chain state as the single source of truth. A lost network response is not a failed transaction, so reconcile by hash before allowing a retry.
• Guard against concurrent use of the same note state in flight, and refresh after each confirmation.
• Wallet support rides on standard signing. EVM wallets sign the sign-in message as a plain personal message (EIP-191, for example MetaMask, Rabby and Trust), Cosmos wallets sign it with ADR-36 (Keplr and family), and both derive the private account from that one deterministic signature.
• Each release publishes its contract identities, supported message types, supported products and API schema, and you should integrate against a matching set.

Talk to us in Telegram about partner integrations. Revenue sharing for integrators is coming, as described in Build on Redacted.

See Architecture, Relayer and Fees.