Roadmap

The whole transfer runs against an in-memory chain that always returns the same result: quote, confirmation, execution, reconciliation and events. It is the profile the Sandbox uses by default, so an integration can be written and tested before any network access is granted.

Transfers are sent as ordinary EVM transactions to a local Anvil node. The adapter builds the transaction, asks the gateway to sign it and broadcasts it, and the receipt comes back from a real EVM implementation.

The user's account signs an authorization that points its address at the Account Core contract. From then on it validates operations with the contract's logic while keeping the same address. Delegating, revoking the delegation and pointing at another implementation all work.

The operation travels as a UserOperation to an EntryPoint contract through a bundler, and a Paymaster contract pays the gas. This is what lets a user send a token without holding the network's native coin.

The API, the SDK and the Sandbox all reach Arbitrum Sepolia. A transfer started from any of the three ends in a transaction hash that can be looked up in a public block explorer.

The same three surfaces reach Base Sepolia, a network on a different rollup. Chain identifiers, contract addresses and RPC endpoints come from configuration, so enabling another EVM network is an entry in a manifest.

Sponsored execution on a public network needs an external bundler, a Paymaster with funds and a simulation before submitting. The work covers connecting those pieces and switching to a second bundler when the first one rejects the operation or does not answer.

Execution on EVM networks where the funds are real. It depends on the custody, security and operational capabilities listed in the other areas being finished first.

Bitcoin transfers go through the same Operation model as the other families, against a simulator that always returns the same result. The differences of the UTXO model stay inside the adapter.

A native adapter talks to a Bitcoin Core node running a private network. It chooses which UTXOs to spend, builds the transaction as a PSBT, sends it for signature and broadcasts it, including the change output that returns the remainder to the sender.

A Partner can send and receive Bitcoin against a private network from the API, the SDK and the Sandbox, with no wait for confirmations and no need for coins with real value. It is the environment for building the integration before going to a public network.

Bitcoin transfers on a public test network, where the fee changes with demand, a confirmation takes minutes and a transaction can sit waiting in the mempool. The adapter handles those conditions.

Bitcoin on the network where the funds are real. It requires replace-by-fee to raise the fee of a stuck transaction, locking the UTXOs already committed to an operation, a dust policy and handling of chain reorganizations.

The adapter builds Cardano transactions in their own shape: inputs, outputs, witnesses, change, validity interval and the minimum amount of ADA every output has to carry. It reads the protocol parameters from the node to calculate the fee.

Cardano signs with the Ed25519 curve. The Partner Signer Gateway carries that curve alongside the one EVM and Bitcoin use, holds the Cardano key references, and exposes the raw public key that the payment credential hashes. A Cardano key reference never derives the key of another chain for the same wallet.

A Cardano address is derived from the key hash alone. It can be shown to the user and receive funds as soon as the wallet is created, without sending any transaction first.

Sending ADA, choosing which UTXOs to spend and building the change output. The fee is paid in ADA taken from the transaction's own inputs, is measured from the transaction that settled, and is accounted as what it is: ADA that left the wallet.

An account with no ADA cannot send, because the fee comes out of the transaction's own inputs. The platform adds an input of its own and co-signs, so a user who was only ever sent tokens can still move them.

A component watches the chain for transactions that pay into a wallet, and checks that the amounts and assets that settled match what was recorded. The result updates the ledger and produces the corresponding event.

Every account has a payment key and a staking key, at roles 0 and 2 of one CIP-1852 account, and the address published carries both credentials. That is what makes an address on Cardano delegable at all: the staking credential is part of what the address is, so it cannot be added to one that already exists.

Transferring assets other than ADA in the same transaction, and delegating: registering the staking key on chain with its certificate — a refundable deposit of 2 ADA — and choosing a pool. Two commercial questions come first: whose the rewards are, and who picks the pool.

Cardano available on its public test network from the API, the SDK and the Sandbox. A Partner can send and receive ADA with no funds at risk, and check every transaction in a public explorer.

Cardano on the network where the funds are real. It depends on the custody, security and operational capabilities listed in the other areas being finished first.

Solana keeps balances in accounts owned by programs, and each token balance lives in its own separate account. The adapter derives and creates those accounts, and deposits the minimum amount of SOL they need in order not to be deleted.

Sending the native coin and SPL tokens through the same Operation model as the other families, building both the instruction that moves the amount and the one that creates the recipient's token account when it does not exist yet.

A Solana transaction carries a recent blockhash and expires a short while later. When it expires, the adapter builds it again with a new blockhash and asks for a new signature. The quote also states the priority fee and the confirmation level being waited for.

A component watches for incoming transfers and checks the settled amounts against the ledger, waiting for the confirmation level agreed for each operation before treating it as final.

Solana available on its public development network from the API, the SDK and the Sandbox. A Partner can send and receive SOL and SPL tokens with no funds at risk, and check every transaction in a public explorer.

Solana on the network where the funds are real. It depends on the custody, security and operational capabilities listed in the other areas being finished first.

Tron uses the same signature curve as the EVM family, so one key serves both, but its addresses are written in base58 and start with a T. The adapter converts between the two forms and stores the Tron address in the user's chain account.

Sending the native coin and TRC-20 tokens, the standard most stablecoins on Tron use. A TRC-20 transfer is a call to a contract, so the adapter sets the spending limit that call needs.

A Tron transaction spends bandwidth, and a contract call also spends energy. An account gets both by freezing TRX, or pays for them by burning TRX at the time of the transaction. The quote calculates the cost from what the sending account has frozen.

A component watches for incoming transfers and checks the settled amounts against the ledger, recording how much bandwidth and energy each transaction actually consumed.

