builderApprovedFills
Stream every fill made by users who had an active fee approval for your builder at the time of the fill.
Every live data message includes both routing identifiers with the same value:
{"type": "builderApprovedFills", "channel": "builderApprovedFills"}Other payload fields are omitted above. Existing clients may continue routing on either field.
How this differs from builderFills
builderFills streams fills that were routed through your builder — the fill's own builder field matches your address.
builderApprovedFills streams every fill made by a user while your builder-fee approval was active for them, regardless of how that order was routed. A user who approved your builder and then traded through another frontend still appears here, and those fills carry "builder": null.
Consequences worth planning for:
A fill can appear on both channels. Subscribe to both only if you want that.
One fill can be attributed to several builders at once — a user may hold approvals from more than one. Each subscribed builder receives its own copy.
The set is driven by approval state at the block of the fill, not by current approval state. Revoking an approval stops future fills from appearing; it does not retract past ones.
An approval is treated as revoked only when its max fee rate is set to exactly
0%.
Subscribe
{
"type": "subscribe",
"subscription": {
"type": "builderApprovedFills",
"builder": "0xb84168cf3be63c6b8dad05ff5d755e97432ff80b"
}
}builder is required and must be a 20-byte hex address. It is matched case-insensitively.
Unsubscribe
Fill data format
Each entry is [address, fill], where address is the user who made the fill.
Note that builder inside the fill is the routed builder and is frequently null. Attribution to your builder is implied by the channel, not by this field.
Examples
Error messages:
Common errors
Last updated