Clearing V1
Builder codes
Builder codes are how third-party interfaces, venues, and aggregators earn a share of protocol fees for the flow they bring. Optionbolt puts them on-chain, in the clearing core itself, as a single global registry, rather than tracking attribution off-chain at each venue. They are the core’s one attribution primitive; the core stays otherwise participant-agnostic.
On-chain, in the core
Most venues track builder attribution off-chain, in the operator’s books. Optionbolt keeps the registry on-chain in the clearing core, so attribution is legible to anyone and portable across every venue that clears through the core: a builder integrates once, against the core, and is credited no matter which CLOB or AMM the flow lands on. There is no operator to trust for the accounting.
How a code works
Each builder is a code, an id mapped to a payout address and an attribution share in basis points, capped at a protocol maximum. An integrator attaches their code to the flow they route, and the core credits that builder’s share on the actions it clears. Attribution is global, a builder code, not a tag on a particular option or a particular user, and it is the only attribution source in a core that otherwise knows nothing about who is behind an action. Codes are non-transferable and can be revoked for abuse.
Paid from the protocol’s share
A builder’s share comes out of the protocol’s fee, not on top of it. A writer or trader pays the same whether or not a code is attached; the code only splits the protocol’s cut between the protocol and the builder. What the fee is, and when it applies, lives on the Fees page; builder codes are just how a slice of it is attributed.
The builder approver
The registry is managed by a builder approver, a role deliberately separate from protocol admin. Onboarding an integrator, setting or removing a code within the attribution cap, is the approver’s job, so it keeps working independently of governance, and even after admin is renounced. Admin can reassign the approver, but the approver runs the registry day to day. Keeping the two roles apart means integrator onboarding never waits on a governance action.
Core codes and venue codes
The core’s builder codes are separate from a venue’s own. A CLOB, or the Hyperliquid order book, may run native builder codes on the trades they match; the core’s codes attribute the protocol actions that clear through it. An integrator routing flow can carry both, earning at the venue for the trade and at the core for the clearing, which is why building on the core is worthwhile even where the premium trades somewhere else.