High-Frequency Market Making on BULK

What high-frequency market making on BULK actually looks like in practice — the infrastructure, the rules everyone plays by equally, and the tools available. For official documentation, see docs.bulk.trade/bulk-exchange/hf-market-making and docs.bulk.trade/bulk-exchange/builder-codes.

The core promise: no paid speed advantage[edit]

BULK's stated design principle is explicit: "There are no private feeds, VIP queues, or negotiated latency tiers." Every market/GTC/IOC/modify/conditional order transaction gets the same 25 millisecond maker window before it becomes eligible to take liquidity, applied identically across every participant and entry point. This is a published protocol rule, not something you can pay to skip.

That means the only legitimate way to get a latency edge on BULK is physical proximity to the validator network — co-location — not a commercial arrangement with the exchange. Currently, the lowest-latency region is Europe, where most validator nodes operate; expect regional infrastructure to shift toward wherever trading activity concentrates over time.

Setting up for high-frequency operation[edit]

Use an agent wallet (keychain): Rather than signing every order with your primary wallet's private key, BULK supports authorized sub-keys ("agent wallets") scoped for high-frequency signing — covering the full order lifecycle (place, modify, cancel) without exposing your master key to your trading infrastructure.

Consider running a validator in follower mode: Running a follower-mode validator gives you direct local reads of network state and higher throughput, without requiring you to actually participate in consensus. This is meaningfully more infrastructure than most traders need — it's specifically for participants running enough volume that shaving milliseconds off state visibility matters.

Builder codes: getting paid for the order flow you route[edit]

If you're building trading tools, a bot framework, or a front-end that routes orders to BULK on behalf of other users, builder codes let you attach a small fee to orders you route — separate from BULK's own fee — without any order internalization (every order still lands on the same deterministic public order book regardless of how it arrived).

Mechanics:

A user must explicitly approve you as a fee recipient (via the `abc` field) before your builder-code fee can apply to their orders.
Approved fees range from 1–15 basis points, set per approval.
Each master account can have at most 10 approved builder-code recipients at once.
You can't approve yourself, and you can't approve your own linked sub-accounts.
Orders only carry your fee when explicitly routed through you (`{"builderCode": {"to": "your_pubkey", "fee": 5}}`) — omit it and no fee applies.
Approval can be revoked (`rbc`) by the user at any time; revocation blocks settlement on any of your still-unfilled resting orders.

This is the mechanism that makes it viable to build a trading bot, terminal, or strategy product on top of BULK and get paid for the flow you generate — without needing BULK's permission for each integration, only the end user's.

The core promise: no paid speed advantage[edit]

Setting up for high-frequency operation[edit]

Builder codes: getting paid for the order flow you route[edit]

See also[edit]