Mempool Auction

Overview

A mempool auction emerges when more transactions seek inclusion than available block space can hold. Producers choose among visible candidates using fee rate, priority fee, explicit bundle payments, or other revenue signals.

Some auctions are implicit in public fee markets, while others use builders, relays, sequencers, or private bundle systems. Bids may compete for simple inclusion or for a specific ordering position that enables arbitrage and other MEV strategies. Wallets should estimate urgency and set bounded fees rather than blindly outbidding competitors. Protocol designers need transparent rules, censorship resistance, and protections against spam or collusion. A high bid cannot guarantee execution if the transaction becomes invalid, loses a dependency, violates builder policy, or reaches the producer too late.

These records allow a later rescan to reconstruct the result when an endpoint, webhook, or local index becomes unreliable. Operational records should retain the raw transaction, network identifier, sender and destination, asset and amount, block reference, execution status, and observed timestamps. Status labels should describe what is known without overstating settlement. Unknown, pending, included, failed, replaced, and finalized conditions need separate handling, together with a recovery procedure for transactions whose observed state conflicts across providers.

Submission, peer acceptance, block inclusion, execution, confirmation, and finality provide different evidence, and a transaction can advance, stall, be replaced, or disappear from the canonical chain between those stages. Mempool Auction should be represented as a sequence of observable states rather than one success flag. Practical implication: Mempool auctions allocate scarce ordering through bids, but fee caps, validity, delivery timing, and builder policy still determine execution.