Program, order and strategy

1inch Aqua separates what a maker's liquidity does from how Aqua stores and accounts for it. The same definition moves through three layers before it becomes a live, fillable strategy, and each layer belongs to a different part of the stack.

Program → Order → Strategy (in Aqua)

Layer Belongs to What it is
Program SwapVM An ordered sequence of opcodes, instructions, and parameters
Order SwapVM The container that wraps a Program with maker metadata and authorization headers
Strategy Aqua The ABI-encoded form of an Order: opaque bytes that Aqua registers and accounts for

Aqua treats the Strategy body as a black box. It does not parse the Program or interpret any instructions; it only manages balance accounting. All execution logic stays inside SwapVM, the Aqua swap engine (the deployed AquaSwapVMRouter).


What an Order contains

Field Purpose
Program bytecode The ordered sequence of instructions SwapVM executes on every quote() and swap()
MakerTraits 256-bit packed header: authorization flags, hook indexes, epoch, nonce, time bounds
Maker address Identifies the liquidity owner; makes the Order unique per maker
Salt Optional; allows a maker to have multiple Orders with identical parameters

When useAquaInsteadOfSignature is set in MakerTraits, Aqua's registry acts as the authorization mechanism, and the Order is treated as valid by virtue of having been shipped. When it is unset, the Order is authorized by an EIP-712 signature and functions as a standalone SwapVM order, independent of Aqua.


How an Order becomes a Strategy

  1. Developer composes a Program (opcodes + instructions + parameters)

  2. Program is wrapped into a SwapVM Order with maker metadata and authorization headers

  3. The Order is ABI-encoded and passed to Aqua.ship(); at that point it becomes an Aqua Strategy

  4. Aqua derives a strategyHash = keccak256(abi.encode(strategy)) and stores virtual balances under balances[maker][app][strategyHash][token]

The hash encodes every parameter, so any parameter change produces a different hash. This enforces immutability by identity: a Strategy cannot be edited in place, only closed with dock() and reopened with a fresh ship().

Virtual balances are an internal accounting counter inside Aqua.sol, not custody. Tokens stay in the maker's wallet under a revocable, per-chain, per-token allowance and move only when a taker fills atomically; the protocol holds zero tokens.


Two authorization paths

Path Authorization Balance source
Aqua (shipped) ship() call; useAquaInsteadOfSignature = true Aqua virtual balances
Standalone signature EIP-712 signature from maker Embedded in Program args (static) or SwapVM storage (dynamic)

The Program bytecode is identical across both paths. Only the authorization mechanism and balance source differ.


  • The SwapVM engine runs the Program inside an Order.

  • The Program Model page covers bytecode format, registers, and instruction ordering rules.

  • The Strategy page explains how Aqua registers and accounts for the ABI-encoded Order.

Did you find what you need?