executeQuote takes the user’s wallets as { evm?, solana? } and only calls the one the quote’s source chain needs. The SDK ships adapters for the common cases. Anything else implements a small interface (see Your own adapter).

EVM

evmWalletFromEip1193 options

Chain-instance pins

Two chains can share a chain id. A test “Ethereum” that is a mainnet fork answers eth_chainId 0x1, exactly like real Ethereum. A wallet pointed at a public RPC would then sign and send to real mainnet, and a signature made for the fork is valid on mainnet too. A pin names a block that exists only on the chain you mean. Before signing on that chain, the adapter reads the block and refuses (WalletError, reason wrong-chain) unless the hash matches. evmWalletFromAccount checks it through its own RPC before the first transaction or typed-data signature, and evmWalletFromEip1193 through the wallet’s provider:
The pin changes whenever the hub team resets their fork: ask them for a block, or pick one the fork mined after it forked, whose hash differs from real mainnet’s at that height (or that real mainnet has not reached yet). On a real network you do not need a pin: its chain id is unique.

Solana

chain is the Wallet Standard chain id of the cluster the hub serves, for example solana:mainnet.

How a Solana order is signed

On the Solana gasless lane the user signs the escrow’s message; a solver pays the fees and submits it. Wallets differ in what they will sign, so executeQuote takes a solanaSigning strategy: Either way, the SDK verifies the Ed25519 signature against the user’s key before submitting it. Pass solanaGenesisHash to executeQuote to refuse signing on another cluster: one key signs for every cluster alike.

Your own adapter

Every method is one JSON-RPC call or one wallet prompt:
Pass the hub’s typed data to the wallet exactly as disclosed: the signature is over those objects, and a re-encoded domain or message signs something else.