Private Relayer

A private relayer abstracts the transaction submission process from the end user. Instead of the user's wallet signing and broadcasting a transaction directly to the public mempool, the user signs a meta-transaction. The relayer then wraps this intent in a new transaction, pays the gas fees from its own pool, and submits it to the network. This completely separates the user's identity and wallet balance from the on-chain transaction record.

The primary security benefit is mempool obfuscation. In a standard transaction, details like the sender's address, recipient, and amount are visible in the public mempool before confirmation, making them vulnerable to front-running and sandwich attacks. A private relayer submits the transaction directly to a trusted validator or through a private channel, ensuring these sensitive details are never exposed to the public peer-to-peer network.

Private relayers typically implement a gas sponsorship model. The end user does not need to hold the network's native token (e.g., ETH for Ethereum) to pay for transaction fees. The relayer operator covers the gas cost, which can be recouped through alternative means such as:

• A flat service fee paid by the dApp integrator.
• A small fee deducted from the transaction amount in a stablecoin.
• A subscription model for users. This significantly improves user experience and onboarding.

Relayers are not open to the public; they enforce strict access control. Typically, only whitelisted smart contract addresses (specific dApps) or authorized user addresses can submit transactions through the relayer's endpoint. This prevents abuse, allows for rate-limiting, and ensures the service is used for its intended purpose, maintaining operational integrity and cost predictability for the operator.

The relayer manages critical transaction parameters to ensure reliability:

• Dynamic Fee Estimation: It calculates optimal maxPriorityFeePerGas and maxFeePerGas based on current network conditions.
• Nonce Management: The relayer maintains and increments its own transaction nonce for its funding account, eliminating nonce conflicts that users would face in a shared system. This requires robust, stateful infrastructure to track pending transactions.

A production-grade private relayer consists of several integrated systems:

• Signer Service: Holds the secure private key for the relayer's funding wallet.
• Transaction Queue: Manages pending user requests, ordering, and prioritization.
• Gas Station: Monitors network gas prices and manages the ETH balance for fees.
• API Endpoint: The secure entry point where whitelisted dApps submit user-signed meta-transactions.
• Monitoring & Alerting: Tracks success/failure rates and gas expenditure.

A core function where the relayer pays the gas fee for the end user. This is essential for:

• Onboarding: Users can interact with dApps without holding the native blockchain token (e.g., ETH).
• Enterprise UX: Applications can offer a seamless, fee-less experience, absorbing costs for their users.
• Batch Operations: A relayer can bundle multiple user operations into a single transaction, optimizing gas costs.

Relayers can enhance privacy by acting as a proxy between the user and the public mempool.

• Origin Hiding: The transaction appears to come from the relayer's address, not the user's, breaking the on-chain link.
• Mempool Protection: Submitting directly to a builder or validator via a private channel (e.g., Flashbots Protect) prevents frontrunning and MEV extraction.
• Use Case: Crucial for institutional traders and any user wanting to conceal their trading strategy or wallet activity.

Private relayers are the execution layer for advanced transaction standards.

• ERC-2771: Allows gasless transactions via a trusted forwarder contract. The relayer receives the signed user intent, pays the gas, and submits it.
• EIP-4337 (Account Abstraction): Bundlers act as specialized relayers, packaging UserOperations from a separate mempool and executing them on-chain, enabling smart contract wallets to operate without gas.

Businesses use private relayers to manage complex blockchain interactions.

• Gas Management: Centralized control and payment of gas fees across thousands of user actions or internal processes.
• Compliance & Security: All transactions can be routed through a monitored, whitelisted relayer for audit trails and policy enforcement (e.g., sanction screening).
• Example: A crypto exchange using a relayer to process all customer withdrawals, paying fees from a corporate treasury wallet.

OpenSea historically used a meta-transaction relayer to allow users to list NFTs for sale without paying gas.

• Process: User signed a message approving the listing. OpenSea's relayer submitted this signed message, paid the gas fee, and interacted with the marketplace contract.
• Benefit: Drastically reduced friction for new users, as they only paid a fee upon a successful sale. This demonstrated the user acquisition power of gas abstraction via a relayer.

