Skip to main content
The Executor runs an intent’s destination calls in a contract separate from the Portal. The Portal deploys its Executor and is the only account authorized to call execute. The behavior below follows the Executor source.

​
Execution flow

  1. The Portal pulls route.tokens from the fulfillment caller into the Executor.
  2. The Portal calls execute with route.calls and route.nativeAmount.
  3. The Executor calls each target in array order, forwarding that call’s value and data.
  4. It returns the array of return data if all calls complete without reverting.
Each target sees the Executor as msg.sender. A call uses the target’s own storage, not the Portal’s storage.

​
Call fields

Use the deployed ABI’s field order when encoding tuples. The source Call struct orders fields as target, data, value.

​
Failure behavior

If any call reverts, all changes in that destination fulfillment transaction roll back. This does not reverse an earlier source-chain funding transaction. A call that returns false without reverting is still a successful low-level call. The Executor does not interpret return values or establish arbitrary postconditions. Encode the required checks in the route or called contracts.

​
Asset handling

The Executor has no per-user balance accounting and does not automatically sweep leftover ERC-20 tokens or native currency. Your calls must transfer or consume the assets intended for the recipient. Approvals and token balances are state in the token contracts even though the Executor has no mutable execution storage of its own.

​
Preparing calls

Before submitting a fulfillment:
  • Verify each target, spender, recipient, and amount.
  • Include approvals required by downstream contracts.
  • Encode output constraints for swaps and deposits where applicable.
  • Simulate the entire fulfillment and estimate gas with the actual route tokens and native value.

​
Next steps

See Destination calls for common patterns or Portal for fulfillment entry points.