What to Unify and What to Keep Distinct in a Multichain API

A business application has a transfer function: "A sends 10 units to B." It initially connects to one blockchain, but now needs to offer the same service to customers using other chains. Is adding a chain selector enough?

Checking the sender, recipient, asset, and amount is similar across chains. But one chain calls a token contract, while another consumes a bundle of assets that has not yet been spent. A recipient may need a token account or a tag in addition to a wallet address. Understanding these differences helps determine what a shared transfer screen can hide and what it needs to show.

We will examine this boundary through BXB's transfer implementations for EVM, Cardano, Solana, and XRPL. The illustrative examples each send 10 units on one of these chains. They do not describe a bridge moving the same asset between chains.

Four independent transfers starting with the same numbers

The first example uses ERC-20 token E on an EVM network; the second uses Cardano native token C; and the third uses token S issued through Solana's original Token Program. A native token on Cardano is a custom asset whose quantity the ledger manages directly, distinct from the native currency ADA. The fourth example sends XRP, the native asset of the XRP Ledger, or XRPL.

In each example, A has 100 asset units allocated for transfers and B has 0. Sending 10 units once leaves these transfer allocations at 90 for A and 10 for B. E, C, and S are different tokens, and A and B on each chain are independent senders and recipients. The numbers do not compare prices or exchange rates.

Assume E and S have zero decimal places, and one integer unit of C on the ledger is displayed as one token. The amount sent for each of these three tokens is therefore the integer 10. For XRP, we send 10 XRP, represented in the request as 10000000 drops, its smallest unit. One XRP equals one million drops.

Assume no minting, burning, token transfer fees, or concurrent transactions. Network fees and any required minimum balances are funded in advance. For XRP in particular, the transferred asset and the fee asset are the same, so 100 and 0 refer to transfer allocations excluding reserves and fees. We will account for the full XRP balances separately below. For the three tokens, 100 and 0 are the balances of those tokens, excluding ETH, ADA, and SOL holdings.

We can now describe what the business requests have in common. The following is an illustrative business model, not a single JSON format accepted by every BXB API.

Business decision	In the example	Meaning to preserve
Where to execute	One selected network	Distinguish production and test networks
Who sends and receives	A to B	Signing authority and recipient details
Asset and amount	10 E, C, or S, or 10 XRP	Asset identifier and amount unit
Request association	This one intended transfer	Later transaction queries and business records

Matching asset names do not identify the same asset. The business model needs both the network and the asset identifier within it. Even the number "10" cannot be executed until its meaning is clear: a display amount or an integer quantity on the ledger. If the example instead used a token with six decimal places, converting the displayed 10 tokens to 10000000 would be a necessary first step.

Select implementations for each chain behind the common entry point

BXB uses a namespace to distinguish chain families. It uses this namespace to select implementations for roles such as network connections, wallet management, proxies that forward requests, and API documentation generation. Components serving the same role have separate implementations for EVM, Cardano, Solana, and XRPL.

The namespace answers "Which set of rules should the implementation follow?" The selected network answers "Which ledger should execute the transaction?" Choosing the EVM family alone does not select a particular chain. The network specified by the business application and the registered asset must lead to the appropriate request construction and node connection.

This structure reduces repetition in integration code. The business server can retain its workflow for accepting a customer's transfer intent, checking whether the actor is authorized, and connecting the result to a business record. The chain adapter turns that intent into a transaction, the data to sign, and the queries needed to read its result. Defining common roles does not make all their inputs and outputs identical.

For example, an EVM token is located by its contract address, while a Cardano native token is identified by the combination of a policy ID, which identifies its minting policy, and an asset name. A Solana token type is identified by the address of an asset account called a mint. The asset in our XRPL example is XRP. Even if the business system manages these through a common asset ID, the adapter still needs the underlying identifiers. Changing the selected chain is therefore insufficient to reuse the previous chain's addresses or asset information.

On EVM, call the token contract and prepare the nonce and gas

To send 10 E, A requests transfer(B, 10) from E's token contract. In a standard ERC-20 transfer, recipient B and the amount are function arguments. The transaction itself is addressed to E's contract. This differs from sending 10 units of the native currency ETH to B.

