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 Partner's account adds an input of its own and co-signs. What is charged is a flat 0.45 ADA per transfer, the same figure for any amount, taken from the amount instead of added to it: sending 10 ADA delivers 9.55. A send below 1.42 ADA is refused when quoting.

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.

Moving a Cardano native asset without holding ADA. The network fee, and the minimum ADA the output carrying the token has to hold, are put up by the Partner's account, and a single fee figure is charged in the token that travels. The sender's ADA balance reads the same before and after.

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

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.

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.

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.

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.

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.

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 conversational bot runs as its own service against the B2B API, with a catalogue of functions that map a message to an API call. What belongs to a Partner — prompts, modes, the function catalogue — lives in its database, so the same code serves another Partner with another configuration.

The same conversation runs from a console client, so the whole journey can be exercised before a number is registered anywhere. It is the channel that proves the flow works without depending on an external provider being available.

A phone number of the deployment registered with the provider, with its verification token, its inbound webhook and its message templates approved. One number per deployment: the channel belongs to the Partner, not to the platform.

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.

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.

Which model answers is configuration of the deployment rather than a constant in the code, chosen per task and with a spending ceiling of its own. A provider that fails or prices itself out is replaced without touching the assistant, and what a conversation cost is a figure the Partner can read.

A long conversation keeps what matters instead of the last few messages: recent turns in full, older ones compacted, and durable facts about the person kept apart. The budget bounds what each turn costs, so a conversation that goes on does not get progressively more expensive or start forgetting silently.

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.

A message being processed when the service dies is picked up again rather than lost, and one that was already answered is not answered twice. Turns of the same conversation are handled in the order they arrived, and what could not be delivered after every retry is set aside for review instead of disappearing.

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

What belongs to a Partner — its prompts, its capabilities, its flows, its knowledge — lives in its own configuration, and the runtime operates on the declared shapes. A second Partner is a configuration rather than a fork, and ChatterPay's own API is one of the several an assistant may be given.

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.

Static analysis runs over the contracts, the application code and every repository of the suite, together with a scan for exposed secrets and an audit of dependencies, and each finding is recorded and tracked. Turning it into a gate that stops the build is a separate step.

Dependencies with known vulnerabilities are updated or replaced, with regression tests over the paths they sit on: signing and EVM on one side, PSBT construction on the other. A bill of materials and a scan of the release images come with it.

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.

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.

Every query carries the tenant it belongs to, applied at the storage layer with row-level security. A Partner's queries only reach that Partner's users, wallets and operations, even when the rows sit in the same tables.

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.

Each service proves its own identity to the next one, and the channel to the signer gateway is authenticated on both ends. Reaching the gateway from inside the network stops being enough to ask it for a signature.

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.

Pending work is taken from a queue in the database rather than from the memory of the process that received the request, and the workers that drain it run as their own service. A restart in the middle of an operation loses nothing.

How many concurrent operations the deployment holds before it degrades, measured and published rather than estimated, with the multi-user load run reproducible enough to be a gate a release has to pass.

Runtime state moves out of the memory of the process, so a second instance of the API is an equal rather than a second source of truth: shared idempotency and locks, and a relayer pool partitioned so two instances never fight over the same account.

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 and applied to a real project, so it can be created, destroyed and recreated by running them, and a change to it is reviewed like any other change.

Every service of the suite — the API, the signer gateway, the portal, the reference Partner and the conversational bot with its dashboard — runs deployed in the development environment, against a managed database, rather than only on a workstation.

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.

Every service writes structured logs carrying the operation identifier and the tenant, so one operation can be followed across the services it passed through. Keys, tokens, seeds and personal data never reach them.

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.