## Concept explanation **MEV** stands for **maximal extractable value**: extra value that appears because someone choosing the block contents can also choose the **order** of transactions. The transactions themselves may stay exactly the same, but changing who goes first, who lands in the middle, and who goes last can shift prices, penalties, or rewards. That means a block builder can sometimes create profit for themselves just by rearranging the queue, while changing the outcome for ordinary users. ## What you see You see a short waiting queue on the left and the actual **block order** in the middle. Each colored card is a transaction. You can drag cards inside the block to change their order, and the **builder profit** meter plus the **user outcome** labels update immediately. The small reference panels show two example orderings: one that is more user-friendly and one that extracts more value, so you can compare the same transactions under different sequencing. ## Try it yourself - **Drag the `User swap` or `User repay` card upward** and watch how the user outcome improves when the user lands earlier. - **Move the builder cards around the user card** to see how sandwiching or front-running can create builder profit. - **Click `Apply MEV order`** to snap to a more extractive ordering, then compare its profit and user impact with the starting queue. - **Click `Reset queue`** to return to the original waiting order and test your own arrangement again. - **Toggle `Show reference orders`** to compare your custom block against the two example block sequences. - **Adjust the `Profit meter scale` slider** to rescale the visible meter and make small or large changes easier to notice. ## Concept explanation A **mempool** is the public waiting area where pending transactions sit before a miner or validator includes them in a block. Because block space is limited, transactions with a higher **offered fee** often get picked sooner, since they are more attractive to include. That does not guarantee instant confirmation, but it usually improves a transaction’s position in the queue and can reduce expected waiting time when many users are competing for space. ## What you see You are looking at a pool of pending transaction bubbles on the left and the next block on the right. The highlighted bubble represents your transaction, and its vertical position shows its current priority relative to the rest of the mempool. The block preview fills from the highest-fee transactions at the top toward lower-priority ones below, while the panel tracks your transaction’s inclusion order, whether it is likely to fit in the next block, and an estimated wait time. ## Try it yourself - **Drag the fee slider** upward and watch your highlighted transaction move toward a better rank in the mempool. - **Lower the fee slider** and notice how your transaction drops behind more competitive bids. - **Check the inclusion order readout** after each fee change to see how bidding changes your place in line. - **Watch the estimated wait time** and compare how a higher fee can improve your chances of getting into the next block. - **Toggle Auto-fill block** to let the next block fill automatically from highest priority to lowest. - **Click Mine next slot** step by step to see exactly which pending transaction gets included next. - **Press Reset mempool** and try different fee values again to explore how fee competition affects ordering opportunities. ## Concept explanation **Front-running** happens when someone can see a **pending transaction** before it is confirmed and uses that information to place their own trade first. In this swap example, the user plans to buy tokens, which would push the pool price upward. A front-runner notices that pending buy, inserts their own buy just before it, then sells after the user’s trade has raised the price. The result is that the front-runner captures value, while the user gets a worse execution than the price they originally saw. ## What you see You’re looking at one block as a sequence of trades. The price chart shows how the pool’s token price changes after each transaction in execution order. The block-order panel shows whether the user’s swap is alone or whether a front-runner has inserted trades around it. The outcome cards summarize how many tokens the user receives, how much the front-runner makes or loses, and how much the user’s execution price changed compared with the original quote. ## Try it yourself - **Click `Remove front-runner`** to compare the same user swap with and without exploitation. - **Click `Insert front-runner`** again and watch how the execution order changes inside the block. - **Drag the `User buy size` slider** to make the pending swap larger and see why a bigger visible order can attract more front-running. - **Watch the price path** and notice how the front-runner’s earlier buy pushes the user onto a higher point on the curve. - **Compare the user outcome card** before and after inserting the front-runner to see the lost tokens relative to the original quote. - **Check the front-runner outcome card** to see how seeing the pending swap can be turned into profit. - **Toggle `Price markers`** if you want to simplify the chart and focus on the line shape instead of each step. ## Concept explanation A **sandwich attack** happens when an attacker places one trade **before** a victim’s swap and another trade **after** it in the same block. The first trade moves the pool price against the victim, so the victim gets a worse execution. Then the attacker closes the position after the victim’s trade has pushed the price even further, capturing profit from the victim’s **price impact**. In a constant-product AMM, bigger swaps usually move price more, which is why larger victim trades can create a larger opening for this strategy. ## What you see You can follow the block from left to right: the attacker buy, the victim swap, and the attacker sell. The price chart above shows how the pool price changes after each step. Each transaction card shows the pool balances before and after that trade, plus the trading account’s token balances so you can see what the attacker or victim holds at each moment. The panel on the right compares the victim’s output with and without the attack and shows the attacker’s round-trip profit. ## Try it yourself - **Drag the victim trade size slider** and watch how the middle step pushes the price further as the victim swap gets larger. - **Compare the victim output box** with the “without attack” reference to see how much value the victim loses when the attacker goes first. - **Look at the attacker profit readout** at the top and notice how it changes as the victim’s price impact changes. - **Read the three cards in order** to see the sandwich structure: attacker trade first, victim trade in the middle, attacker trade last. - **Press `Reset example`** to return to the starting trade size and replay the sequence from the default setup. ## Concept explanation Some **MEV** comes from **arbitrage**, where a trader notices that the same token pair has different prices on different markets and trades to capture that gap. In this example, the trader buys **TOKEN A** on the cheaper decentralized exchange and sells it on the more expensive one. That earns a profit for the trader, but it also pushes the two prices closer together, which can improve **market efficiency** by correcting temporary mispricing. ## What you see You’re looking at two decentralized exchanges side by side, each showing a price for the same `TOKEN A / TOKEN B` pair. The teal flow between them represents the arbitrage route from the cheaper market to the richer one. As prices diverge, the price gap and arbitrage profit increase; when arbitrage runs, both displayed prices move toward each other and the gap shrinks. ## Try it yourself - **Drag one DEX price line** up or down to create a bigger mismatch between the two markets. - **Press `Run arbitrage`** and watch the trade flow move from the cheaper exchange to the more expensive one. - **Increase the `Trade size` slider** to make each arbitrage step capture more profit. - **Adjust `Price impact strength`** to see how strongly each trade pulls the two prices back together. - **Turn on `Auto arbitrage`** and notice how repeated trades gradually reduce the price gap. - **Use `Reset`** to return to the starting prices and test another scenario. ## Concept explanation **MEV** stands for **maximal extractable value**: extra value a block builder, validator, or searcher can capture by choosing how transactions are ordered or bundled. That value is not always the same kind of thing. Some strategies, like a **sandwich attack**, mainly shift value away from a user by making their trade execute at a worse price. Others, like **arbitrage**, can reward the extractor while also improving **market efficiency** by pushing prices on different venues back toward each other. The key idea is that MEV is a family of strategies with different trade-offs, not a single uniformly good or bad behavior. ## What you see You are looking at a side-by-side comparison board. The left panel shows a harmful MEV pattern where a trader is surrounded by front-run and back-run trades, while the right panel shows a beneficial pattern where an arbitrageur closes a price gap between venues. The bars under each scene track three outcomes at once: trader harm, market efficiency, and extractor profit. The selected strategy is highlighted, and the control panel summarizes the live trade-off so you can compare how the same slider setting affects both panels. ## Try it yourself - **Switch the strategy dropdown** between `Sandwich attack`, `Arbitrage`, and `Liquidation` to see how the highlighted case changes while the other panel stays visible for comparison. - **Move the user impact slider** upward and watch how **trader harm**, **market efficiency**, and **extractor profit** shift together. - **Compare Sandwich attack vs Arbitrage** and notice that both can create extractor profit, but only one strongly improves price alignment. - **Select Arbitrage** and **raise the slider** to see a case where extractor profit can coexist with better market prices and relatively low user harm. - **Select Sandwich attack** and **raise the slider** to see how value extraction can come mostly from worsening a trader’s execution. - **Toggle Auto pulse** to let the board animate through changing conditions, then **turn it off** to inspect one fixed state more carefully. - **Choose Liquidation** to explore a mixed case where MEV can hurt a particular user but also help keep a protocol solvent or remove risky positions. ## Concept explanation When you swap on a blockchain, your order can create **MEV** opportunities for bots that try to profit from seeing your trade before it settles. A **public mempool** exposes your transaction to searchers, which can increase the chance of **front-running** or **sandwiching**, especially when your trade is large or your **slippage tolerance** is loose. Using **private transaction submission**, tighter slippage settings, and better routing can reduce how visible and exploitable your order is, which often improves the amount you finally receive. ## What you see You are looking at a swap card feeding into two possible execution paths: one public and one private. The selected route lights up so you can compare how the path changes the estimated attack risk. The result panel summarizes the trade with an attack-risk score, execution-quality score, and final received amount, so you can see how routing choice, slippage, and size work together in practice. ## Try it yourself - **Switch from `Public mempool` to `Private routing`** and notice how the attack-risk bar drops while execution quality improves. - **Increase the trade size slider** and watch how larger orders raise estimated front-run and sandwich risk. - **Raise slippage tolerance** to see how giving the trade more room to move can make it easier for bots to extract value. - **Lower slippage after increasing trade size** and compare whether tighter settings recover some execution quality. - **Use the Reset button** to return to a baseline trade, then test one variable at a time. - **Try to find the safest combination** by pairing private routing with smaller size or tighter slippage, and compare the final received amount.