Skip to main content
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: 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.