Understanding relayers requires knowing what they often avoid: the public mempool.

• Public Mempool: A globally visible pending transaction pool. Transactions here are exposed to frontrunning, sandwich attacks, and other forms of Maximal Extractable Value (MEV).
• Relayer's Role: A private relayer bypasses this public arena by submitting transactions directly to block builders or validators through private channels (e.g., Flashbots SUAVE), offering protection and priority.

The primary function is to act as a transaction proxy. Instead of a user's wallet signing and broadcasting a transaction directly to the public mempool, the user signs a meta-transaction. This signed payload is sent to the relayer's private infrastructure, which then pays the gas fee and submits the final transaction from its own address. This breaks the on-chain link between the user's identity and their activity.

Private relayers operate on a trusted execution model. Users must trust the relayer to:

• Faithfully broadcast the signed transaction without modification.
• Safeguard any private data (like the signed payload) during processing.
• Not censor valid transactions.

The relayer never holds user funds for extended periods (non-custodial for assets), but has temporary custody of the transaction intent. This is a different risk profile than custodial exchanges.

Running a relayer introduces significant operational burdens:

• Infrastructure Security: The relayer's servers and signing keys are high-value targets. A breach could lead to transaction theft or manipulation.
• Gas Management: The relayer must maintain a robust, funded wallet to pay for all user transactions, requiring careful treasury management and gas price forecasting.
• Uptime & Reliability: The service becomes a single point of failure. Downtime prevents all dependent users from transacting.

By processing transactions for users, a relayer may attract regulatory scrutiny. Key considerations include:

• Financial Services Licensing: Could be viewed as a money transmitter or payment processor in some jurisdictions.
• Anti-Money Laundering (AML): May have obligations to monitor and report suspicious transactions, which conflicts with the privacy goal.
• Sanctions Compliance: Must implement controls to avoid processing transactions for sanctioned entities, requiring some level of user screening.

Relayers incur real costs (gas fees, infrastructure) and must develop a sustainable economic model. Common approaches include:

• Fee-Based: Charging users a premium over network gas costs.
• Subscription: A flat fee for unlimited transactions.
• Sponsored by dApps: Protocols pay relayers to offer free transactions to their users, treating it as a user acquisition cost. Without a clear model, the service risks insolvency.

To mitigate centralization and trust risks, the ecosystem is evolving:

• Decentralized Relay Networks: Like the Ethereum Gas Station Network (GSN), which uses a decentralized set of relayers.
• SUAVE (Single Unified Auction for Value Expression): A proposed future Ethereum pre-confirmation layer that could natively support private transaction flow.
• ZK-Proof Systems: Using zero-knowledge proofs to validate transactions without revealing sender details, reducing the need for a trusted intermediary.

The primary purpose of a private relayer is to prevent front-running and sandwich attacks by shielding transaction details from public view. It acts as a trusted intermediary that receives a signed transaction, wraps it, and submits it directly to a validator or block builder, bypassing the public mempool where details are typically exposed.

• Hides Sender: The original sender's address is not visible in the public transaction queue.
• Conceals Intent: The specific function calls, token amounts, and target addresses within the transaction are kept private until inclusion in a block.

A private relayer system typically involves several coordinated components:

• User Client: Signs a transaction with a private key but does not broadcast it publicly.
• Relayer Server: Receives the signed transaction via a private channel (e.g., direct RPC).
• Transaction Bundler: Often packages the private transaction with others for efficiency.
• Direct Submission Path: Uses privileged access (e.g., via a mev-boost relay or direct validator connection) to submit the bundle directly for block inclusion, avoiding the open peer-to-peer network.

Private relayers are critical in high-value and sensitive transaction environments.

• DeFi Trading: Large swaps and liquidity provisions that would be prime targets for MEV extraction.
• Institutional Activity: Hedge funds and funds managing portfolios require discretion to avoid market impact.
• Airdrop Claims & NFT Mints: Prevents bots from copying and outbidding user transactions during competitive events.
• Governance: Allows large token holders to vote privately to avoid influencing the market or becoming a target.

