Routing and Defaults

This lens is for systems where the quiet power sits with path selection: who chooses the route, fallback, counterparty, or execution rail before the user notices.

Questions worth asking:

• Which bridge, verifier, wallet rail, liquidity source, or operator is selected by default?
• Who can change that path without changing the visible user surface?
• What happens when the preferred route slows down, fails, or is paused?
• Are users inheriting mutable defaults they rarely inspect?
• Is the decisive routing logic onchain, or buried in an API, console, or managed policy layer?

Curated comparison set

• Bridge-routing defaults: across and cctp
• Wallet and session-route defaults: walletconnect, walletconnect-network, and reown
• Payment-route defaults: open-payments, walletconnect-pay, and stripe
• Chain-operated path stack: base and coinbase

Keep the point sharp

• A route can look open while still being chosen by one wallet, issuer, operator, or API.
• Product shells like reown or coinbase can sit above open rails and still decide the path users inherit first.
• Fallbacks matter as much as the happy path; they reveal who still owns liveness.
• Managed path selection often recenters power even when settlement happens on open rails.

Focused traversal notes

• bridge-control-planes
• payment-routing-and-settlement-operators
• wallet-session-and-relay-rails

Useful comparison question

Did a system decentralize routing, or merely hide the router inside a cleaner operator stack?

Adjacent lens

• permissions-and-policy

• Last reviewed: 2026-08-13 UTC