Front-running

Prevent transaction observers from profiting by copying or reordering pending actions.

A transaction can reveal information before it executes. Validators can inspect transactions available for inclusion and control their ordering within the blocks they produce. A validator—or another observer able to submit a competing transaction—may use that information for profit.

Example: a public puzzle answer

A contract pays the first account to submit the correct answer:

1. A user broadcasts a transaction containing the answer.
2. The block producer sees the answer before executing the transaction.
3. The block producer creates a transaction with the same answer and orders it first.
4. The copied transaction claims the reward; the original solver receives nothing.

The contract cannot distinguish the solver from the copier because it only sees which valid transaction executed first.

This pattern also appears in auctions, first-come mints, trades with predictable price impact, and claims based on public secrets.

Use commit-reveal

Commit-reveal hides the answer until every participant has committed:

sequenceDiagram
    participant U as User
    participant C as Contract

    U->>C: Commit hash(answer, secret, round)
    Note over C: Commit period closes; answer remains hidden
    U->>C: Reveal answer and secret
    C->>C: Recompute hash and verify commitment
    C->>C: Apply the rules fixed for this round

The commitment binds the answer to a secret value that only the user knows. A copied commitment is useless because the observer cannot reveal the secret. Bind the commitment to the account and round, set deadlines for both phases, and define what happens when a user does not reveal.

Other mitigations

• Use batch auctions or fixed clearing rules instead of ordering by arrival.
• Set slippage limits and deadlines for price-sensitive operations.
• Randomize allocation only with an appropriate randomness design.
• Add deposits when failing to reveal creates costs for other participants.
• Use private submission infrastructure only if its trust assumptions fit your application.

Delays alone do not hide transaction contents, and higher gas bids are not a protocol-level defense against a block producer that controls ordering.

Review before deployment

• Search for rewards based on being first.
• Assume pending arguments and expected state changes may be observed.
• Test copied, reordered, delayed, and replayed transactions.
• Make ordering, tie-breaking, deadlines, and cancellation behavior explicit.

For a broader description of transactions as publicly visible opportunities, read Ethereum is a Dark Forest. The examples use Ethereum, but the information-leak problem applies to any design that exposes a profitable secret before execution.