Using a private relayer introduces specific trust considerations.

• Relayer Honesty: Users must trust the relayer not to censor, front-run, or leak their transaction. Reputation is key.
• Centralization Risk: Relayers are centralized services, creating a potential single point of failure or censorship.
• Cost: Services often charge a fee for the privacy and priority service.
• Not Absolute Privacy: While hidden from the public mempool, the transaction details are visible to the relayer, selected block builder, and the block proposer.

Private relaying is a primary tool in the MEV (Maximal Extractable Value) protection toolkit. It directly counters toxic MEV like front-running.

• Contrast with Public Mempool: The default Ethereum transaction flow exposes all data, creating an MEV auction. Private relayers exit this auction.
• Complement to Other Solutions: Works alongside commit-reveal schemes, encrypted mempools (e.g., Shutter Network), and fair ordering protocols.
• Builder Ecosystem: Integrates with the PBS landscape, where specialized builders compete to include private bundles in their block proposals.

A User Operation is a standardized data structure (defined in ERC-4337) that represents a user's intent, such as a token transfer or a smart contract call. It is the fundamental object a Private Relayer processes and submits to the blockchain. Unlike a traditional transaction, it is not signed by an Externally Owned Account (EOA).

Key components include:

• Sender: The smart account address initiating the operation.
• Nonce: Prevents replay attacks.
• InitCode: For deploying a new smart account.
• CallData: The actions the smart account should execute.
• Signature: Cryptographic proof of the user's intent, which the smart account validates.

A Bundler is a network node in the ERC-4337 architecture responsible for aggregating multiple User Operations into a single blockchain transaction. It is the core counterpart to a Private Relayer. While a Private Relayer focuses on privacy and serving a specific user or dApp, a Bundler's primary role is network-level aggregation and economic efficiency.

• Public Role: Bundlers are typically permissionless and serve the public mempool.
• Aggregation: They batch operations to amortize gas costs.
• Paymaster Interaction: They interact with Paymasters to sponsor gas fees for users.

A Paymaster is a smart contract that can sponsor transaction gas fees on behalf of users, enabling gasless transactions or payment in ERC-20 tokens. A Private Relayer often works in conjunction with a Paymaster to abstract gas complexity from the end-user.

• Gas Abstraction: Users do not need to hold the network's native token (e.g., ETH).
• Sponsorship Models: Paymasters can be funded by dApps (for user onboarding) or use deposit/withdraw patterns.
• Validation: The Paymaster validates a User Operation and agrees to pay for it before the Bundler includes it in a block.

The EntryPoint is a singleton, audited smart contract that acts as the central orchestrator and security anchor for the ERC-4337 account abstraction system. Both Bundlers and Private Relayers must interact with it to validate and execute User Operations.

• Inviolable Rules: It enforces critical security checks, including signature verification and nonce management.
• Execution Flow: All bundled operations are routed through the EntryPoint, which calls the respective smart accounts and Paymasters.
• Deposit Staking: Paymasters must stake deposits in the EntryPoint, which can be slashed for malicious behavior.

A Smart Account (or Smart Contract Wallet) is a programmable account, controlled by logic rather than a single private key. It is the destination for a User Operation submitted by a Private Relayer. This is the core innovation that enables account abstraction.

• Programmable Validation: Custom rules for transaction signing (e.g., multi-sig, social recovery).
• Atomic Batch Execution: Can perform multiple actions in a single operation.
• Upgradability: Logic can be updated without changing the account address.
• Session Keys: Can grant limited permissions to other addresses or relayer services.

In ERC-4337, the User Operation Mempool is a dedicated off-chain space where pending User Operations await inclusion by a Bundler. A Private Relayer may bypass the public mempool entirely for privacy, submitting operations directly to a trusted Bundler.

• Separation: Distinct from the traditional transaction mempool for EOA-signed txns.
• Simulation: Bundlers simulate operations from the mempool to ensure they will succeed and are willing to pay fees.
• Privacy Consideration: Submitting to the public mempool can leak transaction intent, which Private Relayers are designed to prevent.