Developer Overview

Tidal lets your AI application make autonomous XRP and RLUSD payments from a user-funded budget account, without your application ever holding the user's main-wallet key and without asking the user to approve every transaction. You integrate once; from then on your agent can pay for resources inside limits the user set, and every payment is bounded, policy-checked, and auditable.

This page frames the mental model and shows where Tidal sits. The quickstart gets you to a first call; concepts, the integration guide, and the security model go deeper.

What integrating gives you

The core capability is a single, safe payment primitive for your agent: pay this destination this amount, once, within the user's authorization. Everything hard about doing that responsibly — key custody, two-party signing, policy enforcement, idempotency under retries and crashes, settlement and finality on the ledger — is handled by the platform and the SDK, behind a small surface you call from your backend.

Concretely, integrating gives you:

• A developer account model — an organization, application clients, and environment-scoped API credentials — that cleanly separates sandbox from production and one app from another.
• An agent identity and directory: you register each agent's public key under your own opaque user and agent identifiers, and the platform tracks its budget account and lifecycle.
• A user-authorization flow: your app requests authorization, the user approves it in their Tidal wallet within limits they control, and your agent receives only a reference — never the user's keys.
• An idempotent payment call that drives the whole connect-checked, policy-approved, two-of-two signed, settled-on-ledger lifecycle and returns a receipt.
• Webhooks for the events you care about — authorization approved, agent created, payment settled, payment denied, and so on.

The mental model

Three parties cooperate on every autonomous payment, and no single one of them can move money alone. Holding that separation in your head is most of understanding Tidal.

You (the agent developer) hold the agent's private key. It lives in your key store — a cloud KMS in production — and it never leaves it. The SDK asks your key store to produce the agent's signature over an exact prepared payment; it never sees or handles the private key itself. Tidal never holds an agent key, by design and by contract.

Tidal owns wallet execution and the second signature. A policy and risk authority independently evaluates each proposed payment against the user's authorization and limits; only when it approves does Tidal's co-signer produce the second signature. Tidal builds and tracks the payment, enforces idempotency, and reconciles finality — but it cannot pay alone, because it holds only one of the two required signatures.

The user owns the budget account's master key in their Tidal wallet. They fund the account, set the limits, and keep an emergency exit that works even if every Tidal service is offline. They are never in the per-payment hot path, but they are always the owner of the money.

Where Tidal sits

Your agent talks to your backend; your backend talks to Tidal through the SDK; Tidal and your key store together produce the two signatures; the assembled payment settles on the XRP Ledger.

flowchart LR
    agent["Your agent<br/>(runtime)"] --> backend["Your backend<br/>+ Agent SDK"]
    backend <--> keystore["Your KeyStore<br/>(AWS/GCP KMS)<br/>agent key never leaves"]
    backend <--> policy["Policy &amp; risk<br/>authority"]
    backend <--> tidal["Tidal wallet service<br/>+ co-signer"]
    tidal --> ledger["XRP Ledger<br/>budget account"]
    user["User's Tidal wallet<br/>(master key)"] -->|"funds &amp; authorizes"| ledger

    classDef yours fill:#e8f4ff,stroke:#4a90d9;
    classDef tidal fill:#e8fff0,stroke:#3aa76d;
    class agent,backend,keystore yours;
    class policy,tidal tidal;

The two blue boxes and your key store are yours; the green boxes are Tidal's. The XRP Ledger is neutral ground, and the user's wallet reaches it directly for funding, authorization, and their emergency exit.

Where Tidal sits relative to the XRPL

Tidal is not a new ledger or a token. It is a coordination and custody layer on top of the XRP Ledger. Settlement is an ordinary direct XRP or RLUSD Payment transaction; the ledger does what it always does — enforce signatures, quorum, and balances. Tidal's contribution is everything around that: giving each agent its own bounded account, requiring two signatures so no party acts alone, enforcing the user's policy before it will co-sign, and making the whole flow idempotent and recoverable. Autonomous payments are limited to direct Payment transactions — there is no escape hatch for signing arbitrary XRPL transactions from an agent.

Scope and honesty about maturity

Tidal V1 targets exactly one thing well: autonomous, bounded XRP/RLUSD Payment settlement for agents, on a per-agent budget account, with a user-held master key. It is deliberately not a general-purpose signer.

The developer platform's interface — the credentials, the SDK surface, the payment contract — has been specified and accepted for implementation, but it is a product under construction. Throughout these developer pages, anything not yet generally available or still being finalized is marked Draft — to be finalized. Notably, there is no publicly accepted hosted staging target yet, and some parts of the payment surface are shipping as smaller reviewed building blocks ahead of the full one-call flow. We document the accepted contract accurately and flag what is not yet live rather than imply a finished platform.

Read next

• Quickstart — the shortest path to a working call.
• Concepts — the objects and authorities, with an architecture diagram.
• Integration guide — the connect-to-settle lifecycle in sequence.
• Security model — custody, key separation, enforcement, revocation.