Private Transaction Relay

Private relays operate under different trust and architectural models, which define their security and decentralization properties.

• Trusted Relay Model: A centralized entity operates the relay (common for early providers).
• Decentralized Relay Network: A permissionless set of nodes run the service (e.g., Taichi).
• Staked/Slashed Relay: Operators stake collateral that can be slashed for misbehavior (e.g., Eden).
• PBS (Proposer-Builder Separation) Integration: Relays connect directly to block builders in an MEV-Boost auction.

End-user access to private relays is primarily through wallet RPC (Remote Procedure Call) configuration. This is how privacy becomes a user-facing feature.

• Custom RPC Endpoints: Users manually add a relay's RPC URL to their wallet (e.g., https://rpc.flashbots.net).
• Built-in Wallet Features: Wallets like MetaMask and Rabby integrate relays like Flashbots Protect into their UI.
• Bundler Services: For account abstraction (ERC-4337), specialized bundlers often integrate private relays to protect user operations.

A relay can choose to censor transactions by refusing to include them in a block. This creates a central point of failure for transaction inclusion, potentially blocking transactions from certain addresses or containing specific data. The relay's inclusion policy is a critical, often opaque, trust assumption.

• Example: A relay could blacklist transactions interacting with a sanctioned smart contract.
• Mitigation: Users can broadcast to multiple relays or use mev-boost with a diverse set of relay operators.

Validators using a relay must trust it to provide a valid block header and a full block body that matches. This is a cryptoeconomic trust issue: if a relay provides an invalid block body, the validator signs an invalid header and may be slashed. The relay's software integrity and operational security are paramount.

• Risk: A compromised or malicious relay could cause validators to sign for unavailable or incorrect blocks.
• Verification: Some relays provide proofs of block body availability (e.g., via Data Availability Sampling) to reduce this trust.

Relays are a key player in the MEV supply chain. They receive transaction bundles from searchers and choose which ones to forward to validators. This gives them significant power over:

• Transaction ordering within the block.
• Extracted value distribution between searchers, validators, and users.
• Front-running and sandwich attack prevention.

A relay's auction mechanism and proposer payment (tip) routing policies directly impact market fairness.

Sending a transaction to a relay exposes its content before it is publicly on-chain. This creates a front-running risk if the relay or its connected builders are malicious. While the transaction payload may be encrypted, metadata (sender, gas, timing) is still visible.

• Threat: A relay could leak transaction details to affiliated searchers.
• Solution: Protocols like SUAVE aim to decentralize this function, and encrypted mempools (e.g., using threshold encryption) are an active area of research.

The relay landscape can become concentrated, with a few dominant operators processing most blocks. This creates systemic risk:

• Single point of failure: Technical outages at a major relay can disrupt block production.
• Collusion: Dominant relays could coordinate to enforce policies network-wide.
• Governance attack vector: Control over relay software becomes a high-value target.

Client diversity among validators in their relay choices is crucial for network health.

To minimize trust, the relay's operations should be verifiable. Key mechanisms include:

• Public Attestations: Relays can publicly commit to their received blocks and bids.
• Open Source Software: Relay client code should be auditable.
• Performance Metrics: Public data on relay uptime, censorship metrics, and inclusion latency.
• Registries: Lists like the Ethereum Relay Registry help validators assess relay reputation and compliance with policies like OFAC sanctions.

A cryptographic technique for hiding information until a later point in time. It involves two phases:

• Commit: A user publishes a cryptographic commitment (e.g., a hash) of their transaction data.
• Reveal: Later, the user reveals the original data, which can be verified against the commitment. This is an alternative privacy method that doesn't require a trusted relay, but introduces latency and complexity compared to direct private submission.

The security model of a private relay hinges on the integrity of its operators. Users must trust that the relay:

• Will not frontrun them (the primary threat).
• Will not censor their transaction.
• Will not leak their transaction data.
• Will reliably deliver the transaction to a block builder. This centralized trust is the core trade-off compared to broadcasting directly to the permissionless, but exploitable, public mempool.

Specialized nodes that construct full block proposals by selecting and ordering transactions to maximize profit (often via MEV). In Ethereum's Proposer-Builder Separation (PBS) model, private relays typically send transactions directly to these builders. The builder then creates an optimized block and sells it to a validator (proposer) for inclusion. The relay's effectiveness depends on its integration with dominant, high-quality builders.