Opcode gallery

This page is a directory of every opcode family registered on the deployed Aqua router, AquaSwapVMRouter v1.0.2 (0x111111338c5091e8440b67b168bae16a668ac0de). Each family maps to one instruction contract in 1inch/swap-vm. The router dispatches an opcode through _dispatch, which calls _runOpcode in AquaOpcodes.sol: the numeric index in the bytecode selects the instruction function directly.

Registered opcode summary

The table lists every opcode registered in the deployed _runOpcode dispatcher, grouped by instruction family. Indices are the exact numeric slots from AquaOpcodes.sol. The SDK builder column names the exported Opcode from @1inch/swap-vm (package path typescript/swap-vm/src/swap-vm/instructions).

Families

Controls

Control flow and access-guard instructions. They never compute swap amounts — they redirect execution (jumps) or revert on a failed state check. _jump, _jumpIfTokenIn and _jumpIfTokenOut set the next program counter (targets limited to uint16, 0–65,535). _deadline reverts once block.timestamp passes the encoded time. _onlyTakerTokenBalanceNonZero, _onlyTakerTokenBalanceGte and _onlyTakerTokenSupplyShareGte gate the fill on the taker's ERC-20 or NFT holdings; _onlyTxOriginTokenBalanceNonZero gates on tx.origin instead (a weaker check — see the source notes on delegation). _salt is a no-op that adds uniqueness to the order hash. Registered indices: 10–16, 20, 33. See the Controls instruction reference.

XYCSwap

Constant-product AMM (x × y = k). Index 17, function _xycSwapXD. Terminal swap formula that takes no args and requires both virtual balances to be non-zero; on exact-in it computes amountOut, on exact-out it computes amountIn with ceil-division to favor the maker. See the XYCSwap instruction reference.

XYCConcentrate

Concentrated-liquidity swap bounded by a sqrt price range (Uniswap-v3-style), for two tokens only. Index 18, function _xycConcentrateGrowLiquidity2D. Args are two uint256 sqrt-price bounds in 1e18 fixed point (sqrtPriceMin, sqrtPriceMax) where price P = tokenGt / tokenLt. The instruction recomputes liquidity L from the real balances each swap, derives virtual reserves, and performs a single constant-product step; fee reinvestment happens implicitly as real balances grow. See the XYCConcentrate instruction reference.

Decay

Mooniswap-style virtual-balance protection. Index 19, function _decayXD. Args are a uint16 period (2 bytes). It adjusts balanceIn/balanceOut by decaying offsets stored per order, token and direction, then runs the inner loop; after a real swap it records new offsets so a large swap temporarily worsens the rate and restores linearly over the decay period. Reads offset state in quote mode without updating it, so quote and swap can diverge if state changed between calls. See the Decay instruction reference.

Fee

Fee instructions applied to amountIn. All use the shared BPS scale where 1e9 = 100% and feeBps ≤ 1e9 (for example 0.30% = 3000000). _flatFeeAmountInXD (index 21) keeps the fee inside the pool — this is the only non-zero fee in v1. _protocolFeeAmountInXD (27) transfers the fee from the maker to a recipient via safeTransferFrom; _aquaProtocolFeeAmountInXD (28) pulls it from the maker's Aqua balance instead. _dynamicProtocolFeeAmountInXD (29) and _aquaDynamicProtocolFeeAmountInXD (30) read feeBps and recipient from an external provider via staticcall. Registered indices: 21, 27–30. See the Fee instruction reference.

PeggedSwap

Square-root linear curve for pegged assets (stablecoin, wrapped and LST/LRT pairs). Index 31, function _peggedSwapGrowPriceRange2D. Args are 160 bytes: five uint256 fields x0, y0, linearWidth, rateLt, rateGt (initial normalization reserves, the linear coefficient A scaled by 1e27, and per-token rate multipliers assigned by address order). The curve √(x/X₀) + √(y/Y₀) + A(x/X₀ + y/Y₀) = 1 + A is solved analytically at fixed curvature p = 0.5. See the PeggedSwap instruction reference.

Extruction

Delegation to external maker logic for advanced strategies. Index 32, function _extruction. Args are a 20-byte target address followed by N bytes of extructionArgs forwarded to the callee. In quote mode it calls IStaticExtruction.extruction (view); in swap mode IExtruction.extruction (state-modifying). The target returns an updated program counter, a chopped-length of consumed taker args, and updated swap registers. Targets must be deterministic and consistent across both interfaces or quote and swap will diverge. See the Extruction instruction reference.

Precision details

