@KaspaKaha "We’ve shown the work" please share the dataset + code, we'll compare directly and publicly. The rest I've addressed above and won't rehash.
English
Pavel Emdin
3.4K posts
Pavel Emdin
@emdin
Co-founder and busy bee @ Igra Labs | emdin.eth | Assorted cartoon character
Berlin, Germany Katılım Nisan 2007
635 Takip Edilen2.1K Takipçiler
The limiting principle is the one you already granted: Igra isn’t FIFO. Same-block position is set by carrier feerate, not arrival - your words. So position IS purchasable: bid a higher feerate, land ahead. That’s the ordering action a loser couldn’t match, and a controllable advantage an ordinary FIFO/CEX participant never has. That’s the exact line between MEV and “just trading” - and it doesn’t over-include, because FIFO trading has no such lever.
Your 5% is the inclusion axis - landing in a specific victim’s block. That’s the probabilistic half we agreed on at the start; you separated it yourself: inclusion probabilistic, ordering deterministic. The purchasable advantage lives on the ordering axis.
So, from the data: Igra isn’t FIFO, ordering position is fee-purchasable, front-running and sandwiching are both possible (capital/latency-bounded today, not impossible), and “MEV-resistant by design” isn’t accurate - resistance takes L1 consensus mechanisms that aren’t live yet.
We’ve shown the work; readers can weigh it.
English
1/ Appreciate the public follow-up @emdin - and real credit for correcting the ordering point. That was the substance, glad it’s settled.
We’re a team of MEV researchers; transparency is the job. So here’s everything, on the table 👇
2/ Where we agree - which is most of it: sandwiching on Igra is real, persistently attempted, and as attempted it’s been unprofitable. Higher carrier feerate wins the same-block slot. Your findings and ours line up. No fight there.
3/ But “0/12 net-negative → not profitable” has a gap, and it’s the crux. That measures the sandwiches that were attempted, at the sizes those attackers happened to pick. Sandwich P&L is convex in front-run size - one optimum; too small or too large both lose.
4/ So the same victim swap flips negative→positive at the right size. The result shows those attackers sized wrong and left EV on the table - not that an optimally-sized sandwich on those victims is unprofitable. “Not profitably attempted yet” ≠ “not profitable.” The claim needs the per-victim optimum, not the observed sample.
5/ Our number, since you asked - no deflection. 446K KAS total, never a sandwich figure:
• Arbitrage ~99% · Liquidations ~1% · Sandwiches ~0 (we agree with you)
By chain: Igra 365,149 KAS (78%), Kasplex 22%.
6/ Definitions, so it’s checkable:
• Completed sandwich = same-Kaspa-block front+back-run, both land, value = backrun − frontrun − fees → ~0 net-positive (matches your 12).
• Arb extracted value = realized WKAS on a completed cycle, net of carrier fee + gas.
• Venues: Igra L2 + Kasplex L2.
7/ So both hold: front-running resisted-as-executed (agreed); arbitrage MEV live and ~99% of realized extraction (the data). On sandwich profitability, we read it as a sizing result, not a mechanism result - and we’ll show the optimization against your ZS dataset. That’s the engagement worth having.
- a team of MEV experts. Data’s on the table.
Pavel Emdin@emdin
Hey @KaspaKaha, TL;DR this is wrong info, as I already mentioned in my DM to you several days ago. Results of our research which we'll publish soon: ~6% of frontrunning attempts win the carrier race and land (11 confirmed sandwiches over ~25 days), and 0% of those extract anything from victims. Which is... quite good. For the public, this is my DM message, I copy it here since it contains no private data and important for the context: "We independently confirmed your narrow technical point: our doc conflates probabilistic inclusion with fee-prioritized ordering once transactions are selected. We’ll correct that, thanks for noticing. We also completed a chain-wide measurement covering last months, all 37 ZS pools, 10k swaps joined to their Kaspa carriers, and approximately 14.5 million Kaspa blocks. We found 12 genuine same-Kaspa-block sandwiches across five attackers. All 12 were net-negative for the attacker. Our data confirms that while sandwiching is real and persistently attempted on Igra, and that higher carrier feerate wins the same-block position in the cases we observed, it does not currently support your claim re “live and continuous at scale” as profitable extraction. Over the full measured window, only 12 landed chain-wide, and none was profitable. It also fully supports our previous claim re single-digit per-attempt success rates -- empirical number is ~4.5%. We're going to publish these results next week. Your public app displays 404,362 KAS of extracted MEV without a visible methodology or breakdown. To reconcile the findings, could you share: - how much of the 404,362 KAS is attributed specifically to Igra; - the split between arbitrage, liquidations and sandwiches; - the observation period and covered venues; - your definition of a completed sandwich and extracted value; - one representative Igra example that we can independently reproduce. We’re not asking for your detector or full dataset as we need enough evidence to understand whether your Igra claim measures profitable extraction, attempted execution, or mechanism-level exposure. If your Igra signal reproduces against our chain-wide dataset, a broader engagement makes sense."
English
@KaspaKaha Not sure I understand. L1 gives you the ordered raw EVM transactions; it does not give you the execution results. To get the events, someone has to run the EL over that ordered L1 data. Otherwise you just have bunch of payloads.
English
Igra’s a based rollup - every L2 tx is embedded in and ordered by Kaspa L1, and the L2 is a deterministic function of that L1 data. The source of truth is L1, which we index from our own node. Your RPC is a convenience layer for reading L2 state; it isn’t where the ordering - or the ground truth - lives. Deriving from L1 is the rigorous path, not the shortcut.
English
We rebuilt the entire Kaspa L2 searcher network from public chain data alone.
Every arb wallet on Igra + Kasplex.
Clustered into operators by shared executor contracts.
No mempool feed.
No inside access.
Just consensus.
98 searchers.
On Igra alone:
• One operator runs 27 wallets
• Another has cleared ~20K KAS across 5 wallets
Solid lines = same operator, multiple wallets
Dashed lines = competitors arbing the same routes
This is what “MEV is real on Kaspa” actually looks like -
an industrialized, competitive market you can reconstruct purely from on-chain data.
Front-running is resisted.
Arbitrage is the business.
And it’s already crowded.
kaspaKaha.com
$KAS #Kaspa #KaspaDeFi #MEV
English
"On-chain arb is ordering-contingent by construction"
Yes, and on Igra no ordering advantage is purchasable or controllable. Trader win by being first to see the opp and fastest to broadcast. It is speed/latency/strategy, available equally to everyone with the same public RPC.
What ordering action does the winning arb tx take that a loser could not?
"decided by ordering"
Would mean whoever controls ordering wins reliably. 95% failure rate is not control.
"one tx captures each opportunity, therefore MEV"
There is no limiting principle here? By this def, every market maker who wins a fill and trader, who captures a move first, is "extracting ordering-contingent MEV," so all trading revenue is MEV. That's not the definition.
English
We’ve always said Maximal EV - and that’s the crux: MEV is value extractable via transaction ordering. It doesn’t need an ordering authority to capture it; the searcher extracts it. That’s the “maximal.”
On-chain arb is ordering-contingent by construction: each spread closes winner-take-all per block - one tx captures it, the rest revert. “Available to any actor” is true for the attempt, not for the capture. Ordering-extracted value = MEV.
And you made the deeper point yourself: you pointed to DAGKnight to clean up the residual. Exactly - MEV-resistance is something you build at the L1 consensus layer, not something a based rollup inherits for free. Until those mechanisms ship, inheriting L1 ordering ≠ resisting MEV, and ordering-contingent extraction is live.
What Igra genuinely resists is ordering-authority MEV - the sandwich/censorship kind where someone sells position. Real, and to your credit. Searcher-arb MEV is a different animal, and it’s alive. Benign vs adversarial we’ll happily separate for users - both are MEV, they just differ in who they hurt.
English
@KaspaKaha Light node is in the backlog. But honestly, as a researcher you want a full node anyway, trust only your own data from genesis. The 40h sync is one-time, and serious hardware runs ~40 EUR/mo. For reliable rollup research there's no substitute for your own node.
English
Appreciated 🙏 - we do run our own Kaspa L1 node. Igra’s the catch: it’s a 40h+ sync on serious hardware to self-host, so we’re on your public RPC for the L2. Honestly that’s the thing worth solving - a lighter Igra node would do more for reliable rollup research than any rate-limit bump.
English
Great to see the first shot at Igra's own Lido.fi. :)
Igra Labs@Igra_Labs
Ecosystem is growing. LYNX is a liquid staking vault protocol on Igra, now on Galleon testnet. It lets anyone stake IGRA, the network's governance and security token, without running an Attester node, and earn staking rewards. Depositing IGRA mints stIGRA, a value-accruing share. Pooled IGRA is delegated as attester stake into the Igra consensus Diamond; rewards are harvested back to the vault, increasing price per share. Lido-style properties: curated operator set, socialized slashing and penalties, cooldown-gated exits. Unlike Lido, no trusted price oracle is needed, as Igra's staking lives in a same-chain contract the vault reads directly. Contract addresses: kaspakat.gitbook.io/lynx/networks/…. Always do your own research.
English
@Specktacularly @DYORPod @kaspaunchained @BlockchainBants MEV is not EVM-specific. It exists on any chain where someone can influence transaction ordering/inclusion for profit.
English
@DYORPod @kaspaunchained @BlockchainBants Talking safety, whilst not a vital threat, MEV tends to be a challenge on EVM, making trades less efficient for users.
Research still ongoing, but for Kaspa (possibly L2 also) the developers might have found a way to avoid 👇🤔
Pavel Emdin@emdin
Yes, resistant by design: igra-labs.gitbook.io/igralabs-docs/…. We also just ran an empirical study, only ~5% of front-running attempts landed, and even those at a loss to the attacker. Publishing soon. Re volume: MEV resistance removes a tax on traders, it doesn't create demand. It comes from liquidity and apps, both are compounding. ~$260k weekly volume; more LPs and protocols on the way.
English
Just to make sure we're on the same page.
1. Our measured claim: on Igra an attacker cannot reliably buy the winning slot in the victim's block by fee. Co-inclusion succeeds ~5% and can't be driven higher by paying more (no ordering authority to sell position), vs 100% deterministic on Ethereum via Flashbots and similar. That's tx-level and reproducible. (btw even these 5% will be most likely eliminated by the DAGKnight.)
2. The 365,149 KAS you attribute to "MEV" conflates two different things: a) opportunity-based arbitrage, essentially closing a price spread, available to any actor, tightening prices, which you yourselves call benign and b) adversarial, ordering-extracted MEV. Those aren't the same claim. Arbitrage is MEV only if an ordering authority captures the value, and which is impossible on Igra.
3. We'd genuinely appreciate the labeled data -- which tx, netting which fees, and captured by which ordering authority. If none is captured, it's arbitrage trading, avail for all, not MEV and in which case please separate the two for users. "MEV loss" and "benign price-tightening arb any actor can do" are very different animals.
English
1/ Both - but that dichotomy collapses on-chain, and that’s the interesting part.
The spread originates as ordinary cross-venue arb. But “anyone could close it at any time” is a CeFi intuition. On-chain, exactly one tx closes each spread per block - and which one is decided by the carrier race + feerate ladder you documented. Losers revert.
2/ So the capture is ordering-dependent by construction, even when the opportunity is a plain spread. That’s exactly what separates on-chain arb from off-chain arb.
And the term itself - Flash Boys 2.0, Daian et al. - was defined around precisely this: DEX arbitrage won by transaction ordering. Arb isn’t the exception to MEV. It’s the original case.
3/ The honest nuance we’ll grant: it’s benign MEV - it tightens prices, it doesn’t tax users the way a sandwich does. Different ethics, same mechanism.
Happy to tag each cycle in the 365K as standing-spread vs victim-contingent - but both are won by ordering, not by “anyone, anytime.”
English
@KodinglsFun @KaspaKaha Our position is on Ethereum and alike, attacker who sees the victim and pays lands it deterministically. On Igra, the same attacker achieves the required co-inclusion ~6% of the time which is measured, regardless of the size and trade params.
English
@KaspaKaha @emdin Igra's position: "In practice, on our live network, sandwich bots fail and lose money."
Researcher's position: "In pure mathematical theory, the trade parameters allowed for profit if a bot was smarter."
Reality is winning for now, but will that remain?
English
Hey @KaspaKaha, TL;DR this is wrong info, as I already mentioned in my DM to you several days ago.
Results of our research which we'll publish soon: ~6% of frontrunning attempts win the carrier race and land (11 confirmed sandwiches over ~25 days), and 0% of those extract anything from victims. Which is... quite good.
For the public, this is my DM message, I copy it here since it contains no private data and important for the context:
"We independently confirmed your narrow technical point: our doc conflates probabilistic inclusion with fee-prioritized ordering once transactions are selected. We’ll correct that, thanks for noticing.
We also completed a chain-wide measurement covering last months, all 37 ZS pools, 10k swaps joined to their Kaspa carriers, and approximately 14.5 million Kaspa blocks. We found 12 genuine same-Kaspa-block sandwiches across five attackers. All 12 were net-negative for the attacker.
Our data confirms that while sandwiching is real and persistently attempted on Igra, and that higher carrier feerate wins the same-block position in the cases we observed, it does not currently support your claim re “live and continuous at scale” as profitable extraction. Over the full measured window, only 12 landed chain-wide, and none was profitable. It also fully supports our previous claim re single-digit per-attempt success rates -- empirical number is ~4.5%.
We're going to publish these results next week.
Your public app displays 404,362 KAS of extracted MEV without a visible methodology or breakdown. To reconcile the findings, could you share:
- how much of the 404,362 KAS is attributed specifically to Igra;
- the split between arbitrage, liquidations and sandwiches;
- the observation period and covered venues;
- your definition of a completed sandwich and extracted value;
- one representative Igra example that we can independently reproduce.
We’re not asking for your detector or full dataset as we need enough evidence to understand whether your Igra claim measures profitable extraction, attempted execution, or mechanism-level exposure. If your Igra signal reproduces against our chain-wide dataset, a broader engagement makes sense."
KaspaKaha@KaspaKaha
We’ve been watching something quietly grow on Kaspa… MEV - Maximal Extractable Value. All time extracted across Igra + Kasplex: 446,514 KAS Almost entirely arbitrage. Igra currently leads with 78%. Front running and sandwich opportunities also exist. We’re tracking every opportunity - independent of any bot. A full MEV series is coming. kaspaKaha.com @michaelsuttonil @hashdag @Igra_Labs @emdin @kasplex $KAS #Kaspa #KaspaDeFi #MEV
English
One more thing worth establishing early: every deployed L1 covenant should come with a launch proof derived from its covenant-id preimage, covering the full contracts and initial state, and should be fully auditable through inspectable source code.
English
A few developer-facing Kaspa updates:
- sources tell me Silverscript’s audit, and hence its first release, is nearing completion
- Argent has a new home:
github.com/orgs/argent-la…
- Argent has grown up significantly since my last report:
- route planning and related graph algos
- cross-app linking
- compiler-model consolidation
- a unified, simple and intuitive runtime tx-construction API
- and many, many more improvements and fixes
- demo apps now range from the most elementary counter-state example, through a full DEX demo, to chess
Chess was fully ported from the manual-routing implementation that originally inspired Argent to an equivalent automatically generated routing system, completely hidden from the dev/user. Each move is verified through L1 scripts with bounded onchain script cost (<5 KB).
I’m also preparing the first short video episode, showcasing live end-to-end coding of a simple multi-actor Argent app.
English
@FelyJish In theory. There are many attempts to solve MEV on EVM like Arbitrum Timeboost, also private mempools on Ethereum, but no major adoption. Most seems to accepted MEV as necessary evil.
English
@emdin so in theory, every sensible mid-large scale trader from eth should move to igra, since its the only decetralised mev resistance chain? (and hence save a lot of money they would have otherwise lost on mev)
English
Yes, resistant by design: igra-labs.gitbook.io/igralabs-docs/….
We also just ran an empirical study, only ~5% of front-running attempts landed, and even those at a loss to the attacker. Publishing soon.
Re volume: MEV resistance removes a tax on traders, it doesn't create demand. It comes from liquidity and apps, both are compounding. ~$260k weekly volume; more LPs and protocols on the way.
jellyfish f@FelyJish
@emdin is igra already MEV resistance? why isnt more volume coming in then?
English
@Unhedgedd @Justin_Bons @s98746_cory @RAGarbage @PastaBeanFras @Igra_Labs vProgs are not enshrined rollups. validity wise its zk rollup, DA wise is closer validium.
English
@Justin_Bons @s98746_cory @RAGarbage @PastaBeanFras @Igra_Labs enshrined coming with vprogs by end year but functionally beyond with synchronous composibility and unified liquidity
English
Kaspa fixed Bitcoin's speed problem: It can now do nothing thousands of times per second!
English
@Justin_Bons @s98746_cory @RAGarbage @PastaBeanFras @Igra_Labs Agree, monolithic would be easier to reason about. However not having one VM enshrined in L1 allows for diversity. You can put different VMs on top of Kaspa (RETH and ETHRex already proven, nothing prevents using SVM).
English
@emdin @s98746_cory @RAGarbage @PastaBeanFras @Igra_Labs Fair!
That is why I said the question is difficult, because everyone has their own definition
My definition of a good roll-up is closer to sharding. It then becomes part of the L1
A purely monolithic design, which is to be expected from a long-time modular/"L2 scaling" critic
English
@Justin_Bons @s98746_cory @RAGarbage @PastaBeanFras @Igra_Labs According to Drake, "based" is a sequencing-only property ethresear.ch/t/based-rollup…. Why is this critical? Enshrined+based rollups is very lonely category and zero rollups today has their ruleset enforced by the L1.
English
@s98746_cory @RAGarbage @PastaBeanFras @Igra_Labs I have been very clear about my definition of based/enshrined roll-ups
For a start, it needs to be deployed by the L1 itself, which is clearly not the case here
Transaction ordering is a good start, but is the ruleset also determined by the L1?
As that is a critical attribute!
English
Three execution environments exist: @kasplex, @Igra_Labs and covenant-based programmability (not Turing complete, but very powerful for some use cases, see @michaelsuttonil/kaspa-covenants-toccata-hard-fork-outlook-a4d81a40900c" target="_blank" rel="nofollow noopener">medium.com/@michaelsutton…).
Justin Bons@Justin_Bons
@alien_kas Totally acknowledged, something the joke did too! It was more of a jab towards the lack of programmability when compared to other 3rd & 4th gen chains Glad you can see the humor in what I did here too, trying out something new Hopefully CT will enjoy this type of content too!
English
Not trying, already deployed and transacting $1M monthly sir. Yes, as based rollup, no sequencer, Kaspa ordering only. Fast, secure, MEV-resilient.
Justin Bons@Justin_Bons
@PastaBeanFras That's right, still no Smart Contracts in 2026! They are trying to deploy them on roll-ups However, it is not clear whether they will be enshrined/based or not So if so, it could be good, as it is akin to sharding; otherwise, terrible as it mirrors ETH's "L2 scaling" failure
English