Token routing architecture
Route intent without hiding asset, policy, signing, or settlement risk.
Build token router nodes as transparent state machines for asset identity, discovery, quotes, simulation, policy, execution, finality, and reconciliation.
Token routing is not one protocol. A router may compare venues, select chain endpoints, coordinate bridge messages, build transactions, or invoke a custody system. Architecture begins by naming the object being routed and the stage the router owns. A proposed path is not settlement, and a successful API response is not final value transfer.
Use canonical asset identifiers that include chain, contract or native asset, standard, and decimals. Treat wrapped and bridged representations as explicit relationships rather than automatic equivalence. Registry changes are high-impact and need provenance, versioning, approval, and rollback.
Keep discovery, quoting, simulation, policy, execution, settlement monitoring, and reconciliation separate. Bind every stage to an intent ID and immutable versions of the quote, registry, policy, and transaction payload. If the quote expires or state changes, return to the relevant stage instead of silently executing a different route.
Signing should remain outside a general pathfinding process. Prefer unsigned payloads that a user or constrained signer approves. Show exact contracts, approvals, recipients, amounts, deadlines, and chain context. For cross-chain work, model source and destination finality as explicit states with evidence and idempotent retry behavior.
A router is an evidence pipeline
For every intent, preserve the exact asset identities, candidate paths, quote normalization, policy decision, payload, signer, submissions, confirmations, and reconciliation result.
Seven stages, no hidden leap
A trustworthy router shows how a request becomes an observed outcome.
Identify
Resolve exact chain, contract, standard, decimals, and asset representation.
Open guide →Discover
Find eligible venues, bridges, endpoints, or custody paths without assuming equivalence.
Open guide →Quote
Normalize amount, fees, gas, capacity, expiry, and minimum output.
Open guide →Policy
Filter contracts, providers, value, slippage, geography, and approval thresholds deterministically.
Open guide →Execute
Construct the exact payload, simulate, authorize, sign through a constrained boundary, and submit.
Open guide →Reconcile
Observe source and destination states, handle timeout, and compare expected with actual outcome.
Open guide →Make the hidden assumptions visible.
Each answer should map to a test, metric, policy, or runbook—not merely to a design claim.
No. A router may select or invoke a bridge, but it can also compare venues, choose endpoints, or build transactions. The bridge or venue has its own security and settlement model.
Different assets can share the same symbol, and bridged versions may have different contracts and risks. Execution should use chain-specific canonical identifiers.
A quote is a time-bounded claim under specific state and fee assumptions. Execution can fail or state can change. The router should expose expiry, minimum output, and final settlement evidence.
Pathfinding generally does not require custody. Where a service signs, isolate the signer and restrict it to exact assets, methods, amounts, chains, and authorized intents.