BXB's EVM proxy encodes request arguments as call data using the ABI, which describes the contract's function interface. The ordinary signing path builds a transaction containing that data, signs it, and submits it. The conversion described in connecting a contract to a REST API applies here to the token's transfer call.

A's nonce and gas parameters are added at this stage. The nonce is a public value that represents the order of transactions A sends on this network. The gas limit and fee parameters set the resources and cost available for contract execution. The ordinary EVM path examined in BXB queries the sender's nonce and estimates gas to populate these fields. Ethereum's transaction documentation shows how the call data, nonce, and gas fields form part of the data being signed.

Here, assume A signs directly and pays gas in the native currency. Holding 100 E is insufficient to execute the transaction under these conditions if A cannot cover the gas fee. If the transaction succeeds as intended, A's E balance becomes 90 and B's becomes 10, while the execution fee is deducted separately from A's native currency balance. Separating token quantity from execution cost makes it possible to explain what "100 tokens available" on the transfer screen actually means.

On Cardano, select the assets to spend and the outputs to create

Suppose A's 100 C are held in one UTXO on Cardano. A UTXO is an output created by a previous transaction that has not yet been spent. The new transaction consumes it as an input and creates an output containing 10 C for B and a change output returning 90 C to A. It does not remove 10 C from the existing bundle while leaving the rest of that bundle in place. Cardano's UTXO explanation describes consuming inputs in full and creating new outputs.

Assume the input also contains enough ADA. Both B's output of 10 C and A's change output of 90 C must carry the required minimum ADA. The network fee is also paid in ADA. The token quantity is conserved as 100 = 10 + 90. The input ADA is divided among the ADA accompanying B's output, the ADA returned to A, and the fee. The ADA sent to B therefore remains an asset in B's output; it is not simply a consumed fee.

Minimum ADA is not a fixed cost per token. It depends on the size of the output and the protocol parameters, and the requirement applies to the change output as well as the recipient's output. Cardano's integration documentation explains the relationship between this minimum and the output's contents.

The native token transfer path examined in BXB specifies a recipient output using the asset identifier and a positive integer quantity. It uses a transaction-building library to select inputs, construct outputs, sign, and submit. This path treats an ordinary token transfer as an asset movement handled by the ledger. It does not directly translate an EVM transfer function call.

The business request is still "10 C to B." The adapter must determine which UTXOs are available and how to assemble the required tokens, ADA, and change outputs. If another transaction consumes the same UTXO first, the inputs need to be reconsidered. Renaming an EVM nonce cannot express this difference.

On Solana, prepare the recipient's token account and the transaction's validity window

On Solana, S is identified by its mint address, and A's and B's S balances are recorded in their respective token accounts. The wallet address represents authority to send tokens, while the token account holds the quantity for a particular mint. A wallet receiving several types of tokens needs a token account for each type.

The ordinary token transfer path examined in BXB uses A's and B's associated token accounts, or ATAs. An ATA is a token account whose address can be derived from the wallet, mint, and Token Program. The adapter derives the recipient ATA from B's wallet address and includes an instruction that can create it if needed in the same transaction as the transfer. Solana's token account documentation explains the relationship among wallets, mints, and ATAs, as well as the minimum balance required to create an account.

In this example, S uses the original Token Program and is sent with transferChecked. This instruction checks the mint and decimal precision along with the transfer amount. BXB uses the registered asset's decimal precision and accepts amounts in integer ledger units. Because S has zero decimal places, an amount of 10 takes A's S account from 100 to 90 and B's S account from 0 to 10.

A must hold SOL to pay the transaction fee. If B's ATA needs to be created, A, which funds its creation in this path, also needs enough SOL for the account's minimum balance. That minimum balance remains in the account, so it should not all be recorded as consumed alongside the network fee. Assuming both token accounts already exist in our example lets us distinguish token movement from the transaction fee without adding funding for a new account.

Submission also requires a recent blockhash. Including a recent block's hash establishes the window in which the transaction can be processed as valid. The transfer path examined here fetches this value and uses it for signing and submission. Solana's transaction structure explains the relationship among instructions, signatures, and the recent blockhash. If a transaction from this ordinary path is stored for a long time before submission, the blockhash's validity must also be checked. Checking whether the transfer amount is correct and whether the signed transaction is still eligible for submission are separate tasks.

