MEV Protection via Commit-Reveal

01Executive Summary

Maximal Extractable Value (MEV) represents one of the most damaging systemic risks in blockchain systems, with over $1 billion extracted annually from users through frontrunning, sandwich attacks, and validator-controlled transaction reordering. JIL Sovereign eliminates MEV at the protocol level through a two-phase commit-reveal mechanism combined with Verifiable Random Function (VRF) based ordering.

In Phase 1 (Commit), users submit encrypted commitments - a hash of their transaction plus a random nonce - during a 500-millisecond collection window. In Phase 2 (Reveal), the original transactions are disclosed, verified against their commitments, and ordered using a VRF seeded with the block hash. Because the ordering seed depends on the block hash (unknown during the commit window), no party - including validators - can predict or manipulate transaction order.

02Problem Statement

MEV extraction is a structural tax on every blockchain user. When a user submits a DEX trade, any observer who sees the pending transaction can insert their own transaction before it (frontrunning) or wrap it between two transactions (sandwich attack) to extract value. Validators compound the problem by reordering transactions within a block to maximize their own profit.

2.1 MEV by the Numbers

2.2 Attack Taxonomy

03Technical Architecture

3.1 Two-Phase Commit-Reveal Protocol

Phase 1: COMMIT (500ms window)
  |  User submits: commitment = SHA256(tx_data || nonce)
  |  Transaction content is hidden from all observers
  |  Validators collect commitments into commitment set
  |
Phase 2: REVEAL (500ms window)
  |  User submits: (tx_data, nonce)
  |  Validator verifies: SHA256(tx_data || nonce) == commitment
  |  Invalid reveals are discarded (commitment wasted)
  |
Ordering: VRF SHUFFLE
  |  Seed = VRF(validator_key, block_hash || batch_id)
  |  Fisher-Yates shuffle using SHA256 chain from seed
  |  Deterministic: all validators produce same order
  |
Execution: SEQUENTIAL
  |  Transactions executed in VRF-determined order
  |  Slippage and limit checks applied per transaction
  |  Failed transactions produce rejection receipts

3.2 Commitment Structure

3.3 VRF Seed Generation

The VRF seed is generated by the block proposer using their validator key and the previous block's hash. Because the block hash is unknown until the block is finalized (after the commit window closes), no party can predict the ordering seed during the commit phase. The VRF proof is included in the block header so that all validators can independently verify the seed's correctness.

// VRF seed generation
seed = VRF_prove(validator_private_key, prev_block_hash || batch_id)
proof = VRF_proof(validator_private_key, prev_block_hash || batch_id)

// Deterministic Fisher-Yates shuffle
function vrfShuffle(transactions, seed) {
  let state = seed;
  for (let i = transactions.length - 1; i > 0; i--) {
    state = SHA256(state);
    let j = bytesToInt(state) % (i + 1);
    [transactions[i], transactions[j]] = [transactions[j], transactions[i]];
  }
  return transactions;
}

04Implementation

4.1 Batch Window Timing

The default batch window is 3,000 milliseconds (configurable via BATCH_WINDOW_MS). Within each batch window, the first 500ms are allocated for commitment collection, the next 500ms for reveal submission, and the remaining 2,000ms for VRF ordering, execution, and block finalization. This timing ensures that even under network latency, all participants have sufficient time to submit both commitments and reveals.

4.2 Commitment Verification

During the reveal phase, each validator independently verifies that SHA256(revealed_tx || revealed_nonce) == original_commitment. Any reveal that does not match its commitment is silently discarded. The commitment fee is still consumed (preventing spam attacks where users submit commitments without intending to reveal). Users who fail to reveal within the window forfeit their fee deposit.

4.3 Ordering Algorithm

1. Collect Reveals: All valid reveals for the current batch are assembled into an unordered set.
2. Generate VRF Seed: Block proposer generates the VRF seed from their key and the previous block hash.
3. Deterministic Shuffle: Fisher-Yates shuffle using SHA256 chain seeded by VRF output. All validators produce the same permutation.
4. Sequential Execution: Transactions execute in the shuffled order. Each transaction is checked against slippage limits and price bounds.
5. Result Aggregation: Executed transactions are assembled into the block. Failed transactions produce signed rejection receipts.

05Integration with JIL Ecosystem

5.1 Retail Lane Engine

The retail-lane-engine service (port 8563) implements the batch auction clearing algorithm that uses the commit-reveal + VRF ordering described in this claim. Every trade intent submitted to the retail lane is processed through the commit-reveal pipeline, ensuring that all DEX trades receive provably fair ordering.

5.2 Execution Router

The execution-router service (port 8562) determines whether a trade is routed to the retail lane (commit-reveal batches) or the RFQ lane (direct market maker quotes). Small trades and standard market orders flow through the retail lane and receive full MEV protection. Large institutional trades may opt for the RFQ lane where pricing is determined by direct market maker competition.

5.3 Market State Integration

The market-state service (port 8561) adjusts batch parameters based on market conditions. During ELEVATED or STRESSED states, batch windows may be extended and commitment fees increased to prevent spam during volatile periods. In HALTED state, no new commitments are accepted.

5.4 Fee Distribution

DEX fees (200 basis points total - 1% buyer, 1% seller) collected from MEV-protected trades are distributed according to the protocol fee split: 50% to liquidity providers, 40% to platform operations, and 10% to the humanitarian fund. The VRF ordering ensures that this fee distribution is not distorted by reordering attacks.

06Prior Art Differentiation

07Implementation Roadmap

08Patent Claim