# CommitRevealDark

> Every swap must have been committed to in an earlier block, so nobody can react to an order they can see.

A production Uniswap v4 hook. Source: https://github.com/nirholas/commit-reveal-dark. Part of the HookForge catalogue: https://hookforge.pages.dev

## How it works
Sandwiching works because of a timing asymmetry, not because of secrecy. Your order is visible before it executes, and an attacker can construct and place their own transactions after seeing it. Every defence that hides the order attacks the wrong half of that: encrypted mempools, private relays and threshold schemes all try to stop the attacker seeing, which is hard, needs new infrastructure, and fails the moment one relay defects. This attacks the other half. If the pool accepts only swaps that were committed to at least one block earlier, then an attacker who sees your order cannot act on it in the pool, because their own reaction would need a commitment made before they knew there was anything to react to. Seeing the order stops being useful. Nothing has to be hidden, and nothing has to be trusted. A commitment is a hash of the swap's parameters and a salt, so it reveals nothing until it is used. Revealing means simply making the swap: the hook recomputes the hash from what actually arrived and requires it to match a commitment that is old enough, unused and unexpired. A commitment that does not match is not a swap this pool will accept. Commitments carry a bond, and this is the part that makes the scheme cost something to abuse. Without it, a trader would commit to every order they might want at every size, then reveal the one they liked, which is a free option on the pool paid for by nobody. The bond is returned in full when the commitment is used and forfeited to the pool when it expires unused, so keeping options open is exactly as expensive as the options are worth to you. The cost of all this is two transactions and a delay of at least one block, and that is the honest trade. A pool wearing this hook is not for the impatient; it is for flow large enough that being sandwiched costs more than waiting a block.

## Prior art
Commit-reveal is old, and appears on-chain in ENS registration, in sealed-bid auctions and in the sandwich-resistant AMM designs that reorder within a block. Encrypted mempools (Shutter, SUAVE, threshold schemes) attack the same problem by hiding the order. Requiring every swap in a pool to have been committed in an earlier block, so that seeing an order is useless rather than impossible, is the contribution here.

## Where it does not help
Two transactions and a block of delay on every trade, which rules the pool out for anything latency-sensitive and makes it unusable through routers that will not forward the salt. It does not stop an attacker who commits speculatively every block and reveals when they see something worth reacting to: the bond makes that expensive rather than impossible, and a pool that sets the bond too low is not protected, it is inconvenient. Finally, a reveal carries its salt in the clear, so an observer can copy it and execute your trade ahead of you. That is a denial rather than a theft, since the copier pays for the swap and the bond still returns to whoever committed, but a trader who is being griefed this way has no recourse beyond committing again.

## Facts
Slug: commit-reveal-dark
Contract: CommitRevealDarkHook
Callbacks: beforeSwap, afterInitialize
Parameters: delayBlocks (uint32), ttlBlocks (uint32), bond (uint128)
Dynamic fee required: no

## Caveats
- Unaudited.
- A deployment with status "deterministic" is a mined CREATE2 address with no code at it yet. Never present one as live.