The primary role of the oracle is to ensure that the provider carries through on their commitments.
The oracle consists of two parts:
The oracle mechanism in this protocol automates the verification of provider commitments to include specific transactions in L1 blocks. The Oracle Microservice queries the L1 Data Source for transaction hashes and extra data, cross-references these with commitments logged in the Commitments Contract, and then the Oracle Contract verifies adherence. If a commitment is met, the Oracle Contract triggers a reward to the provider via the Bidder Contract; if not, it slashes the provider by interacting with the Provider Contract.
Before the oracle can be engaged according to the protocol's intended sequence of events, several preliminary actions must be taken:
1a. A bidder sends their raw transaction to a provider, such as a Block Builder or the public mempool.
1b. Simultaneously, the bidder issues a bid via the mev-commit peer-to-peer network.
After the bidder's actions, the provider proceeds to:
2a. Retrieve the bid from the MEV-commit network.
2b. Issue a commitment for the transaction mentioned in the bid.
When a bid for a transaction (txnj) is circulated through the mev-commit p2p network and the provider has made a commitment, the oracle is activated to verify whether the provider has honored this commitment.
The process is as follows:
- The provider assembles the complete L1 block, incorporating txnj, to which it previously committed. Note: If the provider doesn’t get selected to construct the L1 Block, the oracle flow does not get triggered.
- The Oracle microservice fetches the block from the L1 chain and verifies the presence of txnj.
- Upon confirmation that txnj is included, the microservice notifies the oracle smart contract of the commitment's fulfillment.
- The oracle smart contract then initiates the transfer of funds from the bidder's prepaid balance to the provider's account.
In the event that a provider fails to include a committed transaction (txnj) in the L1 block, the Oracle Slashing Path is initiated to penalize the provider for the breach of commitment. This process is outlined below:
- The provider is expected to produce an L1 block that includes the committed transaction (txnj). However, if the provider does not include txnj, the protocol moves to the slashing phase.
- The Oracle microservice retrieves the block from the L1 chain and searches for txnj. If the transaction is not found, it triggers the next step.
- The Oracle communicates that txnj was not seen in the Oracle Contract.
- The Oracle Contract, upon receiving this information, initiates the slashing procedure. This involves penalizing the provider by triggering a slash event, which results in the forfeiture of the stake held by the provider contract as a guarantee of honest behavior.
- The confiscated stake is subsequently allocated to the bidder as compensation for the provider's failure to include the committed transaction, thereby ensuring that the bidder is recompensed for the provider's breach of trust.
We offer a mechanism for locking and unlocking funds associated with a pre-confirmed bid.
Funds movement involves locking the bid amount in escrow when a commitment is processed. This occurs only once per bid, meaning if there are multiple commitments for the same bid, the funds will be locked only once.
The funds are released when the Oracle resolves the commitment. If the provider is slashed, the locked funds are unlocked and returned to the bidder.