> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Executor

> How the destination Executor runs route calls and handles failures.

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](https://github.com/eco/eco-routes/blob/ea5111ba0cd644089d04f922e05a5253dbd21fb8/contracts/Executor.sol).

## 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

| Field | Type | Meaning |
| - | - | - |
| `target` | `address` | Destination contract or native-token recipient |
| `data` | `bytes` | ABI-encoded calldata; empty for a plain native-token transfer |
| `value` | `uint256` | Native-token amount sent with this call |

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

## Failure behavior

| Error | Cause |
| - | - |
| `NonPortalCaller` | An account other than the configured Portal called `execute` |
| `CallToEOA` | The target has no code and the call contains calldata |
| `CallFailed` | A target call reverted; the error includes the call and returned revert data |

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](/routes/capabilities/destination-calls) for common patterns or [Portal](/routes/architecture/portal) for fulfillment entry points.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.