We built the perp DEX everyone said was impossible

Perps are a solved product with an unsolved infrastructure problem.

To build the ideal perps DEX, you need three things at the protocol level:

fully on-chain execution
a true, granular CLOB
low gas + fast updates

The problem is that every generation of blockchain infrastructure made at least one of those impossible.

On ETH L1, 12-second blocks meant you couldn't do on-chain matching. So dYdX v2 put the CLOB off-chain and only settled on-chain. Off-chain, one point of failure.
On L2s, you had faster blocks but not enough gas to run a CLOB. So builders like GMX switched to a perp AMM instead. Not a CLOB, worse for traders.
On app-chains, you can run a CLOB, but you have to give up decentralization and network benefits, and you have to trust the sequencer or the "decentralized" validator set.
On Solana SVM, you have a fast L1, but it's not EVM, so on-chain matching is restricted. Builders were pushed toward DLOBs, or more recently, prop-AMMs with a single market maker.

Every path forced a compromise. Until Monad.

Perpl is the first perps DEX that doesn't have to choose. Fully on-chain execution, a true CLOB, and the gas efficiency to make market making viable. All on a decentralized general-purpose L1.

This is the full story of Perpl. The team, the tech, and why it matters.

Part 1: Why Us?

My co-founder, AC, and I have been building together for over 15 years.

We're ex-FPGA developers. We spent decades building hardware design tools for systems that simply cannot fail. Space missions. Deep-sea drilling. Nuclear reactors. Environments where a bug doesn't mean a bad quarter. It means people die.

We then went on to build some of the most complex DeFi and cryptographic primitives ever deployed on-chain.

That track record is why Dragonfly led our $9.25M raise, with Mirana, HashKey, L1D, CMS, BHD, and others. Because of what we'd already shipped.

And now we're leading a team of 10 with one goal: build the endgame perp DEX that nobody thought was possible.

Part 2: What is Perpl?

The correct mental model for Perpl is if Uniswap was a Perpetual Exchange with a CLOB.

Monad gave us what no chain could before: speed without sacrificing decentralization or EVM compatibility. So we built the thing everyone said couldn't work on-chain, a real CLOB with real market making.

It costs 100k gas for market makers to post AND cancel their orders. At the time of writing (MON at $0.02), that's roughly $0.0001. 10,000 post-and-cancels for $1.

Perpl today is 2x as performant as DyDx V4, without running our own chain. At 500M gas per second with 20% blockspace, we can process 1,000 post-and-cancels per second. Given that Monad has been averaging ~3% gas utilization over the past 4 months, with a realistic headroom of 95%, we can push nearly 5,000 post-and-cancels per second. And that performance only improves as Monad increases its gas budget.

Same blockspace as the rest of Monad's DeFi ecosystem. Native collateral support for every ERC-20. Fully composable. Fully extensible. Nation-state resistant. No centralized bottleneck, ever.

Part 3: How it's built?

The north star from day one was to make Perpl the most gas-optimized DEX for market making. Unlike app-chains or off-chain DEXs, every post and cancel on-chain incurs gas costs. That's a real marginal cost someone bears on every single transaction.

Here's how we optimized for gas.

Data Structures

The order book design consists of two bit-index trees and a partition list map. The mapped linked list allows for efficient insertion and deletion of orders in constant time O(1) on the book, following price-time priority. Using pointer manipulation, we can also efficiently change order price levels, expiration, and lot size.

There are two bit-index trees, one to track orders and one to track price levels. The order ID tree is 2 levels deep (256^2), allowing a maximum of ~65k orders per market. The price tree is 3 levels deep (256^3), allowing a maximum of ~16M price levels. For perspective, you can place Bitcoin orders from $0 - $1.6M at $0.10 levels without problems. You can find the highest active bid or the lowest active ask price level in constant time, with a maximum of 3 slot reads.

EVM Quirks

The EVM has many interesting quirks that are important to know when writing a product of this scale, especially how it prices reads/writes to the chain. The obvious optimization is to minimize reads/writes on-chain, but that’s hard to do if you want your DEX to also be fully on-chain. However, there are some tricks we can use to optimize. As seen in the table below, writing to an empty slot is very expensive. Writing, clearing, and writing again is more expensive than overwriting the same slot.

Another interesting quirk is the difference between reading hot data and cold data. If you organize your data in a uniform and predictable manner (e.g., an orderbook), you can use eth_createAccessList to warm up slots you plan to access, thereby drastically reducing the cost of reading from the chain.

Algorithms

Virtualized Funding

Doing things naively on-chain, even with unoptimized data structures and EVM utilization, can be prohibitively expensive. For example, explicitly settling funding payments on-chain for every funding event incurs significant gas costs. This is because perpetual contracts can have hundreds to thousands of positions concurrently.

To address funding issues, payments must be made virtually. This means that the effect of the funding payment settlement is visible after a single transaction, permitting all perpetual contract users to continue as though the payments had settled, without having to update the individual state of each of their positions in the contract.

