How execution works
- The solver supplies the tokens listed in
route.tokensand the required native amount. - The destination Portal transfers those tokens to its Executor.
- The Executor runs
route.callsin array order.
target address, ABI-encoded data, and a native-token value. The target sees the Executor as msg.sender, so set beneficiaries and recipients explicitly where the target contract requires them.
If a call reverts, the destination fulfillment transaction reverts. Source-chain funding remains a separate transaction; a failed destination call does not immediately refund the source vault.
Common patterns
Simulate the complete fulfillment with the required assets and estimate gas before submitting it. Ensure calls consume or transfer their intended balances; the Executor does not automatically sweep residual ERC-20 tokens.
Run a Sauce program
A destination call can cook a Sauce program on a Pot. The program reads live state on the destination chain, checks the conditions you write and composes protocol calls, inside the fulfillment transaction. The route’s calls deploy a Pot the Executor owns withKitchen.deployPot, transfer the route’s tokens into it, and call its cook with the Kitchen’s fee as the call’s value.
Every route’s calls run from the same Executor, so any route can cook on a Pot the Executor owns. The program must send everything it receives to its recipients in the same cook. See Sauce in a route.
Constraints
- Calls run sequentially within one destination-chain transaction.
- A target with no contract code rejects nonempty calldata.
- The Executor checks whether a call reverted; it does not interpret the returned bytes as a success flag or validate an arbitrary call’s business outcome.
- Available API routes and direct contract capabilities are different surfaces. Use the returned quote to determine what the API will execute.
