​
Introduction

The mev-commit contracts verify and manage the movement of funds as a response to bid and commitment activities that occur on our p2p network.

For mev-commit testnet contract addresses please refer to Testnet section.

​
Core Contract Architecture and Functionality

The mev-commit protocol uses 4 core contracts:

  • Preconfirmations Contract
    • This will persist details about the commitments that have been made into contract storage.
  • Bidder Registry Contract
    • This will be where the bulk of monetary transfer occurs.
    • Bidders prepay for bids into this contract.
    • The payment gets processed into a provider-allocated section that a provider can later retrieve.
  • Provider Registry Contract
    • This contract stores the stake a provider bounds to ensure it doesn’t break its promises under preconfirmations.
  • Oracle Contract
    • This simply retrieves details on which commitments to process for rewarding or slashing.
    • Access to the functions on this contract is restricted to the owner of the Oracle key.

​
Fee Vault Contract

The mev-commit chain implements a fee mechanism where all base fees accumulate to a “fee vault” contract. The predetermined address for such a contract is hardcoded into mev-commit-geth.

The fee vault contract is initiated with an immutable treasury address. The contract owner can invoke transfers of the accumulated fees from the sidechain contract, to the treasury address on L1, including bridging.

Since the treasury address is immutable, the contract owner only has the power to initiate transfers. The separation between the contract owner and treasury accounts is useful because key management can be separate; i.e. a secure multisig governing the protocol treasury doesn’t need to submit regular transfer transactions.

​
Bridge Contracts

​
Whitelist Contract

Since multiple bridges will connect to the mev-commit chain, only whitelisted (approved/active) bridging contracts should be able to mint/burn native ether.

  • Managing Bridging Permissions: A whitelist contract on the mev-commit chain manages addresses authorized to mint or burn sidechain ether as part of the bridging process. This contract is crucial for integrating various bridges and maintaining control over which contracts can perform critical functions.
  • Mint/Burn Functionality: The whitelist contract on the mev-commit chain is responsible for minting and burning native ether corresponding to bridging actions. This ensures that ether on the mev-commit chain accurately reflects locked collateral on L1.

​
L1Gateway and SettlementGateway Contracts

To bridge from L1 to the mev-commit chain, a user EOA first calls the InitiateTransfer function on the L1Gateway contract. This function accepts two parameters, a recipient account to receive funds on the counterparty chain, and an amount to transfer. The user must send (lock) the appropriate amount of ether in the L1Gateway contract as a part of the transaction that calls this function.

During the InitiateTransfer transaction, an event is emitted from L1. The relayer continuously monitors for these L1 events from finalized blocks. Once the L1 event is observed by the relayer, it calls the FinalizeTransfer function on the bridge gateway contract residing on the mev-commit chain, the SettlementGateway contract. This transaction mints native ether to the recipient EOA, with an appropriate amount of wei.

To bridge ether from the mev-commit chain back to L1, a user follows the same pattern as described above, as the relayer monitors both chains for transfer events.

Note the destination gateway contract enforces a flat fee on the destination address. This is a constant fee paid to the relayer during the transfer finalization transaction. It currently serves as a simple 1 wei placeholder. In production, this fee must be greater on average than the gas cost of transfer finalization transactions sent from the relayer.

​
Deploying Custom Contracts

You can deploy your own custom contracts on our mev-commit chain. To do so, simply set your Chain ID to 17864 and RPC Url to https://chainrpc.testnet.mev-commit.xyz. Now you can deploy any EVM compatible contracts to the mev-commit chain. Feel free to use Foundry, Hardhat, or any other smart-contract development and deployment framework.