Gas Optimization in Perpetual Contracts

Every basis point of gas overhead is a tax on your traders. We spent six months finding it all.

Why gas optimization matters differently for trading protocols

For many DeFi applications, gas optimization is a quality-of-life improvement. For a trading protocol, it's existential. If opening a position costs $15 in gas, you've eliminated retail participation. If maintaining and closing a position adds another $20, you've made the protocol unusable for anyone trading in sizes below a few thousand dollars.

The competitive landscape makes this worse. Centralized exchanges have near-zero transaction costs for most operations. Every dollar of unnecessary gas overhead is a reason for a trader to stay on Binance rather than use your on-chain product. Gas efficiency isn't just engineering hygiene; it's a direct product requirement.

Storage layout optimization

EVM storage is the most expensive resource. Reading from and writing to storage slots costs significantly more than computation. The first optimization pass involves packing data structures to use as few storage slots as possible.

A storage slot is 32 bytes. Many data types — addresses, booleans, small integers — are smaller than that. By packing multiple fields into a single slot, you can read or write several values with the cost of one storage operation. Solidity does this automatically for state variables declared sequentially in some cases, but complex structures require manual layout planning.

Function visibility and inlining

Internal functions that are called only once don't need to be separate functions. Inlining them saves the call overhead. External versus public visibility matters: public functions have additional calldata decoding overhead that external functions avoid when called internally. These are small savings individually, but they accumulate in a hot code path that runs on every trade.

Loop optimization

Every operation inside a loop multiplies. Array length caching, memory variable reuse, early exit conditions — all of these reduce the gas cost of loops. In a perpetual protocol, the most critical loops are in position valuation and liquidation price calculation, which run on every relevant transaction.

The results

After six months of optimization, Aark's core trading operations are significantly cheaper than our initial implementation. The specific numbers are in our public audit reports. The practical effect is that the protocol is viable for traders in sizes from a few hundred dollars up to institutional size, without gas costs dominating execution economics at either end.

Calldata optimization

Calldata — the data passed to a smart contract function call — costs gas proportional to its size. Zero bytes are cheaper than non-zero bytes. Function signatures can be chosen to minimize the cost. For high-frequency operations like order placement and cancellation, calldata optimization compounds significantly.

One underutilized approach is encoding related data tightly into packed uint256 values rather than using separate parameters. Instead of passing eight separate parameters to a place-order function, pack them into two or three uint256 values and decode on the other side. The gas savings vary by use case, but for our core trading functions, this approach reduced calldata costs by around 15% compared to naive parameter passing.

Off-chain computation, on-chain verification

The biggest single lever for gas reduction in a perpetual protocol is moving computation off-chain and only verifying results on-chain. For operations like P&L calculation and liquidation price determination, the computation is complex but the verification is simple: you can prove the result is correct with much less work than it takes to compute it from scratch on-chain.

This is the same principle behind ZK proofs, though we use a simpler verification approach for most operations. The matching engine runs off-chain, produces signed match results, and the contract verifies the signature and executes the settlement. The computation savings are significant — what would require substantial gas to compute on-chain can be reduced to a signature check.

When we published our gas cost breakdown after launch, several teams reached out to ask how we achieved the numbers. The honest answer is that it wasn't one clever trick — it was six months of systematic optimization across every hot code path. There's no shortcut. You have to instrument every function, identify the expensive operations, and work through them one by one.

The ongoing optimization work

Gas optimization isn't a one-time project. The EVM evolves, new opcodes get added, and the Solidity compiler improves its output with each version. We review gas costs on every significant protocol change and run the full test suite with gas reporting enabled as part of the CI pipeline.

The most impactful recent change was a refactoring of the position storage layout that reduced the average cost of position updates by approximately 12%. It took two days of work and required careful regression testing. Worth it — at the trading volumes we're seeing, that 12% reduction translates to meaningful savings in aggregate gas costs for traders.