Skip to article content
Acrossprotocol

Acrossprotocol relayers

How do Across relayers fill an intent? Operators use their own capital to provide the destination assets that a user's order requires. The documented V3 bot identifies unfilled deposits across chains and attempts fills when its token balances permit.

Operator Software
Across V3 Relayer, a Node.js application for operating relay infrastructure.
Minimum V3 Host
The documented V3 minimums are a 64-bit dual-core CPU at 2+ GHz, 4 GB RAM, and a UNIX-like operating system such as GNU/Linux or macOS.
Submission Default
The V3 bot defaults to SEND_RELAYS=false , which disables relay transaction submission.

Destination Fills and V3 Repayment

The /deposit/status endpoint lets integrations verify whether an intent has filled on the destination chain. The Swap API's expectedFillTime estimates destination-fill time in seconds; V3 repayment follows a separate root-bundle process.

V3 root bundles contain three Merkle roots with repayment information for relayers that fulfilled deposits within a given block range. Operators can select their repayment chain, which affects the distribution of liquidity provider fees.

V3 Operator Workflow

  1. Configuration

    The V3 bot reads sensitive configuration from .env , which needs restricted filesystem permissions. Set SECRET to a private-key or mnemonic file path, and configure the chain-specific RPC_PROVIDER_* endpoints. The RPC_PROVIDERS setting determines provider preference order.

  2. Simulation With Submission Disabled

    The command SEND_RELAYS=false yarn relay runs the V3 bot without submitting relay transactions. Operators can review simulated transactions and token approvals before enabling live submission.

  3. Live Submission Enabled

    Live relay submission starts with SEND_RELAYS=true yarn relay , after operators review simulations and token approvals. The bot detects unfilled deposits across chains and attempts fills when its token balances permit.

Illustration: Acrossprotocol relayers: V3 Operator Workflow

View image file

V3 Inventory and Infrastructure

Automatic rebalancing uses a JSON configuration for target allocation percentages per token and chain. Operators can also configure WETH wrapping and unwrapping thresholds, along with repayment-chain selection.

V3 Inventory and Infrastructure (Acrossprotocol relayers) - illustration

View image file

Redis caching stores RPC responses, and REDIS_URL configures the cache connection. The MAX_FEE_PER_GAS_SCALER_* and PRIORITY_FEE_SCALER_* settings control per-chain gas multipliers and priority-fee adjustments. The MAX_RELAYER_DEPOSIT_LOOK_BACK setting defines the deposit lookback window in seconds.

Transaction signing requires the V3 bot to access private keys in memory.

V3 Operator Decision Checklist

  • If you're still reviewing transactions or token approvals, keep SEND_RELAYS=false ; the bot doesn't submit relay transactions.
  • Use SEND_RELAYS=true after reviewing simulations; live fill attempts still require sufficient token balances.
  • For a V3 signing host, isolate the deployment, use key-based remote access, restrict secret-file permissions, and maintain secure offline key backups.
V3 Operator Decision Checklist (Acrossprotocol relayers) - illustration
V3 Operator Decision Checklist - diagram.

View image file

· updated