A route-data export gives a treasury team a reproducible record of what left, what arrived, and what each leg cost, provided it joins the route quote to confirmed on-chain evidence. Treat the quote as intent and chain records as settlement: a route marked complete does not by itself prove the destination amount or accounting value.
What should a route export contain?
Use one row per transfer route, plus linked rows for each on-chain leg and fee; this preserves detail when a single business payment crosses networks or swaps assets along the way. Assign an internal route ID and keep external transaction identifiers unchanged so the record can be traced back to source data.
- Intent: route ID, business purpose, requesting entity, quote timestamp, expiry, and quoted minimum output.
- Assets: source and destination chain IDs, token contract or mint, raw integer amounts, and token decimals.
- Settlement: source and destination transaction hashes or signatures, block number or slot, timestamp, and finality status.
- Costs: network gas, bridge or protocol deductions, swap spread or execution difference, and any separate service charge, each denominated in its actual asset.
- Valuation: functional-currency price, price source, timestamp, and valuation policy for both outflow and receipt.
Keep raw token units alongside human-readable amounts. ERC-20 values are integers scaled by token decimals; rounding the raw value before reconciliation can conceal dust or create a false mismatch. Store chain identifiers as well as names, and token contract addresses as well as symbols: “USDC” alone does not identify the same asset on every network.
How do you join a route to its settlement?
Model a cross-chain route as a state machine: quoted, submitted, source confirmed, destination observed, reconciled, or failed. The operator’s route ID connects the business instruction to those states; on-chain identifiers establish what happened at each chain boundary. This is where how quickswap bridges Bitcoin to Ethereum provides useful context for why a cross-chain movement can involve separate source and destination records. A quickswap-style bridge-and-swap flow still needs its own accounting trail built from those records.
On Ethereum, retrieve the transaction receipt and retain its transaction hash, block number, status, gas used, effective gas price, and logs. Decode token Transfer events for the actual movements; the transaction’s input data describes the call, not necessarily the final amount received. The Ethereum JSON-RPC specification defines receipt status as success or failure, but a successful receipt only means execution succeeded—it does not establish that the business instruction received its expected output.
For Solana, use the signature to retrieve the transaction and compare pre- and post-token balances by account index, mint, and owner. Solana’s RPC documentation notes that a newly created token account may appear only in postTokenBalances, so treat its pre-transaction balance as zero. On Arbitrum One, preserve the receipt and account for the parent-chain data component in the transaction cost; the Arbitrum documentation describes fees that include both chain execution and parent-chain posting.
How do you reconcile amounts and value?
Reconcile in token units first, then value each leg under the company’s accounting policy. For each asset, calculate source debit minus destination credit and identified deductions; do not net unlike tokens or assume a quote’s minimum output is the settled amount. Use a consistent valuation timestamp—commonly execution time for a realized transfer—and retain the price source for audit replay.
For example, say a route debits 10,000 USDC, shows 8 USDC in network gas and 12 USDC in separately identified route costs, and credits 9,980 USDC on the destination chain. The token movement reconciles: 10,000 − 8 − 12 = 9,980. If the export instead shows 9,970 received, leave a 10 USDC exception open until the destination transfer, additional fee, or partial execution explains it; do not bury the gap in “slippage.”
What exceptions should stop reconciliation?
Keep a route open when the source succeeded but the destination leg is absent, when a transaction reverted, or when the destination token contract or owner differs from the expected record. A quote that expired before submission is not a realized trade, and a replacement transaction should be linked as a new attempt rather than overwriting the original hash. For regular payouts, set a confirmation policy per chain and record both the observed inclusion time and the time the team considers the transfer final.
quickswap can be the practical route when a treasury needs to move an asset between networks and exchange it in one flow, but the export should remain independent of the service’s route status. Before acting, ask: can another reviewer reproduce every debit, credit, fee, and valuation from the identifiers and raw records in this file?
Top comments (0)