Cross-Chain Order Executor

The Cross-Chain Order Executor is a distributed system built for hedge fund clients who need to execute complex multi-step orders across blockchain networks. A typical order might look like "swap USDC to WETH on Arbitrum, bridge WETH to Ethereum via Wormhole, then transfer to a cold wallet." The system breaks these orders into atomic steps, queues them via Redis, and dispatches each step to a specialized worker that knows how to interact with that particular venue or bridge protocol.

The system currently supports ten venue workers processing orders across seven chains simultaneously, covering DEX aggregators (Jupiter, 1inch), bridge protocols (Wormhole, Stargate, Hyperlane), and native bridges (Arbitrum L1/L2, Polygon Portal).

Architecture

The core design uses an abstract worker pattern. Each supported venue gets its own worker subclass that implements venue-specific logic for quote generation, calldata construction, and result interpretation. Workers pull orders from Redis queues and publish results back, creating a clean separation between order routing and execution.

A dual-lock system coordinates execution across chains. Execution locks prevent simultaneous transactions on the same chain, while claim locks prevent bridge redemption operations from conflicting with new order submissions.

Dynamic Chain Discovery

Rather than hardcoding chain configurations, the system auto-discovers available chains from environment variables at startup. Each chain gets its own lightweight Fastify server that handles transaction submission, confirmation tracking, and gas estimation.

function discoverChains(): ChainConfig[] {
  const chains: ChainConfig[] = []
  for (const [key, value] of Object.entries(process.env)) {
    const match = key.match(/^(.+)_CHAIN_ID$/)
    if (match && value) {
      const name = match[1].toLowerCase()
      const chainId = parseInt(value, 10)
      chains.push({
        name,
        chainId,
        rpcUrl: process.env[`${match[1]}_RPC_URL`]!,
        serverPort: 3000 + (chainId % 1000),
        type: name === 'solana' ? 'solana' : 'evm',
      })
    }
  }
  return chains
}
 
// ETHEREUM_CHAIN_ID=1     → EVM server on :3001
// ARBITRUM_CHAIN_ID=42161 → EVM server on :3161
// SOLANA_CHAIN_ID=900     → Solana server on :3900

Adding support for a new EVM chain is purely a configuration change -- add the environment variables, and the system picks it up on the next restart.

Wormhole Integration

The most technically challenging integration was Wormhole's Token Bridge. Unlike other bridge protocols that expose simple "send and forget" APIs, Wormhole's SDK uses an async generator pattern that yields an unknown number of transactions. The bridge lifecycle splits into three distinct phases -- initiation on the source chain, guardian attestation monitoring, and redemption on the destination chain -- each with its own failure modes and retry semantics. I wrote a detailed blog post covering the async generator pattern, phase-aware monitoring, calldata regeneration, and the dual-lock coordination system.