How to Architect a Commit-Reveal Scheme for DEX Trades

A commit-reveal scheme is a cryptographic protocol that separates the submission of a trade's intent from its execution. In a typical DEX like Uniswap V3, a user's transaction is public in the mempool before it is mined, allowing MEV bots to front-run profitable trades. A commit-reveal scheme mitigates this by having users first submit a cryptographic commitment (e.g., a hash) of their trade details. Only after a delay do they reveal the actual trade parameters, at which point it is too late for others to exploit the information. This architecture introduces a trade-off between latency and protection.

The core of the scheme involves two transactions. The commit transaction contains a hash, H = keccak256(abi.encodePacked(secret, amountIn, minAmountOut, deadline)). Here, secret is a random number only the user knows, and the other parameters define the trade. This hash is published on-chain, locking in the user's intent without revealing the details. The contract stores this commitment with a timestamp, initiating a commit phase during which no execution can occur. This phase must be long enough to ensure network propagation and prevent block-level manipulation.

After a predefined waiting period (e.g., 5 blocks), the user submits the reveal transaction. This transaction provides the preimage—the original secret, amountIn, minAmountOut, and deadline. The contract recalculates the hash from these inputs and verifies it matches the stored commitment. It also checks that the current block timestamp is before the deadline. If all checks pass, the contract executes the swap against the current on-chain liquidity. Crucially, the price is determined at reveal time, not commit time, which protects against front-running but exposes the user to price movement during the delay.

Implementing this requires careful smart contract design. The contract must manage state for pending commitments, enforce timing constraints, and securely handle the swap execution. A basic structure includes functions for commit(bytes32 commitmentHash), reveal(uint256 secret, uint256 amountIn, uint256 minAmountOut, uint256 deadline), and an internal _executeSwap logic. You must also include a mechanism to slash or cancel commitments if the user never reveals, to prevent state bloat. Gas costs are doubled for users, and the system's utility depends on the chosen delay being acceptable for the trading pair's volatility.

While effective against pure front-running, commit-reveal has limitations. It does not protect against back-running (trades that follow after execution) or sandwich attacks if the reveal transaction itself is detectable. For full protection, it is often combined with other techniques like submarine sends or integration with a private mempool service like Flashbots Protect. Furthermore, the scheme adds latency, making it unsuitable for highly volatile or arbitrage scenarios where speed is critical. Its primary use case is for large, non-urgent trades where price improvement from avoiding MEV outweighs the risk of adverse price moves during the commit phase.

To deploy this, you can extend an existing DEX router or build a wrapper contract. Key parameters to optimize are the commit phase duration and the cryptographic hash function. Using a secure random number for the secret is essential; it can be generated client-side with ethers.utils.randomBytes(32). Always audit the contract for timing attacks and ensure the reveal transaction cannot be intercepted. For a practical example, review the code for Gnosis Protocol v1 (now CowSwap) which uses a batch auction with commit-reveal elements to achieve fair price settlement.

A commit-reveal scheme operates in two distinct phases. In the commit phase, a user submits a cryptographic hash of their trade details—such as token amounts, addresses, and a secret salt—to a smart contract. This hash acts as a commitment, locking in the user's intent without revealing the sensitive parameters to the network. In the subsequent reveal phase, after a predetermined delay, the user submits the original trade details and the salt. The contract verifies that the hash of these inputs matches the initial commitment before executing the trade. This delay is the key mechanism that neutralizes front-running bots, as they cannot act on information that is still hidden.

To build this system, you need a foundational understanding of Solidity and the EVM. Core concepts include hashing functions like keccak256, which are deterministic and one-way, making them ideal for commitments. You must also understand how to manage state variables to store commitments and time-based logic using block timestamps or numbers to enforce the reveal delay. Familiarity with a development framework like Hardhat or Foundry is essential for testing the timing and security of your contracts. Setting up a local testnet with tools like Anvil or Hardhat Network allows you to simulate block progression and front-running attacks.

The primary smart contract requires several key state variables: a mapping to store commitments (hashes) linked to user addresses, a constant or configurable REVEAL_DELAY (e.g., 5 blocks), and a struct to bundle reveal parameters. The commit function will typically be payable if it requires a deposit to discourage spam. Critical security considerations include ensuring the salt has sufficient entropy (use block.timestamp and msg.sender cautiously), preventing replay attacks across chains or contracts, and implementing a strict window for the reveal phase after the delay expires. All user inputs must be tightly packed and hashed consistently in both phases.

A robust testing strategy is non-negotiable. Use Foundry's vm.warp or Hardhat's network manipulation to test the reveal delay precisely. Write tests that simulate a malicious actor attempting to:

