TTorna

An on-chain index primitive for Solana

Sorted on-chain state that writes in parallel.

On Solana, keeping state sorted usually means one giant account that serializes every write, plus an off-chain indexer to read it back. Torna is a B+ tree with one node per account, so writes that land in different leaves commit in the same slot. No slab, no indexer.

Live on devnet · SDKs on npm and crates.io · internally reviewed, external audit pending

The moat

Why the writes run in parallel

The usual on-chain book keeps each side in one slab account, so every order on a side takes the same write lock and serializes, one per slot. Torna puts each B+ tree node in its own account, so orders that fall in different leaves touch different accounts and Solana commits them in the same slot. A deep book spreads its price levels across many leaves.

The usual bookone slab account per side$100$180$260one slabone account, one lockslot 1slot 2slot 33 orders, 3 slotsone shared account serializes themTornaprices that fall in different leaves$100$180$260leafaccount Aleafaccount Bleafaccount Cslot 13 orders, 1 slotdisjoint accounts run in parallel
Three makers whose prices fall in different leaves. Left, the side's one slab serializes them across three slots; right, Torna gives each leaf its own account, so they commit in one slot. Adjacent prices in a sparse book share a leaf and still serialize, and matching itself is always serial.
4.6-7.1xmore committed tx/slot when maker writes
land in different leaves vs. one shared leaf

Measured on a single-node solana-test-validator, the real Agave banking stage, via torna/bench. Devnet is shared and noisy, so the controlled number is the honest one. This parallelizes book maintenance, not matching: top-of-book is price-time serial by definition, and nothing can change that.

Build anything sorted

Anything that needs sorted state with many concurrent writers maps onto one tree. You choose what the key and value mean.

Order books

Price-time priority, parallel maker quotes (matching stays serial), real escrow.

Liquidation queues

Sorted by health; keepers pop the worst, borrowers update in parallel.

Leaderboards

Top-N with cheap reads and concurrent score updates.

Governance

Sorted stake or votes, queryable on-chain without an indexer.

Expiry queues

Ordered by deadline; the soonest to expire is the leftmost leaf.

Your sorted index

Generic key to value, value up to 128 bytes per entry.

Proof it works

We built a full order book on it

TornaDEX is a central limit order book built entirely on Torna: real SPL-token escrow, place, cancel, and match as real on-chain transactions, live on devnet. It is the reference integration that proves the primitive end to end, not the product.

TornaDEX, live on devnetsyncing
Best bid
-
Best ask
-
Spread
-
Resting orders
-
Open the trading terminal

Go deeper