Developer setting up L2 bridge infrastructure on laptop, architecture diagrams on screen, home office with monitors, technical work session.
Protocols

Relayer Infrastructure Configuration Guide

A durable operational reference for configuring relayer infrastructure, covering environment variables, gas fee policies, RPC endpoint management, high-availability setups, and security best practices.
introduction
RELAYER INFRASTRUCTURE CONFIGURATION

Introduction

A durable operational reference for configuring LayerZero relayer infrastructure to ensure reliable cross-chain message delivery.

The LayerZero protocol relies on a permissionless set of off-chain agents—Decentralized Verifier Networks (DVNs) and Executors—to validate and deliver cross-chain messages. The operational reliability of these agents is a direct dependency for any omnichain application (OApp) that uses them. This guide provides a canonical reference for configuring the relayer infrastructure that underpins this pipeline, covering environment variables, gas fee policies, RPC endpoint management, high-availability setups, and security best practices.

A misconfigured relayer can lead to delayed message verification, failed execution, or unexpected gas costs that erode the user experience and security guarantees of an OApp. Operators must tune their systems to handle variable network conditions, such as RPC provider rate-limiting or gas price spikes on destination chains. Key configuration areas include setting appropriate _lzFee parameters to ensure timely execution, managing WebSocket subscriptions for block-level event polling, and implementing redundant RPC endpoints to avoid a single point of failure.

This page is intended as a durable operational reference for teams running DVN or Executor software. It does not cover the initial software installation or the economic design of staking and slashing, which are addressed in sibling topics. Instead, it focuses on the runtime configuration that directly impacts message delivery performance. Chainscore Labs can review relayer configurations for production readiness, identifying misalignments between gas policies and network conditions, single points of failure in RPC infrastructure, and security gaps in key management.

OPERATIONAL REFERENCE

Quick Facts

Key operational areas and actions for configuring and maintaining a production-grade relayer.

AreaWhat changesWho is affectedAction

Environment Variables

Configuration flags controlling chain RPCs, gas policies, and signing keys

Relayer operators, DevOps teams

Audit current configuration against the latest client release notes

Gas Fee Policy

Dynamic gas estimation logic and execution fee parameters

Application teams, Executor operators

Review _lzFee settings and gas price multipliers to prevent delivery stalls

RPC Endpoint Management

WebSocket subscription stability and failover behavior

Relayer operators, Infrastructure teams

Implement redundant RPC providers and validate failover logic in staging

High-Availability Setup

Active-passive or active-active deployment topologies

Relayer operators, SRE teams

Test leader election and database locking mechanisms to avoid double-execution

Security Best Practices

Key management, firewall rules, and patch application procedures

Relayer operators, Security engineers

Enforce hardware security module usage for signing keys and apply security patches immediately

Monitoring and Alerting

Metrics for verification latency, execution success rate, and RPC health

Relayer operators, Monitoring teams

Configure Prometheus/Grafana dashboards with alerts for delivery SLA breaches

Transaction Submission

Nonce management, retry logic, and mempool strategy

Executor operators

Verify nonce ordering and gas replacement logic under chain congestion scenarios

technical-context
OPERATIONAL REFERENCE

Core Configuration Domains

A structured breakdown of the primary configuration domains that govern relayer behavior, reliability, and cost in a LayerZero-based message delivery pipeline.

Configuring a LayerZero relayer—whether a Decentralized Verifier Network (DVN) node or an Executor—requires precise tuning across several interdependent domains. These domains collectively determine how the off-chain agent connects to networks, authenticates messages, pays for on-chain transactions, and recovers from failures. A misconfiguration in any single domain, such as an under-provisioned RPC endpoint or an incorrectly set gas policy, can lead to missed verification windows, stuck message execution, or excessive operational costs. Operators must treat these configuration domains not as a one-time setup checklist but as a living operational surface that must be monitored and adjusted as chain conditions, gas markets, and protocol requirements evolve.

The primary configuration domains include: RPC and Chain Connectivity, which governs how the relayer reads state and submits transactions to each supported chain; Transaction and Gas Policy, which controls fee estimation, priority fees, and retry logic for on-chain execution; Security and Key Management, which defines how signing keys are stored, accessed, and rotated for verification and execution duties; High Availability and Failover, which ensures the relayer can survive node failures, network partitions, or cloud outages; and Observability and Logging, which provides the telemetry needed to detect anomalies, measure performance, and trigger alerts. Each domain interacts with the others—for example, an aggressive gas escalation policy can mask an unhealthy RPC connection by forcing transactions through with high fees, delaying the detection of a connectivity fault.