On XRPL, include the XRP amount, sequence, and recipient requirements

Our XRPL example is a Payment that sends XRP directly. We selected native XRP because it is handled by the BXB asset and payment paths examined here. We do not extend this implementation's support to other assets or payment methods available on XRPL itself. In the XRPL Payment documentation, a direct XRP payment delivers the specified XRP amount to the recipient.

BXB reads the recipient address and amount in drops, then includes the sending account's sequence, the fee, and the last ledger index in which the transaction may be included. The sequence governs transaction order for the sending account, while the last ledger index places an upper bound on validity. These roles are defined in the XRPL transaction common fields. The sequence resembles an EVM nonce in representing order, but this does not make the transaction format or submission and confirmation procedures identical.

A destination tag may also be needed. When a service receives deposits for multiple customers at one address, the tag can tell it which customer should be credited. If the receiving account requires a tag, a payment that omits it is rejected. The BXB path also checks this recipient requirement before submission. The destination tag's role is to carry business information distinguishing customers behind an address. The adapter cannot simply generate a value to fill it in as it would prepare a nonce.

Now we can account for the XRP balances. Assume A and B are already activated and each holds its required reserve. On top of that reserve, A holds a transfer allocation of 100 XRP plus the exact fee for this transaction; B's transfer allocation is 0 XRP. After a successful transfer of 10 XRP, A holds its reserve plus 90 XRP, and B holds its reserve plus 10 XRP. The amount set aside for the fee is consumed. Reserves and transfer allocations are not held in separate accounts; we have divided one XRP balance into parts for explanation.

If an account's total balance were exactly 100 XRP, saying it has 90 XRP after sending 10 XRP would omit the fee. The reserve requirement must also be considered. According to XRPL's reserve documentation, the required amount depends on the network and factors such as ledger objects owned by the account. One fixed reserve amount cannot be applied when calculating every account's transferable balance.

Preserve support boundaries and completion criteria when presenting a common result

All four transfers share a goal: deliver 10 units of a specified asset to the recipient and connect the result to the business request. To achieve that, responsibility for handling each chain's differences can be made explicit. The component constructing the transaction handles the nonce, input UTXOs, recent blockhash, or sequence. Information known to the business, such as a recipient tag, and any additional native asset funding required must remain visible at the request stage.

Support boundaries must be made explicit in the same way. BXB's Solana token path examines a mint's extensions to determine which instructions to offer. If it encounters an extension it cannot interpret, it distinguishes support for reads from support for writes. This describes the instructions the current adapter understands, not a claim that Solana cannot transfer the asset. Supporting a chain does not mean supporting all its assets, every feature, or identical API endpoints.

When results are brought into a common screen, a single word, "success," is also insufficient. The following stages illustrate distinctions useful for business integration. They are not common status names returned by every BXB path.

Business stage	What to check	Decision in the example
Rejected before submission	Are the required details, assets, and authority available?	Do not start the transfer
Submitted; result pending	Which transaction on which network is being tracked?	Do not yet conclude that balances are 90 and 10
Business operation complete	Are the intended movement and required confirmation conditions established?	Record transfer allocations of A 90 and B 10, plus costs

The evidence used to establish completion must also be retained for each chain. An EVM receipt containing an execution result and a Solana confirmation status, for example, do not have the same response format. The Solana waiting path examined here accepts confirmed or finalized. If a business needs to distinguish those levels, receiving a response alone should not determine final completion. Keeping a common business status together with the chain-specific evidence used to reach it is a design requirement for handling these differences.

This association is also needed when a response is lost. As explained in transfer timeouts and retries, querying an existing transaction and creating a new one must be distinguished. Each chain adds its transaction ordering, consumed inputs, and validity rules, so the same retry action cannot be applied across every chain.

Unifying a multichain API starts with keeping the questions asked repeatedly by the business consistent. Who intended to send which asset, to whom, and in what amount? Which transaction and result did that intent lead to? The adapter's role is to preserve the asset identifiers, costs, execution conditions, and confirmation evidence needed to answer those questions for each chain.