Supported chains

1inch Aqua is deployed at one deterministic address on 13 EVM chains. The registry (Aqua), the router (AquaSwapVMRouter v1.0.2) and the KycNFT credential share the same address on every one of these chains.

The 13 Aqua chains

supportedChains = [1, 10, 56, 100, 130, 137, 146, 324, 4663, 8453, 42161, 43114, 59144]. Note Unichain is 130 (the SDK README's 1301 is a known error).

Robinhood Chain (4663) joined the chain set on 2026-07-16

Robinhood Chain was previously excluded from the Aqua chain set: its registry was a different, CREATE3-deployed address (0x7c2D…ec86), it had no KycNFT, and it was flagged unsupportedForAqua. That exclusion ended with the 2026-07-16 universal redeployment:

• Aqua was redeployed on all chains — Robinhood included — to one universal registry address (0xe8026b…139b), together with the dependent AquaSwapVMRouter v1.0.2 (0x016b41…B070). Both were superseded in the 2026-07 vanity redeployment — the current addresses are 0x1111113ccf…a90a (registry) and 0x111111338c…c0de (router); see Contract addresses.
• The KycNFT credential (0x26FF…a468) is configured for chain 4663; resolver flows on Robinhood have been validated.
• The Aqua API accepts and indexes chain 4663 in production.

Robinhood's earlier chain-specific contracts (0x7c2D…ec86 registry, 0xA536…331A router) are superseded — use them only to decode historical activity. See Verified contract addresses for the full historical list.

Cross-chain: no native settlement

The unified address is a deployment convenience, not a shared ledger. Aqua and the AquaSwapVMRouter have no native cross-chain settlement. Each of the 13 chains is a fully independent deployment with its own registry state, its own router, and its own KycNFT credential set. A strategy shipped on one chain can only be filled on that same chain.

The shared address from the Supported chains table means the same bytecode lives at the same address on every chain. It does not mean the deployments share liquidity, balances, or a KYC allowlist. There is no bridge, no message-passing, and no cross-chain accounting anywhere in the v1.0.2 router or the Aqua registry.

Why each chain is isolated

Two independent facts in the deployed code keep every chain self-contained:

• Registry balances are per-deployment. Maker inventory lives in the Aqua registry on a single chain, keyed by _balances[maker][app][strategyHash][token]. Shipping a strategy funds that mapping on that chain only; pull and dock read and write the same local mapping. Nothing reads or credits balances on another chain.
• The order/strategy hash is chain-bound.SwapVM is an EIP712 contract, so a maker-signed order is hashed through _hashTypedDataV4, whose domain separator folds in chainId and the router address (verifyingContract). The same order re-submitted on a different chain produces a different digest and is not a valid signature there. Aqua-native strategies (useAquaInsteadOfSignature) are identified by strategyHash = keccak256(strategy) in the local registry, which only exists where the strategy was shipped.

A fill always executes against the router deployed on the chain the transaction is sent to. Each AquaSwapVMRouter is constructed with one Aqua registry address and one WETH address for that chain:

         
         

           Solidity
         
 
         
         

           
           

             
1
2
3
4
5
6
7
8
9
10
11
           
 
           
           
// swap-vm/src/routers/AquaSwapVMRouter.sol (v1.0.2)
constructor(
    address aqua,   // the Aqua registry on THIS chain
    address weth,
    address owner,
    string memory name,
    string memory version
) SwapVM(aqua, weth, owner, name, version) AquaOpcodes(aqua) { }

// quote / swap are 5-arg and resolve inventory from the local registry only:
// swap(Order order, address tokenIn, address tokenOut, uint256 amount, bytes takerTraitsAndData)
         
       

What this means for makers

A maker who wants to be fillable on multiple chains operates each chain as a separate venue:

• Ship the strategy on every target chain. ship(app, strategy, tokens, amounts) is a per-chain call against that chain's Aqua registry; the returned strategyHash is only meaningful there.
• Fund inventory per chain. The amounts pushed on Ethereum are not available to fills on Base or Arbitrum. Inventory does not rebalance itself across chains.
• Manage lifecycle per chain. dock and pull act on one chain's balances at a time; parking or withdrawing on one chain leaves the others untouched.

What this means for takers

The KycNFT credential is a per-chain deployment as well. Holding the credential on one chain does not make a taker recognized on another — the credential must be held on each chain where that taker intends to fill. Because balances and the KYC set are local, a route that succeeds on one chain gives no guarantee about any other chain.

Moving value across chains is out of scope for Aqua. Neither the router nor the registry bridges tokens or relays state between chains. To move funds from one chain to another, use a separate bridge as an independent step, then ship or fill against the Aqua deployment on the destination chain. Hosted routing and cross-chain aggregation are handled by 1inch Business products, not by the on-chain Aqua contracts documented here.