Setting Up a Private Transaction Relayer Network

A private relayer network is an infrastructure layer that abstracts gas fee management and transaction submission from end-users. Instead of users signing and paying for transactions directly, they sign meta-transactions (messages authorizing an action) which are then packaged, funded, and submitted by a trusted relayer. This model enables key features like gasless transactions, sponsored operations, and enhanced privacy for dApp users. The network typically consists of a relayer node (the software that processes requests), a signer wallet (which holds the gas funds), and a backend service to manage logic and queueing.

To begin, you need to set up the core relayer node. A common approach is using the Gelato Relay SDK or OpenZeppelin Defender for managed services, or running a custom node with Ethers.js and a transaction queue like Bull or Redis. The node must listen for user requests via an API, validate the user's signature on the meta-transaction, apply any business logic (e.g., checking a payment), and then wrap the user's intent in a new transaction signed by the relayer's private key. Security at this stage is critical: the relayer must never have access to the user's private key, only the ability to verify their EIP-712 or EIP-2771 signatures.

Next, configure the funding mechanism. The relayer's signer wallet must hold native tokens (like ETH, MATIC, or AVAX) to pay for gas. For production systems, implement a gas tank strategy with automated replenishment using services like Gelato's 1Balance or a custom smart contract that holds funds. You must also decide on a fee model: will transactions be sponsored by the dApp, paid for by the user in ERC-20 tokens, or use a hybrid model? This logic is handled in your backend before the relayer submits the transaction to the public mempool.

Finally, integrate the network with your dApp. Your smart contracts must be compatible with meta-transactions, often by inheriting from OpenZeppelin's MinimalForwarder or implementing EIP-2771 Context. On the frontend, use libraries like ethers.js v6 or web3.js to create the signed meta-transaction payload and send it to your relayer's secure API endpoint. Monitor your network using tools like Tenderly for transaction simulation and Blocknative for mempool visibility to ensure reliability and quickly debug failed transactions.

A private transaction relayer network requires a robust infrastructure foundation. The core components include dedicated servers or cloud instances to run the relayer nodes, a private blockchain node (like a Geth or Erigon client for Ethereum), and a secure key management system for signing transactions. You must provision these resources with high availability and redundancy in mind, as network downtime can halt all relayed transactions. For cloud deployments, providers like AWS, Google Cloud, or specialized Web3 infrastructure services (e.g., Alchemy, Infura for node access) are common choices.

The software stack is centered around the relayer software itself. This is typically a custom-built service written in languages like Go, Rust, or TypeScript, which listens for user requests, constructs transactions, signs them with a private key, and broadcasts them to the blockchain. You will need to integrate with a specific EVM-compatible node RPC endpoint and may require additional services for monitoring (Prometheus, Grafana), logging (ELK stack), and secret management (HashiCorp Vault, AWS Secrets Manager). All software should be containerized using Docker for consistent deployment.

Security and operational requirements are non-negotiable. You must establish a secure process for generating and storing the relayer's private keys, often using hardware security modules (HSMs) or cloud KMS solutions. Network security involves configuring firewalls, VPCs, and DDoS protection. Furthermore, you need a plan for gas management, including funding the relayer's wallet with the native chain token (e.g., ETH, MATIC) and implementing logic to handle gas price fluctuations and transaction failures gracefully.

A private transaction relayer network is a key infrastructure component for account abstraction and gasless transactions. Its primary function is to receive signed user operations (UserOperations), bundle them, and submit them to a paymaster contract for sponsorship before sending the final bundle to an EntryPoint contract on-chain. This architecture decouples the user from needing native tokens for gas, enabling seamless onboarding. Core components include the relayer server, a bundler service, a paymaster for gas sponsorship, and a mempool for holding pending operations.

