Routing Strategies

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

Submit the returned tx.to, tx.data, and tx.value unchanged. See Deployments to inspect the contracts involved.

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.

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.

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

await wallet.sendTransaction(result.tx);

`ensowallet-v2`

With ensowallet-v2, a per-user Enso smart account executes the shortcut. Its address is deterministic (CREATE2 from the Enso wallet factory) and the factory deploys it inside the user’s first transaction, so it can be used as an approval target before it exists on-chain. Resolve it with GET /api/v1/wallet:

curl "https://api.enso.build/api/v1/wallet?chainId=1&fromAddress=0xd8da6bf26964af9d7eed9e03e53415d37aa96045&routingStrategy=ensowallet-v2" \
  -H "Authorization: Bearer $ENSO_API_KEY"

{ "address": "0x3A567FbcbD44392be20031217E4880e82292A163", "isDeployed": false }

Approve that address when a position must be operated without transferring it (for example an ERC-721 approve(wallet, tokenId) on a concentrated-liquidity position manager). Route and Bundle responses list any approval still missing under preTransactions with type: "requiredApproval".

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 for composition guidance.

Updated 2026-07-15

Build

Examples

Reference

Public strategies

`router`

`delegate`

`ensowallet-v2`

Receivers and spenders

​Public strategies

​router

​delegate

​ensowallet-v2

​Receivers and spenders

Public strategies

`router`

`delegate`

`ensowallet-v2`

Receivers and spenders