SecureRpc - MEV Relay for Censorship Resistant Staking

SecureRpc is a bare-metal, fully conformant JSON-RPC/gRPC Infrastructure plane that aims to perform well and meet the following requirements:

  • censorship resistance
  • latency
  • optimizations
  • support for bespoke RPC Calls
  • seamless usage
  • privacy focused
  • improve trade execution
  • improve trade settlement
  • resistant against coercions from state-level actors

All of this while using as little of your validators’ resources as possible, and without hosting on any cloud provider infrastructure like AWS or Google Cloud.

Differences between SecureRpc and Flashbots

Key differences between SecureRpc (current state, 09/27/2022) and Flashbots-equivalent Relays (Flashbots, Bloxroute, Blocknative):

Searchers can send their bundles to our SecureRpc Relay (OpenMEV) - that’s the only interaction we allow ATM.

Support for whole block submission should be available post devocon (Late October 2022) along with bottom of the block bidding support.

We are also not adding ETH for blocks: there is no loss there as we’re not bleeding additional money (ETH) per block we send to validators (i.e. subsidy).

To the point of this method, there is a lack of concept (re: motivation) where this money would come from to begin with. We’ve found that EIP1559 gives enough tools to include the priority fee in the transaction, so why add another transaction? On the other hand, EIP1559 makes the calculation of how much one will ‘tip’ at the end of the day really awkward. So having such a transaction optional maybe is not a bad idea. However, we have taken out the requirement when validating the block sent to the mev-boost-relay for now.

Block Building

If available, we add a transaction bundle from our private virtual mempool at the top of the block - this is done by our private block builder.

  • When validating a block coming from the block builder
    We skip the tracing part and checking against some arbitrary blacklist - that also gives us slight timing advantage since tracing takes some time (unambiguously). We don’t check for direct payment of reward to the block proposing validator since we don’t include such a transaction. We maximize reward by adding high value transaction from our private virtual transaction mempool.



We are aware of the issues mentioned in this discussion thread Draft Outline for a pDAO proposal on Rules of SP and MEV-Boost - #27 by Valdorff, and are willing to help enable such oversight, etc, for the RP DAO.

We’ve found that EIP1559 gives enough tools to include the priority fee in the transaction, so why add another transaction?

Your relay will be incompatible with my bot then. It sends the ETH using an internal transfer and relies on an EOA address as the recipient. I can maybe change it in the future.

This does not have anything to do with the relay: the relay does not check transaction validation, thats on the block builder.

Any valid ethereum transaction that is valid will not have any issue, that comment is in reference to a flashbots API implementation detail that affects how we are measured in some metrics that compare relays.

Manifold Finance is also prepared to take earned fees to be used to provide rETH/ETH liquidity / reinvest back into Rocket Pool.