Revenue Share Pool

A Revenue Share Pool operates as a dedicated treasury smart contract. It automatically collects a pre-defined percentage of the protocol's transaction fees or protocol revenue. This collected capital is then distributed to eligible participants, such as stakers or governance token holders, on a regular basis (e.g., weekly or per epoch). The distribution is often proportional to the amount of tokens a user has staked or locked in the pool.

• Revenue Source: The specific fees being shared (e.g., swap fees, lending interest, minting royalties).
• Distribution Schedule: The frequency and trigger for payouts (block-based, time-based).
• Eligibility Criteria: Rules defining who receives shares (e.g., stakers, veToken holders).
• Claim Mechanism: How users access their share (automatic accrual, manual claim function).
• Treasury Address: The secure, often multi-sig controlled wallet holding the undistributed funds.

• SushiSwap (xSUSHI): Stakers of the xSUSHI token receive a 0.05% share of all trading fees generated on the platform.
• GMX (esGMX): A portion of the protocol's fees from swaps and leverage trading is distributed to stakers of GMX and GLP tokens.
• Curve Finance (veCRV): Holders of vote-escrowed CRV (veCRV) receive a share of trading fees from pools they vote to incentivize, in addition to protocol admin fees.
• LooksRare: Traders and creators earn WETH rewards from a pool funded by a 2% protocol fee on all NFT sales.

This mechanism is a primary method for protocol-owned value accrual. Instead of all revenue going to developers or a central entity, it is redirected back to the protocol's user base and supporters. This aligns incentives, as stakeholders benefit directly from the protocol's growth and usage. It transforms governance or utility tokens into cash-flow generating assets, creating a sustainable economic flywheel where increased usage leads to higher rewards, which in turn attracts more capital and users.

A critical distinction from simple staking rewards:

• Revenue Share: Distributes real yield generated from protocol activity (e.g., ETH, stablecoins). It does not dilute existing token holders.
• Inflationary Rewards: Mints and distributes new tokens from the protocol's treasury as rewards. This increases the token supply, causing potential dilution unless demand outpaces issuance. Revenue sharing is often seen as a more sustainable and mature model, as payouts are backed by actual protocol earnings rather than future token inflation.

Revenue sharing is frequently coupled with vote-escrow tokenomics. Users lock their governance tokens (e.g., CRV, BAL) to receive veTokens, which grant:

1. Voting Power on gauge weights (directing liquidity mining incentives).
2. Boosted Rewards from liquidity provision.
3. A Share of Protocol Fees. This model, pioneered by Curve Finance, creates a powerful incentive to lock tokens long-term, reducing circulating supply and aligning long-term holders with the protocol's success. The revenue share acts as the "dividend" for this long-term commitment.

The core security of a Revenue Share Pool depends on the smart contract code that collects and distributes funds. Vulnerabilities like reentrancy, improper access control, or math errors can lead to loss of funds. Audits by reputable firms and formal verification are critical. Users must trust that the contract logic correctly handles edge cases and prevents unauthorized withdrawals.

A key trust question is who holds the treasury assets before distribution. Risks include:

• Centralized Custody: Funds held in a multi-sig wallet controlled by a small team.
• Non-Custodial Design: Funds are locked in an immutable, audited smart contract.
• Upgradability: Proxy contracts allow for code updates, which can fix bugs but also introduce centralization risk if upgrade keys are not properly decentralized.

Decisions about the pool's parameters—like fee allocation percentages, distribution schedules, or supported assets—are often governed by a DAO. Security depends on:

• Proposal and voting mechanisms being resistant to manipulation.
• Timelocks on executed transactions to allow for community review.
• The distribution of voting power; excessive concentration can lead to malicious proposals being passed.

If distributions are made in a different asset than the revenue earned (e.g., paying ETH based on protocol fees in USDC), the pool relies on a price oracle. Manipulation of this oracle (oracle attack) can distort the value of payouts. Secure pools use decentralized, time-weighted average price (TWAP) oracles from multiple sources to mitigate this risk.

The user-facing claim function must be secure and efficient. Considerations include:

• Preventing denial-of-service attacks that could block claims.
• Mitigating gas griefing where malicious actors make claims prohibitively expensive.
• Implementing merkle drop or similar patterns for efficient batch distributions, which require users to trust the published merkle root.

Revenue Share Pools may attract regulatory scrutiny depending on their structure. Key considerations:

• Security vs. Utility Token: If the primary purpose is profit distribution, it may be classified as a security in some jurisdictions.
• Tax Implications: Automated distributions create taxable events, and the pool's design should provide transparency for reporting.
• KYC/AML: Some protocols may integrate compliance checks for participants, adding a layer of centralized control.