Perpl debuts a novel solution to efficiently settle funding payments for all positions in a perpetual contract, virtually. It is based on adapting the staking algorithm and virtual orders to eliminate the need for explicit periodic funding payment settlement.

Inverting Orders

Depending on the strategy, market makers may have orders on both sides of the order book, profiting by making the spread. To handle this scenario efficiently on the chain, where a market maker’s position switches between long and short, we created a method to invert positions.

This prevents deallocation and reallocation cycles of position memory, reusing the same position memory for a position transitioning from long to short or vice versa. Furthermore, computations are reduced from having to compute a position decrease/close, then a position creation, when an order implying this change is matched, to simply computing a position invert.

Change Orders

Another important feature is change orders. Market makers frequently employ a post-cancel strategy: they post multiple orders, cancel them shortly thereafter, and then post new ones. This is very inefficient in on-chain implementations if the system naively allocates, deallocates, and finally reallocates slot state to realize the post-cancel-post sequence over one or more blocks.

Zooming out and realizing that market makers are really just changing their orders allowed us to innovate and create a change order operation that permits any combination of price, lot size, or expiry block to be changed in one efficient transaction. In this way, the state does not need to go through costly reallocation cycles. Furthermore, the order memory state is never deallocated to zero after initial use and is efficiently reused with a unique order ID counter that immediately selects the lowest available order memory address.

This means that the EVM's most expensive operation, a state slot transition from zero to non-zero, is performed only once in the exchange's lifetime for each order memory slot. Thereafter, the allocation is the much less expensive X-to-Y transition, where both X and Y are non-zero.

Bit Packing

The final piece of the puzzle is bit packing or maximizing the amount of information that can be stored in a 256-bit slot. Additionally, to minimize reads, frequently queried information is packed together, facilitating access pattern optimization. Most variables don’t ever need to get as large as 2^256 (1.1579209e+77), so a lot of care and thought (rounding, overflow) goes into minimizing each variable's container size to pack data most efficiently.

The result: the most gas-efficient on-chain CLOB ever built.

Part 4: Why On-Chain?

The liquidity flywheel

At the end of the day, traders judge a perp dex on one thing: execution quality. Deep books and tight spreads.

Appchains can offer cheap quotes, but cheap quotes on an island don't build deep liquidity. Traders need diverse collateral, composability with lending and hedging protocols, and infrastructure they can trust without a centralized sequencer.

On Perpl, users can seamlessly do things like hedge their delta on the same chain, use LP positions as collateral, borrow against their margin, and more.

Perpl gives market makers the gas efficiency of an appchain without the trade-offs. O(1) operations, change orders, time in force (TIF), 100k gas per post-and-cancel on a decentralized L1 with the full Monad DeFi ecosystem behind it.

Lower cost per quote, more tools to manage risk, more collateral options, more reasons to stay.

Tighter spreads, deeper books, better fills, more traders.

Built for autonomous capital

Perpl is the first time anybody can fork the entire perps exchange. Full orderbook state, full blockchain state, locally via hardhat or foundry and simulate against it.

Traders can backtest strategies against real orderbook data. Protocols can test integrations before deploying. Agents can verify before executing. No off-chain orderbook and no appchain can offer this.

If you can't fork it, you can't trust it.

The moat autocompounds

Every time Monad increases its gas budget, Perpl's throughput improves. Every new DeFi protocol on Monad is a potential composability partner. Every new ERC proposal is integrated seamlessly. Every new EVM tooling improvement benefits Perpl automatically.

Appchains have to build everything themselves. Perpl inherits the entire EVM ecosystem's innovation for free. The longer the timeline, the wider the moat.

Perpl is built for what finance is becoming, not what it was.

Part 5: Why now?

In March 2025, Hyperliquid's validators voted to delist a token and force-settle positions at a price they chose. Traders on the wrong side lost money not because of the market, but because of a governance decision made by the team that runs the chain.

That's not decentralization. That's a CEX with extra steps. This wasn't a one-off. It's the inevitable outcome of an architecture in which the exchange, validator set, and the bridge are controlled by the same entity. When things break, the people who run the chain decide who gets paid. The fact that it's "on-chain" doesn't matter if the chain itself is the single point of failure. And it keeps happening. 2 out of 3 bridge multisigs. Appchains where the sequencer is the team. Off-chain orderbooks where you can't verify a fill until after the fact. Every cycle, the same lesson: infrastructure that looks decentralized but isn't will eventually act like it isn't.

Meanwhile, the demand side has never been stronger.

On-chain trading volume is climbing every quarter. Stablecoin market cap is at an all-time high. TradFi is actively moving execution and settlement onto crypto rails. Funds that wouldn't touch DeFi two years ago are now asking where they can trade with full transparency and no counterparty risk.

And then there are agents. Autonomous trading systems are growing exponentially, and they have a specific infrastructure requirement that Perpl is uniquely positioned to meet.

More capital will flow on-chain. More institutions will demand transparency. More agents will execute autonomously. More protocols will compose with each other.

And Perpl scales with it all.