hexbook is a central limit order book running inside one NEAR smart contract. That makes it transparent and non-custodial, and also slower and more constrained than a centralized exchange. This page lists the limits we know of.

​
Speed and ordering

​
Taker orders

  • At most 128 maker orders per taker order (max_fills, default and cap). With the NEAR Intents relay’s 300 Tgas, about 40 is the practical limit. A large market order against a deep, fragmented book fills partially and the rest is refunded.
  • Gas decides where proceeds go. Each payout costs ~22 Tgas. Payouts that do not fit in the gas you attached are credited to internal balances in hexbook.near instead of being sent to intents.near, including the taker’s own proceeds. Claim them with claim_balance. See Placing orders.
  • One token per transfer. An order sends exactly one token; there are no multi-leg or cross-book orders.
  • No self-trade prevention. A taker order can fill the same account’s resting orders.

​
Maker orders

  • Per-book limits: 200 resting orders per owner and 500 orders per price level.
  • Dead orders still take slots. Expired orders, and orders killed by cancel_all / bump_epoch, count toward both limits until something closes them: a trade, a batch cancel or prune. A maker that only bumps its epoch fills its 200-order cap in a few requotes, after which new placements are skipped with owner_cap. Cancel your dead orders in the same batch. See Build a market maker.
  • Live-price scan is bounded. To decide whether a placement would cross, a batch scans at most 128 orders per side for the best live price. Past that, a dead order counts as live, which can cause spurious cross skips.
  • Batch size: at most 64 cancels and 32 placements, and the batch’s logs must fit in 16 KiB. A bigger batch panics.
  • Batch placements never take. A placement that would cross the book is skipped, not executed. To take liquidity, send a taker order.
  • Same-block duplicates. Two orders of one maker with the same side and price created in the same block have the same hash. The second is skipped (duplicate) in a batch and panics from a transfer.
  • Prices must be on the tick and amounts at least the book’s minimum. Off-tick or too-small placements make the whole batch panic.
  • Fixed timestamps. Expiry is checked against the block timestamp, so it has block granularity. Your clock must be in sync, or expires_at may already be in the past when the batch runs.

​
Fees and limits that can change

  • Protocol fees are set per book by the operator and can change at any time, up to 1% per side. A change applies to resting orders too.
  • Minimum order amount and tick size can change. Existing orders stay, but new orders must follow the new values.
  • Referral fees are chosen by the taker’s frontend, up to 1% in total, on top of the protocol fee.

​
Operator powers

The contract has administrative roles (DAO, OrderBookManager, Upgrader, PauseManager):
  • Pausing. Trading (mt_on_transfer), maker actions (on_auth) and prune can be paused separately. While on_auth is paused you cannot cancel orders, withdraw or claim through intents, and your resting orders stay in the book.
  • Closing orders and books. The operator can close any order (owner_close_order), with its balance credited to the maker’s internal balance in the book, and remove empty books.
  • Upgrades. The code can be replaced through approve_contract_code_hash and deploy_and_migrate. An upgrade can change any behaviour on this page.
  • Placing for others. Accounts with the OwnerOverride role can place orders owned by another account (meant for escrow contracts).

​
Tokens and storage

  • Only NEAR Intents tokens. The book accepts deposits only from intents.near and pays out only to intents.near balances. Tokens must already be in your intents.near balance.
  • One variant per asset. Each book trades one specific token id. Other bridged versions of the same asset are different tokens and are not accepted.
  • The contract pays for storage. Makers do not deposit NEAR for their orders. The per-book minimum order amount and the per-owner cap are the only protection against storage spam.

​
Data

  • No trade history on chain. Views show the current book, balances and orders, not past trades. History lives only in the event logs of hexbook.near’s receipts: you need an indexer or the HEX API. See Indexing.
  • volume counts dead orders. The volume in get_active_pairs and get_volume includes dead orders until they are closed, while get_orderbook hides them.