Holder Yield & Creator Royalties
How trading fees flow back to holders and to the token's creator.
Two of the four fee buckets described in Fee Structure — holderRewardFeeBps and creatorFeeBps — exist specifically to route value to people, rather than to the token's supply or its post-migration liquidity. This page covers how each actually gets paid out.
Holder yield
holderRewardFeeBps streams a configurable share of every trade to the token's existing holders, proportional to their holdings at distribution time — the closest analogue to a traditional dividend, funded entirely by trading activity rather than emissions or inflation. Because it's a fee-on-trade rather than a fixed schedule, holder yield scales naturally with how actively a token is traded: a quiet token accrues slowly, a busy one compounds faster.
Creator royalties
creatorFeeBps is unique among the four buckets in where it settles: rather than going to a plain address, it's configured against a creatorKey — the exact same deterministic keccak256(platform, handle) key that backs Universal Social Tipping's escrow. On every trade, the creator's configured share streams straight into that creatorKey's escrow bucket via OmniTokenomicsEngine.collectFee, which calls OmniTippingEscrow.depositToCreatorKey directly.
The practical effect: a creator's trading-fee royalty and their social tips are the same money, sitting in the same bucket, claimed with the same single claimTips call. There's no separate 'claim my creator fees' flow to remember — a creator authenticates once via OAuth and sweeps everything, whether it arrived as an organic tip from a fan or as a streamed royalty from their own token's trading volume.
Tip
Configuring a creator royalty requires the token's OmniTokenomicsEngine owner to first confirm the target OmniTippingEscrow deployment is set — this prevents a token from silently streaming fees into an escrow contract that hasn't actually been wired up, where they'd otherwise sit unclaimable.
