Lanes

A quote’s winner discloses how the order must be opened. The SDK reads that into a lane (quote.lane.kind), and executeQuote runs it. You never branch on lanes to execute, but your UI can use them to tell the user what is coming. Which lanes a hub offers depends on its catalog and its providers. executeQuote refuses informational and unsupported quotes before any wallet prompt.

​

wrap-native

The quote carries one transaction (executionTx): wrapAndOpen(order) on the chain’s UserProxy, with the coin as value. Before the wallet sees it, the SDK checks:

• the target is the catalog’s UserProxy for the source chain, on the source chain;
• value is the amount asked for, and there are no approvals;
• the calldata is wrapAndOpen, and decoded: the order’s user is the funding account, its input is the wrapped native in the quoted amount, its output is the quoted amount of the asked-for asset, on the destination chain, to the recipient.

As soon as the wallet returns the transaction’s hash, the SDK registers the order with POST /order/openfor (no signature: the chain proves the deposit), then waits for the receipt. Registering at once matters: the aggregator refuses a registration once the quote’s expiresAt has passed, and a deposit registered too late is filled but never recorded. A reverted deposit throws WalletError (reverted): nothing was deposited. An unfilled order refunds the wrapped coin.

​

evm-permit2

The user signs an EIP-712 Permit2 order; a solver opens it on chain. The token needs an allowance to Permit2 (0x000000000022D473030F116dDEE9F6B43aC78BA3) first: executeQuote sends that approval when it is missing (permit2Approval: "unlimited" by default, or "exact"), before signing. The checks: the typed data is a Permit2 batch witness whose domain is on the source chain; the permitted token and amount are the input asked for; the witness’s user, recipient, output token, amount and destination chain match the request; its nonce, deadline and expiry are present; and on an auction, the signed amount is the auction’s floor. The signature goes to the hub with the one-byte 0x00 scheme prefix (66 bytes).

​

swap-token (token-in)

For a token the escrow does not take directly: the UserProxy swaps it into the wrapped native, then opens the escrow, in one transaction (swapAndOpenV2(order, tokenIn, amountInMax)). The quote’s pay amount is a ceiling: amountInMax, the most the swap may spend (slippageBps in the request, 1–1000). The SDK approves the UserProxy for exactly that ceiling, decodes the calldata like wrap-native, and also checks that tokenIn is the asked-for token and the ceiling is within the tolerance. Reverse (exact-output) quotes are refused on this lane: its price is only known from what the user spends.

​

solana-escrow

The hub discloses the escrow transaction’s message. The user signs it; a solver adds its fee-payer signature and submits it. Before signing, the SDK checks:

• the message parses (a legacy Solana message), its fee payer is the disclosed solver, and the user is one of its signers;
• the disclosed digest is the SHA-256 of those bytes;
• the sender is the funding account, and the fee payer is not the user.

The signature goes to the hub as 0x00 ‖ signature ‖ public key, base64. See Wallets for the signing strategies.

​

evm-3009

The user signs an EIP-3009 ReceiveWithAuthorization for a token that supports it; the aggregator settles it. The SDK checks that the typed data is an EIP-3009 authorization on the source chain, that its payer is the funding account and its value the quoted input, and submits the raw 65-byte signature.

​

open-flow

An aggregator’s own bridge or transfer: the user sends the disclosed transaction, then signs its intent (EIP-191), and the order is registered with POST /order. The SDK follows it on the hub’s lifecycle view (GET /status/{id}) until the recipient is paid or the order goes to recovery. Open-flow orders are not listed in GET /orders.