Today, we sit down with Eliott Méa, a rising researcher in the blockDAG space. Méa recently received a Kaspa Ecosystem Foundation (KEF) grant to develop solutions to the oracle problem. Moreover, he is the Lead Oracle Architect at Kaskad, a DeFi lending and borrowing platform built within Kaspa’s ecosystem. He holds a Master’s degree in Pure Mathematics from ETH Zurich, where he first dove into crypto through his thesis on oracles under the supervision of Yonatan Sompolinsky. His work spans programming, statistical modeling, and mathematical finance—making him an ideal candidate to dissect the complexities of oracle and MEV problems. We break down the interview into four parts: centralized exchanges and their order-book mechanics; the current state of DeFi oracle systems, high-frequency trading systems and how they relate to Kaspa; and a closing section on Méa’s research future. 

Exchanges and Their Internal Order book Mechanics 

Nicholas: How can both centralized exchanges and decentralized exchanges manipulate a coin's price, order transactions, and CLOBs mechanisms? Do you have any real-world examples of said manipulation tactics that have recently occurred? 

Eliot Mea: CEXs are essentially centralized databases. Something is lacking in the general understanding, and even in Oracle whitepapers: any CEX can have its API display a completely false price. At any instant, one venue might display an “absurd” order book (e.g., BTC/USDT = $1). As long as these quotes satisfy the mechanical rules of a LOB (e.g., no negative spreads), such a snapshot is possible, even if it looks economically irrational. Without sending orders to try and buy at these low prices, it is literally impossible to prove that the venue's API is incorrect.

On the other hand, a truly decentralized DEX would not be able to manipulate the price other than by manipulating the market. It’s important to note that the job of an oracle isn’t to detect market manipulation. This is why it is essential not to rely on CEXs in decentralized finance, as they will always have too much power relative to what we are trying to accomplish. 

In order to be robust against such an attack from CEXs, oracles effectively ignore 49% of prices, which implies a huge loss of information. This, in turn, makes oracles less accurate and slow to react to fast market changes. An example of this would be what happened on October 10, 2025. Binance didn’t use an oracle and took the price of eUSD from their spot LOB. This means it would cost a fraction of the total market cap to manipulate the price of many collateral loans (which someone took advantage of). The reason oracles like Chainlink didn’t crash is that they ignored this market move, treating it as an outlier in the median. However, this is just proof of inaccuracy; you can’t just ignore what is happening on a market, because you then lag behind the true value and are slower to react to genuine market moves. 

Nicholas: Many point the finger at Binance for the October 10th market crash, as Binance relied on its internal spot market prices to value collateral for leverage trading, rather than using oracle data. Why did this occur, and why do Binance and other crypto exchanges rely on their order book prices instead of oracles? Is there a financial incentive for it? 

Eliot Mea: As far as I am aware, there is no financial incentive to do this. Many people, including big players, are unaware of such risks. This is why attacks happen all the time: builders ignore academic results, as well as the importance of oracles and other security features in crypto. They either wake up once the exploit has been used or continue ignoring it until the next one. Then, once such events come to light, people rush to invent new solutions, but don’t realize that a rigorous model is the result of many years of research. To reiterate my previous answer, because Chainlink and other oracles are blind to “half” of what happens, they didn’t fail; however, this doesn’t mean it’s a good thing. 

Nicholas: Some claim that a Binance futures listing without a corresponding spot listing for a digital asset can cause price volatility as the gap remains wider without the necessary arbitrage between the asset's spot price and futures price. Is this a concern for Kaspa? Do you believe the concern is warranted? 

Eliot Mea: Some people have a misunderstanding about how futures work. Perpetual futures are a zero-sum game and don’t involve the trade of any asset. When someone opens a leveraged long, he is simply matched with someone who has shorted an equal amount. Once you close your long, either someone has opened the same long at the same time, or someone has closed a short position. This means that futures never interact with the spot price; they are an isolated game. This would be different if some exchanges allowed users to use KAS as collateral for leverage trading, which would induce liquidations and thus impact the spot price. But this isn’t the case. Now, nothing is perfect, and there is emotional influence from seeing leverage and associating it with fear or greed. However, I see all the Binance futures discussions as noise.

The Current State of Oracle Mechanisms 

Nicholas: Oracle security rests on the assumption that at least 50% of data providers are honest with the price feeds they provide. How do these price feeds create a "ground truth" (GT) price, and how can providers manipulate the GT price for their own benefit? 

Eliot Mea: They rely on the assumption that 50% of data providers are honest, but just because consensus mechanisms can rely on this doesn’t mean oracles can too. The difference is as follows. In consensus mechanisms, dishonest behavior is clearly defined and objectively verifiable. For instance, attempting to double-spend in Bitcoin or proposing an invalid block; in Ethereum, it triggers deterministic penalties. Oracles, however, function differently. You want to penalise users based on being far from the ground truth, but your understanding of the ground truth is itself influenced by this “wrong” observation. So there is no deterministic rule.

Therefore, a way to easily manipulate a median-based oracle is to skew your observation by an arbitrarily small value epsilon each time. There is maximal value such that if you skew more, you are penalised, but at that skew, the mechanism doesn’t detect you. This is because the oracle cannot differentiate between observation error from your end or outright lying. Now this would lead to strictly superior profit (conditioned on skewing enough to make a small arbitrage). So if everyone does this, your oracle price will move far from the “ground truth” (GT), and there is nothing you can do about it.

