Reminder: the Hyperliquid dev team does not profit from increased activity as it does not collect trading fees. On the contrary, it is entirely self-funded with exponentially increasing burn. There is not a single private investor.
>$25M of revenue has gone back to the community through HLP. Another project could have easily pocketed some or all of these profits.
What’s the point of all this? To build something that really matters. When finance moves onchain, it will bring trillions of dollars of value to billions of users. It won’t move for a half-baked system, but the Hyperliquid L1 has a shot.
Some users think that Hyperliquid is already a complete platform. This is flattering, and the Hyperliquid community is indeed one-of-a-kind!
But as someone spending most waking moments pushing Hyperliquid to its full potential, I’m confident that there is a long way to go. In particular, the following are all complex, multi-phase undertakings: 1) deploying the native EVM 2) seamlessly integrating the EVM with existing native components (e.g., order books) 3) fully decentralizing the network
On top of that, the following are continuously being improved: 1) high TPS and low latency L1 with HyperBFT consensus 2) performant financial primitives including fully onchain spot and perp order books, vaults, oracles, automated liquidity and account abstractions 3) state-of-the-art and community-owned order book liquidity via HLP
When you see a 100x, you drop everything to make that a reality. Factors of <2 are insignificant. Big things take time to build, but nothing else is worth building.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
1/ There's a lot of edge in building a production crypto HFT system the right way.
The abstractions should be rich enough to prevent careless mistakes but not too rigid to work with.
I converged on these after countless hours of building, debugging, and rewriting code 🧵
2/ Let's focus on a concrete example: How do you deal with continuous quantities?
Doing math in code with raw numeric types is error prone. Multiplying the price of one symbol by the size of another is sure way to blow up your strategy.
Just be careful? Nah, we can do better.
3/ A pervasive feature of our trading system is the concept of "units."
The first idea is to have separate types for Price, Size, Notional, etc.