Blockchain Transaction Lifecycle
Why this note exists
The MEV and sandwich attack notes assume you understand how transactions travel from your wallet to the blockchain. If you know proof-of-work and proof-of-stake at a high level but have never thought about what happens between submitting a transaction and seeing it confirmed, this note fills that gap.
The Problem: Ordering Matters
On a traditional stock exchange, the exchange itself controls the matching engine: orders arrive, the exchange timestamps them, and they execute in price-time priority. Nobody outside the exchange can reorder the queue.
On a blockchain, there is no central matching engine. Instead, transactions go through a public waiting room before a single actor (the block producer) assembles them into a block. That block producer gets to choose which transactions to include and in what order. This ordering power is the root of everything in MEV.
A transaction’s journey: wallet → mempool → block builder → block producer → confirmed block.
Step by Step: From Wallet to Blockchain
Step 1 — You Sign and Broadcast
When you submit a transaction (say, a swap on Uniswap or PumpSwap), your wallet:
- Constructs the transaction (which contract to call, with what parameters).
- Signs it with your private key (proving you authorized it).
- Broadcasts it to the peer-to-peer network — the mesh of nodes that make up the blockchain.
At this point, your transaction is not yet confirmed. It’s just a signed message floating through the network.
Step 2 — The Mempool (the Waiting Room)
Your transaction lands in the mempool (short for “memory pool”) — a holding area where each node stores unconfirmed transactions it has heard about. Think of it as a public bulletin board:
- Anyone can read it. Every node on the network can see every pending transaction, including its full details: what you’re buying, how much, which contract, your slippage tolerance — everything.
- Nothing is guaranteed yet. Being in the mempool doesn’t mean your transaction will be included in the next block, or in any block at all.
- It’s not ordered. Transactions in the mempool have no official sequence. They are just a pool of candidates waiting to be picked up.
Public visibility is the key insight
In traditional finance, your order is private until it hits the exchange. On a blockchain, your pending transaction is visible to everyone before it executes. This is why MEV exists: bots can see what you’re about to do and act on it.
Solana’s twist: Solana doesn’t have a traditional public mempool. Transactions are forwarded directly to the current leader (the validator responsible for producing the next block). However, transactions are still visible to anyone who runs infrastructure close to the leader or uses specialized services like Jito. The mempool is less public but not private.
Step 3 — Block Production (the Ordering Decision)
Every few seconds (12 seconds on Ethereum, ~400 milliseconds on Solana), one node is selected to produce the next block. This node is called the block producer (called a “miner” in proof-of-work, a “validator” or “proposer” in proof-of-stake — same role, different selection mechanism).
The block producer’s job: take some transactions from the mempool and arrange them into a block. Here is where the power lies:
- Inclusion: The block producer chooses which transactions go into the block. It can include yours, skip it, or delay it to a future block.
- Ordering: The block producer chooses the sequence. Transaction A can go before B, or B before A — the block producer decides.
- Injection: The block producer can insert its own transactions anywhere in the sequence. It can place its own buy before your buy, and its own sell after your buy.
In traditional finance, a broker who trades ahead of client orders commits front-running — a crime. On a blockchain, there is no such legal prohibition. The mempool is public, the block producer’s ordering discretion is a protocol feature, and anyone can submit transactions.
Why would a block producer care about ordering?
Because ordering determines who gets which price. If your swap will push a token’s price up, someone who buys before you gets a better price and can sell after you at the higher price. The profit from choosing the right order is MEV — Maximal Extractable Value.
But the Bots Are Not the Block Producer
This is a crucial point. The bots that watch the mempool — called searchers — are not the block producer. They are just regular participants who can see pending transactions and submit their own. So how does a searcher get its transaction ordered before yours if it doesn’t control the block?
The answer: searchers pay the block producer to order things their way. The mechanism depends on the chain:
Ethereum (legacy, pre-2020). Block producers ordered transactions by gas price — whoever bid the highest fee went first. Searchers exploited this: if they saw your swap in the mempool, they submitted their front-run with a higher gas price than yours, so the block producer would naturally place it earlier. This led to priority gas auctions (PGAs) — bots furiously outbidding each other for ordering priority, wasting gas and congesting the network.
Ethereum (modern, with Flashbots). The ecosystem developed a more structured system. Searchers now submit bundles to specialised actors called builders: “here are 3 transactions — my front-run, then the victim’s trade, then my back-run — execute them in this exact order, and I’ll pay you a tip.” The builder assembles bundles from many searchers into a complete block and offers it to the block producer (validator), who selects the most profitable block. Everyone gets paid: the searcher earns MEV minus the tip, the builder earns tips minus the validator payment, and the validator earns the best bid.
Solana (with Jito). Solana has no public mempool — transactions go directly to the current leader (block producer). But Jito Labs built an analogous system: searchers submit bundles to Jito’s block engine. The current leader, if running Jito’s modified validator client, includes these bundles atomically. The searcher pays a tip to the validator for inclusion. The effect is the same: searchers pay for ordering control.
This is not a hack — it is the protocol working as designed. The block producer is economically rational: it includes the transactions that pay the most. A searcher who bids a higher fee gets priority the same way a bidder at an auction wins by bidding more. The protocol does not distinguish between “legitimate user paying a normal fee” and “bot paying a premium to front-run someone.” There is no rule against it, no terms of service, no regulator to complain to. MEV is not an exploit of a vulnerability — it emerges from two design choices that are each individually reasonable:
- Pending transactions are public — necessary for a decentralized network where any node must be able to validate the chain.
- Block producers order by economic incentive — necessary to prevent spam and compensate validators for their work.
The combination means: anyone who pays more gets priority, and everyone can see what you’re about to do. That’s the structural root of MEV.
How much time do bots have? The mempool typically holds more transactions than fit in a single block. On Ethereum, a block is produced every ~12 seconds and can hold a few hundred transactions, but thousands may be waiting. Your transaction might sit in the mempool for one block, several blocks, or longer during congestion. This gives bots plenty of time to spot your transaction, compute the optimal front-run, and submit their bundle — all before the next block is produced.
On Solana, blocks are produced every ~400 milliseconds — far less time. This is why Solana MEV bots are latency-optimised: they co-locate servers near validators and use the fastest possible network paths. The race is measured in milliseconds, not seconds.
MEV bot mechanics
For the full pseudocode of a sandwich bot’s core loop — mempool scanning, profit simulation, bundle submission — see What a MEV Bot Actually Does.
Step 4 — Execution
Once the block producer assembles the block, the transactions execute in the chosen order. Each transaction runs the smart contract code, updates the blockchain state (token balances, pool reserves, etc.), and the results are final. On most chains, once a block is confirmed, the ordering is permanent — there is no appeal.
Step 5 — Confirmation and Finality
The block is broadcast to the network. Other validators verify it and add it to their copy of the chain. After enough confirmations (1 block on Solana for practical finality, 12-15 minutes on Ethereum for strong finality), the transaction is considered irreversible.
The Lifecycle, Visually
You (wallet)
│
▼ sign + broadcast
Peer-to-peer network
│
▼ gossip to all nodes
Mempool (public waiting room)
│ │
│ ▼ bots scan for opportunities
│ Searchers (MEV bots)
│ │
│ ▼ submit bundles + tips
│ Builder (assembles optimal block)
│ │
▼ ▼
Block producer (validator) picks the best block
│
▼ execute in order
State changes (balances, reserves)
│
▼ propagate to network
Confirmed on-chain (irreversible)
Why This Creates MEV
The combination of three properties:
- Visibility — pending transactions are public before execution.
- Ordering discretion — the block producer controls the sequence.
- Deterministic pricing — AMM prices are a known function of reserves, so the effect of any transaction can be computed in advance.
This means a bot can: see your pending swap → calculate what it will do to the price → insert its own transactions before and after yours → profit from the price movement your trade causes. This is a sandwich attack, and it’s possible only because of the lifecycle described above.
Ethereum vs Solana: Two Models
| Property | Ethereum | Solana |
|---|---|---|
| Block time | ~12 seconds | ~400 ms |
| Mempool | Public, persistent | No traditional mempool; txns forwarded to leader |
| Block producer | Selected per-slot by PoS | Rotating leader schedule |
| MEV infrastructure | Flashbots (builder/proposer separation) | Jito Labs (bundle engine) |
| Transaction visibility | Full mempool gossip | Visible via leader proximity / Jito |
| Atomic bundles | Via Flashbots/builders | Via Jito bundles |
On Ethereum, the MEV supply chain is formalized: searchers find opportunities, builders construct optimal blocks, and proposers (validators) select the best block. On Solana, the separation is less formal but Jito’s block engine plays an analogous role.
Both models preserve the core dynamic: someone can see your transaction before it executes and profit from ordering.
Connection to Traditional Finance
In traditional markets, the equivalent of mempool visibility would be if every limit order were broadcast publicly before reaching the exchange. This is roughly what happens with indications of interest (IOIs) in dark pools or the consolidated tape for quotes — but with a critical difference: on a blockchain, the viewer can also act on what they see within the same block, with no regulatory prohibition.
The closest TradFi analogy is the scandal around brokers front-running client orders — exactly what regulations like MiFID II and SEC Rule 15c3-5 were designed to prevent. On a blockchain, this is not a scandal; it is the default behavior of the protocol.
Questions to sit with:
- The note explains that mempool visibility plus block producer ordering discretion creates MEV. Solana removed the public mempool, yet MEV persists. If you were designing a new L1 chain from scratch, could you eliminate MEV structurally — or is it an inevitable consequence of any system where someone must choose transaction ordering? What would a “zero-MEV” chain have to give up?
- Ethereum’s MEV supply chain (searcher → builder → proposer) was designed to reduce the negative externalities of priority gas auctions. But it also professionalized and scaled MEV extraction. Did Flashbots reduce MEV harm to users, or did it just make the extraction more efficient? How would you measure the difference?
- The note draws a parallel between blockchain front-running and TradFi broker front-running (which is illegal). If the mechanism is identical — an intermediary sees your order and trades ahead of it — what is the principled argument for why one is a crime and the other is a protocol feature? Is it purely jurisdictional, or is there a structural difference?
See also
- mev-fundamentals — what actors do with this ordering power
- Sandwich Attacks — the most common predatory use
- constant-product-amm — the deterministic pricing that makes MEV calculable
- bonding-curves — primary market context for Pump.fun MEV