The Problem With Fixed Fee Builder Codes Builder codes enable applications like wallets (@phantom) and trading interfaces (@tread_fi) to route user transactions through perpetual protocols (@HyperliquidX) while earning a share of the fees. The fee structure here really matters. Fixed minimums create barriers, while revenue sharing unlocks experimentation. If a customer has ten dollars to spend on transaction fees. Under a traditional fixed-cost model, if the underlying protocol charges five dollars, only five dollars remain for the builder layer. This creates an inherent zero-sum competition: the protocol and builder are fighting over the same limited pie, each trying to extract maximum value from a fixed budget. They’re simultaneously partners and competitors, creating a fundamental tension that stifles innovation. When there’s a hard line in the sand – “you must pay three basis points” – builders face an immovable hurdle that constrains their ability to experiment, optimize, and ultimately deliver value to end users. The Revenue Sharing Alternative Instead of competing for a fixed pie, the protocol takes a percentage of whatever the builder earns. If the builder can only capture one basis point from the customer, they pay the protocol some percentage of that one basis point. If they find innovative ways to capture ten basis points, the protocol benefits proportionally from that success, and the builders benefit even more from the value they create for themselves and the protocol. It’s advantageous for builders because they can experiment and discover new ways to frame the pie, while the protocol earns more revenue as it becomes home to the best founders. Builders, in turn, gain the freedom to experiment aggressively with pricing models, user experiences, and value propositions without worrying about clearing a mandatory cost hurdle. Zero fee builder codes enables this type of revenue share model and also unlocks a unique distribution mechanism for the perp DEX: trading venues can credibly market themselves as the cheapest venue while simultaneously expanding their margins. This increases distribution into things like wallets. Assuming liquidity is the same, do you think Phantom would use a builder code that has revenue share or one that has mandatory hurdles? Rather than fighting over how to divide ten dollars, the focus shifts to growing that ten dollars into twenty dollars. Builders closest to the customer have the best visibility into what users value and what they’re willing to pay for (look at @BasedAppHQ). Whether it’s an app store, Roblox’s creator economy, or other successful marketplace models, the winning formula consistently involves revenue sharing rather than fixed listing fees. Creators can start small, test ideas, and scale what works, all while the platform benefits proportionally from successful experiments. The Path Forward By aligning incentives between protocols and builders, revenue sharing creates the conditions for genuine experimentation, rapid iteration, and ultimately, the kind of thinking that expands entire markets. I expect, over time, more teams utilizing builder codes will prefer zero fee builder codes. @Lighter_xyz and @paradex are likely the first two to come to market with this.