To set up a basic relayer, you first need to deploy the necessary smart contracts. The most critical is the EntryPoint contract (v0.6), which is the singleton contract that validates and executes bundles. You'll also need a paymaster contract, which holds funds and implements logic to decide which operations to sponsor. For testing, you can use the verifying paymaster from the account-abstraction samples repository. Deploy these contracts to your target network (e.g., a local Anvil instance or a testnet) using Foundry or Hardhat.

The next step is to configure and run the bundler software. The official reference implementation is the ERC-4337 Bundler, written in Rust. Clone the repository and configure the bundler.config.json file. Key settings include the entry_point address, the beneficiary address (which receives gas refunds), the RPC URL for your Ethereum node, and the chain ID. You must also configure the whitelist or policy to define which paymasters and account factories your bundler will accept operations for. Run the bundler with cargo run to start listening for UserOperations via its JSON-RPC endpoint.

Your application's frontend or SDK must then be configured to send UserOperations to your private relayer network instead of directly to a public RPC. Libraries like UserOperation.js or ZeroDev SDK can help construct these operations. The user signs the operation, which is then sent via eth_sendUserOperation to your bundler's RPC URL. The bundler validates the operation's signature and paymaster data, adds it to its mempool, and eventually creates a bundle to submit on-chain. This setup allows you to offer gas sponsorship, batch transactions, and session keys as features for your users.

For production, security and monitoring are critical. Implement rate limiting and operation validation logic to prevent spam. Monitor your bundler's mempool size and bundle submission success rate. Use a high-availability RPC provider like Alchemy or Infura for reliable node access. Consider running multiple bundler instances behind a load balancer for redundancy. Keep your paymaster contract funded and monitor its balance, as it will pay for all sponsored gas. This private infrastructure gives you full control over the transaction flow and user experience for your application.

A relayer node is a specialized server that receives, validates, and forwards user-signed transactions to the blockchain. For a private network, you control the infrastructure, which is critical for applications requiring privacy, custom gas policies, or guaranteed transaction ordering. The core components include a secure execution environment, a blockchain client (like Geth or Erigon), and the relayer software itself, which is often built using frameworks like OpenZeppelin Defender or custom Go/Node.js services.

Begin by provisioning a cloud server or dedicated machine. For a production-grade node, we recommend a minimum of 4 vCPUs, 8GB RAM, and a 100GB SSD. Use a hardened Linux distribution (Ubuntu 22.04 LTS is common) and configure a non-root user with sudo privileges. Essential first steps include setting up a firewall (UFW or iptables) to allow only necessary ports (e.g., 8545 for JSON-RPC, 30303 for peer discovery) and installing Docker for containerized deployment, which simplifies dependency management and updates.

Next, configure the blockchain client. For an Ethereum-compatible chain, sync a Geth node in --syncmode snap for faster initial synchronization. The critical configuration is the geth command to start the node with your private network settings: geth --datadir ./chaindata --networkid 12345 --http --http.addr 0.0.0.0 --http.api eth,net,web3 --http.corsdomain "*" --nodiscover. This command initializes a local chain with network ID 12345, enables the HTTP JSON-RPC interface on all addresses, and disables peer discovery to keep the network private.

The relayer application logic is typically a service that listens for incoming transaction requests via an API, wraps them with the necessary gas and network parameters, and submits them using a funded account. A basic Node.js relayer endpoint using Ethers.js might look like this:

javascriptCopy
app.post('/relay', async (req, res) => {
  const { signedTx } = req.body;
  const provider = new ethers.providers.JsonRpcProvider('http://localhost:8545');
  const txResponse = await provider.sendTransaction(signedTx);
  res.json({ txHash: txResponse.hash });
});

Secure this endpoint with API keys and rate limiting immediately.

Finally, implement operational safeguards. Use environment variables or a secrets manager for your relayer's private key and API credentials—never hardcode them. Set up Prometheus and Grafana for monitoring node health, including sync status, memory usage, and pending transaction queues. Automate deployment and updates using a CI/CD pipeline. For high availability, consider deploying multiple relayers behind a load balancer, ensuring they share a synchronized mempool or database to prevent transaction duplication or nonce conflicts.

