Introducing Hubble Exchange a Purpose-Built Chain for Perps



Hubble Exchange is a trustless and composable trading system for perpetuals. Engineered at the intersection of derivatives and application-specific VMs. Hubblenet is a perp-specific chain; customized to embed a fully Decentralized Limit Order Book and its Matching Engine.

These perp-specific customizations enable Hubblenet to be the foundation of a next generation on-chain trading system.

Tech Specification

  • We forked Avalanche’s subnet-evm repo — which constitutes all the boilerplate for running an EVM app chain.
  • We deploy our solidity smart contracts that constitute all the business logic around depositing/withdrawing margin, placing orders, accepting matched orders, paying fees, liquidations etc.
  • As users place orders, the orders are confirmed and indexed locally in the validator node. In addition to open orders, all the information about open positions, margins, pending funding, and margin ratio is also maintained within the indexer.
  • Within the `buildBlock` function (called by the consensus layer whenever a validator is chosen as the block producer) and before the transaction bundling starts, we place a hook called `RunBuildBlockPipeline`. This hook fetches data from the indexer and executes steps in the following order:
  • Fetch Active markets
  • Fetch open orders
  • Evaluate open positions for liquidations in all markets
  • Run liquidations
  • Run the matching engine
  • Relay the above operations as local txs
  • Continue the transaction bundling process as usual

In summary, we forked the block-building process and plugged in our order-matching system to allow for the matching engine to be as decentralized as the validator set of the hubblenet.


Ethereum uses precompiles to efficiently implement cryptographic primitives within the EVM instead of re-implementing the same primitives in Solidity. For instance, some of the pre-compiles are included: ecrecover, sha256, modular exponentiation etc. Avalanche introduces the concept of a stateful precompile — precompile that adds state access. These work by providing direct reads/writes to levelDB which is the underlying database powering Ethereum and most other EVM-based chains.

By moving the most complex computational parts of a multi-collateral and cross-margin exchange to a stateful precompile while assigning a fixed gas cost to the operation, we were able to build a system where gas requirements for various operations like place orders, match orders, perform liquidations remains constant even as new markets/collateral are added.

Multiverse of OrderBooks

Hubblenet has been built in a way that supports more than 1 order book. It is possible to plugin more order book sources as long as at least 1 validator in the network wants to support matching orders on the book. All the order books share liquidity with each other. This allows for the following possibilities:

  • Private orders: Relay orders privately to participating validators
  • Just-in-Time orders: These orders will be revealed only when they are matched
  • Gasless orders
  • Broadcast orders on an agnostic data availability layer: Traders can relay signed orders on a cheap data availability layer and participating validators can pick these orders and match them on the hubblenet

We see a validator economy emerge around these possibilities for e.g. a validator who chooses to support private orders can charge a premium to provide that service. No matter what, Hubblenet will be the layer of settlement.

OrderBooks Diagram

Discussion on throughput

Since pre-compiles bless us with the ability to move all heavy operations to GoLang instead of solidity; this means that the throughput on the hubblenet is constrained not by the block gas limit but only by the LevelDB throughput, estimated at 164,000 ops/sec (writes) and 129,000 ops/sec (reads). See benchmarks here. Now assuming even if placing an order or matching an order updates 10 storage slots, that gives us a throughput of at least 16,400 txs/sec. However, we would be dishonest if we were promising such a throughput for hubblenet. The reason is that in decentralized systems the bottleneck is not db IOPS but consensus — (including but not limited to) block propagation. So even though optimizing the hubblenet down to the core with precompiles can work today, it will however cause the block sizes to increase tremendously which as we all know is not good for decentralization. Hence, we plan to take a conservative approach and gradually migrate business logic to pre-compiles as we grow and see more adoption and figure out integrations with data availability layers to allow for faster light clients even with bigger block sizes.


Composability, the lifeblood of DeFi, underscores its disruptive potency. For DeFi, composability isn’t just a killer feature; it’s the foundational bedrock on which the financial future will be built. For that reason, we took a very conscious decision to build the Hubblenet as an EVM chain. So, exposing a multi-collateral/cross-margin perps exchange as money legos — opens the playground for applications like fully decentralized leveraged tokens, automated hedging strategies, and algorithmic trading strategies to be built on the Hubblenet. The Hubble Exchange DAO is happy to incubate developer teams who would like to build such products.

USDC is the choice of gas token on hubblenet. Traders will be able to bridge native usdc from any chain to the Hubblenet. This means since gas is being paid in usdc, validators on hubblenet will be earning real yield to validate the subnet. It also makes building dapps on the hubblenet more straightforward and agnostic of any specific ecosystem.


By customizing the block-building process of our chain and embedding a Matching Engine within it, we have achieved truly Decentralized Matching. This is a monumental feat, representing a significant advancement in the realm of on-chain perps. That said, we are only beginning to scratch the surface of the cutting-edge features and perp-specific optimizations that are unlocked at the intersection of app-specific chains and perpetuals; efficient throughput management through stateful pre-compiles, private, just-in-time, gas-less orders as well as the potential for further scalability by integrating a data availability layer to host the order book.

For traders today, the mention of a trading system being “on-chain” invokes a certain preconceived notion of there being some compromise, whether that is on UX, cost or latency. Hubble Exchange V2 defies this belief and displays that a trading system has the potential to be truly decentralized, yet uncompromising.

Hubblenet is primed to be the foundation of an unparalleled on-chain perps experience.

Welcome to the next generation of on-chain perpetuals. Welcome to Hubblenet.

Testnet is Live

Hubble Exchange’s Orderbook testnet is live on:


Test it out in three simple steps:

  1. Claim testnet USDC through the faucet at:
  2. Connect wallet and switch networks to the Hubblenet, you can do this easily inside the app!
  3. Trade!
Recent Reads