DEEPSTATEDOCS
Mechanism

Onchain Order Book

Pool identity, epochs, matching, settlement, and permissionless market creation.

Implemented in source

DeepstateV1 is a multi-pool order-book engine backed by radix trees. It is non-upgradeable: deployment creates one implementation contract with no proxy or upgrade entry point.

Pools and books

A pool is identified by the hash of two token addresses sorted from lower to higher address. No owner call creates or approves a pool. The first valid order initializes the current book for that pair.

Each pool advances through epochs as its nonce space is consumed. A book identifier includes the token pair and epoch, which isolates ownership and tree state across historical books.

ObjectIdentity
Poolkeccak256(token0, token1)
Bookkeccak256(token0, token1, epoch)
Orderkeccak256(bookId, packedOrder)

The token pair must be sorted. Client software should derive the canonical order before calling the engine.

Order representation

A resting order is packed into one 256-bit word containing:

  • a signed 32-bit price tick;
  • a 160-bit base quantity;
  • a 32-bit nonce assigned by the contract.

The engine separately records the order owner and whether it is a bid. Orders at the same price preserve time priority through their nonce-derived sort key.

Matching

The best executable liquidity is on the rightmost path of each radix tree. Matching can consume an entire crossing subtree in aggregate when its quantity fits inside the incoming order, avoiding a visit to every leaf. Partial paths are updated and materialized as required by the tree's right-spine accounting.

Matching complexity still depends on the shape and amount of liquidity consumed. “Bounded radix navigation” should not be read as a claim that every multi-maker fill has constant gas.

Settlement

fill settles one order. fillRoute mutates multiple books and nets token deltas before settlement. The engine uses transient storage for route balances and a transient reentrancy guard.

The engine assumes standard ERC-20 behavior. Fee-on-transfer, rebasing, callback-heavy, or otherwise inexact tokens are outside its accounting model and should not be listed by a responsible interface without dedicated validation.

Custody

The contract holds only the collateral required by resting orders and filled proceeds that makers have not claimed. A maker cancels an open remainder or claims a filled order by submitting the original packed order. The engine verifies ownership and transfers the owed tokens.

“Non-custodial” here means users do not give an operator discretionary control over balances. It does not mean assets never reside in a contract.

Permission boundaries

Anyone can interact with a compatible pool. The router owner cannot prevent pool initialization or matching. The owner can configure a global protocol fee and one optional top-of-book hook per pool.

The deepstate.sh listing policy is separate from contract permissioning. An unlisted pool remains usable directly or through another interface.

On this page