Tron available on its public test network from the API, the SDK and the Sandbox. A Partner can send and receive TRX and TRC-20 tokens with no funds at risk, and check every transaction in a public explorer.

Tron on the network where the funds are real. It depends on the custody, security and operational capabilities listed in the other areas being finished first.

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.

Routes with several steps execute against local profiles. The result comes back marked as simulated in the API answer and on screen, and its transaction hashes do not link to a block explorer.

A route that crosses networks is stored as several legs, each with its own route identifier, amount, hash and state. That is what lets an operation report that one leg settled and another did not, and lets the part that failed be refunded.

Two assets on the same network are exchanged against a pool this deployment owns and prices, at a fixed rate rather than a market one. It exists because the aggregator does not recognise the test representations, so outside a real network nobody else quotes that pair. The quote states what will be delivered before it is accepted, and says that the route is not a market.

The same swap runs from the Sandbox through the SDK and from the conversational bot, because it is one more operation on the same API and not a feature of one screen.

Executing a real route on a public network, with a limit per tenant, a switch that stops execution when the service misbehaves, and a check that the route about to run is still the one that was quoted and confirmed.

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.

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.

The ledger checks that the unified balance equals the sum of the balances observed on each network's chain. When the two do not match, it records the difference and identifies which network it comes from.

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. The quote states how many transfers 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 contract a delegated account runs. Its variables are stored at slots calculated from a namespace, so a change of implementation can add state without overwriting what is already stored.

The wallet address is calculated when the user is created, before anything is written on chain. From that moment it can be shown and can receive funds, and it stays the same after the account is deployed.

The same user has the same address on every enabled EVM network, because the account is the wallet's own EOA: what each network holds separately is the delegation to the account implementation, not the address.

The key that authorizes operations can be replaced with a different one. The address, the funds and the account's history stay as they are, so a compromised operational key is replaced instead of migrating the wallet.

Recovering the highest authority is requested first and only takes effect once a waiting period is over. During that period whoever holds the current authority can cancel it.

A delegation can be withdrawn with an API call. The account goes back to being an ordinary account, keeping its address and its funds.

Every rotation, recovery and revocation is stored with its date and its result. That is what makes it possible to answer, afterwards, which key could authorize an operation at the moment it happened.

Validator, admin and recovery are three different keys, each with its own key reference. Whoever holds the operational key cannot change the account's configuration or recover it.

An account that is already delegated can be pointed at a new implementation with a new authorization. A deployed account receives corrections without moving the funds to a different address.

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.

Movements are written as entries that are never modified or deleted. A correction is written as a new entry, so the history shows what was recorded and when it was corrected.

After a transfer, the reconciler reads the transaction receipt and the Transfer event the contract emitted, and compares the amount and the recipient against what was recorded. The operation is completed only when both agree.

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.

The amount committed to an operation in progress is reserved in the database until it settles or fails. A restart between the quote and the settlement finds the reservation there, so the same balance cannot be spent twice.

Each execution path proves settlement in a different way: a UserOperation has its own hash and needs the EntryPoint event, a LI.FI route settles leg by leg, and a Bitcoin spend produces a change output. The reconciler reads each of those forms of evidence.

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 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.

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.

The Sandbox on this site executes with the published SDK against a running B2B API. The requests it makes are the same ones a Partner's code makes.

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.

The OpenAPI specification, the implementation and the SDK are generated and checked from the same source. A field that is documented but not implemented, or the other way round, stops the build.

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.

Exposing the operations of the API as Model Context Protocol tools, with the same authentication, the same limits and the same human confirmation required from any other caller.

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.

Deliveries are proven against a receiver that verifies the signature, keeps the valid ones and rejects the rest, with the result of each attempt recorded.

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.

Each of those roles signs through the gateway or a keystore, and every signature records which role produced it. The API asks for the signature of the role the operation requires.

The build runs static analysis over the contracts, the application code and the repositories, plus a scan for exposed secrets. A finding stops the build.

Dependencies with known vulnerabilities are updated or replaced, and the audit runs as part of the build so a new one is detected the moment it is introduced.

The signing keys the API can still reach move behind the gateway, so the API is left holding only public addresses and key references.

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.

State is stored in PostgreSQL and every schema change is a versioned migration applied in order. A database can be rebuilt from scratch by running them.

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.

Balances, reservations and ledger entries are stored as tables with keys and constraints, so the database itself rejects a negative balance or a reservation with no operation behind it.

Every query carries the tenant it belongs to, applied at the storage layer. A Partner's queries only reach that Partner's users, wallets and operations.

Short-lived tokens, credential rotation, and transport controls — TLS, allowed origins and request limits — for a deployment reachable from the internet.

The same code runs against four profiles chosen by configuration: an in-memory simulator, a local EVM node, a private Bitcoin network and public test networks. Every surface states which profile it is running on.

The same set of checks runs over every repository of the suite with one command. A change that breaks a different repository fails there.

Each end-to-end run saves its results — transaction hashes, receipts, deliveries — in files kept under version control, including the runs against public test networks.

Each repository declares a minimum coverage and the build fails when a change goes below it. The minimum is higher on the code that moves funds.

The end-to-end journeys run in the pipeline with no manual steps, including starting up the nodes they need and cleaning up what they leave behind.

The production topology is written down: which services run, how they talk to each other, where the data lives and which parts run inside the Partner's environment. The infrastructure work implements that document.

The development environment is described in infrastructure-as-code files, so it can be created, destroyed and recreated by running them, and a change to it is reviewed like any other change.

A pre-production environment with the same services, the same network topology and the same configuration as production, 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 reaches a fraction of the traffic first and is compared against the previous version before continuing. If it fails, going back is a single step that has already been tested.