For teams operating production relayer infrastructure, the operational risk lies in the gaps between these domains. A common failure mode is a correctly configured gas policy that is never tested against the actual RPC latency of a remote chain, leading to systematic underpricing during network congestion. Another is a high-availability setup that fails over correctly but uses a stale signing key, causing all transactions to revert. Chainscore Labs can review a relayer's full configuration stack—from RPC endpoint selection and key management architecture to gas escalation parameters and alerting thresholds—to identify these cross-domain failure modes and ensure the system is tuned for reliable, cost-effective message delivery under real-world network conditions.

IMPACT BY ROLE

Affected Operators and Teams

Relayer Operators

Relayer operators are directly responsible for the configuration and uptime of Executor and DVN software. This guide is the primary reference for tuning environment variables, gas fee policies, and RPC endpoint management to ensure reliable message delivery.

Action Items:

  • Audit current EXECUTOR_GAS_CAP and EXECUTOR_GAS_BUFFER settings against recent on-chain gas volatility.
  • Validate that RPC endpoints for all supported chains are configured with redundant fallback URLs.
  • Review the high-availability setup section to ensure no single point of failure exists in the current deployment.
  • Implement the security best practices for key management, specifically isolating the transaction signing key from the verification key.

Chainscore can review your production configuration to identify misalignments with network conditions and recommend hardening measures.

implementation-impact
PRODUCTION READINESS

Configuration Impact Areas

Each configuration domain directly affects the reliability, cost, and security of message delivery. Operators should review these areas systematically before deploying to production.

01

Gas Fee Policy and Execution Cost

The Executor's gas pricing strategy determines whether messages are delivered promptly or left pending during network congestion. Misconfigured gas caps, stale oracle prices, or incorrect _lzFee parameters can cause systematic delivery failures. Operators must model worst-case gas costs for each destination chain, implement dynamic bumping logic, and set appropriate execution margins. Application teams should validate that their _lzFee parameters align with the Executor's configured pricing floor to avoid messages being skipped.

02

RPC Endpoint Management and Failover

A single RPC endpoint failure can halt all message verification or execution for a given chain. Operators must configure redundant RPC providers with automatic failover, implement health checks that detect stale or censoring endpoints, and maintain separate WebSocket subscriptions for event polling. For DVNs, the ability to reliably query block headers and transaction receipts across multiple chains is a critical security function. Chainscore can review RPC architectures to identify single points of failure and recommend hardening measures.

03

High-Availability and Redundancy

Running a single Executor or DVN instance creates a direct path to service interruption. Production deployments require active-active or hot-standby configurations with leader election, shared state management, and automated failover. Operators must also consider geographic distribution of instances to mitigate data center outages. For DVN operators, downtime directly impacts the security of applications that depend on their verification, as messages may timeout or require fallback verification paths.

04

Security and Key Management

DVN operators manage signing keys that attest to the validity of cross-chain messages. Compromise of these keys allows an attacker to forge verification proofs, potentially draining assets from dependent applications. Operators must use hardware security modules (HSMs) or secure enclaves, enforce strict access controls, and implement key rotation procedures. Executor operators must also secure their transaction submission keys, as they control the ability to execute or censor messages.

05

Monitoring and Alerting Thresholds

Operators need real-time visibility into verification latency, execution success rates, RPC call failures, and message queue depth. Without properly configured alerting, a silent failure in the verification pipeline can persist for hours before detection. Recommended alerting thresholds include: verification latency exceeding 2 blocks, execution failure rate above 1%, and RPC error rate above 5%. Chainscore can help teams design and implement production-grade monitoring dashboards and alerting rules.

06

Chain-Specific Configuration and Compatibility

Each supported chain has unique RPC behaviors, gas mechanics, block times, and reorg depths that affect relayer logic. Operators must tune confirmation thresholds, gas estimation strategies, and retry logic per chain. New chain deployments or network upgrades can introduce breaking changes to transaction formats or event structures. A configuration validated on Ethereum mainnet may fail on an L2 with different finality guarantees. Operators should maintain a chain-specific configuration matrix and test against testnet forks.

PRODUCTION READINESS ASSESSMENT

Configuration Risk Matrix

A structured assessment of operational risks introduced by relayer configuration choices. Use this matrix to identify failure modes, affected parties, and required actions before deploying or modifying relayer infrastructure.

AreaFailure ModeWho is affectedAction

RPC Endpoint Management

Reliance on a single public RPC endpoint leads to rate limiting, missed events, and message delivery stalls during network congestion.

Relayer operators, OApp developers, end users

Configure a load-balanced pool of at least three geographically distributed RPC providers with independent failover logic.

