mev-commit

mev-commit

@Primev
Live
Instructions

Total reward

$12,000

Status

Live

Findings submitted

12

Start date

15 Sep 2025

End date

21 Sep 2025

Primev’s L1 smart contracts for routing builder payments, distributing validator stipends, and managing bidder deposits.

Core components:

  • BlockRewardManager — a minimal router that forwards builder payments to a validator’s fee recipient (with an owner controlled protocol fee %).
  • RewardDistributor — Pays periodic (e.g., weekly) ETH stipends to operator-defined recipients based on validator-key participation, with optional delegate claims. Also allows permitted token distribution in a similar manner.
  • DepositManager - Contract that bidders can “set their code” to via EIP-7702 to have the core contracts automatically top-up deposits during the settlement process.
  • BidderRegistry - Contract facilitating the bidder registration process, and depositing process.

Prize distribution and scoring

  • Public Prize Pool: $12,000

  • Additional pay for dedicated Cantina researcher: $2,000

Scoring described in the competition scoring page.

Findings Severities described in detail on our docs page.

Documentation

Scope

Out of Scope

  • For all contracts, the designated owner account is assumed to be honest. That is, transactions coming from the owner account should be trusted by all actors. Further, all values set by the owner account are assumed to be safe and correct. The owner account is also assumed to be able to receive/handle ETH.
    • For example, it would be OOS to say “the owner account of the BidderRegistry.sol is able to set a preconfManager address in the bidder registry that would cause ___ undesired behavior”. This is OOS because it would be assumed the owner set a correct and safe preconfManager address.
  • Every contract is upgradeable, pauseable by the owner, and most on-chain parameters are mutable by the owner. This is assumed safe and expected.
  • Contracts which use 48 byte validator or builder BLS pubkeys, only validate those pubkeys by byte length. We are aware there are ramifications to not validating BLS identities/signatures on-chain, and this is something we’ll address in future versions of the contracts.
  • Small and/or trivial changes to the contracts that would result in trivial gas savings are considered out of scope. Changes to the contracts resulting in non-trivial gas savings would be considered a low-severity finding.
    • For example, we’re aware that in certain scenarios, using strict vs non-strict inequalities can have different gas consequences. We value correctness, understandability, and readability in our code, and do not wish to refactor around trivial gas savings.

OOS Items Specific to BlockRewardManager

  • In payProposer, the tx is intended to revert if feeRecipient payment fails.
  • The potential fee % causing builder payment to reduce mev reward amount is out of scope, as we have future requirements for our validators and builders for this to be acceptable.
  • We have no issue with the payProposer function being executed by any address.
  • payProposer does not have a 0 msg.value check to avoid unnecessary operations. Any legitimate call of payProposer is expected to have a non-zero msg.value and should behave as expected.
  • The builder calling payProposer() accepts the risk that the feeRecipient() could have logic that increases gas costs. This is the same risk they take when paying them without using our contract, and they are likely aware if a recipient has an expensive receive() function.

OOS Items specific to RewardDistributor

  • grantETHRewards(), grantTokenRewards(), and claiming with a long list of recipients is known to be an expensive function as the list of Distributions grows. This will be broken up into multiple calls to avoid reaching gas limits. Operators will typically only use the global override option and will be monitored. (Merkle tree considered, but value gas-efficient recipient claims over distributions)
  • overrideRecipientByPubkey() is known to be an expensive function for mass-updating keys. This will be rarely used and only an option to have niche support for operators that do not properly separate their groups of pubkeys between multiple operators. The setOperatorGlobalOverride() function will be by far the more commonly used method of setting their recipient. overrideRecipientByPubkey() can be called by any user on any pubkey, even if it is not managed by them. This is not a problem; this only updates that user’s recipient for that key, which will never be read or used if they do not manage that key. We do not care about any miscellaneous calls of this function by users who do not manage the pubkey.
  • Operators being contract addresses that cannot claim or migrate rewards is not considered an issue. Operators are already essentially confirmed to be EOA/multisig before rewards are granted. If somehow they cannot claim, the owner can reclaim rewards from them and distribute them somewhere else.
  • We will only add standard ERC20 tokens that are compatible with the contract (no fee-on-transfer, unsafe, ERC-777, etc).
  • Operators claim ETH and ERC-20 at their own risk of handling. If they cannot handle ETH or tokens granted to them, they should migrate their rewards/update their recipient address.
  • The owner will not incorrectly override a tokenID mapping (the owner is trusted and will not incorrectly use the contract).
  • Any tokens added will be compatible with the contract/SafeERC20.
  • Malicious operators can theoretically increase Reward Manager grant gas costs by setting different recipients for each of their BLS keys. This requires operators to have many different BLS keys registered. In addition, operator overrides will be monitored, and our off-chain service can adjust behavior in cases of intentional abuse if needed.
  • No zero checks in grant functions are for gas savings, the reward manager will validate this off-chain.
  • Operators can override individual BLS key recipients to 0 at their own risk, no check for gas savings. They can always migrate rewards if rewards are granted to the 0 address. If they claim to the 0 address, it is their own responsibility and not considered a contract issue.

OOS Items Specific to DepositManager and BidderRegistry

  • Any issue that’s specific to EIP-7702 itself in general. This mechanism is live on L1 ethereum and we trust it’s gone through enough QA to be trusted.
    • Example: “EIP-7702 is flawed in ___ way, that’s not relevant to mev-commit’s specific usage of the mechanism”
  • Any issue involving a bidder EOA using EIP-7702 to “set their code” to anything except the exact implementation of the deposit manager that’s being audited, would be invalid. UNLESS these actions could negatively impact an actor in the system other than the relevant bidder.
    • Example: A bidder EOA could “set their code” to the deposit manager, set some EOA-specific state, “set their code” to a different contract implementation, then write to state in some way that causes issues for the bidder. This would be OOS since the bidder uses EIP-7702 in an unintended way that only affects their own account.
  • The “depositManagerImpl” set in the bidder registry is assumed to be correctly set to the address of the exact deposit manager implementation being audited. See here.
  • It is assumed the deposit manager and bidder registry contracts will be deployed on the latest commit of the erigon EL at this repo https://github.com/primev/erigon.
  • It is assumed that the DepositManager contract implementation is deployed with correct/reasonable constructor params for _bidderRegistry and _minBalance. See here
  • It is assumed that bidder’s can reasonably obtain and trust the DepositManager and BidderRegistry contract addresses they interact with.
  • It’s expected behavior that once a bidder calls requestWithdrawalsAsBidder for a specific deposit/provider, that bidder cannot deposit new funds w.r.t that provider, until the bidder successfully calls withdrawAsBidder.
  • Anyone can call topUpDeposit when a bidder has 7702 code set.
  • Any issue involving the implementation of EIP-7702 changing in the underlying evm environment for which these contracts are deployed, is invalid.
    • Example: “Future EIPs may change the code.length associated with an EOA who’s set their code. With the current implementation of EIP-7702, code.length will always be 23 for an EOA who’s set their code, but this may change”. This would be an OOS issue since it relies on the implementation of EIP-7702 changing

Build Instructions

POC

Contact Us

For any issues or concerns regarding this competition, please reach out to the Cantina core team through the Cantina Discord.