A private RPC endpoint is the primary interface through which your application or users will submit transactions to your relayer network. Instead of connecting directly to individual node providers, you expose a single URL that acts as a gateway. This endpoint is typically a lightweight web server that authenticates requests, applies any custom logic (like gas policies), and forwards them to the backend infrastructure. Setting this up involves deploying a service, often using frameworks like Express.js for Node.js or a similar web framework, that can handle JSON-RPC requests.

The core component behind this endpoint is the load balancer. Its job is to distribute incoming JSON-RPC requests across your pool of configured node providers (e.g., Alchemy, Infura, QuickNode, or private nodes). This provides critical benefits: high availability (if one provider fails, traffic routes to others), load distribution (preventing overloading a single provider), and performance optimization (routing requests to the fastest or cheapest node). You can implement strategies like round-robin, latency-based routing, or failover logic within your load balancer.

For a basic implementation, you can use a reverse proxy like Nginx or HAProxy. However, for blockchain-specific needs—such as tracking nonces, managing request timeouts, or handling chain reorgs—a custom application load balancer is often necessary. Here's a simplified Node.js example using the express and axios libraries to create a round-robin load balancer across two RPC URLs:

javascriptCopy
const express = require('express');
const axios = require('axios');
const app = express();
app.use(express.json());

const providers = [
  'https://eth-mainnet.g.alchemy.com/v2/YOUR_KEY',
  'https://mainnet.infura.io/v3/YOUR_KEY'
];
let currentIndex = 0;

app.post('/', async (req, res) => {
  const targetProvider = providers[currentIndex % providers.length];
  currentIndex++;
  try {
    const response = await axios.post(targetProvider, req.body);
    res.json(response.data);
  } catch (error) {
    res.status(500).json({ error: 'RPC request failed' });
  }
});

app.listen(8545, () => console.log('Relayer endpoint on port 8545'));

In production, your load balancer must include robust error handling. This involves catching provider timeouts, parsing error responses (like -32005 rate limit errors), and implementing automatic retries with a different provider. You should also add request logging and metrics collection (using tools like Prometheus) to monitor the health and performance of each backend node. This data is essential for identifying unreliable providers and fine-tuning your routing logic.

