Skip to main content

​
Overview

Builder codes are BULK’s routed-order-flow attribution mechanism. They can carry a transparent builder fee on top of BULK’s base trading fees using the builderCode, abc, rbc, and builderCodeApprovals fields.
Builder codes are now live on BULK’s exchange endpoints.
This is sometimes compared to Payment for Order Flow (PFOF), but BULK’s model is fundamentally different from traditional PFOF.

​
How It Works

A builder attaches a builder-code fee to the specific order they route. The fee is transparent in the signed order payload, capped by user approval, and settled in addition to the user’s standard BULK fee tier. The key distinction: these are not spread-charged fees. The integrator does not internalize flow, route to a private market maker, or degrade execution quality. Every order - regardless of which frontend submitted it - is routed to the BULK Network and executed on the same deterministic order book. All participants receive the same BULK Best Bid and Offer.

​
User Approval

Before an order can pay a builder-code fee, the account owner approves the recipient with abc:
  • fee is basis points and must be 1..=15.
  • Each master account can approve at most 10 builder-code recipients.
  • The recipient must be an existing canonical root payout account. An account cannot approve itself or another account in its own master/sub-account tree.
  • Approvals are master-account scoped. abc must be signed by the master account; agent wallets cannot approve builder-code recipients. Account snapshots expose builder-code recipients as builderCodeApprovals: [{ "recipient": "...", "maxFee": 5 }].
  • Users can revoke approval with rbc. rbc must also be signed by the master account; agent wallets cannot revoke builder-code recipients. Revocation prevents builder-code fee settlement for resting orders that have not filled yet.

​
Routed Orders

Include the builderCode payload only on m or l orders routed through the builder:
Orders without a builder code omit the field entirely:
"builderCode": null is rejected by the JSON API. A builder-code fee applies only to the order side carrying the field, whether that order fills as maker or taker. The same rule applies to nested market and limit orders, including an OnFill trigger or consequent. In canonical signing bytes, an absent builderCode contributes no bytes. A present value contributes the Some tag (1), the 32-byte recipient pubkey, and the one-byte fee.

​
For Builders

  • Use abc/rbc for user authorization and show the active builderCodeApprovals state before routing
  • Attach builderCode: {to, fee} only to orders actually routed through your builder code
  • The builder-code fee is applied on top of the user’s standard BULK fee tier and credited to the recipient account
  • All orders are routed to the network and matched fairly - no internalization, no dark pools, no preferential routing

​
Why This Matters

Traditional PFOF creates a conflict of interest: the broker sells your order to a market maker who profits from the spread. On BULK, there is no such conflict. The builder earns a transparent fee, the user gets the best available price from the full order book, and the network treats every order identically.

​
API Reference