Gas Fee Policy

Static or incorrectly bounded gas fee parameters cause systematic execution failure during base fee spikes, leading to unbounded delivery latency.

Executor operators, OApp developers, end users

Implement dynamic fee estimation with configurable percentile targets and a maximum cap. Validate against historical chain congestion data.

Private Key Storage

Unencrypted hot wallet keys on disk or in environment variables allow immediate fund drainage and unauthorized message execution if the host is compromised.

Relayer operators, protocol treasury

Use a production-grade KMS or HSM. Enforce key rotation policies and ensure the execution wallet balance is minimized with a top-up strategy.

High-Availability Setup

Running a single Executor instance creates a single point of failure; a crash or network partition halts all message processing.

Relayer operators, OApp developers

Deploy multiple active instances behind a leader-election mechanism or use a distributed task queue to ensure at-least-once execution.

Configuration Validation

A misconfigured Endpoint address or chain ID causes the relayer to listen to the wrong contract, silently failing to process any messages.

Relayer operators

Implement a startup validation script that verifies on-chain contract addresses against a known, version-controlled configuration manifest before beginning operations.

Transaction Submission Strategy

Aggressive nonce management or lack of transaction replacement logic leads to nonce gaps or stuck transactions, blocking the entire execution queue.

Executor operators, OApp developers

Use a managed nonce pool with configurable replacement (speed-up/cancel) logic and a dead-letter queue for transactions that cannot be confirmed within a timeout window.

Logging and Monitoring

Insufficient structured logging and no alerting on execution failures allows delivery SLAs to be breached for hours or days without operator awareness.

Relayer operators, OApp developers

Export structured logs and metrics to a centralized observability platform. Define alerts for execution failure rate, verification latency, and wallet balance thresholds.

Dependency Version Pinning

Auto-updating Executor or DVN client versions introduces an untested breaking change that corrupts the local database or alters execution behavior.

Relayer operators

Pin all client versions via content-addressed hashes. Integrate new version rollouts into a CI/CD pipeline that includes a canary deployment against a testnet environment first.

RELAYER INFRASTRUCTURE

Production Readiness Checklist

A systematic checklist to validate that a relayer infrastructure deployment is ready for production traffic. Each item identifies a critical operational domain, explains its importance for reliable message delivery, and defines the confirming signal.

What to check: Verify that the relayer is configured with multiple, independent RPC endpoints for each supported chain, using a load balancer or built-in failover mechanism.

Why it matters: A single RPC provider is a critical single point of failure. An outage or rate-limit event will halt all message verification and execution for that chain.

Confirmation signal: Simulate a primary RPC failure. The relayer must automatically switch to a secondary endpoint without manual intervention and without dropping in-flight message processing. Logs should show a clear failover event and no increase in verification or execution latency beyond the configured timeout.

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

EVM ecosystems

  • Ethereum logo
    Ethereum
  • Arbitrum logo
    Arbitrum
  • Optimism logo
    Optimism
  • Polygon logo
    Polygon
  • Avalanche logo
    Avalanche
  • Cronos logo
    Cronos

Non-EVM ecosystems

  • Solana logo
    Solana
  • Sui logo
    Sui
  • Aptos logo
    Aptos
  • Hedera logo
    Hedera
  • Stellar logo
    Stellar
  • NEAR logo
    NEAR

Additional ecosystems

  • Polkadot logo
    Polkadot
  • Cosmos logo
    Cosmos
  • TON logo
    TON
  • Cardano logo
    Cardano
  • Algorand logo
    Algorand
  • Tempo logo
    Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

RELIAYER OPERATIONS

Frequently Asked Questions

Common operational questions from teams configuring and maintaining LayerZero relayer infrastructure in production.

An Executor must maintain a consistent view of the destination chain's state to accurately estimate gas and submit execution transactions. At minimum, operators should provision:

  • Full nodes (non-archive) for each supported destination chain to query transaction receipts and current nonces.
  • WebSocket connections for subscribing to pending transaction events and block headers. The Executor uses these to detect when a submitted execution has been included or needs replacement.
  • Redundant RPC endpoints from at least two independent providers to mitigate single-provider outages. The Executor client should be configured with a primary and fallback endpoint per chain.

For chains with deep reorg histories or where the Executor must verify historical packet delivery, archive nodes may be required. Operators should test RPC latency under load, as slow responses can cause the Executor to miss the execution window and allow competing Executors to claim the reward.

Chainscore can review your RPC infrastructure architecture to identify single points of failure and recommend hardening measures aligned with your delivery guarantees.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

01

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

02

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

03

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

04

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Start a build

Need a blockchain engineering team?

Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.