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

# Routing Strategies

> Choose the execution account used by Route API and Bundle API transactions.

export const date_0 = "2026-07-15"

A routing strategy determines which account executes the returned shortcut and where intermediate assets and protocol state live.

<Tip>
  Submit the returned `tx.to`, `tx.data`, and `tx.value` unchanged. See
  [Deployments](/pages/build/reference/deployments) to inspect the contracts
  involved.
</Tip>

## Public strategies

| Strategy        | Use when                                                                                                                                                                               | Input permissions                                                                |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| `router`        | An EOA submits through Enso Router. This is the standard choice for token-based Route and Bundle flows.                                                                                | Submit any transactions returned in `approvals` before the shortcut transaction. |
| `delegate`      | The supplied `fromAddress` executes through the delegate client. Use it when execution must retain protocol state at that address or the integration requires delegate-call semantics. | Do not send router approvals unless the response requires them.                  |
| `ensowallet-v2` | The flow uses the EnsoWallet V2 smart-account client.                                                                                                                                  | Follow the approvals and transaction fields returned for that client.            |

Legacy strategy values may remain available for existing integrations but should not be selected for new implementations.

## `router`

With `router`, an EOA submits the transaction to the returned Enso Router address. Intermediate assets remain with the execution contracts until later actions consume them.

```typescript theme={null}
const result = await client.getBundleData(
  {
    chainId: 1,
    fromAddress,
    routingStrategy: "router",
  },
  actions,
);

await wallet.sendTransaction(result.tx);
```

## `delegate`

With `delegate`, the supplied `fromAddress` is the execution context. This supports EOA delegation as well as compatible smart-wallet integrations; protocol ownership and non-tokenized state remain associated with that address.

```typescript theme={null}
const result = await client.getBundleData(
  {
    chainId: 1,
    fromAddress,
    routingStrategy: "delegate",
  },
  actions,
);

await wallet.sendTransaction(result.tx);
```

## Receivers and spenders

The routing strategy changes which account holds intermediate assets. Keep intermediate outputs with the executor when later actions consume them.

* Query-level `receiver` controls final-output delivery.
* Action-level `receiver` overrides recipient behavior only for actions that support it.
* `spender` identifies the supported account supplying inputs; it is not interchangeable with `receiver`.
* `refundReceiver` is used for dust or applicable bridge refunds.

See [Bundle API](/pages/build/get-started/bundling-actions#receivers-and-intermediate-assets) for composition guidance.

<div className="text-right text-xs gray-200 font-semibold w-full" style={{marginTop: '0'}}>
  <p style={{
        color: "#b2b2b2"  
    }}>Updated {date_0}</p>
</div>