Nicholas: Let’s get philosophical: do you think a GT price is ontologically possible? If so, is it possible for the GT price to remain static? Will there always be a possibility for translation invariance if we assume a GT price exists? 

Eliot Mea: From my mathematical finance course at ETHZ, we learnt that an efficient market is defined mainly by a no-arbitrage (NA) condition. Obviously, this assumption doesn’t hold due to information fragmentation, latency, fees, liquidity, and other factors. However, theoretically, we can define the GT price as the midpoint BBO you would obtain if, at a time t, you simulated all arbitrage across venues. This price evolves just like any other, based on demand and supply, but represents the value above which there is net excess supply, and under which there is net excess demand. I will soon write a blog post on this with visual representations of what “simulating arbitrage” means.

Nicholas: The Oracle problem seems to be a double-edged sword; we must decentralize the data provider structure and the price feeds they provide. Is it possible to truly decentralize the latter? How can we ensure Oracles aren't receiving the same data from a single centralized data source? 

Eliot Mea: Unfortunately, there will never be a way to decentralise the price we can receive for a CEX. No matter how many nodes fetch it, the saying goes “trash in, trash out”. So the CEX will always be able to display a terrible price, in which case the nodes will push that terrible price on-chain. The best way to do things would be to have a DCLOB on Kaspa that would be so easy to use (UI plus inherent advantages due to MEV resistance and RTD) that it would suck in all liquidity from existing CEXs, rendering them negligible and, by extension, useless for the oracle. For now, that might be wishful thinking. 

The High-Frequency Trading Arms Race and Kaspa Solutions 

Nicholas: You've posted about the current HFT arms race in traditional finance, whereby firms build ultra-fast infrastructures (co-location, microwave links, fiber optic routes) to gain microsecond advantages in orderbook latency. This race is wasteful as the fastest traders “snipe” stale quotes from market-makers, turning financial markets into extractive systems that tax everyone without improving efficiency or total profit. I have two questions about this. 

First, you've offered two potential solutions to eliminate this arms race problem: Frequent Batch Auctions (FBAs) and Speed Bumps. Can you explain how these two procedures might resolve the issue and why they have not been implemented in traditional finance or crypto yet?    

Secondly, will FBAs and Speed Bumps play a part in how Kaspa addresses the oracle problem? 

Moreover, Yonatan alluded to another possible solution, namely the idea of a Turing-complete scheduler, aka "server-free latency-agnostic prioritization of transactions," allowing users to create conditional transactions or pre-commit responses via Kaspa's consensus ordering to any kind of market movement. Does this idea play into your oracle research? At the very least, if this idea were achieved, we could do away with the HFT arms race, right?  

Eliot Mea: Let’s answer both questions at once. Decentralized exchanges naturally introduce FBA. This is because trading cannot be continuous, as each trade must wait to be included in a block; hence, the faster speed is still lower-bounded by the block time, as no trade can be included faster. To an extent, this limits the HFT arms race that Eric Budish was so afraid of. Now let’s focus on what Yonatan talked about, which, imo, is much more interesting than the above basic feature. 

An idea for decentralised finance is the following: are there benefits to having exchanges worldwide (think of this as software you could give to miners, where each miner acts as an exchange)? Is there increased welfare from this fragmented liquidity that remains on the same sequencer, and if so, what are those advantages? My current goal is to understand how and under what conditions (or setups) it is NOT true that liquidity centred at one venue is stronger and provides inherent advantages. For example, having closer geolocation for any user allows it to be fairer, in the sense that you would be less vulnerable to adversarial risk and thus more incentivised to provide liquidity. This is what it means to create a true DCLOB that can compete with Hyperliquid. 

Nicholas: Yonatan has discussed implementing MEV auctions whereby miner competition could lead to an environment where miner payments ("kickbacks") naturally match the extractable MEV. How much of his MEV auction research plays into your oracle research? How are the two related to one another? 

Eliot Mea: MEV, as Yonatan works on it, doesn’t play a role in my research. Instead, I focus on extractable value from HFT, centralisation, etc. They will be related to one another because it is strictly better to have a DCLOB with MEV resistance than Hyperliquid, which can extract value from its users with no consequences. In the same way, I don’t focus as much on what advantages Kaspa provides in a DCLOB (even if there are many), but on what a DCLOB can provide in itself. 

Closing Out

Nicholas: Once DAGKNIGHT is implemented, how will it change the playing field for MEV auctions and price oracle auctions? 

Eliot Mea: This isn’t too much a question that I have asked myself.

Nicholas: Before we close out, is there any chance you can share with us any progress you’ve made in your research? How long do you imagine yourself focusing on oracle designs? Lastly, what else would you like to work on in the future? Do you have other research interests outside of crypto? 

Eliot Mea: The results I have found in oracles are summarized in two papers, not published but in draft form. One of them will be made public soon and is currently being implemented with my cousin Paul Colagrande, but still needs heavy testing to fine-tune parameters (i.e., have academics review it, etc.)

In the future, I would like to work on different problems that may arise in Kaspa research, or, more generally, on what Yonatan deems essential. From his experience, he has a much better understanding of where academia is lacking in crypto/decentralised finance, and I am passionate about working on such subjects under his supervision. Though one day, I should be good enough to tell him where I think we should focus more attention. For now, I am more focused on learning and becoming an expert in the areas we are currently interested in. 

For now, I’d like to stay in crypto, as it combines very theoretical mathematics with very concrete problems that benefit society (from my perspective). I have never enjoyed working so much, and I look forward to contributing more.