For everyone / Fee sharing
Application fee sharing
An application that wants ecosystem support settles a published share of its own protocol take, never its users' money, through a public on-chain router. Written to be argued with rather than admired.
The idea
On most chains the chain earns only its fees, while the businesses built on it keep everything they make and each launch their own coin. Pickle's idea is that a business wanting the chain's support pays a small, published share of its own earnings into PKL, through a public pipe anyone can watch. Not the customers' money, only the business's cut. Small businesses pay nothing; big ones pay a bit more; nobody pays more than 18 percent of anything.
A general-purpose chain captures value only from gas. The businesses built on it, exchanges, lending markets, marketplaces, games, keep all of their revenue, and each launches its own token in order to monetise, which fragments attention and liquidity across the ecosystem it sits in. Pickle inverts that. An application that wants ecosystem support settles a published share of its protocol take through an on-chain router, and that share feeds the single ecosystem asset. The claim is not that this is generous; it is that application revenue on Pickle is verifiable on-chain rather than estimated by third parties.
Four components: a governed, timelocked registry recording each application's tier, published rate schedule, category adapter, bond and suspension state; a router that receives protocol take, splits builder retention from ecosystem share and emits a revenue event; a multi-asset vault accumulating and allocating the ecosystem share per epoch; and category adapters defining the revenue base per application type. Rates are a published schedule per tier and are never negotiated per application. For an automated market maker, integration is pointing the pool's fee recipient at the router.
What counts as protocol take, and what never does
Protocol take is the application's own revenue. It is never any of the following, at any tier, permanently:
| Never in any revenue base | Why |
|---|---|
| Liquidity-provider fees, supplier interest | compensation to capital |
| Creator royalties | payment to creators |
| Liquidator bounties; keeper, solver, oracle and relayer payments | compensation to service providers |
| User principal, trader profit and loss, margin, funding payments, seller proceeds, collateral | counterparty money, not revenue |
| Pass-through infrastructure costs | costs |
A chain that taxes its own liquidity does not have liquidity to tax. The arithmetic behind the rule rather than the sentiment: taxing an automated market maker's total fee instead of its protocol take would cut provider returns by roughly 40 to 48 percent, and capital compares returns across chains within days. This exclusion list is one of the parameters that no simple token vote can change.
How it works
| Component | Responsibility |
|---|---|
| AppRegistry | tier, published rate schedule, category adapter, bond, suspensiongoverned and timelocked |
| FeeRouter | receives protocol take, splits builder retention from ecosystem shareemits a public revenue event per settlement |
| RevenueVault | multi-asset accumulation and allocationper epoch |
| Category adapters | define the revenue base per categoryexchange, perpetuals, lending, marketplace, game, names, subscription, generic |
Every settlement and allocation emits a public event, so any revenue dashboard is a read over those events rather than a spreadsheet somebody maintains. Integration is deliberately small: for an automated market maker it is one line, pointing the pool's fee recipient at the router.
The schedule
| Annual protocol take | Marginal ecosystem share |
|---|---|
| First $100,000 | 0%the builder keeps 100% |
| $100,000 to $500,000 | 6%the builder keeps 94% of this band |
| $500,000 to $1,000,000 | 12%the builder keeps 88% of this band |
| Above $1,000,000 | 18%the builder keeps 82% of this band, and at least 82% at any scale |
Brackets are marginal, applying only to the revenue that falls inside them. Cliff rates were rejected deliberately: a rate that jumped on the whole base at a threshold would reward an application for holding its reported revenue just underneath one. Cumulative ecosystem share at the bracket edges: nothing at $100,000, 4.8 percent at $500,000, and 8.4 percent at $1,000,000.
The builder keeps at least 82 percent at any scale, and everything below $100,000 is free. Rates change only by a governed, timelocked vote on the whole tier, never per application, because per-application negotiation is how ecosystems get captured.
Effective rates
| Annual protocol take | Effective rate |
|---|---|
| $50,000 | 0%the whole amount falls in the free bracket; the builder keeps all of it |
| $250,000 | 3.6%$9,000 ecosystem share |
| $500,000 | 4.8%$24,000 ecosystem share |
| $1,000,000 | 8.4%$84,000 ecosystem share |
| $5,000,000 | 16.08%$804,000 ecosystem share |
| $20,000,000 | 17.52%$3,504,000 ecosystem share; still under the 18% top bracket |
Because the brackets are marginal, the effective rate is always below the top marginal rate and approaches it only slowly. At twenty million dollars of annual revenue it is 17.52 percent, still under the 18 percent top bracket, and it never reaches it at any scale.
A worked example
An exchange with ten million dollars of daily volume at a 0.30 percent swap fee, split 0.25 percent to liquidity providers and 0.05 percent to the protocol. The provider share is never touched. The daily flow, at the top marginal rate:
$30,000/day total fees
|- $25,000 -> liquidity providers, inside the pool (never touched)
`- $5,000 -> protocol take, through the FeeRouter
|- $4,100 -> the application's treasury (82%)
`- $900 -> ecosystem share:
$540 buyback / $180 treasury
$90 security / $90 incentivesThe same discipline applies in every category. In a perpetuals venue, trader profit and loss, margin, funding payments, the liquidity vault's share and the liquidator's bounty are never in the base, and the protocol's liquidation share is measured as actually transferred, never as an assumed ratio. In a lending market, supplier interest is not revenue; only reserve accrual and the protocol's liquidation share are. In a marketplace, seller proceeds and the creator royalty are not revenue. Fee levels differ across categories because applications price their own fees: Pickle defines only what counts as protocol take per category, never what an application may charge.
That buyback reduces PKL's total supply. It is not a reduction in circulating supply during the vesting years, and the buyback page gives the arithmetic.
What this does not enforce
Enforcement is economic rather than physical
Deployment is permissionless, and a sequencer-level tax is deliberately rejected. On a general-purpose EVM the transfer patterns such a tax would have to intercept are indistinguishable from account-abstraction settlement, marketplace payouts and vault withdrawals, and changing token semantics to catch them would invalidate every audit on the chain.
What Pickle offers instead is conditional: verification, grants, liquidity support, incentives and placement all depend on routing revenue. A bond-and-challenge mechanism prices under-reporting: a registered application posts a bond in PKL, and a successful challenge showing unrouted protocol take forfeits it. The first-party venues make the flagship activity transparent because their own books are on-chain.
An application can decline to register and keep everything. It then forfeits ecosystem support, and that is the whole of the consequence. Spread-based revenue and off-chain revenue remain undetectable. This layer makes honest revenue sharing cheap, verifiable and rewarded; it does not make dishonest revenue sharing impossible.
Application tokens
Applications at any tier may launch their own token and may distribute their retained share to its holders. Pickle is agnostic about what a builder does with the builder's share. The only rule is settlement order: the ecosystem share is settled at the router, on gross protocol take as defined by the category adapter, before the application's treasury receives or distributes anything. It is never computed on an application-declared profit after its own distributions.
And the verified mark means revenue verified through the router, not token endorsed. That distinction is stated in the explorer as well as here, because it is the one a reader is most likely to blur.