Builder Codes and Frontend Integration Mechanics

A planned frontend-revenue mechanism described by the project documentation; it is not presented as live yet.

Official Papertrade documentation · Updated November 5, 2026 · Canonical domain: papertrade.finance

Planned builder-code model

The docs describe a future flow where frontends tag originated intents with a builder identifier and receive a share of protocol-side revenue from those trades.

No extra user fee

The planned builder share is described as coming from protocol LP-revenue allocation rather than as an additional charge layered on top of the trader action.

Integration path

The relayer-only launch profile still controls which submitters can reach the batch executor. Permissionless builder routing depends on a future deployment or configuration profile.

Status

The supplied documentation labels builder codes as coming soon and does not provide a firm activation date.

Attribution vs execution

A builder code identifies the frontend or integration that originated eligible activity; it does not replace the underlying signed intent or BBO pricing model. Attribution can therefore be added without turning a builder into the counterparty to the trade.

Why deployment status matters

Integration documentation can describe planned protocol capabilities before they are enabled in the live execution profile. Builders should verify active contract configuration and relayer permissions instead of assuming every documented future mechanism is currently available.