Relay Client

A primary function is to protect users from frontrunning and sandwich attacks by submitting transactions to a private mempool. This prevents searchers from viewing pending transactions on the public mempool. Advanced clients also implement cryptographic commitments to hide transaction content until it is included in a block, enhancing censorship resistance.

• Example: A user's large DEX swap is hidden until execution, preventing predatory bots from manipulating the price.

The client intelligently routes transactions to a network of builders and searchers competing to construct the most profitable block. It evaluates backrun opportunities and bundle construction to capture and return MEV (Maximal Extractable Value) to the user as priority fees or rebates.

• Mechanism: The client may split a transaction, sending components to specialized searchers for optimal arbitrage or liquidations before final inclusion.

To ensure reliability and competitive outcomes, a relay client connects to multiple block builders. This creates redundancy if one builder fails and fosters competition, driving better execution prices for users. The client monitors builder performance metrics like inclusion rate and latency.

• Key Benefit: Diversification prevents reliance on a single point of failure and mitigates the risk of centralized builder censorship.

Before forwarding a transaction, the client performs local simulation to verify it will not revert, protecting the user from wasted gas fees. It also validates the builder's payload (the proposed block) against consensus rules and execution integrity before signing off, ensuring the final block is valid.

• Process: This involves running a local EVM execution client to simulate transaction outcomes and cryptographically verifying block headers.

The client handles complex fee logic, separating the priority fee (to the validator) from potential MEV rebates. It manages payment streams to builders and searchers for their services. Some clients support conditional transactions that only execute if certain on-chain conditions are met, optimizing gas spend.

• Example: A transaction may specify a maximum slippage tolerance; the client will only submit it if a builder can meet that condition.

Relay clients expose standardized JSON-RPC endpoints (e.g., eth_sendPrivateTransaction) that wallets and dApps integrate with seamlessly. This abstracts the complexity of the MEV supply chain from end-users. The API handles transaction status tracking, receipt retrieval, and error reporting.

• Developer Use Case: A wallet SDK simply sends a signed transaction to the relay client's endpoint instead of broadcasting it publicly to the P2P network.

The core function of a relay client is to route user transactions to a network of specialized block builders via mev-boost on Ethereum. It does not build blocks itself but acts as a gateway, selecting the most profitable or reliable block proposal to forward to validators. This separation of concerns is fundamental to proposer-builder separation (PBS).

• Process: The client receives a transaction bundle, queries multiple relays for block header bids, and submits the highest-value header to the validator.
• Goal: Maximizes validator rewards while maintaining network decentralization and censorship resistance.

A critical design goal for relay clients is to mitigate transaction censorship. They achieve this by connecting to a diverse set of relays with different policies.

• Relay Diversity: By default, clients like mev-boost are configured to connect to multiple, independent relays (e.g., Flashbots, BloXroute, Agnostic).
• Fallback Mechanisms: If one relay censors or rejects a valid transaction, the client can route it through another. This distribution of trust is a key defense against centralized control over block inclusion.

A primary security concern is whether a relay client censors transactions. This can occur through transaction filtering based on origin, content (e.g., OFAC-sanctioned addresses), or gas price. Relays implement commitment schemes (like signed headers) to provide cryptographic proof of what they received, allowing users to detect exclusion. The health of the network depends on a diverse set of relays to prevent centralized points of control.

Users must trust the relay to faithfully transmit their transaction data to builders. Key risks include:

• Data withholding: The relay receives a transaction but does not propagate it.
• Data manipulation: Altering transaction parameters (like maxPriorityFee).
• Timing attacks: Delaying a transaction to benefit other parties. Mitigations include using multiple relays (multiplexing) and builders publishing block bodies to prove they received the exact payload.

Trust is often managed through reputation systems and cryptoeconomic security. Malicious behavior, such as signing conflicting blocks or censoring, can lead to:

• Reputation loss: Builders and searchers may blacklist the relay.
• Financial slashing: In proof-of-stake relay designs, a staked bond can be forfeited.
• Ejection from relay registries: Being removed from trusted lists used by major RPC providers and wallets.

Despite decentralization goals, relay operation has high barriers to entry (performance, compliance), risking consolidation. A dominant relay becomes a single point of failure for the entire proposer-builder separation (PBS) ecosystem. Attacks or regulatory action against a major relay could disrupt block production. The community mitigates this by supporting open-source relay software and permissionless relay networks.

Relays are gatekeepers to block builders, who compete for Maximal Extractable Value (MEV). A relay could:

• Prefer certain builders (e.g., those sharing more revenue).
• Run its own builder and give itself preferential access.
• Front-run transactions it receives. Transparency in builder selection algorithms and auction mechanics is crucial for maintaining a fair and efficient market.

The relay's own software and infrastructure must be secure. Vulnerabilities could lead to:

• Private key compromise: Allowing an attacker to sign fraudulent block headers.
• DoS attacks: Taking the relay offline and disrupting the network.
• Software bugs: Causing incorrect block commitments or data leakage. Best practices include regular audits, bug bounties, and high-availability, geographically distributed deployments.