Primev / mev-commit

Mev-commit is a peer-to-peer networking platform designed to facilitate real-time interactions and coordination between mev actors and execution providers. It provides a robust network for exchanging execution bids and cryptographic commitments, which are used to specify execution requirements in detail and to receive credible commitments that act as promises to fulfill bid requirements. Mev-commit allows actors to engage in “fast games” such as preconfirmations through real-time cryptographic commitments and settles results using a high throughput blockchain for permissionless access.

Prize distribution and scoring

• Total Prize Pool: $65,000

• Primary Prize Pool: $63,700

• $1300 of the prize pot is reserved for Low & Informational severity findings. These reports are judged based on quality and reviewers are then ranked from 1st to 5th for the purpose of prize allocation.

  • 1st: $300
  • 2nd: $250
  • 3rd: $250
  • 4th: $250
  • 5th: $250

• Scoring described in the competition scoring page.

• Findings Severities described in detail on our docs page.

Documentation

• Technical Documentation

Recorded Walkthrough

• Part 1: mev-commit-walkthrough-part1

• Part 2: mev-commit-walkthrough-part2

• Part 3: mev-commit-walkthrough-part3

Scope

• Repository: https://github.com/primev/mev-commit
• Commit: a8f287ed6c2759edad7cc1c2df9d30f6d5da31c3
• Files: All files in the contracts/contracts directory.

Build Instructions

1. Clone the https://github.com/primev/mev-commit repo.
2. Install https://book.getfoundry.sh/.
3. Navigate to the contracts directory.
4. Run forge clean && forge build --via-ir

Basic POC test

• Major contracts each have their own respective unit test file in the contracts/test directory. These can be utilized for POC testing, and are all runnable using forge clean && forge test \--via-ir from the contracts directory. Examples below:

  • PreconfManagerTest.sol
  • SettlementGatewayTest.sol
  • MevCommitAVSTest.sol

Out of scope

• For all contracts, the designated oracle account is assumed to be honest. That is, transactions coming from the oracle account should be trusted by all actors.
  • For example, a previous audit revealed that the BlockTracker.sol’s oracleAccount can manipulate _blockNumber to skip windows. An issue similar to this would be considered out-of-scope, since the oracle account is assumed to be honest.
• The owner account for each contract is also assumed to be honest and secure. Every contract is upgradeable, and most on-chain parameters are mutable by the owner.
• For the standard-bridge contracts, the relayer account is assumed to be honest and secure.
• L1 reorg risk in our standard-bridge is assumed not present, due to the relayer waiting for TransferInitiated event finalization before calling finalizeTransfer on the counterparty chain.
• A slashAmount must be included when registering each vault in MevCommitMiddleware.registerVaults. We acknowledge there’s a risk in a vault’s ERC20 token value changing rapidly, causing a validator to be pseudo-undercollateralized by a particular vault. This risk is mitigated by updateSlashAmounts, and a price oracle will be integrated in the future.
• 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. See https://github.com/primev/mev-commit/issues/213.
• For all three validator registry contracts, the main output our protocol cares about is the respective isValidatorOptedIn functions. Validators can be “registered” (ie. have some form of state stored in the contract), without being “opted-in”. The intricacies of each contract’s isValidatorOptedIn function varies.
• 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.

• Automated findings by Lightchaser

Primev report

Contact Us

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