This section pins down four things that trip up program authors reading the summary table above: the exact byte offset of each argument field, how the SDK's raw-price helper maps onto the sqrt-price bytes the opcode actually stores, the difference between the decimal indices shown here and the hex bytes in a program, and why the flat-fee argument is called feeBps on-chain but built with FlatFeeArgs.fromBps in the SDK. Everything below is verified against 1inch/swap-vm at tag v1.0.1 and the matching @1inch/swap-vm TypeScript coders.

Argument byte offsets

Argument blobs are built with abi.encodePacked and read back with fixed slice(start, end) calls, so fields are concatenated in declaration order with no padding and no length prefixes between them. The one length byte that precedes the blob (see the info panel at the top of this page) is the total args length; individual fields are located purely by offset. The table gives the offset of every field for the opcodes where the layout is non-trivial (more than one field, or a field wider than the opcode's mnemonic implies).

rawPrice → sqrtPrice bridge (XYCConcentrate)

The _xycConcentrateGrowLiquidity2D opcode stores sqrt prices, not prices: two uint256 fields, sqrtPriceMin and sqrtPriceMax, each 32 bytes in 1e18 fixed-point, where P = tokenGt / tokenLt (higher-address token over lower-address token). The Solidity builder XYCConcentrateArgsBuilder.build2D takes those sqrt values directly and requires 0 < sqrtPriceMin < sqrtPriceMax.

The SDK exposes two constructors on ConcentrateGrowLiquidity2DArgs so callers can supply whichever form they hold. If you already have sqrt values, use fromSqrtPrices; if you hold plain prices, use fromRawPrices, which does the sqrt conversion for you before encoding. The bridge is:

// raw price P in 1e18 fixed-point  ->  stored sqrt price in 1e18 fixed-point
sqrtPrice = bigintSqrt(rawPrice * 1e18)   // so (sqrtPrice / 1e18)^2 == rawPrice / 1e18

// @1inch/swap-vm
ConcentrateGrowLiquidity2DArgs.fromRawPrices(rawPriceMin, rawPriceMax)
// is equivalent to
ConcentrateGrowLiquidity2DArgs.fromSqrtPrices(
  bigintSqrt(rawPriceMin * 1e18n),
  bigintSqrt(rawPriceMax * 1e18n),
)

Both paths land in the same coder, which writes exactly addUint256(sqrtPriceMin) then addUint256(sqrtPriceMax) — the 64-byte layout in the offsets table above. The contract reads them back with slice(0, 32) and slice(32, 64).

Opcode radix: decimal here, hex in program bytes

Every opcode index in this gallery is written in decimal, matching the numeric slots in AquaOpcodes.sol. In an actual program each opcode is a single byte, so when you inspect or hand-assemble order.data (hooks || program) you will see the index in hex. Convert before you read raw bytes:

So a byte reading 0x11 in the program is index 17, XYCSwap — not the decimal value 11 (which is 0x0b, _jumpIfTokenIn). The reserved gap indices are equally worth converting: decimal 0–9 is 0x00–0x09 and decimal 22–26 is 0x16–0x1a, all mapping to the no-op _notInstruction.

Fee argument naming: feeBps vs FlatFeeArgs.fromBps

The names collide but describe different scales. On-chain the field is called feeBps, yet it is not basis points: Fee.sol defines BPS = 1e9 and treats feeBps as a value on a 1e9 = 100% scale, requiring feeBps ≤ 1e9. The SDK stores that same 1e9-scale integer in the field FlatFeeArgs.fee (a uint32), while the factory FlatFeeArgs.fromBps takes real basis points (10,000 bps = 100%) and scales up by 100,000 to reach the on-chain units:

// @1inch/swap-vm — FlatFeeArgs
FlatFeeArgs.fromBps(30); // 30 bps = 0.30%  ->  fee = 30 * 100000     = 3_000_000
FlatFeeArgs.fromPercent(0.3); // 0.30%          ->  fromBps(0.3 * 100)    = 3_000_000
FlatFeeArgs.fromBps(10000); // 100%           ->  fee = 10000 * 100000  = 1_000_000_000 (1e9)
new FlatFeeArgs(3_000_000n); // raw 1e9-scale constructor, same as fromBps(30)

The coder encodes fee as a single uint32 (addUint32), which is the 4-byte feeBps field the opcode parses with parseFlatFee at offset 0. So the summary table's feeBps 4 (uint32) and the SDK's FlatFeeArgs.fromBps(...) agree on the bytes; only the input unit differs (1e9-scale on-chain and in the fee field, real bps at the fromBps boundary). The example in the Fee family note above — 0.30% = 3000000 — is exactly FlatFeeArgs.fromBps(30). The same 1e9 scale and the same fromBps/fromPercent convention apply to the protocol-fee opcodes (27–30), whose feeBps field shares the identical 4-byte uint32 layout.