Outcome-first execution, from intent to settlement.

The Router owns execution. The product owns the user.

Universal Router separates routing and execution infrastructure from wallet identity, UI and signer implementation. Products provide normalized wallet and source context. The Router owns provider comparison, route selection, preparation, submission, status, receipts and recovery.

Universal Router never stores wallet seed phrases or private keys. Signing remains outside the Router boundary. Before provider submission, signed execution is validated against the prepared execution commitment.

Describe the outcome, not the bridge.

The application specifies the result that must arrive. Provider-specific execution mechanics remain behind the Router boundary.

{
  "intent": {
    "recipient_address": "0x…",
    "requested_amount": "120.00",
    "requested_currency": "USDC",
    "destination_asset": "USDC",
    "destination_network": "BASE",
    "amount_mode": "EXACT_OUTPUT",
    "source_mode": "AUTO",
    "gas_policy": "AUTO",
    "payout_policy": "SINGLE_REQUIRED",
    "max_debit_usd": "123.50"
  },
  "wallet_portfolio": {
    "source_mode": "AUTO",
    "wallets": ["…"]
  }
}

One operation from intent to receipt.

Router v2 lifecycle endpoints use service authentication. Wallets and payment products integrate through an authenticated backend or service boundary; user authorization and signing remain client-side.

POST /v2/intents
→ POST /v2/intents/{intent_id}/quote
→ POST /v2/intents/{intent_id}/prepare
→ client authorization / signing
→ POST /v2/executions/{execution_id}/activate
→ POST /v2/executions/{execution_id}/submit
→ GET /v2/executions/{execution_id}/status
→ receipt / recovery

Provider integration is not binary.

A provider is not promoted merely because an API returns a quote or transaction payload. Capabilities are tracked independently and promoted from runtime evidence for a concrete route profile.

Capability status is route-specific. A provider can be verified for one execution profile while remaining certification-gated for another.

Execution supply competes behind one intent.

Eligible supply is filtered by account model, network, asset, execution capability and certification state. The product is not permanently bound to one provider.

Provider names describe technical integrations and capability evidence. They do not imply a formal partnership or endorsement.

Gas policy is composed separately from execution supply.

One intent layer. Multiple execution networks.

Universal Router normalizes network-specific signing, gas, provider and settlement mechanics behind one outcome-oriented execution model.

Network status describes concrete route profiles. It does not imply that every asset, provider or execution mode on the network has the same maturity.

BNB Chain across providers, accounts and networks.

BNB Chain is a first-class source and destination environment in Universal Router. Eligible BSC routes can be tendered across multiple execution providers while the Router composes account-aware gas policy, locks debit constraints and keeps status and recovery attached to the operation.

Provider-declared coverage is used for discovery. Execution availability remains route- and certification-specific.

Scoped verified does not mean blanket BNB coverage. BSC source handling is account-, asset- and route-specific. Native BNB is represented in provider discovery, while a native BNB-to-token route is not yet presented as runtime-certified.

Multiple sources. One exact recipient payout.

The verified profile combines Base USDC and Arbitrum USDC into one exact-output Base USDC settlement. BNB Chain is available to Nexus discovery, but it is not part of this currently settled multi-input profile.

Execution is a state machine, not a quote response.

Once submission may have happened, an unknown response is not permission to debit the user again.

Coordinate execution without taking custody.

Unknown post-submit conditions enter status resolution and recovery. Recovery can wait, continue, refund or require a manual action according to verified evidence.

Routes promote by evidence, not integration claims.

Certification applies to a concrete route profile rather than an entire provider or network. A transaction payload is useful evidence; it is not equivalent to safe end-to-end execution.

Selected runtime execution evidence.

Toward provider-independent exact-output settlement.

The reference settlement model is solver-fronted: the solver supplies destination liquidity, while the destination contract never receives user source principal. The settlement identifier binds source commitment, destination chain, token, exact output, recipient and deadline, preventing a second accepted fill.

The reference contracts, testnet artifacts and validation tooling are implemented, but resolver-to-settlement testnet end-to-end certification is still pending. Production execution is disabled.

The ERC-7683 resolver remains a non-executable reference model with explicit production blockers.

Universal Card is the first client of Universal Router.

Universal Card exposes the same infrastructure as a consumer flow: choose the outcome, review the maximum debit, authorize the locked operation and follow it through settlement or recovery.

IntentAuthorization
├─ recipient
├─ exact receive
├─ source debit ceilings
├─ route digest
├─ execution digest
├─ nonce
├─ expiry
└─ one-time execution

Explicit limits are part of the architecture.

Universal Router promotes execution profiles individually. Provider integration, successful quoting or network coverage does not imply blanket production readiness. Routes without sufficient execution, status or recovery evidence remain certification-gated or fail closed.