• Decode or guess the commitment hash.
• Submit a reveal before the delay.
• Use another user's revealed data.
• Front-run the reveal transaction itself. Your tests should also verify the contract correctly refunds deposits after a successful reveal or after a commitment expires. Consider integrating with a DEX like Uniswap V3 by having the reveal function call ISwapRouter.exactInputSingle with the now-visible parameters.

For production, you must decide on the scheme's economic parameters. A commitment deposit penalizes users who don't reveal, compensating the network for stored state. The reveal delay must be long enough to prevent block-level front-running but short enough for a good user experience (5-20 blocks is common). Gas optimization is crucial; store only the hash (a bytes32) in the commit phase. Finally, architect for upgradeability or a pause mechanism using proxy patterns, as novel attack vectors may emerge. The complete system creates a fair, transparent, and resilient trading environment resistant to MEV extraction.

A commit-reveal scheme separates a transaction into two distinct on-chain phases to protect sensitive information. In the commit phase, a user submits a cryptographic commitment—typically a hash of their trade parameters plus a secret random value (a salt). This hash, like keccak256(amountIn, amountOutMin, path, salt), is published to the blockchain. At this point, observers only see an opaque hash, hiding the trade's direction, size, and asset pair. This prevents Maximal Extractable Value (MEV) bots from frontrunning the transaction, as they cannot decode the intent from the hash alone.

The reveal phase occurs after a predetermined delay or block height. The user submits a second transaction containing the original trade parameters and the secret salt. The smart contract verifies the reveal by hashing the provided data and checking it matches the stored commitment. If valid, the trade executes. The delay between commit and reveal is critical; it must be long enough to prevent the revealing transaction itself from being frontrun, but short enough to maintain usability. Common implementations use a 1-5 block delay on Ethereum.

Architecting this requires careful smart contract design. The contract must maintain a mapping from user addresses to their commitments, enforce the reveal delay, and validate the hash. A basic structure includes functions for commit(bytes32 commitmentHash), reveal(TradeParams params, uint256 salt), and an internal _validateReveal check. The commit function often requires a small deposit to prevent spam. The EIP-5568 standard outlines a specification for stealth addresses and related commit-reveal patterns, providing a useful reference.

A major challenge is user experience. Managing two transactions and safeguarding the salt adds complexity. Solutions include using meta-transactions for the commit, or having a relayer network submit the reveal to ensure timely execution. Furthermore, the scheme does not protect against time-bandit attacks, where a miner reorgs the chain to capture a revealed profitable trade. For full protection, it is often combined with other techniques like threshold encryption sent to a private mempool.

In practice, protocols like CowSwap and Flashbots SUAVE employ variations of commit-reveal to mitigate frontrunning. When implementing, use a cryptographically secure random salt (at least 32 bytes) and a hash function with strong collision resistance. Always audit the time-lock logic and the final trade execution to ensure the revealed parameters cannot be manipulated between the two phases.

In decentralized exchanges (DEXs), transaction details on public blockchains are visible in the mempool before confirmation, creating a front-running vulnerability. A commit-reveal scheme mitigates this by splitting a trade into two phases. First, a user submits a cryptographic commitment—a hash of their secret trade parameters. Later, in a separate transaction, they reveal the original data. This architecture ensures the trade's intent is hidden during the vulnerable commitment phase, preventing malicious bots from exploiting price information.

The core contract architecture requires two primary functions: commit and reveal. The commit function accepts a bytes32 commitment hash, typically computed off-chain as keccak256(abi.encodePacked(secret, amountIn, amountOutMin, deadline, msg.sender)). It stores this hash mapped to the user's address with a timestamp. A crucial security element is enforcing a reveal deadline (e.g., 10 minutes) to prevent users from indefinitely locking in stale commitments and clogging state.

