Skip to main content
The Bundle API accepts an ordered array of public actions. This page documents stable Enso composition actions and common protocol action families.
Start with the Bundle API guide for request shape, execution, approvals, and response handling. Use the standalone Route API when Enso should choose the complete path. The enso:route section below documents the route action used inside a Bundle request.
Protocol support and inputs change over time. Use Supported Actions for the current action list and Standard per Protocol for actions available on a specific protocol. Generic protocol tables below describe common fields, not a universal schema for every integration.

Action index

Chaining actions

Use a previous output as a later input with a zero-based reference:
Array outputs require an explicit item index:
The following source-backed example splits USDT into two routed outputs and passes both into a CLMM deposit:
References must point to an earlier available output. Checks such as check and minamountout do not produce a normal token amount for downstream consumption.

Action outputs

Ondo quote estimates

GET /api/v1/shortcuts/quote supports routes containing the synthetic ondosplit and ondomerge actions. It returns a soft estimate based on current Folio view data and Ondo soft attestations; it does not build an executable Ondo transaction or obtain a hard attestation. Use the Route API when execution-ready Ondo actions are required. Generic split and merge actions remain unavailable in the Quote API.

Core actions

route

enso:route finds a path between tokenIn and tokenOut inside a Bundle request. It can expand into swaps, deposits, or redeems, and the Bundle response includes the selected hops in route. This is different from the standalone Route API, which is usually simpler when the entire request has one final destination.
The fee array aligns with amountIn; "100" is 1%. Values must be between 1 and 100 basis points. Omit fee when no fee should be collected. By default, route fees are deducted from the input assets on the source chain and sent to feeReceiver. For a cross-chain route with destination execution, set destinationFeeReceiver to collect the fee from the delivered bridge asset on the destination chain instead. feeReceiver remains required as the fallback for direct bridges without destination execution or routes where destination collection does not apply. For cross-chain routing, add destinationChainId. ignoreBridges and refundReceiver apply only to cross-chain route actions. Source completion and destination execution are asynchronous.

swap

Swaps one token for another using a specific pool or exchange protocol.

deposit

Deposits tokens into a protocol to receive a position token or add liquidity.
Use the optional positionId to deposit into.

redeem

Redeems underlying assets from a protocol by exchanging shares or tokens. Use it to exit a position and retrieve the desired tokens.

Bridging

The bridge action lets you perform transactions spanning multiple chains. It relies on Stargate and LayerZero to coordinate interactions.

bridge

Facilitates cross-chain token transfers using various bridge protocols with optional callback actions on the destination chain. When used with callback actions (callback array), it can execute a destination-chain sequence after tokens arrive. Source bridging and destination execution are asynchronous; callback failure cannot revert a finalized source-chain bridge. Monitor the transfer through Bridge Status.
Important: When using callbacks, the callback bundle MUST start with a balance action to check the bridged token balance on the destination chain.
Bridge providers do not all support the same callback shapes. Use Crosschain Routing for provider-specific constraints.

Slippage protection

The route action accepts its own slippage or explicit minimum settings. For direct protocol actions and internal routes used by composition actions, add slippage or minamountout checks where the flow requires explicit protection.

slippage

Derives a quote-backed minimum for a previously produced output and adds an on-chain check. The transaction reverts when the received amount is below that minimum. The referenced output must already exist. In split -> slippage -> depositclmm flows, the slippage checks intentionally sit before depositclmm because they protect the internal routes that prepare its inputs.

minAmountOut

Applies slippage protection specified in absolute amount (minAmountOut) to ensure the received amount is within the acceptable range of the expected output.
minamountout is an assertion-only action. Do not use its position as a downstream token-amount reference.

Deposit & Redeem Actions

depositCLMM

Deposits tokens into a Concentrated Liquidity Market Maker pool (like Uniswap V3).

redeemCLMM

Redeems tokens from a Concentrated Liquidity Market Maker position (like Uniswap V3).

singleDeposit

Deposits a single token into a protocol. This is a specialized version of the deposit action for single token deposits.

multiDeposit

Deposits multiple tokens into a protocol (like Curve or Balancer) in a single operation.

tokenizedSingleDeposit

Deprecation Notice: This action is deprecated in favor of using singleDeposit with the appropriate protocol. It will be removed in a future API version.
Deposits a single token and receives a tokenized position.

tokenizedMultiDeposit

Deprecation Notice: This action is deprecated in favor of using multiDeposit with the appropriate protocol. It will be removed in a future API version.
Deposits multiple tokens and receives a tokenized position.

multiOutSingleDeposit

Deposits a single token and receives multiple output tokens (typically used for certain AMM positions).

Lending Actions

flashloan

Borrows tokens from a lending protocol without upfront collateral, executes callback actions atomically, and repays the debt within the same transaction.
Flashloans have dedicated documentation. See the Flashloans Reference for supported protocols, chain availability, parameters, and examples.

borrow

Borrows a token from a lending protocol using a deposited token as collateral.

repay

Repays a loan on a lending protocol.

repay on Behalf of Another address

Repay parameter onBehalfOf enables you to repay a loan on behalf of a given address:

Yield Farming Actions

harvest

Harvests rewards from yield-generating positions.

Token Management Actions

approve

Approves a spender to use tokens.

transfer

Transfers tokens to a specified address.
For NFT transfers see erc721:transfer below.

transferFrom

