exact

Fixed-amount payments — the standard x402 scheme, supported on all 14 networks.

exact is the standard x402 scheme: the payer authorizes precisely the amount stated in the payment requirements. It is the only scheme available on every network Solvador supports, and the right default for fixed per-request pricing.

EVM

On the 11 EVM networks, exact settles USDC via ERC-3009 transferWithAuthorization. The payer signs an off-chain authorization; Solvador submits it on-chain. Neither the payer nor your server spends gas.

Smart wallets

Smart-contract wallets are first-class payers:

Deployed wallets verify signatures via ERC-1271.
Counterfactual wallets — not yet deployed on-chain — are accepted via ERC-6492 signatures. On the wallet’s first payment, Solvador deploys it through its factory at settle time. Wallets from well-known audited factories are supported, including Coinbase Smart Wallet, Safe, Alchemy LightAccount, ZeroDev Kernel, and Biconomy.

Tokens without EIP-3009

Tokens that don’t implement EIP-3009 (such as USDG on Robinhood Chain) settle through Permit2: the payer makes a one-time on-chain approval to the canonical Permit2 contract, after which every payment is an off-chain signature like anywhere else. For permit()-capable tokens, that one-time approval can itself be gasless — see the eip2612GasSponsoring extension.

Solana

exact on SVM settles USDC using standard x402 Solana payment payloads.

NEAR

exact on NEAR uses NEP-366 delegate actions: the payer signs a delegate action and Solvador’s relayer wraps it in an outer transaction, paying the NEAR gas. Payers need no NEAR for gas.

XRP Ledger

XRPL is keyless: the payer signs the complete transaction, which carries its own sub-cent network fee. Solvador verifies the signed blob by simulation; at settle time it re-verifies, submits, and reports success only when the transaction is validated on-ledger with tesSUCCESS. XRPL settlements never count against your quota.

Example payment requirements

A resource server advertising exact on Base for $0.01 in USDC produces requirements like:

{
  "scheme": "exact",
  "network": "eip155:8453",
  "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "amount": "10000",
  "payTo": "0xYourReceivingAddress",
  "maxTimeoutSeconds": 300,
  "extra": {}
}

amount is in atomic token units (USDC has 6 decimals, so 10000 = $0.01). x402 client SDKs construct the signed payment payload from these requirements automatically — you never build scheme payloads by hand. For the wire format of the signed payload itself, see the x402 specification and the @x402/* client packages.

EVM