The reveal function is where the trade executes. It accepts the original preimage parameters (secret, amountIn, etc.). The contract first recalculates the hash from these inputs and verifies it matches the stored commitment for msg.sender. It then checks that the reveal transaction occurs before the deadline. Only after these checks pass does the contract interact with the DEX router (e.g., Uniswap V2's swapExactTokensForTokens) to perform the actual swap. This separation guarantees the trade parameters are only actionable when they are simultaneously revealed and executed.

Effective state management is key. The contract must track mapping(address => Commitment) public commitments. Each Commitment struct should store the bytes32 hash and a uint256 commitTime. All state related to a pending commitment must be cleared upon a successful reveal or after the deadline passes to save gas and prevent state bloat. Consider adding a slither modifier to allow users to reclaim gas by deleting expired commitments.

For production use, integrate with a specific DEX. For a Uniswap V2-style swap, the reveal function would call IUniswapV2Router02(routerAddress).swapExactTokensForTokens(amountIn, amountOutMin, path, msg.sender, deadline). Always use a user-supplied deadline parameter within the revealed data to protect against stale transactions. This pattern can be extended for complex trades, like multi-hop swaps or limit orders, by including the entire route path in the committed hash.

While effective against simple front-running, commit-reveal has limitations. It requires two transactions, doubling gas costs, and exposes users to reveal griefing, where an attacker sees the reveal and front-runs the final execution. For high-value trades, consider combining it with a submarine send via a private mempool service like Flashbots. Always audit the scheme for timing attacks and ensure the cryptographic hash function (Keccak256) is used correctly without collisions.

A commit-reveal scheme is a two-phase cryptographic protocol designed to prevent front-running and information leakage in decentralized finance. In the commit phase, a user submits a hashed commitment of their trade details (e.g., token, amount, price) to a smart contract. This hash, created using keccak256, conceals the actual data. In the subsequent reveal phase, the user submits the original plaintext data. The contract verifies it by re-hashing and comparing it to the stored commitment. This ensures trade intentions remain secret until execution, neutralizing the advantage of bots that monitor the public mempool.

To implement this, you must first define the core data structure. A typical struct Commitment includes fields for the user's address, the hashed commitment, a deposit amount (to penalize non-revelation), and a timestamp. The contract stores these commitments in a mapping, such as mapping(address => Commitment) public commitments. The commit function, commitTrade(bytes32 _hashedData), accepts the hash, requires a deposit (e.g., 0.1 ETH), and records the commitment with a block timestamp. It's crucial to use msg.sender to tie the commitment to the user's address for later verification.

The reveal function is where execution logic integrates with a DEX like Uniswap V3. revealTrade(address tokenIn, uint amountIn, uint minAmountOut, uint deadline, bytes32 salt) takes the original trade parameters and a random salt. It reconstructs the commitment hash using keccak256(abi.encodePacked(tokenIn, amountIn, minAmountOut, deadline, salt, msg.sender)). If this matches the stored hash, the contract proceeds. It then uses the IUniswapV3Router interface to execute the swap via exactInputSingle, transferring the output to the user. Finally, it returns the user's deposit and deletes the commitment from storage to prevent replay attacks.

Security considerations are paramount. Always use a sufficiently large, random salt to prevent brute-force reversal of the hash. Implement a reveal deadline (e.g., 10 blocks) after the commit to prevent users from indefinitely locking funds. The deposit should be slashed if the user fails to reveal in time, which can be done in a cleanup function. Furthermore, validate all DEX parameters during the reveal to ensure the submitted minAmountOut and deadline are still valid, protecting against stale trades. Avoid storing plaintext data in events during the commit phase.

Here is a condensed code example for the core functions:

solidityCopy
function commitTrade(bytes32 _hashedCommitment) external payable {
    require(msg.value == COMMIT_DEPOSIT, "Deposit required");
    commitments[msg.sender] = Commitment(_hashedCommitment, msg.value, block.timestamp);
}

function revealTrade(...) external {
    Commitment memory c = commitments[msg.sender];
    bytes32 reconstructedHash = keccak256(abi.encodePacked(...));
    require(reconstructedHash == c.hashedData, "Invalid reveal");
    require(block.timestamp <= c.timestamp + REVEAL_WINDOW, "Window expired");
    // Execute swap via IUniswapV3Router
    payable(msg.sender).transfer(c.deposit);
    delete commitments[msg.sender];
}

This pattern can be extended for batch reveals or integrated with a relayer network for gasless reveals using EIP-712 signatures.

Testing this system requires a comprehensive strategy. Use Foundry or Hardhat to simulate front-running attacks: deploy a malicious bot contract that tries to read and front-run the commitment from an event log (which should contain no data). Write tests for edge cases: revealing with wrong data, revealing after the deadline, and attempting to replay a revealed commitment. Measure gas costs for both phases, as the reveal transaction will be more expensive due to the DEX swap execution. For production, consider using a commit-reveal registry contract that multiple trading dApps can use, standardizing the security model across the ecosystem.

A commit-reveal scheme is a two-phase cryptographic protocol designed to prevent front-running and other forms of Maximal Extractable Value (MEV) in decentralized exchanges. In the first commit phase, a user submits a hash of their trade details (e.g., token, amount, secret salt) to a smart contract. In the subsequent reveal phase, the user submits the original data, allowing the contract to verify the hash and execute the trade. This delay between commitment and execution prevents bots from observing a profitable transaction in the mempool and front-running it.

The primary gas cost components are the two transactions: commit and reveal. The commit function typically costs 45,000-65,000 gas for storing a hash in a mapping and emitting an event. The reveal function is more expensive (100,000+ gas) as it performs verification, state updates, and the core swap logic via a DEX router like Uniswap V3's SwapRouter. A naive implementation can double the gas cost compared to a direct swap. Key optimizations include using cheaper storage patterns, minimizing event data, and batching reveals.

To optimize the commit phase, avoid storing unnecessary data. Instead of a full struct, store only the bytes32 commitment hash. Use a mapping indexed by user address to enable efficient lookups. Emit events with minimal indexed parameters; often, just the user address and commitment hash are sufficient for off-chain tracking. Consider setting a short, enforceable reveal deadline (e.g., 10 blocks) within the contract to prune stale commitments and prevent state bloat.

The reveal phase offers the most optimization potential. Use call or delegatecall to execute the swap against the canonical DEX router contract to avoid redundant liquidity checks. Aggregate multiple reveals in a single transaction using a helper contract to amortize the fixed 21,000 gas base cost. For the swap itself, use exact-input single-hop swaps where possible, as multi-hop routes through UniswapV3Router increase gas cost by ~40,000 gas per hop. Always verify the commitment with require(commitments[msg.sender] == keccak256(abi.encodePacked(params, salt)), "Invalid reveal"); before any external calls.

Advanced architectures can further reduce costs. Use a batch reveal contract where users sign off-chain messages (EIP-712) authorizing their reveals. A relayer then aggregates multiple signed reveals into one on-chain transaction, drastically reducing per-user gas costs. Alternatively, integrate with a shared sequencer or a private transaction service like Taiko's Based Booster to submit the commit transaction, avoiding the public mempool entirely and potentially removing the need for the scheme for some users.

When implementing, always conduct gas benchmarks using tools like hardhat-gas-reporter against a forked mainnet. Compare the cost of your commit-reveal flow against a direct swap on Uniswap V3 or PancakeSwap v3. The trade-off is clear: you pay extra gas for MEV protection. The scheme is most justified for large, predictable trades on highly competitive blockchains like Ethereum Mainnet. For smaller trades on L2s with native MEV mitigation, the added cost may not be warranted.

A well-architected commit-reveal scheme for DEX trades fundamentally shifts the security model from on-chain transparency to cryptographic commitment. The core security guarantee rests on the cryptographic binding between the commit and reveal phases. The commit hash must be a secure, pre-image resistant hash (like keccak256) of the trade parameters and a user-generated secret. If an attacker can feasibly reverse the hash or guess the secret, the entire scheme fails. Furthermore, the contract must enforce that the revealed parameters exactly match the initial commitment, preventing manipulation of slippage tolerance or token amounts between phases.

The scheme's resilience depends heavily on the commit phase duration and the revelation window. A short commit phase offers little protection, while an excessively long one degrades user experience. The revelation window must be long enough for users to submit their transaction under normal network conditions but short enough to prevent block space from being permanently locked. A common pattern is a 5-10 minute commit phase followed by a 1-2 block reveal window. Contracts should implement a sweep function allowing anyone to clear expired, unrevealed commitments to recover gas and state.

Key operational risks include secret management and transaction ordering. Users must store their secret securely between transactions; loss means the committed funds are permanently locked. The reveal transaction itself can be front-run if the secret is submitted in a predictable manner. Using a commit-reveal scheme in conjunction with a private mempool service like Flashbots Protect or a tx.origin check in the reveal function can mitigate this. Always assume the content of the reveal transaction will eventually be public.

From an integration perspective, your DEX's UI and indexers must handle the two-step workflow. The UI needs to store the user's secret locally (e.g., in browser storage) and automatically generate the reveal transaction after the commit is confirmed. Off-chain components, like a graph indexer, must track commitments and their states (pending, revealed, expired) to display accurate user balances and order books. Failing to synchronize these states correctly can lead to a broken user experience where funds appear stuck.

Finally, conduct thorough testing with tools like Foundry or Hardhat. Write tests that simulate adversarial conditions: front-running the reveal, attempting to reveal with incorrect parameters, letting commitments expire, and testing the gas costs of both happy and edge-case paths. A commit-reveal scheme increases gas overhead by 40-60k gas per trade; factor this into your fee structure and ensure it remains competitive with other privacy-preserving solutions like CowSwap's batch auctions.