# MEV on Igra
## About this document This FAQ addresses common questions from builders, integrators, auditors, and exchanges evaluating Igra's MEV properties. ## Summary Igra has structural properties that make the most common MEV attacks (sandwiching, front-running, oracle manipulation) significantly harder than on Ethereum or single-sequencer L2s: 1. Igra does not have a centralized sequencer or a persistent Ethereum-style public mempool 2. Igra fully relies on Kaspa L1's \~100ms observation window and parallel block production with partial miner visibility, which makes timing-based gaming extremely hard 3. Igra's ordering inherits from Kaspa L1 where deterministic MEV requires 50%+1 of hashrate *** ## Fundamentals **What is Igra Network?** Igra is an EVM-compatible blockchain that uses Kaspa L1 for transaction sequencing and data availability. No centralized sequencer, no validator set, no Igra-controlled ordering. Transactions are wrapped into Kaspa transactions, included in Kaspa blocks by Kaspa miners, and ordered by Kaspa's [GHOSTDAG consensus](https://eprint.iacr.org/2018/104.pdf). See the [Igra litepaper](https://github.com/IgraLabs/research/blob/main/igra-litepaper-v1.0.pdf) for full architectural details. **How is transaction order determined on Igra?** By Kaspa's Selected Parent Chain (SPC), decided post-hoc by GHOSTDAG consensus across parallel-mined blocks. Kaspa runs at 10 BPS with multiple miners building blocks simultaneously and no cross-miner visibility. After blocks are produced, GHOSTDAG computes the canonical SPC deterministically from the DAG. No actor controls SPC selection in advance. As Kaspa lead developer Michael Sutton noted on Crescendo activation: *"the mere intra-round chaos of the parallel DAG at 10 bps will already make economic manipulation much harder than in other, leader-based systems."* (Michael Sutton, ["Kaspa Updates to Crescendo and 10BPS"](https://kaspa.org/kaspa-updates-to-crescendo-and-10bps/)) **MEV-wise, what is the difference between Igra and other EVM blockchains?** On Ethereum, MEV is a mature extraction market. On Arbitrum, Optimism, and Base, one company orders every transaction and is trusted not to extract MEV. On Igra, ordering is decided by Kaspa's mining network with its hundreds of parallel miners. No actor can deterministically control end-to-end ordering of Igra transactions without 50%+1 of Kaspa hashrate. **Who can extract MEV on Igra?** Below 50 percent of Kaspa hashrate: no one can extract MEV deterministically. Sophisticated searchers paying large fee premiums on [Kaspa wrapper transactions](https://igra-labs.gitbook.io/igralabs-docs/for-developers/architecture/specifications/igra-transaction-protocol) can extract probabilistic MEV at single-digit per-attempt success rates. For comparison, the same attacks succeed at near-100 percent rates on operator-controlled L2s and on Ethereum via MEV-Boost and private order flow. Above 50% hashrate extraction becomes deterministic, but an attacker at that threshold has access to larger attacks (double-spends, deep reorgs) that earn more per unit of hashrate. This is the standard 50%+1 security boundary for PoW blockchains, comparable to other major PoW chains and stricter than PoS chains where 33% suffices to stall finality. **Is there a public mempool?** No persistent Igra public mempool of the kind searchers watch on Ethereum. Transactions go from the user's RPC provider through a Kaspa wrapper transaction directly into Kaspa's L1 mempool. A sophisticated attacker running a Kaspa full node can observe Igra transactions via the payload prefix, but the observation window is approximately 100 milliseconds (Kaspa's block time at 10 BPS), one to two orders of magnitude shorter than Ethereum's 12-second window, and the attacker has no deterministic way to act on what they observe. *** ## Sandwich attacks **Can my DEX users be sandwiched?** At single-digit percentage success rates per attempt, versus near-deterministic success on Ethereum and operator-controlled L2s. A successful sandwich requires the attacker's frontrun and the victim's swap to land in the same Kaspa block (same miner, same template), that block to be selected by GHOSTDAG consensus as the primary block for its window, and the attacker's backrun to land in a subsequent block before competing arbitrageurs close the price gap. No single party controls any of these events. **What if the attacker pays a large gas fee?** Gas price does not affect ordering on Igra. The relevant economic lever is the KAS fee rate on the Kaspa wrapper transaction. This lever operates probabilistically via [Kaspa's mempool sampler](https://medium.com/kaspa-currency/a-kaspa-performance-update-860f2e8d1e3d), which has built-in randomness. Paying more fee increases the attacker's probability of preferred ordering; it does not guarantee it. As a rough sense of magnitude: a 10x fee premium lifts inclusion probability into the 60 to 80 percent range per individual miner, but compound success probability for a sandwich (same-block co-inclusion with the victim, SPC selection, backrun ordering) remains in the single-digit percent range. *** ## Other MEV classes **What about frontrunning (not sandwiches)?** Same structural analysis as sandwiching. The attacker needs their transaction in the same Kaspa block as the victim with earlier ordering. Probabilistic, not deterministic. The single-operator and PBS mechanisms that make Ethereum frontrunning efficient do not exist on Igra. **What about liquidation frontrunning?** Deploying a lending protocol on Igra does not eliminate liquidation competition but raises the cost floor and changes the competition structure compared to Ethereum and operator-controlled L2s, where liquidators win by paying the highest priority fee (deterministic ordering) or by direct backchannel access to the sequencer. On Igra, neither lever exists. A liquidator pays a KAS fee premium, which buys probabilistic priority, but does not guarantee inclusion ahead of competing liquidators. Liquidation outcomes are decided by which liquidator's tx lands in the SPC block of the window, with intra-block order set by KAS fee rate when multiple are co-included. The race is bounded by Kaspa's approximately 100ms block time, not Igra sequencer latency. For borrowers, this means extraction is more competitive among liquidators and less value captured by privileged actors. Net effect is neutral to positive for borrower outcomes. **What about oracle manipulation?** The ordering properties that bound sandwich MEV also bound oracle-manipulation MEV: an attacker cannot reliably position a price update before or after a target transaction. *** ## Comparisons **How does Igra compare to other chains?** **Arbitrum (**[**Timeboost**](https://docs.arbitrum.io/how-arbitrum-works/timeboost/gentle-introduction)**):** centralized sequencer auctions 60-second express-lane access; winner gets deterministic priority, proceeds go to treasury. Igra has no auction or sequencer; structural resistance instead of monetized MEV. **Optimism, Base:** centralized sequencer, no technical MEV protection beyond public commitments. Coinbase runs Base while operating a major exchange. Igra has no equivalent operator or conflict of interest. **Taiko:** based rollup like Igra but settles on Ethereum. Preconfers read Taiko's public mempool and give priority-fee-weighted preconfirmations. Igra has no public mempool and no preconfer role. **Ethereum L1:** [MEV-Boost](https://boost.flashbots.net/) runs a public builder auction extracting hundreds of millions annually. Kaspa does not currently have an Ethereum-style PBS or builder market. *** ## For DEX and protocol builders **Do I need to implement commit-reveal or other MEV-protection schemes?** For most use cases, likely not. The ordering properties of Kaspa provide structural protection that is absent on Ethereum. DEX designs that require explicit MEV protection on Ethereum (FairSwap, batch auctions, commit-reveal) may operate adequately with standard AMM or orderbook mechanics on Igra. Applications handling very high value or requiring formal ordering guarantees should still perform their own threat analysis. **Does priority fee do anything?** Igra priority fee does not affect transaction ordering. If a frontend wants to offer priority to users, the lever is the KAS fee rate on the Kaspa wrapper transaction, set at the RPC provider level or by the user on the L1 side. *** ## For exchanges and infrastructure **Is there a public Igra mempool I can subscribe to?** Not in the Ethereum sense. Relevant pending-transaction visibility is at Kaspa L1, not Igra. Integrations that want pending-transaction feeds should query Kaspa's mempool (via kaspad), filtered on the Igra payload prefix. **Can I run my own RPC endpoint?** Yes. An Igra node runs kaspad, viaduct, reth, and an rpc-provider. Running your own endpoint eliminates dependency on third-party RPC providers and reduces pre-L1 visibility of your users' transactions. See [Igra documentation](https://igra-labs.gitbook.io/igralabs-docs/quickstart/how-to-setup-a-node) for node setup. *** ## References 1. Sompolinsky, Y., Wyborski, S., Zohar, A. ["PHANTOM GHOSTDAG: A Scalable Generalization of Nakamoto Consensus."](https://eprint.iacr.org/2018/104.pdf) AFT 2021. 2. Michael Sutton. ["Kaspa Updates to Crescendo and 10BPS."](https://kaspa.org/kaspa-updates-to-crescendo-and-10bps/) Kaspa.org, May 2025. 3. Igra Network. [Igra Litepaper v1.0.](https://github.com/IgraLabs/research/blob/main/igra-litepaper-v1.0.pdf) 4. Igra Network. [Documentation.](https://igra-labs.gitbook.io/igralabs-docs/) 5. Daian, P. et al. ["Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges."](https://arxiv.org/abs/1904.05234) 2019. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://igra-labs.gitbook.io/igralabs-docs/for-developers/mev-on-igra.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.