Finally, secure your endpoint. At a minimum, use API key authentication to prevent unauthorized public access. For more sensitive operations, consider implementing IP whitelisting or more advanced authentication methods. The configured endpoint URL (e.g., https://rpc.yourdomain.com) is what you will provide to your dApp or backend services, completing the public-facing setup of your relayer network's infrastructure layer.

The core of your fee strategy is determining the cost basis for relaying a transaction. This includes the gas you pay on the destination chain, any gas spent on optional pre or post-processing logic, and the operational overhead of your relay infrastructure. For a basic setup, your fee can be a simple markup: userFee = estimatedGasCost * gasPrice * (1 + profitMargin). More advanced strategies might implement dynamic pricing based on real-time network congestion using oracles like Chainlink or Pyth for gas price feeds.

You must decide how users will pay these fees. The two primary models are fee abstraction (paying in the source chain's native token) and fee payment in destination gas. Fee abstraction is more user-friendly but requires you to manage cross-chain value flows. A common implementation is to have users sign a message authorizing a fee, which your off-chain relayer submits alongside the main transaction, collecting payment on the source chain via a FeeCollector contract. The EIP-4337 Bundler specification provides a robust reference for this pattern.

For transparency and trust, your fee logic should be verifiable. Consider implementing a commit-reveal scheme or publishing signed fee quotes. Your relayer backend can generate a quote including the fee amount, a nonce, and an expiry timestamp, sign it, and send it to the user's client. The user then submits this signed quote with their transaction request. Your on-chain RelayHub contract can verify the signature and enforce the quoted fee, preventing the relayer from charging more than advertised.

Here is a simplified example of a smart contract function that validates a signed fee quote before executing a relayed call:

solidityCopy
function relayCall(
    address target,
    bytes calldata data,
    uint256 maxFee,
    uint256 nonce,
    uint256 deadline,
    bytes calldata signature
) external {
    require(block.timestamp <= deadline, "Quote expired");
    require(!usedNonces[nonce], "Nonce already used");
    
    bytes32 messageHash = keccak256(abi.encodePacked(target, data, maxFee, nonce, deadline));
    address signer = ECDSA.recover(messageHash, signature);
    require(signer == trustedRelayer, "Invalid signature");
    
    usedNonces[nonce] = true;
    
    // Execute the call and transfer the fee to the relayer
    (bool success, ) = target.call(data);
    require(success, "Call failed");
    
    payable(signer).transfer(maxFee);
}

Finally, monitor and iterate. Use analytics to track average profit margins, fee payment failure rates, and user adoption. Be prepared to adjust your model based on gas price volatility and competitive pressures. A well-calibrated fee strategy ensures your relayer network remains operationally sustainable without becoming a prohibitive cost for your users, striking a balance between service quality and economic viability.

A private relayer network acts as a middleware layer between your dApp's frontend and the blockchain. Instead of users signing and sending transactions directly from their wallets (which requires them to hold native gas tokens), the frontend sends a signed meta-transaction to your relayer endpoint. This meta-transaction contains the user's intent (e.g., swap, mint) and a signature, but lacks gas payment details. Your relayer network is responsible for wrapping this intent in a new transaction, paying for the gas, and broadcasting it to the network. This architecture is fundamental for gasless UX, onboarding, and complex transaction batching.

To integrate, your frontend must be configured to use a custom RPC provider or a dedicated SDK. For networks like Polygon, you might use the @biconomy SDK to create and send userOp objects for Account Abstraction. For EVM chains, you can use the ethers.js JsonRpcProvider pointed to your relayer's API endpoint. The core frontend flow involves: 1) constructing the transaction data with the user's wallet, 2) signing the data (often a EIP-712 structured message), and 3) sending the signed payload via HTTP POST to your relayer's /relay endpoint. The relayer returns a transaction hash once it submits the sponsored tx on-chain.

Here is a simplified code example using ethers.js and a hypothetical relayer API:

javascriptCopy
import { ethers } from 'ethers';

// 1. User signs the meta-transaction data
const userSignature = await signer._signTypedData(
  domain, // EIP-712 domain
  types,   // EIP-712 types
  payload  // The transaction intent
);

// 2. Send to private relayer
const relayResponse = await fetch('https://relayer.your-dapp.com/relay', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    signature: userSignature,
    payload: payload,
    userAddress: signer.address
  })
});

const { txHash } = await relayResponse.json();
// 3. Monitor the relayed transaction
const receipt = await provider.waitForTransaction(txHash);

This pattern decouples signing from submission, which is the key to gasless experiences.

Security is paramount when integrating a relayer. Your frontend must validate the relayer's response and implement error handling for failed transactions. Always use HTTPS for all API calls. The relayer should implement rate limiting, nonce management, and signature verification to prevent replay attacks. For production dApps, consider using established infrastructure like OpenGSN (Gas Station Network), Biconomy, or Stackup which provide battle-tested SDKs and dashboard for managing relay policies, instead of building your own from scratch. These services handle the complexities of gas estimation, nonce conflicts, and transaction queuing.

Finally, monitor the integration's performance. Track metrics like relay latency, transaction success rate, and gas sponsorship costs. Provide clear user feedback in the UI—inform users when a transaction is being relayed and when it's confirmed on-chain. A well-integrated relayer network should be invisible to the end-user, resulting in a seamless Web3 experience where complex blockchain interactions feel as simple as clicking a button on a traditional web application.