HyperEVM: How to optimize for a high throughput exchange

That's not the answer I wanted, but the product still had to be built. How could we make an RFQ exchange fast and affordable on HyperEVM?

Our RFQ combo vault system brings together RFQ trading, outcome markets on HyperCore, and smart contracts on HyperEVM. HIP-4 supplies the underlying fully collateralized outcome contracts, which our combo system combines into multi-leg positions.

We spent weeks researching and testing on HyperEVM to understand the chain as much as we can. The resulting design reduces the work required for each trade, batches related actions, and routes transactions according to how quickly they need to execute. In this article, I'll go into detail on one of the optimizations we did around gas spikes on HyperEVM.

Problem: Limited block space and gas spikes#

HyperEVM has a limited gas budget. Its small blocks allow up to 3 million gas roughly every second, while big blocks allow up to 30 million gas roughly every minute. This gives applications frequent confirmations and room for larger transactions, but limits how much work can execute in each block.

HyperEVM is part of Hyperliquid’s execution environment and shares its HyperBFT consensus. It uses HYPE for gas and supports EIP-1559 under the Cancun ruleset, without blobs.

For a trading application, the challenge is that everyone seeking a fast confirmation competes for the same small-block capacity. Every storage write, repeated call, and separate transaction consumes some of that budget. Frequent blocks help with latency, but throughput still depends on how much work each trade requires.

Under standard EIP-1559 parameters, the gas target is half the block limit. Usage above that target raises the next base fee; usage below it lowers the fee. A full block raises it by up to 12.5%, while an empty block lowers it by up to 12.5%. These changes compound. The illustration below shows the multiplier relative to the starting base fee after repeated 12.5% increases.

For a generic 200,000-gas action, starting at an illustrative 0.1 gwei, 59 consecutive full blocks would raise the base fee to about 100 gwei. At a HYPE price of $80, the base-fee component would cost about $1.80. The same action would cost $18 at a base fee of 1000 gwei, excluding any priority fee.

Note: these are daily average gas fees. Individual blocks can easily spike up to over 1000 gwei.

As you can see, when the network congests, it makes it very unattractive to sponsor gas as the gas fee can easily overtake the transaction amount itself.

Our Solutions#

Reduce the onchain work per trade#

We start by keeping persistent storage small. Data that can be supplied and verified when needed does not have to be written into storage in full for every position. This reduces repeated writes and leaves more block space available for useful execution.

At settlement, we read the underlying outcome results from HyperCore through native read precompiles. Hyperliquid documents these reads as reflecting the latest HyperCore state when the EVM block is constructed. This lets our settlement logic use the underlying market results directly.

Reducing gas per operation helps twice: each trade costs less to execute, and more work can fit into the available block space.

Batch related actions into one transaction#

Separate transactions repeat overhead. An ordinary EVM transaction starts with a 21,000-gas intrinsic cost before calldata and execution. Combining related calls removes repeated transaction costs and can make repeated access to shared state cheaper.

As a simple illustration, ten separate 80,000-gas transactions consume 800,000 gas. Removing nine sets of 21,000-gas overhead brings that to 611,000 gas before accounting for the batch wrapper, calldata changes, and shared-access savings. Actual savings depend on the operations being combined.

We apply batching in two places:

• Deposit and trade: We combine both operations in one transaction, configured so that a failed trade reverts the deposit as well.
• Settlement: We process multiple eligible tickets together, spreading transaction overhead across the batch.

For deposit and trade, the all-or-nothing behavior comes from requiring the relevant calls to succeed. Multicall3 supports that behavior, as well as optional-failure calls, so the configuration matters.

Match the block type to the urgency of the work#

HyperEVM produces two types of blocks:

The two block types have separate transaction queues. This gives developers access to both frequent confirmations and larger blocks, depending on the operation.

Therefore we can route actions according to their own time sensitivity:

Separate senders keep both lanes available. HyperEVM selects the lane at the address level, so this lets us process urgent and non-urgent work concurrently.

We compare the fee estimates for both lanes when scheduling eligible work. Hyperliquid exposes separate estimates for the next small and big blocks, making the comparison straightforward.

This gives us flexibility when demand crowds the small-block lane. Routing accounts for both the fee difference and the acceptable delay, since neither price nor inclusion time is guaranteed by the block interval alone.

Initial thoughts on Elysium#

An L2 chain built on top of HyperEVM makes a lot of sense for high-throughput applications like this. Elysium is a good start, it promises to give Hyperliquid apps more room to run: it targets 100 ms blocks and 300 million gas per second, with HYPE as gas and settlement back to HyperEVM.

For our HIP-4 Combo exchange, we could keep quoting offchain and move the vault and trade-acceptance contracts to Elysium. That would give accepted trades more execution capacity. Combo settlement could then use Elysium’s planned HyperCore reads to check the underlying HIP-4 outcomes, provided those reads expose the resolution data we need.

However it is too early to tell with the chain being just launched on November 9th, and its HyperCore read/write integration is scheduled for roughly four weeks after mainnet. Elysium also starts with a single sequencer and permissioned validation. Its planned HyperCore reads also rely on sequencer attestations, so a move would change our trust assumptions. We still have to observe whether it can actually reliably accept trades, read resolved outcomes, and pay out Combos at a lower cost.

Originally published on X.