Roadmap

A user who holds the same token on several networks sees a single balance: the sum of all of them. The platform keeps track of how much sits on each network and returns the total.

Nobody is asked which network to use. When the requested one cannot fund the amount and another holding the same asset covers it whole, the quote is issued on that other network, and its network and asset representation may differ from the ones the request carried. The same request against the same balances always picks the same network.

When no single network holds enough, the amount is settled as several transfers, each one within a single network, and the quote states how many there will be, which network each one uses and what each one costs before the sender confirms.

The unified balance is a field of the public API, has its type in the SDK, and is the number a conversational channel answers with when someone asks how much they have. The three surfaces read the same value.

The platform asks the live LI.FI service which routes exist for a pair of assets, what they cost and what state an execution is in. It only reads, so a Partner can see real prices and real route availability.

A route that crosses networks is quoted from the provider's live prices and can be executed from the API and the SDK. The execution is a labelled simulation: the answer says so and its hashes link to no block explorer. Settling the route for real on a public network, with a limit per tenant, a stop switch and a check that the route about to run is the one quoted, is what completes the capability.

The list of assets that can be swapped is built from the routes the aggregator actually covers. Asking for a quote on an asset with no route is answered with that reason, instead of an empty route. It covers the assets a Partner's production deployment enables on mainnet.

The cost on chain, in the network's own unit, with the account that paid it named: the Paymaster, the relayer, or the sender out of their own inputs on a UTXO chain. A path that cannot measure the cost says so, and never reports zero in its place.

An operation that settled on several networks — a send split across them, a cross-chain settlement — reports each transaction with the network it settled on and its explorer link. Attributing a flat list of hashes to networks was guesswork before.

The relayer, the operational validator, the Paymaster with its EntryPoint deposit and stake, the EntryPoint and the test-funding account, per network, with the balance each one has at the moment of the call. An account running dry is otherwise indistinguishable from a malfunction.

Each Partner's collection account, once per network, with what has accrued to it and has not been swept onto its address yet, per asset. The gap between the two is what a sweep closes, and the two disagreeing is the reconciliation signal.

A fee paid out of the user's balance and one the Partner absorbed are different money with different consequences. Reporting the split per operation and adding it up per period is what turns them into two figures instead of one.

Each type of operation has its fee defined in a catalog. The quote returns the amount that will be charged and what it corresponds to, calculated before the operation executes.

Money paid into a wallet's address by somebody else is observed and credited once its network's depth is reached; what cannot be attributed is recorded instead of credited, and a credit the chain drops is undone. What is open is the EVM network's own coin: on the deployed test networks a native deposit from an external address is not yet credited, and Bitcoin and Cardano deposits, read by the same component, have not been exercised on a public network yet.

A fee is priced by the policy of the Partner, the chain and the operation type, accrued to a collection account when the operation is booked, and swept to the Partner's collection wallet as an operation of its own. Charging on chain per operation would roughly double its gas for an amount usually smaller than that gas.

The collection address is configuration of the Partner and is replaced by an administrative operation that records the previous address, the new one, who ordered it and when. A rotation for every network rewrites every network that has a destination of its own, and says which ones it kept.

A Partner can pull the reconciliation of its own operations for a period: what was recorded, what the chain proved, and every case where the two disagree, separated into the ones the reconciler resolved and the ones left for manual review.

A daily process closes the period, calculates the balances of each tenant and produces a report with the movements and fees of the day, so the Partner can compare it against its own accounting.

The Partner sends an operation and immediately receives an identifier and a state. Settlement takes as long as the network takes, so the final state arrives through events or by querying the operation.

A typed client that handles authentication, idempotency keys, retries and the operation model. The Partner calls a method and receives the typed answer.

A phone number or an alias resolves to the wallet it belongs to, from the API and from the SDK, without creating anything. A recipient can be checked before an operation is built, and one who does not exist yet is answered as such rather than invented.

An example application that authenticates against the API, sends operations and receives webhooks. It verifies the signature of every delivery and rejects the ones that do not verify.

An anonymous visitor executes against real test networks under a visitor identity that carries no personal data, with amounts fixed by server policy and a daily budget for the environment. When the budget runs out it degrades to a labelled simulated profile instead of failing.

Every authenticated route is bounded per client, per tenant and for the deployment as a whole, and a caller over one of them is answered 429 with Retry-After before the work starts. Authentication says who is calling; it says nothing about how often.

A Partner that wants to hand its own users an interface gets one carrying its brand — colour, typeface, logo, domain and product name per tenant — built on the same API and SDK any integrator uses. It sits beside the main model, where the application belongs to the Partner and is fed by signed webhooks.

