This episode's guest is Jeff Yan, founder of Hyperliquid. Jeff began his career in the high-frequency trading field at Hudson River before moving to the crypto world, where he built one of the largest market makers in the sector.
Article author: @flirting with models
Article source: Aki Wu Blockchain Blockchain
This episode features Jeff Yan, founder of Hyperliquid. Jeff began his career in the high-frequency trading (HFT) space at Hudson River before moving into the crypto world, where he built one of the largest market makers in the sector. He delves into the infrastructure of centralized crypto exchage, adversarial algorithms, and why HFT profits and losses can actually be predictive of medium-term price movements. He explains what he sees as problems with current decentralized exchanges and introduces the early ideas behind Hyperliquid. Released on May 8, 2023, this episode offers a glimpse into many of Jeff Yan's early thoughts.
How to get into crypto trading from Harvard
Jeff Yan: My experience is similar to many HFT practitioners: I graduated from Harvard University with a major in Computer Science and Mathematics, and then joined Hudson River Trading, a large market-making institution in traditional finance. I was working on US stocks at the time, and the experience was excellent. When I joined, the company had about 150 people, and it's much larger now. I benefited immensely from working there, being exposed to the most interesting problems, where engineering and mathematics could be perfectly combined—almost a "paradise" for quantitative finance. In 2018, with the rise of Ethereum smart contracts, I read the (Ethereum) Yellow Paper and instantly had an "aha" moment. I was convinced that this was the future, so I left to work on an L2-oriented exchange protocol.
We chose to focus on prediction markets because Augur was already showing strong product-market fit (PMF), and we were more skilled in and focused on the underlying technology capabilities of exchanges. Therefore, after securing funding, we moved to San Francisco to build our team. However, a few months later, I decided to shut down the project because the timing wasn't right: regulatory uncertainty was extremely high, and user acquisition was incredibly difficult. At that time, most people weren't familiar with smart contracts, their interest was more focused on token speculation, and there was no real demand for DeFi, so the project was ultimately shelved.
Afterwards, I spent some time reflecting and traveling, ultimately choosing to return to trading. Compared to constantly "searching for product-market fit" (PMF) in the market, trading itself is more direct and interesting. Initially, I considered joining an established company, but considering my experience with crypto products and my familiarity with industry mechanisms, I started with proprietary crypto trading. At first, it was just a side hustle, but I quickly saw significant opportunities, and the business expanded much faster than expected. The inefficiency of the market surprised me. I then devoted myself to it for almost three years: the real systematic launch occurred in early 2020, coinciding with the market cycle. As the market size and trading volume grew 10 to 100 times, we grew in tandem, eventually entering the top tier of centralized exchange (CEX) market makers.
About a year ago, we began systematically evaluating DeFi trading opportunities. This was similar to our early observations when we entered the CEX trading market—inefficiencies were widespread. However, the difference lies in the fact that some DeFi protocols have inherent flaws in their mechanism design, resulting in limited trading experience and capital efficiency. At the same time, following the FTX incident, the market's awareness of "not your keys, not your coins" and counterparty risk has significantly strengthened, leading to a continued rise in demand for truly decentralized products. Based on these changes, we judged that the window of opportunity for building decentralized exchanges had arrived. Over the past one to two quarters, we have continuously invested resources in advancing this direction; the High Frequency Trading (HFT) business has been operating and maintained in a relatively stable state, while our current main investment and focus is concentrated on solidly implementing this decentralized trading technology stack and completing its systematic construction.
Market making vs. order taking: What are the differences between the two?
Jeff Yan: In my view, this is indeed the first major decision to make when entering high-frequency trading. From a macro perspective, the two have many similarities: both are essentially demanding on infrastructure and highly sensitive to latency. However, in many key aspects, they show opposite emphases: market making relies more on infrastructure capabilities; order taking relies more on statistical and mathematical modeling.
I believe the choice of path largely depends on the type of work and research you prefer to invest in. Taking market making as an example, you are to some extent constrained by counterparties who "push through" the price, leaving very little room for error. Typically, using leverage and placing orders across multiple instruments and price levels creates significant implicit risk exposure; if an error occurs, the cost of tail risk is often very high. In contrast, a taker strategy can be triggered only once a day—and can still be an effective high-frequency strategy, potentially based on news or specific market signals.
Because triggers are less frequent, you have the flexibility to refine your model: not triggering most of the time doesn't matter, as long as the performance is good enough when it does. Conversely, market making lacks this flexibility—even if it performs well 99% of the time, a mere 1% delay or failure to keep up with the data can wipe out the entire PnL for the remaining 99%. This is the fundamental difference between "infrastructure-driven" and "model-driven" approaches.
Corey Hoffstein: Could it be understood more intuitively like this: the party choosing to "take orders" is willing to cross the bid-ask spread because they expect the price to continue moving in their direction, and therefore are willing to bear the spread cost; while the party "making markets" hopes the price will remain as stable as possible within their trading window—when someone crosses the spread to trade with them, they then hedge or reverse the trade on the other side to profit from the spread. Is this distinction reasonable? That is, one party prefers a sideways market within their trading window, while the other prefers directional movement.
Jeff Yan: Yes, that's basically how it works. In high-frequency trading, we typically evaluate markout (review profits) over extremely short time windows, but this same principle applies to more general trading frequencies: as long as you choose to "take a bite," you'll immediately incur a fixed loss (spread and fees) at the moment the price reaches the midpoint. Only if, subsequently, within your set prediction time window, the average price movement covers this immediate loss and further compensates for the fees, will your strategy have a positive expected value.
Market making is the opposite: at the moment of execution, your initial PnL is often at the highest level that the trade can achieve—because you have just captured a spread. What you are betting on is that this portion of the profit will not be completely eroded by "deteriorating selection" on average.
Therefore, in a market scenario, if all transactions are observed using markout over time, a decrease in PnL over time is usually the more common pattern; your only expectation is that the decrease does not become negative.
Corey Hoffstein: Before our call, you mentioned that the hardest part of scaling a business isn't research, but infrastructure. I also saw a similar statement you made on X: "Being able to do data normalization doesn't guarantee you'll make money, but not being able to definitely not make money." Could you talk about your biggest lessons learned regarding infrastructure, and why it's so crucial?
Jeff Yan: This question can be roughly divided into two parts, which are closely related: one is "trading infrastructure," and the other is "research infrastructure." Data cleaning leans more towards the latter, as it is part of statistical practice; the former refers to high-frequency trading systems in a narrower sense. Both are extremely important.
While the research aspect is more well-known, it is important to emphasize that the signal-to-noise ratio and noise patterns in high-frequency trading are several orders of magnitude worse than those in most academic studies, making the handling of outliers far more crucial.
If a proper framework for handling these issues is lacking, and outliers are simply ignored, the model may be directly compromised by a black swan event. However, if normalization or filtering is not properly implemented, extreme samples will dominate model training and parameter selection. In practice, using quantiles is often more robust than using raw values in many tasks. Even when using raw values, a clear trade-off must be made between "discarding outliers" and "pruning outliers," and these choices often have a significant impact on the final result.
The biggest lesson sounds simple: you must personally review the data. Don't assume that just because you're smart enough or your pipeline is "clean" enough, the model input will automatically meet expectations. The time spent examining raw data can hardly be considered "excessive"—because almost every review yields new findings. Early on, the team should have all raw data streams provided by the exchange completely logged into disk, checked line by line, proactively identifying anomalies and performing consistency checks.
Here's a seemingly absurd but real case: At one point, an exchange had a bug in its market data feed, swapping the "price" and "quantity" fields. For example, Bitcoin's 20,000 / 0.1 was recorded as 0.1 / 20,000, causing complete distortion of our internal statistical and counting logic. Many teams had to shut down their systems or switch to backup data sources. This kind of incident illustrates that no matter how "robust" your logic is designed, it's impossible to cover all abnormal situations. Therefore, it's crucial to maintain as close proximity to and as traceable as possible to the original data.
Furthermore, timestamps require close attention. Exchanges often provide multiple timestamps in their data, and their true meaning needs to be analyzed and aligned manually. This is particularly crucial for understanding "black box latency"—what exactly are you measuring? Are you truly "keeping up" with the market, or is the other party pushing low-quality data? By breaking down and comparing timestamps, these situations can be better distinguished, thereby determining whether the network is healthy and whether latency is within a controllable range.
What is "fair price"? How is it measured, and why should high-frequency market making revolve around it?
Jeff Yan: Different trading firms do have different definitions of "fair," which often depends on their respective trading styles. But what they have in common is that "fair" essentially condenses your modeling results into a "predicted price." This abstraction is very valuable because it breaks down "how to build a profitable strategy" into two equally difficult tasks: price prediction and order execution.
This echoes your previous question about market making and order taking: market making leans more towards the execution side, while order taking leans more towards the modeling side. For order taking strategies, research and decision-making almost entirely revolve around the "fair price." As for what information should be included in the fair price, it depends on which data processing stages you believe you have an advantage in, and where the market's efficiency gaps specifically exist.
Furthermore, there isn't necessarily only one fair price. In a more machine learning-oriented framework, you can maintain fair prices for different prediction periods simultaneously, such as predictions for 1 second and predictions for 1 day; the execution strategies will be utilized in different ways, and the corresponding optimization objectives may also differ along the PnL dimension.
For beginners, a relatively effective "coarse cut" approach is to first give a single value around which you are willing to quote or cross price spreads, and treat it as your "oracle"; then, with historical price series available, further consider how to achieve optimal execution around that value.
Corey Hoffstein: Could it be simplified to this: Observing a particular exchange, if we assume Binance aggregates almost all liquidity, then Binance's price can be considered the fair price; if other exchanges (such as OKX) have lags ranging from milliseconds to seconds, then we can trade across the price difference based on Binance's fair price, waiting for it to "catch up." Of course, there are also more statistical approaches, that is, not taking a single exchange as the "true value," but combining relevant signals from the order book to estimate the fair price. Is this explanation valid? I'm not entirely sure either.
Jeff Yan: Yes, that's the right approach. Using the most liquid exchange as the fair price is indeed a good first approximation. Early on, price discrepancies between exchanges often reached 10%. The main challenge then wasn't price prediction, but rather how to efficiently transfer funds between exchanges; therefore, this method was very effective at the time. In recent years, the market has undergone an evolution: liquidity was initially dispersed, then flowed back and concentrated on Binance (especially recently). Therefore, as you said, using the Binance price as the fair price is a reasonable starting point.
However, it's important to emphasize that directly equating a single external source with the fair price requires caution. For example, OKX's lag might only be a few milliseconds, and actual transactions may not be as direct as described. Furthermore, suppose there's an opportunity: whenever Binance's price changes while OKX has no buy orders, you follow the price movement and attempt to close your position for arbitrage—this might work in most cases, but this is the crypto market, and there's the risk of discontinuity: for example, OKX might suddenly go into wallet maintenance, temporarily severing deposits and withdrawals between Binance and OKX, breaking the arbitrage chain, and potentially causing price divergence. In this situation, if your fair price relies solely on Binance's price, you might face passive risk exposure.
Therefore, there are many details involved. Even within this seemingly intuitive framework, it is far more complex than simply "taking a number from a data source as a fair value"—it can only serve as a good first approximation.
Corey Hoffstein: This leads to my next question: the many technical characteristics and "pitfalls" of crypto exchage. Historically, their technical reputation has been unstable: you mentioned examples of "dirty data" (such as swapping price and quantity fields), API crashes, poor documentation, hidden endpoints, and even undisclosed parameters. I recall you recently gave an example on X: bypassing the risk control engine or running it in parallel—these completely undocumented details constitute "orthogonal alpha" unrelated to price prediction. My question is: how much alpha does work such as deeply understanding API details and accurately measuring endpoint latency actually contribute? Compared to this, which is more important: more "traditional" statistical alpha (such as using order book signals to determine pressure and direction)?
Jeff Yan: I remember that tweet you mentioned received a pretty good response.
Corey Hoffstein: By the way, I'm still not sure if that was an April Fool's joke.
Jeff Yan: April Fool's Day is over, and I admit it was a joke. But it's closer to reality than most people think. The real "funny part" is that it's actually partly true. I've been wanting to write a follow-up, and this is a good reminder—I'll post it as soon as I finish recording this episode.
Going back to your intuition, I think your judgment is on the right track. People who work at a company for a long time often develop preferences; or they may have entered with preferences from the start—for example, "I studied math, so I should build cooler machine learning models, mine signals, and generate alpha—that's the key, because that's the hardest part." This "just build the model" approach might work in large companies because the division of labor is highly specialized; but if you need to run the entire business independently, this alone won't get you far.
The "dirty work" you mentioned—thoroughly understanding the API, filling in documentation gaps, and measuring latency at each endpoint—is crucial. My understanding of high-frequency trading (and many things in general) is that it's more like the product of multiple factors than a simple addition. Your input in different "buckets" may seem summed, but the output often reflects a multiplicative relationship. For example:
Overall effectiveness ≈ Infrastructure × Model
If the "infrastructure" factor is only 1, while the "modeling" factor is 10, then for every unit of effort invested, the rational choice is often to prioritize addressing the weakest link. The difficulty in high-frequency trading lies in the challenge of accurately judging the level of each of these factors. Therefore, continuous "meta-analysis" is necessary in practice—is what I'm doing now truly the most important thing? You'll quickly find that the answer isn't obvious. Many competitive advantages lie precisely in the ability to prioritize.
In this sense, the seemingly "dirty" work is often crucial. We should pragmatically reap the low-hanging fruit, following the 80/20 rule. When the market is booming, the easiest pitfall to fall into is thinking, "The foundation is solid; now I can do some cooler machine learning research and pursue innovation." We've paid the price for this. This doesn't mean there's no alpha in this direction, but rather that the investment is large and the marginal returns often diminish rapidly.
When your team is small, your existing strategies are still effective, and market opportunities are still plentiful, you need to repeatedly ask yourself and be honest about what should be your top priority right now. Don't be "lured" by superficial data to chase directions that should not be your priority at the moment.
Corey Hoffstein: For those looking to engage in high-frequency trading in the crypto space, you've suggested two paths: one is to trade directly on Binance and focus on alpha generation (I understand this leans more towards "active order taking" than "market making"); the other is to choose an exchange with long-tail characteristics, deeply understand its infrastructure features, and find advantages accordingly. Could you elaborate on why you consider these to be the optimal paths? What are the methodological differences between them?
Jeff Yan: This can be compared to the intuitive conclusion of a "bell curve"—don't stay in the middle. If we understand the horizontal axis of the bell curve as different exchanges, then the most prominent problems are often in the middle range, which can be roughly corresponding to platforms in the 2nd to 7th tiers.
Their trading volume is far less than Binance's, but the intensity of competition is similar to that of "toxic traffic," and the traffic quality may even be worse. At least on Binance, we know that its retail traffic accounts for a very high proportion , which creates a "buffering effect"—a more favorable mix of toxic and retail traffic. Top HFT companies have basically already fully integrated with the top few exchanges (you can roughly understand this as the top 15), and will be trading at full capacity with larger-scale and more mature strategies; it's difficult to "squeeze" much profit out of these mid-tier platforms. If you are willing to challenge highly scalable large-scale CEX strategies, start directly with Binance, and generalize as much as possible—there's no reason to start from the "middle."
The other path you mentioned also holds true: go to the far left of the bell curve. Look for small, overlooked opportunities—either too small for big players to spend time on, or too niche for them to cover. Niche infrastructure is a prime example.
Exchange systems are developed and implemented by people. Just as many DEXs may have obvious flaws in their protocol design, some small centralized exchanges may also have clearly identifiable defects in their technical implementation. If you truly understand the "uniqueness" of its operating mechanism, this in itself can translate into a strategic advantage. Infrastructure is often a significant source of alpha, and there is no absolutely clear boundary between "model vs. infrastructure."
You might worry about "non-generalization": for example, you might master a specific "exploitation method" on a small exchange, but it won't directly help on Binance. I think the value of "running an effective strategy" is generally underestimated. For most teams, this should be the primary goal; the size of the strategy doesn't necessarily need to be overly concerned in the initial stages.
Of course, there's a fundamental premise: if the platform is so small that there's almost no transaction volume, research and deployment are meaningless. However, as long as there's a certain transaction volume, some returns can usually be achieved. More importantly, if the strategy has a high Sharpe ratio and is sufficiently robust to retail events, then the skills and experience you gain will be something most participants don't possess.
Even if specific strategies cannot be directly generalized, my experience is that as long as you successfully navigate the "research-deployment-production" loop, the insights gained in this process often far exceed expectations. Even if you subsequently start over or switch to leading platforms like Binance, the overall difficulty will significantly decrease. Furthermore, while many detailed differences cannot be transferred one-to-one, you will begin to extract common principles from "things that have already proven effective" and continuously generate new ideas; these ideas are usually significantly better than ideas conceived out of thin air.
Therefore, both paths have their value. If it's difficult to choose one at the moment, you can start small and gradually move towards larger ones; frankly speaking, it's also worth trying both paths.
Corey Hoffstein: You mentioned "toxic traffic." Could you give a definition for someone who has never heard of this concept?
Jeff Yan: Its essence is "information-dominated traffic." I have a framework for understanding the growth of the crypto market: I entered the market relatively late, and can only imagine the earlier state by looking back. Even when I entered, the scale of retail funds was already considerable, and there were large participants, but the core contradiction in the supply and demand relationship was still that available liquidity was insufficient to meet the trading needs of the retail side. Therefore, retail traffic was the most direct and worthwhile target. The most intuitive approach was to develop a relatively universal market-making strategy to provide liquidity through order placement. As long as retail investors matched your orders, you could largely retain the profits contributed by them across the spread; at that time, this model itself was consistently profitable. This, in turn, constituted a strong signal: the dominant traffic in the market at that time still mainly came from the retail side.
However, as time went on, market participants gradually realized this and began to deploy market-making strategies on a large scale. As liquidity on the market-making side increased, the significance of taker strategies rose, and the bid-ask spread was continuously compressed. To continue capturing high-quality retail traffic, takers emerged and became more selective in "screening" the inferior orders on the market-making side, taking them away one by one. This is a common path in market evolution. It's worth noting that takers also provide significant value to the market; a simple dichotomy of "market making = market maker, takers = counterparty" is inaccurate, as these two roles often intertwine in practice. In my view, a more ideal market structure allows participants to trade freely in their own way.
From a market maker's perspective, however, this type of order volume significantly increases the difficulty of the strategy: the previously relatively easy model—continuously placing orders and earning a small spread each time they are filled—can be "drained" by a few trades. For example, you might accumulate a profit of about 1 basis point in about 99% of retail trades, but lose 10 basis points in a single trade in about 1% of trades (this is just a mental model, not an exact number). In this structure, tail losses are enough to wipe out most of the regular profits.
Therefore, "toxic traffic" largely refers to this type of traffic represented by those who take orders and have an informational advantage. Of course, whether something is considered "toxic" depends on the specific strategy you are using; but in most contexts, a relatively intuitive distinction can be made between "retail traffic" and "institutionalized/high-level traffic."
How common is it for "adversarial algorithms" to trick HFTs in the crypto market?
Jeff Yan: Crypto does indeed have a "Wild West" feel to it. To look at it more positively, crypto is also an experiment, and stance and perspective are particularly important within it. Regulators often seize on one point—"They haven't followed our carefully crafted securities laws." DeFi proponents, on the other hand, argue that these securities laws themselves are likely influenced by lobbying and human judgment; crypto might offer a more libertarian experimental space: what exactly must be regulated? I'm not entirely sure either; reality is probably somewhere in between. I'm not a regulator or policymaker; I'm just sharing some philosophical observations. Returning to the practical level, if you don't pay attention to manipulative and exploitative strategies, trading in the crypto market will be extremely difficult.
Another reality is that it's not that exchanges are unwilling to be regulated, but rather that it's often unclear who should regulate which exchange—at least for me, this is unclear. Many legal frameworks differ significantly between countries, which is perhaps one of the important reasons why the problem persists. Furthermore, operating an exchange is extremely difficult in itself; they also need to handle a large number of other matters simultaneously.
To give a more concrete example: spoofing is a very common practice. I don't intend to delve into its strict technical definition under US securities and futures law; the spoofing discussed here is more broadly defined: from the order book and the subsequent price action, you can often clearly observe that someone places a huge number of orders, but obviously has no real intention to execute them—in fact, they might even feel disadvantaged if they were executed. Although it's difficult to prove their "intention" legally, these orders are clearly not for execution, but to create the illusion of an extremely abundant order book on one side. The result is that if some algorithms interpret order book liquidity as a price trend signal, they may be misled and place orders in the corresponding direction. Once the "induction" takes effect, the spoofing algorithm will either place more easily hit maker orders or actively absorb the passive orders exposed by the induction.
This type of situation is very common. Another, more blatant one, is various forms of market manipulation, such as organized groups that "pump and dump" stocks.
Out of observation, I've infiltrated several such groups, never participating in the transactions, only observing. This phenomenon is quite large-scale. Recently, much of this activity has indeed been cleaned up, which is a good thing; but in earlier years, they could even create exaggerated trading volumes: an "insider" would announce a token, followed by a rapid influx of retail users (their organization method is unclear to me), and the insider would use the traffic to unload their holdings. For high-frequency trading, this scenario seems manageable on the surface, but it's actually very difficult to handle because the strong mean reversion effect often backfires on the strategy.
As for the approach, it brings us back to the trade-offs you raised earlier regarding infrastructure, models, and strategies—where should our efforts be focused? For me, this type of issue falls under the category of "miscellaneous/special scenarios" that must be covered, and can also be categorized as risk management and special situation handling.
In short, if this part of the work is not completed, even if other aspects are done almost perfectly, this part may still become the key factor determining the long-term average PnL success or failure in different market conditions and for different targets.
Jeff Yan: We were genuinely shocked when we first encountered this situation. Looking back, we were lucky: initially, the targets we traded were either not easily manipulated, or the other party hadn't had time to act. We hadn't anticipated this problem at all, and built the system under the premise of "ignorance," and PnL progressed smoothly for a while. But once caught in the trap, the impact is extremely severe—if the strategy isn't constrained, a day's worth of PnL could be lost in a minute. Sometimes automated trading is the most "foolish" type of trading because it's essentially just a finite state machine lacking human discretion, simply executing according to a preset path. Our approach was quite pragmatic: of course, you can sit down and analyze, model, to predict whether manipulation exists; but one of our advantages at the time was our extremely fast reaction, data-driven approach, and lack of obsession with the "most standard" path. For us, the approach was—once a specific loss pattern appeared, we would immediately shut down the relevant logic;
Jeff Yan: These kinds of rules can often be written within an hour and deployed directly to the production environment. At the time, we strictly followed the 80/20 rule: we did miss some opportunities because of this, but it also freed up time and energy to scale up and advance key projects that could amplify PnL tenfold, instead of being constantly held back by these problems. There might be about 5% of the time when we forgo potential benefits due to shutdowns, but this is essentially a matter of trade-offs and judgments—investing resources in the most valuable work.
With more resources and time available, we have gradually deepened our understanding of this area: we now have more complex models to predict relevant market conditions and identify ongoing behaviors; compared to the earlier, more "discrete" on/off processing, we now adopt more continuous parameter and weight adjustments to dynamically constrain and adaptively configure the strategy.
To date, we have developed a relatively deep understanding of how these manipulative behaviors operate and their identifiable characteristics. However, it must still be emphasized that the 80/20 rule remains the most important guiding principle for newcomers.
Is market manipulation more prevalent in long-tail cryptocurrencies and small exchanges?
Jeff Yan: This kind of thing is relatively rare on any exchange, especially on Bitcoin and Ethereum, because they have much better liquidity. I think it depends more on the asset itself than on the exchange. I've seen (manipulation/fraud) on almost every exchange; the methods vary across platforms, and you can sense that the participants aren't exactly the same, but the overall approach is largely the same.
There is a "sweet spot": if a token has almost no trading volume, it is usually not worth investing in; but it is different for some altcoins with a certain trading volume - the algorithm will expect a certain amount of trading and liquidity on them, so there may be a space that can be "induced", allowing manipulators to profit from it.
Corey Hoffstein: I've always believed that the way we observe the market is often constrained by our own trading timeframes. As a high-frequency trader, your intuition about microstructures might be quite different from mine, as someone with a longer holding period and a more fundamental perspective. You once tweeted that the market is like a viscous fluid, where external shocks manifest as damped oscillations during price discovery. I found that analogy very interesting; could you elaborate on it?
Jeff Yan: I also value understanding the essence of things. This is probably related to my background in mathematics and physics — without understanding the underlying mechanisms, it's difficult for me to innovate within a "black box" system. Therefore, I tend to construct mental analogies and metaphors to help understand how markets work.
Using the "viscous fluid" model as an example, let's return to a more fundamental question: Why can high-frequency trading make money? Many retail investors view it as a form of "predation," for example, believing that we are "rushing ahead" or "hunting stop-loss orders." I'm not claiming that high-frequency trading is "doing good," but I believe it does provide a necessary service to the market to some extent.
External factors influencing prices can be abstracted as "shocks" exerted on the system (which, for us, are largely random): for example, someone urgently needs to complete a transaction and obtain liquidity immediately; or a news event changes the "fair value" of an asset. Although some may attempt to interpret the event itself, such demands are often sudden and typically "exit after execution." The order book is essentially a strong PvP (player versus player) arena, with many participants entering with a clear sense of urgency; and a feedback loop is formed: momentum trading triggers more trading, thus giving rise to various unstable equilibria.
In this structure, prices typically experience a large initial shock before market participants gradually enter the market and engage in a game around the true fair price. The first jump is usually the largest; afterwards, some will judge that an "overslip" has occurred and engage in mean-reversion trading—this could come from mid- to high-frequency participants, for example, believing that "the price will fall back on the mean in the next 5 seconds." At the same time, some will believe that the event has a far-reaching impact and choose to push prices up further until a larger increase occurs; for example, an event like "Elon adding Doge to Twitter" might be seen as having a "real impact" within their narrative framework, thus conversely breaking through the positions on the mean-reversion side.
Overall, this is more like a "price vote" and a continuous game played with real money. Its key feature is that the volatility gradually converges. As participants gradually build their target positions, funds continuously complete a weighted average, and prices eventually tend to converge to a more stable fair price range.
In this process, the core function of high-frequency trading remains to provide liquidity by buying low and selling high. If the price path is viewed as a fluctuating curve, high-frequency trading buys when the curve is low and sells when it is high. On average, the trading impact will have a smoothing effect on the curve—causing the price to approach the fair price more quickly and to operate around the fair price as much as possible during the price formation process.
Therefore, within this analogy, the stronger the high-frequency trading capability and the more abundant the market liquidity, the higher the viscosity (stronger the damping) of this "fluid." This mental model may not be rigorous, but it largely conveys the meaning I intended in that tweet.
Why can high-frequency trading P&L predict mid-frequency price changes?
Jeff Yan: These are some of our internal "exploratory ideas." As I mentioned before, iterating around directions that have proven effective is almost always better: higher success rate and easier to scale. But we also reserve room for a few bolder explorations, which occasionally do produce results. This time it was a relatively successful "interest project," and we didn't have strong prior judgments when we started it.
The primary motivation was that our available capital had exceeded the capacity that high-frequency strategies could effectively support; although we had already connected to multiple exchanges, this was largely a constant-term expansion with diminishing marginal returns—as the size of the platforms we subsequently connected to became increasingly smaller. Therefore, we began to consider whether we could extend our reach into the mid-frequency trading domain—ideally, this would be an "ideal asset" with a Sharpe ratio of 3–4 and a capacity hundreds of times greater than that of high-frequency strategies. This idea sounded extremely attractive.
However, we generally agree with the basic framework of an efficient market. Yes, we have an advantage in high-frequency trading, but if given a set of daily data and asked to predict daily returns, it's difficult to find a reliable entry point directly. Based on this cautious approach, this "brainstorming" idea provides a relatively feasible path: in mid-frequency trading, obtaining data sources that are valuable to others but inaccessible to them can itself create a strategic advantage. We can't obtain "alternative data" like some institutions, such as satellite imagery or parking lot traffic statistics. So, what do we truly possess? We possess our own HFT PnL—a proprietary data set that is clearly not random noise; its time-series pattern reveals certain structural characteristics, making it worthy of further study.
Further questioning reveals its correlation with various factors. Returning to the earlier discussion of "toxic traffic and retail traffic," it is highly correlated with retail traffic. A relatively simple priori assumption is that if you can distinguish the types of market participants and understand their behavioral patterns, you can often obtain better signals. The overall priori assumption remains that "most signals lack stable predictability," but the direction is not necessarily clear. Therefore, our approach is: since we possess this indicator, and it is related to retail traffic, which is probabilistically related to price formation—we should thoroughly explore this path and conduct rigorous analysis and verification.
Jeff Yan: We did indeed conduct this analysis. The overall approach was to incorporate a series of features centered around P&L (such as the change in P&L, the "derivative" of P&L, etc.) into a regression framework to predict price performance at a mid-frequency scale across different time windows. Initially, we were unsure how to implement mid-frequency research, so we adopted a relatively "broad coverage" approach: starting with 5-minute returns and then gradually expanding the time scale to several hours.
Jeff Yan: The research primarily relies on our internal dashboard data system, which aggregates P&Ls (Prices and Trades) for different strategies across different exchanges and assets, and supports segmentation by exchange/strategy/asset. Due to significant data noise, robust processing is required; obviously, we won't directly use the P&L of a single coin to regress its mid-frequency trend—the noise is too high and the interpretability is limited. We basically follow the 80/20 principle, using methods such as binning and grouping, to arrive at a rather interesting and counterintuitive conclusion while minimizing obvious overfitting and adhering to existing priors:
Whether for market making or order taking, PnL on the high-frequency side shows a significant negative correlation with subsequent returns of crypto assets, and the effect is not weak. We were very excited when we tried to capture it in live trading: within a 1-2 hour prediction window, the magnitude of this effect reached approximately tens of basis points, and the volume was relatively high.
The problem is that this signal almost exclusively suggests short, lacking a symmetrical reverse effect (which might theoretically exist, but our strategy iterations aim to avoid prolonged periods of continuous losses). In other words, when we are making money, the model's message is closer to: shorting is the right thing to short.
Jeff Yan: So, what exactly short? Intuitively, it should be perpetual contracts or futures. But in practice, there are two real-world constraints.
The first factor is funding rates . When this situation occurs, many experienced participants are also short; even if they focus on different underlying signals, their alpha levels may be highly correlated, and market behavior tends to move in the same direction. Funding rates will reflect and absorb this level of congestion.
Secondly, the individual targets with the most "significant and effective" signals are often extreme samples, and these targets are actually difficult to short in practice. The reasons may include insufficient liquidity, limited securities lending, and incomplete contract instruments.
Nevertheless, the overall effect remains usable. High-frequency trading naturally generates inventory, which you can hedge or internalize between strategies; even without internalization, you can apply a bias to inventory targets when the signal is strongest (e.g., minimize or avoid positions), thus making a positive contribution to overall P&L.
Regarding the idea of "abstracting a single, reusable mid-frequency short-selling strategy," we believe it lacks persuasiveness and therefore did not package it as an independent strategy. This falls into the category of alpha closest to being publicly shareable; however, its feasibility still depends on your strategy portfolio and trading process design, and it may very well be transformed into a viable alpha within a specific framework.
Corey Hoffstein: I really like this idea: short directly on futures may not be feasible because funding rates may have already priced in the signal; but absorbing this alpha by adjusting inventory bias is an alternative path and can have a substantial impact on P&L.
This reminds me of some practices in my frequency band—for example, DFA (Distributed Averaging Capital) doesn't explicitly trade momentum, but when buying value stocks, they exclude those with significantly weak momentum: instead of directly using momentum as a factor to establish a position, they wait for the negative momentum phase to subside on a completely different timescale before entering the value sector. This is similar to the logic here: instead of expressing the theoretically "orthogonal" alpha as an explicit position, it's integrated into the trading process, continuously improving results through marginal advantages and subtle refinements. This concept is very insightful.
Jeff Yan: To add something. Your example was very interesting. I hadn't encountered it before, but I have heard some "human traders" who primarily trade with large positions mention similar practices: in the crypto market, they trigger actions whenever the 50-day moving average crosses above or below another moving average ("golden cross" or "death cross"). This means their core decision-making doesn't rely on technical analysis, but they treat a certain technical condition as a trigger. I haven't specifically studied the case you mentioned, but it reminded me of a similar approach—waiting for a seemingly reliable "conditional signal" to change before executing a predetermined trading process.
Corey Hoffstein: Yes, essentially it's about waiting for a certain conditional signal to change. That's very interesting. We've talked a lot about centralized exchanges, but not much about on-chain strategies/decentralized exchanges. You mentioned that your favorite on-chain strategy, which you've since discontinued, was RFQ (RFQ) manipulation. Could you explain what it was, why you liked it so much and how well it worked, and why you stopped using it?
Jeff Yan: About six months ago, we started increasing our investment in DeFi. At that time, the industry generally believed that the best opportunities were migrating to on-chain, while centralized exchanges had entered a phase of diminishing marginal returns (overall trading activity was low). Therefore, we decided to spend more time researching DeFi. During that period, RFQs (Request for Quotes) became a hot topic. CrocSwap's Douglas recently posted some interesting tweets, and I largely agree with his point: this design is not ideal—it attempts to directly transplant mechanisms that work in traditional finance (TradFi) to DeFi, but it may not be suitable for the on-chain environment.
To help unfamiliar listeners understand, here's some background: The purpose of RFQs is quite clear—to help market makers filter out "toxic traffic" and allow retail users to directly connect with them. A retail user initiates a request: "I am a retail user, please give me a quote." The market maker returns a quote (usually better than the spread, or at least sufficient to meet the retail user's desired larger transaction size). After receiving the quote signed by the market maker, the retail user broadcasts the signed payload to a smart contract; once the contract verifies the signature's validity, the asset settlement between the two parties is completed. Essentially, it's closer to a "protocol-based OTC" mechanism.
The idea sounds reasonable and is quite common in traditional finance (TradFi): users can obtain larger-scale transactions that are less likely to be "front-loaded" by high-frequency trading, which is a better service for retail. However, in the context of DeFi, this is almost an obvious design flaw because you cannot prove that the other party is indeed a "retail investor"—on-chain anonymity is the default, and there is no KYC layer of identity verification.
To verify this assessment, we wrote a very simple Python script to initiate batch price quoting requests. The market makers did indeed provide extremely favorable quotes: the spread was only about 5 basis points, and the quotes were valid for 60–90 seconds. In most cases, from the market maker's perspective, obtaining such a trade should be attractive; the trade size they were willing to offer was also quite substantial (in the hundreds of thousands of dollars). However, this also directly exposed the mechanism's flaws: in a system where identity cannot be verified and anonymity is assumed by default, anyone can impersonate a "retail investor" and exploit the pricing mechanism to gain an advantage. This is the fundamental reason why we initially liked this type of on-chain RFQ strategy but quickly stopped using it.
Jeff Yan: Our approach is actually quite simple: we wait for price fluctuations. The crypto market is inherently volatile, and once the price changes, we broadcast the signed transaction to the blockchain. The counterparty has limited options. This strategy has a very high Sharpe ratio. Furthermore, it doesn't even require waiting for price fluctuations to trigger—it's essentially closer to a "free option" with a clear time value: you can wait until the price is close to expiration before deciding whether to submit the trade.
Jeff Yan: This also made the returns more stable. That's how we did it. Obviously, we weren't the only participants doing this (we were probably one of them), and market makers reacted quickly: they started stopping providing us with normal quotes, arguing, "You're making us lose money, you're obviously not retail investors," so they either gave us extremely wide spreads or simply stopped quoting. We could also deal with this, for example, by changing our address or changing our wallet to continue requesting quotes.
From a principle standpoint, I don't believe there's anything wrong with the strategy itself. It's more of a practical concern: the greatest value of implementing this strategy might lie in demonstrating to the market that the microstructure of the RFQ has inherent flaws—that capital and intellectual resources should shift towards a more rational mechanism. Perhaps in this sense, our "experiment" has already fulfilled its function.
I understand that many RFQ mechanisms now incorporate a "last look" for market makers, rather than allowing retail investors to retain the final decision-making power. As you mentioned, we later discontinued this strategy. I do believe it's an evolution; however, once market makers are given a last look, the core advantages of RFQs are essentially weakened or even eliminated. This is also evident in related discussions on Twitter: it's very difficult to outperform Central Limit Books (CLOBs) at the mechanism level, and I don't think RFQs can reliably achieve this in DeFi. This experience further illustrates that after repeated trial and error, we increasingly feel that this field is still immature, and the mechanism design of many protocols has not been fully considered.
Against this backdrop, we made a strategic decision: instead of "arbitrage-style adaptation" to existing mechanisms, we should build a platform that is truly geared towards retail users and can achieve decentralized price discovery.
Why switch to Hyperliquid?
Jeff Yan: The reason we decided to get involved ourselves was because we encountered a strong sense of confusion in DeFi transactions: even during the DeFi downturn in mid-2022, retail traffic remained considerable, yet users were experiencing extremely poor user experiences with protocols. They were paying high gas fees despite the poor performance of the underlying public chains, while also using solutions with flawed mechanism designs (such as RFQs). Even more surprisingly, users were still willing to continue using them; the data clearly showed that the demand persisted. Based on this assessment, we conducted further in-depth research.
I don't quite remember the exact position of the FTX incident on this timeline, but it should have been shortly before its collapse. After FTX crashed, the market narrative quickly shifted to counterparty risk: expressions like "Not your keys, not your coins," which were previously more like slogans, suddenly became the most pressing concerns for most people. This further reinforced our belief that "we should build some kind of infrastructure." But we repeatedly weighed what exactly to build: first, we needed to understand the real needs of users and the unmet needs in the market.
At that time, the market already had numerous clones of swap, with various minor innovations and aggregators emerging one after another, and different curves and formulas resulting in a huge parameter space. However, we were not optimistic about the AMM route: a significant portion of the liquidity generated by so-called "market making" was low-quality liquidity driven by erroneous or misleading narratives (such as the way "Impermanent Loss" was described, and the legacy effects of liquidity mining). Even if AMM did represent the main market demand, this track was already highly crowded, and the incremental value that launching another similar product could provide was unclear.
Therefore, we turned our attention back to centralized exchanges: What do users truly need? Where does price discovery primarily occur? Where is effective liquidity concentrated? The answers were remarkably consistent—perpetual contracts. Perpetual contracts are an extremely ingenious innovation (the idea can be traced back to traditional markets, but it has been fully developed in the crypto market). In the decentralized space, projects that truly provide this capability in a decentralized manner are almost nonexistent. While dYdX uses an order book structure, its matching process remains somewhat centralized; it's the closest approach, but that's about it. Our conclusion is: since the gap is clear, let's fill it.
The value proposition for traders is also straightforward: if you appreciate the centralized trading experience of Binance and Bybit, but are unwilling to take on the risks of custody — then Hyperliquid is trying to provide that option.
Hyperliquid recently launched its closed beta test, aiming to provide a trading experience consistent with centralized exchanges (CEXs): sufficiently narrow spreads, near-instant order confirmation, and almost zero gas costs (used solely for DoS defense). Under congestion-free conditions, its blockchain can process tens of thousands of orders per second. All actions are fully transparent and recorded on-chain, with all transactions presented as on-chain transaction records—this is our vision.
Our primary target audience is the DeFi community because educating a wider audience that "you can do without custodians and entrust your trust to on-chain contracts" is costly and not our forte; while DeFi users are already willing to use it. What we aim to do is demonstrate to them that most protocols are not serious, some are merely stopgap measures/band-aid solutions, or temporary mechanisms based on local prices—suitable for gamblers, but not for serious traders who need real liquidity and reliable price discovery. What we offer is usable liquidity and a decentralized price discovery mechanism.
Blockchain and smart contracts can inherently fulfill escrow and settlement functions, establishing verifiable trust at the mechanism level. However, promoting this concept is not easy, nor is it our forte. Our strategy is more direct: showcasing the differences through products and facts, allowing users to see that among the complex choices of protocols, most solutions are not rigorous, many are merely short-term patches (some even based solely on local prices). Such mechanisms may be more suitable for "Degen-style" participation, rather than for professional traders who require a stable trading experience and genuine liquidity.
Hyperliquid differs in that we designed it from the outset around these needs. To this end, we made significant technological innovations and dedicated most of a quarter to intensive development. Initially, we were also attracted to dYdX's approach: off-chain matching and on-chain, custodial-free settlement. However, after further analysis, we concluded that this model had a structural flaw—the degree of decentralization of a system depends on its most centralized link. Based on this assessment, we could not accept this solution because it was difficult to scale to our envisioned scale and vision.
Therefore, we return to our starting point: complete decentralization is essential. Under our constraints, this almost means there's no other choice—we must develop our own public blockchain. We don't intend to circumvent these limitations, nor do we blindly follow existing conclusions. While it's widely believed that building our own L1 blockchain is extremely difficult, our approach is to focus on resolving the consensus issue first. Tendermint isn't perfect, but it's highly mature and has undergone extensive real-world testing. We chose to build upon it and have progressed to our current stage.
Why did Hyperliquid choose to build its own L1 system and consider it a key "vertical integration" decision?
Jeff Yan: Over the past few years, L1 has become a major narrative in the industry, with many large investments revolving around it, such as the so-called L1 projects like Solana and Avalanche. The concept itself is actually not complicated: L1 refers to a blockchain ontology. In contrast, there is the "smart contract-based implementation path"—that is, implementing exchange logic through smart contracts on top of another existing L1 (such as Ethereum or Solana), with that L1 responsible for execution and settlement.
This is important because it involves a rather subtle incentive structure. Many teams are willing to "build on a particular L1," partly because it makes it easier to gain support and promotional resources from VCs/funds holding large amounts of tokens; and the value of general-purpose smart contract L1s also depends on the application ecosystem, so they naturally tend to attract developers to "deploy contracts on my platform." In contrast, the Cosmos chain based on Tendermint is closer to a self-sovereign model—lacking strong external incentives to drive its expansion, and its value does not directly flow back to a single entity.
Based on my personal experience (we've tried both paths), it's hard to imagine building a truly high-quality exchange solely using an existing L1 platform as a general-purpose contract platform, especially in derivatives scenarios and particularly in order book mode. A kind of supporting evidence is dYdX: as a recognized pioneer, it also chose to switch to its own blockchain after five years of operation. Their motivations may include legal pressure (I can only speculate), but in any case, their current architecture is clearly not fully decentralized; once the new chain is ready, the old architecture will gradually be phased out. For us, if the goal is to build a truly high-quality exchange, pursuing the L1 path is a more orthodox and scalable direction.
To give a more concrete example: if an exchange is fully implemented as a "smart contract," it will inevitably be strongly constrained by the rules of the underlying contract platform. Taking Ethereum as an example, transactions and state updates typically require user transactions to trigger. Therefore, for one of the most basic operational actions of a perpetual contract exchange—such as settling funding fees every 8 hours—if there are 100,000 open "sessions/positions" in the system, the number of storage slots that need updating simply cannot be accommodated within a single block. You would then have to design an additional mechanism for "who triggers the funding fee settlement": this might require auctioning trigger permissions, designing incentives and fee allocation, and subsidizing gas costs for the triggerer. More importantly, this process often cannot be completed atomically, ultimately resulting in a settlement "approximately every 8 hours," but the specific execution time depends on the activity level of the participants at that time, potentially delayed by several minutes. For strategic traders, it is difficult to establish a stable execution and risk control framework around this uncertainty.
These operations are considered "basic" for all perpetual contract exchanges. Implementing them on a self-developed blockchain simplifies the process significantly: the funding fee settlement logic can be written into the consensus protocol. For example, it could be stipulated that when a new block is produced and its timestamp is a multiple of every 8 hours since genesis, the system automatically triggers funding fee settlement and executes the corresponding logic. This makes the overall implementation more direct and controllable. In other words, operating a perpetual contract exchange is, in essence, closer to building an Level 1 blockchain than simply writing a few smart contracts.
Why does Hyperliquid believe that order book DEXs are superior to the "tiered fee" liquidity pool model?
Jeff Yan: The fee tiering aspect is indeed quite representative. You'll see that many AMMs are slowly "evolving" into an order book model. For many DeFi practitioners, this inevitably brings a sense of frustration—as if they are ultimately reinventing the wheel. There may be some local innovations in the process, but from a deeper structural perspective, the liquidity pool model has its "ingenuity" but also carries a sense of being "over-packaged."
This is because AMM largely originated from the computational and storage constraints of its time. Back in 2018 (when Uniswap first appeared), the on-chain arithmetic operations that could be carried were extremely limited. A transaction could often only update a very small amount of storage state, and users could not accept excessively high gas costs. AMM was a compromise solution developed under these highly limited computing power and storage conditions to achieve "barely usable" functionality.
Its operation, in a sense, relies on persuading funds to enter the pool and provide liquidity. At the same time, packaging Impermanent Loss as a marketing narrative is, in my view, a very clever but also questionable practice: emphasizing to retail users that "depositing is not a transaction, but rather earning returns"; even potential losses are explained as "impermanent" and negligible costs. Whether this narrative adequately reveals the risk is, at least, open to discussion.
From a trader's perspective, arbitrage opportunities in AMM pools are relatively explicit in mechanism: arbitrage around these pools can generate profits. While such trading is now quite crowded, it was indeed a strategy with a clearly positive expected value in its early stages. Unlike order book markets, the liquidity providers in these pools are often not professional market makers, but rather retail limited partners (LPs). Many people deposit funds into the pools and then leave them unmanaged for extended periods, relying on so-called "mining rewards" to maintain participation. Without effective management and risk awareness, their expected returns in the long run may be less than ideal, and they may even continuously and passively suffer losses from unfavorable choices.
"Liquidity mining" initially attracted liquidity through incentives; however, as these incentives diminish, some funds may remain in the pool, and participants may even lack sustained attention to their exposure. This structure itself is hardly sustainable. Some might argue that "trading volume remains high," but within your framework, this is more likely related to incentive and marketing mechanisms than a natural consequence of long-term equilibrium. In long-term equilibrium, truly sustainable liquidity may gradually decline until limited partners (LPs) are forced to raise fees to higher levels to cover the implicit costs of unfavorable choices; once fees increase, retail traffic will be further suppressed, creating a negative feedback loop.
At that level of liquidity that is "actually bearable," the results of calculating returns and risk costs are often not ideal. This is one of the fundamental reasons why I believe the pooled liquidity model is difficult to sustain in the long run.
The so-called "upgraded version" can be understood as GMX and a series of "GMX clones": they no longer rely on constant function curves, but instead use oracle prices. To ensure that oracle readings at the time of a transaction are as close as possible to the "true price," these protocols often incorporate numerous restrictions and expedient designs. However, even so, related problems frequently arise—for example, someone might manipulate prices on a centralized exchange and then profit by trading against the manipulated oracle quotes on GMX. In terms of mechanism, these methods are essentially more like "pain-relieving patches" rather than fundamentally solving the problems of price discovery and counterparty information advantage.
In my view, with the progress made in underlying technologies such as L1 consensus in recent years, we no longer need to make excessive compromises between "decentralization" and "usable transaction formats": maintaining decentralization while also supporting order book-based transactions. Based on experience, this is almost the only fully validated path that can achieve true price discovery and form a "real market".
Will self-built L1 slow down price discovery due to cross-chain and fiat currency deposits and withdrawals?
Jeff Yan: This is indeed a common problem across the entire crypto industry, not just limited to DeFi. Even when arbitrage is done on centralized exchanges, the deposit and withdrawal process still runs on the public blockchain. Once there is congestion on the chain, the transfer efficiency will decrease significantly. Our initial focus on perpetual contracts is essentially an 80/20 trade-off: the vast majority of trading volume and price discovery in the market are concentrated in perpetual contracts. Building on this, we do another 80/20 by first using USDC as collateral to establish the core pathway; then gradually introducing various stablecoins to diversify risk is not difficult. For most users, this model is smoother: after depositing USDC into the bridge/chain/contract system, they can express their opinions and trade a large number of crypto assets in one place.
Regarding the expression of viewpoints and price discovery for highly volatile assets, positions can be established and arbitrage executed as long as collateral is available. A typical scenario is spot-perpetual arbitrage: obtaining funding fees and trading the spot-futures price difference. In this structure, the perpetual side can be entirely completed on Hyperliquid without frequent movement of spot or USDC.
Of course, the cross-chain issue itself still requires continued attention. There are already many noteworthy full-chain technology directions; we have integrated some of these solutions and will continue to support their evolution. Due to resource and priority constraints, we will not personally invest in "original innovation" of multi-chain infrastructure, but the ultimate goal is clear: assets can originate from any source chain and be staked through trusted minimization or decentralized bridging methods, thus directly serving as collateral for Hyperliquid.
Currently, whether using the UI, Python SDK, or directly calling the raw API to try Hyperliquid, the end-to-end latency is roughly between 100 and 300 milliseconds; this value is not entirely certain due to the randomness of block generation. You might think this is an order of magnitude slower than Binance's order placement latency. However, the impact of latency does not accumulate linearly like transaction fees; for our core user group that we prioritize—retail users—humans can hardly reliably distinguish the difference between 100 milliseconds and tens of milliseconds.
Even if they can distinguish between them, it's usually not a key factor; what they care about more is getting "instant" interactive feedback. In typical market conditions, prices don't change substantially between 100 milliseconds and 10 milliseconds.
For most trading scenarios, the latency introduced by block time can be approximated as zero, so running a self-developed L1 cache can keep it within an acceptable range. In contrast, on-chain confirmation times exceeding 10 seconds on chains like Ethereum significantly degrade the user experience—prices can fluctuate considerably within 10 seconds. Furthermore, from the user's perspective, the benefits of latency improvements exhibit diminishing marginal returns. Regarding order book speed, the more critical metric is TPS; specifically, for decentralized exchanges, this translates to the number of orders and order cancellations that can be processed per second.
Indeed, compared to centralized exchanges like Binance, decentralized exchanges often have a throughput that is an order of magnitude lower.
However, in my view, this gap doesn't necessarily constitute a substantial problem—computing power continues to improve, and current performance is already "good enough" in an engineering sense. I don't know the exact metrics of Binance's matching engine, but assuming it can handle 1,000,000 transactions per second, while our self-developed L1 aims for 100,000 transactions per second, this doesn't simply lead to the conclusion that "Binance is 10 times better." The protocol could consciously design the upper limit at 100,000 TPS, which would still be sufficient to support price discovery for the covered assets and meet most user needs. Indeed, during periods of extreme volatility, some frequent reorders might be delayed by several blocks, or even ten blocks, before being processed on-chain.
However, similar phenomena can occur in centralized exchanges as well. Therefore, although there may be a difference of "one order of magnitude" in numerical terms, it does not necessarily correspond to a cost consequence of "one order of magnitude".
Conversely, if the comparison is made to a general-purpose smart contract chain, whose throughput might only be 10 TPS, then the difference between 10 and 100,000 becomes decisive. Furthermore, this isn't just a TPS issue; it also involves engineering trade-offs. dYdX has consistently emphasized the off-chain order book path—as far as I understand it, even in version 4, their plan is still for validators to run their own order books, only putting settlements on-chain.
In theory, this might bring an order of magnitude improvement in TPS, but at a considerable cost. It would significantly expand the MEV space, while also making "what is fact" more ambiguous—in my view, the order book should be considered part of the system state; placing it off-chain makes the overall system more difficult to reason about and verify. Therefore, I prefer to accept a few orders of magnitude performance loss in exchange for a significant improvement in robustness, resilience, and transparency; in my opinion, these gains far outweigh the costs.
One more point: We also conducted a systematic survey of the latest consensus research. It's foreseeable that consensus will become a major bottleneck in the system, but there have been many new achievements in recent years, and the directions are very valuable. Tendermint is indeed relatively "old," with its core ideas dating back at least ten years. The academic community has accumulated extensive experience in related issues; however, many newer consensus protocols have not yet reached production-ready levels. Therefore, we have currently chosen Tendermint as a phased solution, but almost everything except the consensus mechanism is developed in-house: not relying on the Cosmos SDK, but using Rust to implement high-performance components from scratch.
Meanwhile, we have completed the relevant research and will continue to follow up. For us, once a better, production-ready consensus protocol emerges, the migration cost of replacing Tendermint with the new solution will not be high; when conditions are ripe, we expect to achieve at least a 10x performance improvement. We remain optimistic about the technology roadmap: both our self-developed components and the PoC (proof of concept) are ready, and benchmark data shows good performance. We will not proceed with our current marketing and user growth efforts unless we confirm that the platform can handle the target workload.
My focus is on control, will, success, action, and determination—this aligns perfectly with our "get things done" approach and sets us apart from many other teams. Our goals are often not "conservative": for example, "Can we create a Binance without sacrificing user experience while maintaining complete decentralization?" Most people might think this would take at least five years. But we don't presuppose conclusions; instead, we start with first principles and engineer them into reality. This willpower and execution are equally crucial in trading: you need both the desire to win and the motivation to profit; lacking either makes it difficult to go the distance. Now, as we build a larger system, this "chariot-like" approach is even more important—the market truly needs it, but few are willing to take on the responsibility, partly because it's inherently difficult. Our choice is straightforward: we'll do it.