Transfers tokens from a specified address to another address.
For NFT transfers see erc721:transferFrom below.

erc721:transfer

ERC-721 doesn’t expose a transfer(to, tokenId) selector — this is a UX alias that emits a transferFrom(walletAddress(), receiver, tokenId) call. Unlike erc721:transferFrom, this action’s input schema does not accept sender; the sender is always the executing wallet at runtime.

erc721:approve

Approves a spender to operate on a single ERC-721 token id. Mirrors erc20:approve but with tokenId in place of amount.
ERC-721 approve(spender, tokenId) requires msg.sender to be the owner of the token id (or an approved operator). The effective msg.sender inside a bundle depends on routingStrategy — for router, that is the shared EnsoShortcuts contract; for delegate / ensowallet-v2, the per-user wallet. The token id must be owned by whichever address msg.sender resolves to at execution time.

erc721:transferFrom

Transfers an ERC-721 token id between two addresses. Mirrors erc20:transferfrom but takes tokenId instead of amount, and sender is optional — when omitted it defaults to the executing wallet.

permitTransferFrom

Approves and transfers a token that supports permit in a single step using a signature. A permit signature needs to be generated offchain and passed to the API.

Utility Actions

balance

Gets the balance of a token for the caller’s address.
The balance action supports advanced parameters for checking external account balances and building routes with estimated amounts. See the Advanced Balance Reference for details, risk considerations, and examples.

split

Routes one input amount into more than one tokenOut. It returns an array with one amount per output token; downstream actions must select each value with index. This is not an arbitrary percentage splitter. See Chaining actions for a complete split -> depositclmm example. A split must feed a compatible later deposit flow; it is not a terminal transfer action.

merge

Routes more than one input token into a single output amount.

call

Makes an arbitrary contract call for interactions not covered by a public action. The return shape follows the supplied ABI, and output references can be used inside nested argument objects.
Arbitrary calls can transfer assets or grant permissions. Verify the target, ABI, calldata, and returned transaction before signing. See the custom contract call guide.
For arithmetic over prior outputs, prefer the documented Math Actions.

fee

Calculates and deducts a fee from a specified amount, sending the fee to a designated receiver. This action is typically prepended to bridge operations to facilitate fee collection. The fee action calculates the fee as amount * (bps/10000) and sends this amount to the receiver. It returns amount - fee, which can be used in subsequent actions via useOutputOfCallAt.

ensofee

Calculates and deducts Enso’s protocol fee from a specified amount. The ensofee action calculates the fee as amount * (bps/10000) and sends this amount to Enso. It returns amount - fee, which can be used in subsequent actions via useOutputOfCallAt.

Math Actions

Math actions perform on-chain arithmetic operations over values from previous actions. These are useful for computing amounts dynamically within a bundle — for example, dividing a routed amount to distribute across multiple recipients. All math actions use protocol math and take two operands: amountA and amountB. Each operand can be a static value or a reference to a previous action’s output via useOutputOfCallAt.

add

Returns amountA + amountB.

sub

Returns amountA - amountB.

mul

Returns amountA * amountB.

div

Returns amountA / amountB (integer division).

min

Returns the smaller of amountA and amountB.

max

Returns the larger of amountA and amountB. Example: Route then divide output by 2 and transfer halves to two addresses

Helpers Actions

Helpers actions provide on-chain comparison and conditional logic, enabling bundles to branch based on runtime values. These are useful for building guard conditions, assertions, and conditional flows. All helpers actions use protocol helpers.

Comparison Actions

Compare two uint256 values and return a boolean result. The result can be referenced by subsequent actions.

isequal

Returns true if amountA == amountB.

islessthan

Returns true if amountA < amountB.

isequalorlessthan

Returns true if amountA <= amountB.

isgreaterthan

Returns true if amountA > amountB.

isequalorgreaterthan

Returns true if amountA >= amountB.

check

Asserts that a boolean condition is true. If the condition is false, the entire transaction reverts. Use this to enforce invariants — for example, ensuring an output amount meets a minimum threshold.

not

Negates a boolean condition. Returns true if the input is false, and vice versa.

toggle

Selects between two values based on a condition. Returns amountA if the condition is true, otherwise returns amountB. This is the on-chain equivalent of a ternary expression (condition ? amountA : amountB). Example: Check that a routed amount is above a minimum before proceeding

Protocol Support

The Bundle API supports a wide range of protocols. Some common ones include:
  • aave-v2, aave-v3: Aave lending/borrowing
  • balancer-v2: Balancer liquidity pools
  • curve: Curve Finance stable swaps and gauges
  • curve-gauge: Curve gauges for staking
  • erc20: Standard token operations
  • erc721: Non-fungible token operations (approve, transfer, transferfrom)
  • erc4626: ERC4626 vaults
  • enso: General Enso operations including route, split, merge, balance, and arbitrary calls
  • math: On-chain arithmetic operations (add, sub, mul, div, min, max)
  • helpers: On-chain comparisons and conditional logic (isequal, islessthan, isgreaterthan, check, not, toggle)
  • permit2: Uniswap’s Permit2 operations
  • uniswap-v2, uniswap-v3: Uniswap pools and routers
  • yearn: Yearn Finance vaults
  • compound-v2, compound-v3: Compound lending/borrowing
  • stargate: Cross-chain bridging
For a complete list of supported protocols, use the Projects API endpoint: GET /standards.

Updated