A single surface, with its own modules and permissions, where the Partner operates its channel and configures what belongs to it: networks, assets, capabilities, limits, fee policies, webhooks and channels. Every change is versioned, approved and reversible, over five roles and an append-only audit trail with secrets redacted.

The assistant runs as its own service against the public API, with a catalogue of functions that turns a message into a call. It was adapted from the assistant the consumer product already ran, so what a Partner gets on day one is a channel that works rather than one being written.

The assistant creates the operation through the same public API any other caller uses, under the same idempotency key, the same tenant limits and the same reconciliation. Asking twice moves the money once, and what happened is visible in the ledger and in the webhooks rather than only in the chat.

The portal talks to the same bot through a web channel of its own, so a visitor can try the conversational flow without a phone number. It runs under the same limits and the same environment budget as the rest of the Sandbox.

An operational surface over the assistant's own database, where the Partner reads what was said, and the modes, functions and templates behind it. It reads the conversations today; what is open is its access model for a Partner — the roles, and the deployment that separates one Partner from another.

A public Model Context Protocol server lets Claude.ai, Claude Desktop and any other MCP client read balances, deposit addresses and history, and price and execute transfers and same-network swaps. It operates one demonstration account shared by everyone who connects, on Arbitrum Sepolia and Base Sepolia, and every movement of funds executes the quote the person approved, within per-transfer and per-hour limits.

A Partner's user signs in from the AI client with OAuth and consents to what the client may do, and the server then serves that user's account alone. Reading and moving funds are separate permissions, every execution follows the Partner's limits and policies and the person's approval of the quote, and each one is recorded in the audit trail.

What the assistant may do is a declared list with its arguments, its permissions and its limits, checked before the call runs. A model cannot reach an operation that was not granted to it, and every invocation is recorded with what it asked for and what it got back.

Someone from the Partner steps into a live conversation, answers as themselves and hands it back, with the assistant held while they hold it. What was pending when they took over resumes exactly once when they release it, rather than being dropped or run twice.

Images, documents and voice notes transcribed to text, the interactive forms the provider offers, the service window that governs when a conversation may be started, and the approved templates for starting one outside it. The parts of the channel a real support conversation runs on.

Reaching many people at once, bounded by a declared budget and by the provider's own limits, with a switch that stops a running campaign at once. Whoever asks to stop receiving them stops receiving them, and that decision outlives the campaign that prompted it.

The Partner loads its own articles and the assistant answers from them, citing which one it used. A fixed set of questions with their expected answers is run against every change, so a new model or a new prompt cannot quietly make the answers worse.

Every state change of an operation produces an event. The Partner reads them from a cursor, or receives them as HTTP calls signed with its secret so it can check that they come from the platform.

When an operation is started from a conversation, the result is sent back through the same channel to the same user, so whoever asked for the transfer gets the answer where they asked for it.

The event is written to the database before delivery is attempted. If the destination fails, it is retried with increasing waits, and after the last attempt it is left in a separate queue for review.

A person starts an operation from a conversation, receives the quote with the amount and the fee, and confirms it in an explicit message before anything executes. The sender's identity comes from the channel.

Two more channels for receiving requests and sending back results, under the same limits, the same policy and the same confirmation as WhatsApp.

Signing runs in a separate service, inside the Partner's environment. The API sends a digest and a key reference and receives the signature; it never reads the private key.

A backend where the private key is generated and used inside the service and cannot be exported. The gateway asks it for the signature and receives the result.

Each operation carries an idempotency key. If the same request arrives again, the API returns the result of the first one instead of creating a second operation.

The Sandbox authenticates against the API with client credentials and obtains a token, with the same request and answer shape as the production flow.

A Partner gets its own instance, its own database and its own secrets. Isolation is the boundary of the deployment rather than a column in a shared table, so nothing another Partner runs can reach its data.

A caller proves who it is with a signed assertion instead of sending a shared secret: one key per client, named by its identifier so it can be rotated on its own, and an assertion that cannot be replayed. Tokens are short-lived and the registry of clients survives a restart.

The API, the SDK, the Sandbox and every operation state whether they run on a public test network or on a labelled simulation, so a simulated result is never read as a settled one.

One chart deploys the suite, and what it needs from a cloud is written as a list of requirements — a container runtime, a managed database, a secret store, a queue — rather than as the name of a provider. The GCP implementation of that list is the first one.

A pre-production environment with the same services, the same network topology and the same configuration as a Partner's production deployment, differing only in the volume of data and the scale it runs at.

Metrics, logs and traces that let one specific operation be followed across every service. Backups run on a schedule, and restoring them into a clean environment is exercised to confirm that they work.

A release to a production deployment reaches a fraction of the traffic first and is compared against the previous version before continuing. It can be paused at any point, and going back is a single step that has already been tested.