Decided to start writing some stuff down — as some guy said, writing down problems solves most of them?!
So blah blah blah… for the last year or so, I’ve been actively market-making on DEXs on Solana and by this, I mean not the price-inefficient CLAMMs and CPMMs or the Meteora DLMMs. I mean the orderbooks, which are actually meant to be market-made.
Anyway, there are a bunch of problems I’ve noticed and even the core engineers at Anza are acknowledging them now.
First thing, makers really struggle when it comes to MM on Solana. Price moves really slow on-chain, and landing transactions is very hard. This leads to liquidity losses — market makers need to make a small profit on every trade to be sustainable. The optimistic scenario for a maker txn is:
→ 1 slot to place the order
→ 1 slot to update or cancel
That’s the perfect case, which takes ~0.8 seconds.
Now mid-curve, real scenario — every maker has to spend time and money just to find an edge in transaction landing to even get that optimistic path.
Right now, makers have to fight with each other and against the taker to update or cancel an order while the price-time slips and it just gets worse.
Solana’s account model uses per-transaction write locks. That means you can’t touch the same account in parallel and since orderbooks manage shared accounts, this becomes a full-on race. Shared contention doesn’t scale and that’s the choke point. We need makers to fight to improve price — to actually make the book — not fight for txn landing edge.
How are we supposed to improve on-chain liquidity when the promised “Nasdaq-on-chain” is still a struggle to achieve? A few teams are in-fact trying to solve this; Atlas is building an SVM-based Layer 2 ? with priority txns and price updates. The core team just introduced ASS (App-Specific Sequencing) and MBP (Multiple Block Producers) — but who knows how that plays out, since makers may end up paying more txn fees just to get into a block or win inclusion priority.
Other teams are building sequencers — but that’s just centralized infra wrapped in new clothes.
So I looked at the problem from an exchange perspective:
Why are CEXs so powerful — yet no one has built that level of performance on decentralized tech?
Trading systems, to be any good, need to offer three things:
Performance — 5–20ms (not wire latency), from ingress to egress.
Consistency — same latency at 5k mps as at 500k mps; no latency spikes during high volume.
Reliability — no orders lost, no executions missed, no confirms dropped.
Trading on-chain right now just sucks. I’ve been sandwiched, my bots have been liquidated, my order placements came in late — the whole stack is a mess.
The problem is at the root — not the app layer. Solana is doing an incredible job scaling and evolving that’s why I love it — but we still don’t have a real solution to trading performance.
We talk about building the next-gen Internet capital markets — but where are those markets going to trade? On fixed AMMs (that lose money)? Or on inefficient orderbooks that can’t scale beyond a few dozen participants?
I want to build the pinnacle of parallel, distributed, concurrent processing systems — something that elevates trading to the top. I’m talking Nasdaq-level infra — a single, global, concurrent exchange (orderbook) that can list any market or instrument and still deliver:
blazing performance,
rock-solid consistency, and
reliability without compromise — while staying true to the ethos of decentralization.
An exchange that can literally run without me tomorrow.
Digging deep into our architecture, I spiraled into a dark hole of L2s, rollups, sequencers… people building FPGA-accelerated chains and zkVMs — just wow.
My design philosophy is simple:
User assets should never bridge from Solana — don’t fragment liquidity
The exchange shouldn’t rely on Solana’s block time for trade execution
It should maintain decentralization at all costs
After months of research and talking to different teams about their design principles, I realized no one’s really building for a market so big that it deserves blood, sweat, and obsession to pull it off.
So what the fuck are we building? Enough of this bish bosh.
So here’s the plan.
We’re taking the already well-built Solana validator stack and adding Bulk Tile: a supercharged FIFO orderbook that lives inside jito-solana (for now).
It uses a dedicated port for incoming orders and pushes them to other bulk-solana clients using a special Turbine port (underlying gossip).
All validators running Bulk Tile will match the same orders in a deterministic 25ms cycle, and send the response back.
Then, after N cycles (goal is; 150ms), we aggregate fills, cancellations, transfers — create a net-delta commit. BLS threshold-sign the digest so any honest quorum proves correctness. This signed delta is then used to create a txn — and is committed on-chain during the same 400ms Solana block cycle.
why this matters?
Makers compete on price. Matching is deterministic — cheapest order wins.
True “Nasdaq-on-chain.” Slot time becomes a rollback window, not a bottleneck.
Composable everywhere. Any program can call the Bulk Vault to atomically swap, fund vaults, or trigger liquidations — without warm-up jank.
Since the heavy lifting happens on the validator tile, Bulk preserves Solana’s liveness guarantees while sidestepping account locks.
Trade latency trends 20–30ms on localnet and stays flat at scale. The Vault performs independent verification of every Bulk Exchange cycle’s commitment — ensuring system-wide security and verifiable correctness of state transitions.
No validator can fraudulently alter tx data — any tampering is instantly detected and rejected.
Thats the first update on this sub from me — if you wanna see how this works on validator level, shoot me a text.