Stable Draft
| The Whitepaper Reading Club KL [06] | 2 February 2026 |
|---|---|
| Bulk Trade | [Yudhishthra, Shuen Rui] |
| https://docs.bulk.trade | https://bulk.trade |
Summary
Bulk Trade is a high-performance perpetuals DEX on Solana achieving 20ms order matching through leaderless consensus, eliminating MEV via deterministic FIFO ordering while maintaining full decentralization and self-custody.
Why This Is Important
Bulk.Trade solves the CEX-DEX performance gap by:
- Closing the latency gap – 20ms execution vs 500-2000ms on traditional DEXs, matching centralized exchange speeds
- Eliminating MEV extraction – In 2023, MEV bots extracted $1.38B+ from traders; BULK's architecture makes front-running mathematically impossible
- Removing single points of failure – Leaderless consensus means no sequencer can censor or manipulate orders
- Enabling institutional DeFi – Self-custody + transparency + no counterparty risk with CEX-grade performance
Key Innovation
BULK integrates a specialized matching engine (Bulk Tile) directly into Solana validator nodes via a forked client (Bulk-Agave). Orders bypass Solana's general transaction queue, enabling sub-20ms matching. A leaderless consensus mechanism using BLS threshold signatures ensures that when ≥80% of the stake agrees on execution results, the tick is instantly finalized. This creates a dual finality model: fast execution finality (40ms) with eventual settlement on Solana's main chain. Deterministic FIFO ordering with cryptographic sort keys mathematically prevents front-running.
Overview
Bulk.Trade is a next-generation perpetuals DEX built natively on Solana, designed to match or exceed centralized exchange performance while preserving DeFi's core benefits of decentralization and self-custody. Unlike traditional DEXs that process trades through on-chain transaction queues (introducing latency and MEV vulnerabilities), BULK runs an in-memory execution engine directly on validator nodes. The protocol supports BTC, ETH, and SOL perpetuals with up to 20x leverage, gasless order submission, and sub-40ms trade finality. Below is a detailed breakdown of its architecture, consensus mechanism, and MEV protection.
Team
Founded by Kobie McGlashan (CEO, UK-based, previously BEExperience blockchain recruitment, co-creator SuperteamUK) and Junaid Peer (CTO, Rust/blockchain engineer). The team includes former engineers from FTX, dYdX, Pyth Network, and Solana Labs. Raised $8M seed (Sept 2025) led by 6th Man Ventures and Robot Ventures, with participation from Wintermute Ventures, Big Brain Holdings, and Mirana Ventures. $500K angel (Aug 2024) from Anatoly Yakovenko (Solana co-founder), Jump Crypto, and Archetype.
Key Components
The BULK Tile (In-Memory Execution Engine)
| Problem | Traditional DEXs must wait for blockchain confirmation between each trading step. On Solana, this means 400ms+ latency per operation. Orders sit in mempools where MEV bots can observe and front-run them. The transaction queue becomes a bottleneck during high volatility, causing failed trades and slippage. |
|---|---|
| Solution | The BULK Tile is a high-performance, in-memory execution engine that runs as a sidecar on every Solana validator node. It processes all trading operations (order matching, margin calculations, liquidations) entirely in RAM, decoupled from Solana's on-chain execution. Orders never touch the public mempool, they're received via BULK Net and matched within deterministic 20ms tick windows. |
| How it works | 1. Orders arrive via BULK Net (erasure-coded UDP propagation)2. Every 20ms, a "tick" begins then all orders in the window are grouped3. Orders are sorted using a deterministic cryptographic formula (identical across all validators)4. Matching engine executes price-time priority (FIFO within price levels)5. Margin checks and risk calculations run in parallel6. State delta is computed and signed by validator's BLS key share7. Liquidation engine runs asynchronously for positions below maintenance margin |
Bulk-Agave (Forked Validator Client)
| Problem | Building a new validator network from scratch is expensive, time-consuming, and creates bootstrap problems (who runs validators for a new network?). Existing Solana validators won't switch clients if it means losing Jito MEV revenue which is a significant portion of their income. |
|---|---|
| Solution | Bulk-Agave is a strategic fork of Jito-Agave, the most widely used validator client on Solana (95%+ of stake). Validators can run BULK's trading logic without forgoing MEV revenue from Jito's blockspace auctions. This piggybacks on Solana's existing security and decentralization while adding high-performance trading capabilities. |
| How it works | Validator node architecture:• Solana Consensus Layer (unchanged) └→ Bulk-Agave Validator Client ├→ Jito Block Engine Integration (MEV revenue preserved) ├→ BULK Tile (in-memory execution sidecar) ├→ BULK Net (order propagation receiver) └→ BULK Db (local state storage)Validators receive 12.5% of BULK trading fees as incentive (estimated 1-2% APY boost). |
BULK Net (Order Propagation Network)
| Problem | Traditional order propagation relies on Solana's transaction gossip network, which is optimized for general transactions, not latency-critical trading. TCP-based protocols add handshake overhead. Packet loss can cause order delivery failures. Naive broadcast doesn't prioritize high-stake validators who matter for consensus. |
|---|---|
| Solution | BULK Net is a custom order propagation layer using Reed-Solomon erasure coding and two-hop UDP fan-out. Orders are split into 8 shards (any 6 can reconstruct the original). Raw UDP eliminates TCP overhead. Stake-weighted peer selection ensures high-stake validators receive orders first. |
| How it works | First Hop:• Validator A receives order, immediately encodes into 8 shards• Broadcasts shards via raw UDP to 8 stake-weighted peer validatorsSecond Hop (Immediate Relay):• Each receiving peer does NOT wait for complete reconstruction• Upon receiving first shard, immediately forwards to its own 8 peers• "Receive-first-then-forward" eliminates cumulative hop delaysResult: Sub-20ms propagation to all validators. Inspired by Solana's Alpenglow Rotor mechanism. |
Leaderless Consensus with BLS Threshold Signatures
| Problem | Traditional consensus protocols (PBFT, Tendermint) require a leader to propose blocks. This creates: (1) single point of failure/censorship, (2) MEV opportunities for the leader, (3) bottleneck at leader node, (4) latency waiting for leader selection. Sequencer-based L2s inherit these problems. |
|---|---|
| Solution | BULK uses leaderless BFT consensus where ALL validators continuously execute and sign with no proposal phase needed. BLS threshold signatures allow efficient multi-validator signing: partial signatures aggregate into one compact proof. When ≥80% of stake-weighted validators produce identical results and sign, consensus is achieved instantly. |
| How it works | BLS Signature Flow:1. Master signing key is split into "shares" via Distributed Key Generation (DKG)2. Each validator signs tick's state delta with their share (non-interactive)3. Partial signatures aggregate using Lagrange interpolation4. Final signature is compact (vs. storing 1000 individual sigs)5. Master key never reconstructed so no single point of compromiseConsensus Thresholds:• ≥80% stake: Fast-path, tick commits in 1 round (~40ms)• 60-79% stake: Base liveness, commits in 2 rounds• <60% stake: Tick SKIPPED, orders roll to next tick (skip-and-continue) |
Dual Finality Model
| Problem | Fast execution and strong security are typically at odds. Pure L1 settlement is slow (400ms+ on Solana). Pure off-chain execution lacks cryptographic guarantees. Users want instant trading confirmation but also absolute certainty their funds are safe. |
|---|---|
| Solution | BULK provides two layers of finality:Economic Finality (~40ms): When 80%+ validators sign a tick, your trade is economically final. Reversing requires Byzantine validators to collude and lose their staked SOL.Cryptographic Finality (~400ms): State periodically anchors to Solana's main chain. Once confirmed, trades have absolute mathematical finality backed by Solana's full security. |
| How it works | Order Journey (0-400ms):• 0-15ms: Order propagates via BULK Net• 15-20ms: Order waits for tick boundary• 20-35ms: Validators execute matching, compute signatures• 35-40ms: BLS aggregation completes → Economic Finality• ~400ms: Solana PoH confirmation → Cryptographic FinalityMost traders only care about economic finality (40ms). Settlement happens in the background. |
MEV Elimination (Deterministic FIFO)
| Problem | MEV (Maximal Extractable Value) is profit extracted by reordering transactions. Common attacks:• Front-running: See pending buy → buy first → sell to victim at higher price• Sandwich: Buy before victim + sell after → profit from price impact• Back-running: Execute immediately after to capture arbitrageIn 2023: $1.38B extracted from Ethereum, $300M+ from sandwich attacks alone. Traditional DEXs expose orders in mempools, enabling this extraction. |
|---|---|
| Solution | BULK enforces strict First-In-First-Out ordering with cryptographic guarantees:• All orders in a 20ms tick are grouped and sorted using a deterministic formula• Formula uses hash of order properties (user, timestamp, price, size, direction)• ALL validators produce IDENTICAL sort results thus manipulation is detectable• No mempool visibility so orders go directly to validators via BULK Net• Batch processing within ticks means no time for insertion attacks |
| How it works | Why MEV is Impossible:1. No observation window: Orders don't sit in public mempool2. Deterministic ordering: Cryptographic sort keys prevent reordering3. Batch execution: All orders in tick settle at deterministic prices4. Leaderless design: No single sequencer to bribe or manipulate5. BLS validation: Execution results cryptographically verifiedUnlike Flashbots (privacy only) or CoW Swap (30s batches), BULK eliminates MEV entirely through architecture, not incentives. |
Angmar Vault System & VRTs
| Problem | DeFi liquidity is fragmented across protocols. Capital sits idle in one protocol while another needs it. Users must choose between staking yield OR providing liquidity OR using it as collateral and can't do it all simultaneously. Traditional LP tokens aren't composable across protocols. |
|---|---|
| Solution | Angmar is BULK's shared liquidity vault system (open-source: github.com/Bulk-trade/angmar). Users deposit assets and receive Vault Representation Tokens (VRTs) where its an internal 18-decimal accounting shares. VRTs can be used as collateral, traded, or composed with other DeFi protocols while original assets remain in vault earning yield. |
| How it works | VRT Mechanics:• Deposit 100 SOL → Receive ~100 vSOL (VRT)• new_shares = (amount × total_shares) ÷ vault_equity• vSOL can be: used as collateral, provided to AMM, traded• Original SOL stays in vault earning yield• Redeem: get proportional share + accumulated yieldAdvanced Features:• Delegated strategy execution with risk limits• High-water mark accounting (fees only on new profits)• Lock-in periods with two-step withdrawal• Drift Protocol integration for margin trading |
Questions
[1] How does BULK's approach to MEV elimination compare to intent-based systems like CoW Swap or UniswapX? What are the trade-offs between speed (20ms ticks) and MEV protection (30s batches)?
[2] With 80% stake required for fast-path consensus, what happens during network partitions or when major validators go offline? How does skip-and-continue affect UX during high disagreement periods?
[3] Can the Bulk Tile architecture be generalized beyond perpetuals? What other DeFi primitives (spot, options, lending) would benefit from sub-20ms execution?
[4] How do VRTs change the liquidity landscape? Could this model enable cross-protocol composability or arbitrage in ways not currently possible with traditional LP tokens?
[5] What are the centralization risks of requiring validators to run the Bulk-Agave fork? How does this compare to Jito's approach where validators extract MEV rather than eliminate it?
[6] The 12.5% revenue share to validators creates aligned incentives. Could this model be applied to other Solana protocols? What are the game theory implications if multiple protocols compete for validator attention?
[7] How does BULK's dual finality model compare to dYdX v4's Cosmos appchain or Hyperliquid's proprietary L1? Which provides better security guarantees for institutional traders?
[8] Given MEV extracted $1.38B+ in 2023, what's the ceiling for value BULK could capture by eliminating this extraction? Is there a risk that MEV migrates to other attack vectors?
References
[2] https://github.com/Bulk-trade/angmar
[3] https://ventureburn.com/bulk-raises-8m-seed-funding-to-redefine-perpetuals-dex-trading/
[4] https://wompa.land/articles/bulk-trade-solana
[5] https://alphanet.bulk.trade (Testnet)
Cheat Sheet
Whitepaper Cheatsheet: Bulk Trade
What is MEV (Maximal Extractable Value)?
Definition: MEV is profit that miners/validators can extract by reordering, including, or excluding transactions in blocks they produce. It's essentially 'skipping the line' for profit.
Common MEV Attacks:
- Front-running: Seeing your pending buy order and placing a buy order BEFORE you (buying cheaper, selling to you at higher price)
- Sandwich attack: Placing a buy BEFORE your trade AND a sell AFTER (profiting from the price impact you create)
- Back-running: Placing an order immediately after yours to capture arbitrage opportunities your trade created
Scale: MEV bots extracted $1.38 billion from Ethereum users by April 2023. On Solana, mempool visibility enables similar extraction.
How BULK Eliminates It: Deterministic FIFO ordering within 20ms ticks means no one can reorder. No mempool means no one can see your pending order. Cryptographic sort keys ensure all validators produce identical ordering thus manipulation is mathematically impossible.
What is the Bulk Tile?
Definition: The Bulk Tile is an in-memory execution engine (a 'sidecar') that runs alongside every Solana validator node. Think of it as a specialized co-processor dedicated to trading.
What It Does:
- Receives orders via BULK Net (not through Solana's normal transaction queue)
- Executes deterministic order matching every 20ms
- Runs margin calculations and risk checks
- Processes liquidations asynchronously
- Computes state deltas that get signed by validators
Why In-Memory? Traditional DEXs must wait for blockchain confirmation between steps. The Bulk Tile processes everything in RAM, only touching the blockchain for final settlement. This enables 20ms matching vs 500ms+ on normal DEXs.\
What is Bulk Agave?
Bulk Agave is Bulk’s modified Solana validator client that runs order matching directly inside validators instead of smart contracts.
Key idea:
Execution happens at the block-production layer, while Solana is used only for settlement and finality.
What does it enable?
- Orders bypass the public mempool
- Deterministic matching every 20ms
- No sequencer or centralized ordering
- Validators compute identical state changes
- Final results are committed on-chain
Why it matters
- Low latency: execution happens locally inside validators
- MEV-resistant: no reordering or order visibility
- CEX-like performance: without custody or off-chain settlement
What is the 20ms Tick Cycle?
Definition: Every 20 milliseconds, all validators simultaneously execute a 'tick' which is a synchronized window where orders are collected, sorted, and matched.
The Tick Process:
- Collect (0-20ms): All orders arriving in this window are grouped together
- Sort: Orders are sorted using a deterministic formula (identical across all validators)
- Match: Price-time priority matching (FIFO within price levels)
- Compute: Each validator independently computes the resulting state change
- Sign: Validators sign the state delta with their BLS key share
Why 20ms? Fast enough for institutional HFT needs (~50ms on CEXs), but long enough for global propagation. Deterministic windows eliminate reordering opportunities entirely.
What are BLS Threshold Signatures?
Definition: BLS (Boneh-Lynn-Shacham) is a cryptographic signature scheme that allows multiple parties to create partial signatures that can be aggregated into a single compact signature.
How It Works in BULK:
- A master signing key is split into 'shares' distributed to all validators (via DKG)
- Each validator signs the tick's state delta with their share
- When ≥80% of stake-weighted shares are collected, they aggregate into ONE signature
- This final signature proves consensus WITHOUT reconstructing the master key
Why BLS? Efficiency. Instead of storing 1000 individual signatures (huge), you get ONE compact signature that proves 80%+ of the network agreed. Also non-interactive so validators don't need to coordinate.