How to Implement a Fee-Sharing Model with Stakers

A fee-sharing model is a mechanism where a protocol distributes a portion of its generated revenue to users who stake its native token. This creates a powerful incentive alignment: stakers are rewarded for securing the network and participating in governance, while the protocol benefits from reduced token circulation and a more committed community. Common revenue sources for sharing include swap fees from a DEX, lending interest from a money market, or minting/burning fees from an NFT platform. Successful implementations, like SushiSwap's xSUSHI or Curve's veCRV, demonstrate how effective fee-sharing can drive protocol growth and sustainability.

The core smart contract architecture requires two main components: a fee accumulator and a distribution mechanism. The accumulator contract receives protocol fees, often via a simple transfer call from the main protocol contracts. The distribution logic then calculates each staker's share based on their proportion of the total staked tokens over a specific epoch. A critical design choice is between claimable rewards and auto-compounding rewards. Claimable models let users manually harvest their share, while auto-compounding models, like Compound's COMP distribution, automatically reinvest rewards into the staking position, improving capital efficiency but adding complexity.

Here is a simplified Solidity snippet for a basic fee accumulator and distribution logic. This example assumes an ERC-20 staking token and a simple proportional reward system.

solidityCopy
// Partial example of a FeeDistributor contract
contract FeeDistributor {
    IERC20 public stakingToken;
    IERC20 public rewardToken;
    uint256 public totalStaked;
    mapping(address => uint256) public stakedBalance;
    uint256 public rewardPerTokenStored;

    function notifyRewardAmount(uint256 reward) external {
        // Called by the protocol when fees are collected
        if (totalStaked > 0) {
            rewardPerTokenStored += (reward * 1e18) / totalStaked;
        }
    }

    function earned(address account) public view returns (uint256) {
        return (stakedBalance[account] * rewardPerTokenStored) / 1e18;
    }
}

This contract tracks rewards per token, allowing each staker's claimable amount to be calculated off-chain or via a view function.

Security and fairness are paramount. Use pull-over-push payments for distributions to prevent gas-intensive loops and mitigate reentrancy risks—let users claim rewards instead of sending them automatically. Implement a time-lock or vesting schedule for team/treasury shares to build trust. Crucially, all reward math must be verified to avoid rounding errors or division-by-zero issues that could lock funds. For production systems, consider integrating with established staking frameworks like OpenZeppelin's ERC-4626 Tokenized Vault Standard for safer accounting, or auditing the distribution logic through firms like Trail of Bits or CertiK.

To optimize the model, consider fee tiering based on lock-up duration, as seen with ve-tokenomics, where longer locks grant a higher share of fees. Snapshotting staked balances at specific block numbers prevents reward manipulation via rapid staking/unstaking. For multi-chain protocols, design a cross-chain distribution system using LayerZero or Axelar to aggregate fees from all deployed chains into a single reward pool. Finally, ensure full transparency by emitting clear events for fee collection and distribution, and providing users with a dashboard or subgraph, like those hosted on The Graph, to track their accrued rewards in real time.

Before writing any code, you must define the core economic parameters of your fee-sharing model. This includes determining the fee source (e.g., a percentage of swap fees from a DEX, loan origination fees from a lending market), the distribution token (typically your protocol's native ERC-20), and the staking contract that will hold user deposits. You'll need a development environment like Hardhat or Foundry, Node.js installed, and a basic understanding of Solidity. Essential tools include a testnet faucet (for ETH on Sepolia or Goerli) and a block explorer like Etherscan to verify transactions.

The architectural foundation involves three primary smart contracts. First, a Fee Collector contract that receives protocol revenues, often via a privileged withdrawFees function callable by a designated admin. Second, a Staking Vault (an ERC-20 staking contract) where users lock their tokens to earn rewards. Third, a Distributor logic that calculates and transfers the collected fees to stakers, typically proportional to their share of the total staked supply. A common security pattern is to keep these contracts upgradeable via proxies (like OpenZeppelin's TransparentUpgradeableProxy) to allow for future adjustments to the fee logic.

Start by initializing your project and installing dependencies. With Hardhat, run npx hardhat init and install OpenZeppelin's contract library: npm install @openzeppelin/contracts. For Foundry, use forge init. You will heavily rely on OpenZeppelin's audited contracts for safety: ERC20 for your token, Ownable or AccessControl for permissioned functions, and SafeERC20 for secure token transfers. Write your initial contracts in the contracts/ directory, beginning with the staking vault that inherits from a template like ERC20Staking or building a custom one using ERC721 for NFT staking models.

Configure your hardhat.config.js or foundry.toml to connect to a testnet. You need test ETH and your deployed ERC-20 tokens. Use the following Hardhat deployment script structure to deploy and link your contracts in the correct order: 1) Deploy the ERC-20 reward token. 2) Deploy the Staking Vault, passing the token address. 3) Deploy the Fee Collector, granting it minting rights or a treasury allowance. 4) Set the Fee Collector's beneficiary to the Staking Vault address. Test the flow by simulating fee collection and verifying reward accrual for stakers using console.log statements or Foundry's forge test.

Thorough testing is non-negotiable for financial logic. Write unit tests for all key functions: stake, withdraw, getReward, and notifyRewardAmount (if using a staking standard). Use forked mainnet tests to simulate real fee generation from integrated protocols like Uniswap V3. Critical security considerations include: reentrancy guards on reward distribution, proper access control on fee withdrawal, and mitigation of inflation attacks by using a virtual shares system. Always estimate gas costs for distribution cycles; for large staker sets, consider merkle-based reward claims or snapshotting to avoid unbounded loops.

Once tested, deploy to a mainnet. Use a multisig wallet (like Safe) as the contract owner. Verify all contracts on Etherscan to provide transparency. Key monitoring steps post-launch include tracking the Fee Collector's balance, the average reward rate (APY) for stakers, and total value locked (TVL) in the vault. Be prepared with an emergency pause function and a clear governance process for adjusting parameters like the fee percentage or distribution schedule. Document the integration process for other developers who need to send fees to your collector contract.

A fee-sharing model is a core economic primitive for decentralized protocols, aligning incentives by distributing a portion of protocol-generated fees to users who stake the native token. This mechanism transforms a token from a purely speculative asset into a cash-flow generating instrument, encouraging long-term participation and network security. Common revenue sources for sharing include swap fees on a DEX, loan origination fees in a lending market, or transaction fees in an L2 sequencer. The design must be transparent, trust-minimized, and resistant to manipulation to ensure sustainable growth.

The system architecture typically involves three key components: a fee accumulator, a staking ledger, and a distribution mechanism. The fee accumulator is a smart contract vault that receives protocol fees, often denominated in a stablecoin or the chain's native gas token. The staking ledger tracks each user's staked token balance and their share of the total stake over time, which is crucial for pro-rata calculations. The distribution mechanism, triggered periodically or by user action, calculates each staker's entitled share and transfers it from the accumulator.

A critical implementation detail is managing accrued rewards without constant state updates, which is gas-intensive. The standard approach uses a reward-per-token or magnitude accumulator. This variable increases as fees are added to the pool, and a user's unclaimed rewards are calculated as the difference between the current global accumulator and a snapshot of the accumulator stored per user at their last interaction. The formula is: pendingRewards = (userStake * (currentAccumulator - userSnapshot)) / precisionFactor. This design, used by protocols like Synthetix and many staking derivatives, allows for O(1) reward updates.

Security considerations are paramount. The fee accumulator contract should have strict access controls, allowing only whitelisted protocol modules to deposit fees. Use pull-over-push for distributions to prevent gas-griefing attacks where mass transfers could fail. Implement a claim function that lets users withdraw their accrued rewards, which also updates their personal snapshot. Guard against inflation attacks by ensuring the reward token (e.g., USDC) and the staked token are in separate, non-rebasing contracts. Regular audits of the mathematical logic are essential.

Here is a simplified Solidity code snippet illustrating the core storage and update logic for a fee-sharing staking contract:

solidityCopy
contract FeeSharingStaking {
    uint256 public rewardPerTokenStored;
    uint256 public totalStaked;
    mapping(address => uint256) public userStake;
    mapping(address => uint256) public userRewardPerTokenPaid;
    mapping(address => uint256) public rewards;

    function _updateReward(address account) internal {
        rewardPerTokenStored = rewardPerToken();
        if (account != address(0)) {
            rewards[account] = earned(account);
            userRewardPerTokenPaid[account] = rewardPerTokenStored;
        }
    }
    function earned(address account) public view returns (uint256) {
        return (
            (userStake[account] * (rewardPerToken() - userRewardPerTokenPaid[account])) / 1e18
        ) + rewards[account];
    }
}

For production systems, integrate with a governance framework to allow token holders to vote on key parameters like the fee-sharing percentage (e.g., 50% of fees to stakers, 50% to treasury) or the distribution schedule. Consider gas efficiency for users on L2s by implementing autocompounding vaults or layer-specific solutions. Successful implementations, such as GMX's esGMX and GLP staking or Lido's stETH revenue distribution, demonstrate that a well-architected fee-sharing model is a powerful tool for bootstrapping and maintaining a decentralized ecosystem's economic security.

A fee-sharing model requires a dedicated smart contract to act as the treasury for accrued fees. This contract must securely receive fees from your protocol's core logic—such as a DEX swap router or lending pool—and account for them before distribution. The primary functions are: collectFees() to receive native tokens or ERC-20s, a mechanism to track total collected fees per epoch, and access control to restrict fee collection to authorized protocol modules. Use OpenZeppelin's Ownable or AccessControl for managing permissions.

For ERC-20 fee collection, the contract must explicitly approve the token transfer from the revenue-generating module. A common pattern is to implement a function like function collectTokenFees(address token, uint256 amount) external onlyOwner. For native ETH/AVAX/MATIC fees, the contract should have a receive() or fallback() function. It's critical to use address(this).balance for tracking and to guard against reentrancy attacks using the Checks-Effects-Interactions pattern or OpenZeppelin's ReentrancyGuard.

The contract must maintain accurate accounting for stakers. This is typically done by recording the total fees collected in a variable that increments with each deposit. To enable fair pro-rata distribution later, many designs snapshot the contract's total fee balance at the end of a distribution epoch. A minimal state might include: uint256 public totalFeesAccrued; and mapping(uint256 epoch => uint256 totalFees) public epochSnapshot;. Emit an event like FeesCollected(address indexed token, uint256 amount, uint256 newTotal) for transparency and off-chain tracking.

Consider gas optimization and upgradeability from the start. Store fee totals in a single uint256 instead of complex arrays, and use unchecked blocks for safe arithmetic where possible (e.g., incrementing totalFeesAccrued). If you anticipate changes to the fee logic, design this as a simple holding contract and delegate complex distribution logic to a separate contract via an upgradeable proxy pattern (e.g., UUPS). This keeps the fee collection contract simple and secure.

Finally, thoroughly test the contract. Write Foundry or Hardhat tests that simulate: fee collection from an approved module, rejection of unauthorized calls, correct handling of both ERC-20 and native tokens, and the accuracy of the accrued accounting. Verify that the contract's balance always matches the internal totalFeesAccrued state. The completed contract forms the foundational layer that feeds into the staking and distribution system built in subsequent steps.

A robust fee-sharing contract requires a secure mechanism to collect protocol fees and distribute them proportionally to stakers. The core architecture typically involves two key contracts: a primary Staking contract that manages user deposits and a FeeDistributor contract that handles the collection and prorated allocation of rewards. This separation of concerns enhances security and upgradability. The Staking contract tracks each user's share via a balanceOf mapping and a totalSupply of staked tokens, while the FeeDistributor calculates rewards per share based on incoming fee payments.

The distribution logic often uses a "rewards per share" accumulator to ensure fairness. When fees are deposited into the FeeDistributor (e.g., in ETH or a stablecoin), the contract calculates rewardsPerShare += (feeAmount * 1e18) / totalStaked. This value accumulates over time. When a user claims rewards, the contract calculates their entitled amount as (userShares * rewardsPerShare) / 1e18 - userRewardDebt. The userRewardDebt is updated on every stake, unstake, or claim to prevent double-spending. This model, inspired by MasterChef-style contracts, is gas-efficient for large staker bases.

Implementing this requires careful handling of decimal precision and security considerations. Use Solidity's SafeMath library or built-in checked math (0.8.x) to prevent overflows. The rewardsPerShare variable should use a high multiplier (e.g., 1e18) to maintain precision when dividing. Critical functions like depositFees() should be protected with an onlyOwner or onlyFeeCollector modifier. It's also essential to implement a timelock or multi-signature wallet for privileged functions to mitigate centralization risks and build trust with stakers.

Here is a simplified code snippet for the core distribution logic in a FeeDistributor contract:

solidityCopy
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract FeeDistributor {
    uint256 public accRewardPerShare; // Accumulated rewards per share, multiplied by 1e18
    uint256 public totalShares; // Total staked shares from the Staking contract
    mapping(address => uint256) public rewardDebt; // Reward debt for each user
    
    // Called by the protocol to deposit fees
    function depositFees() external payable onlyOwner {
        if (totalShares == 0) return;
        accRewardPerShare += (msg.value * 1e18) / totalShares;
    }
    
    // Called by a user to claim pending rewards
    function claimReward(address user, uint256 userShares) external {
        uint256 pending = (userShares * accRewardPerShare) / 1e18 - rewardDebt[user];
        if (pending > 0) {
            rewardDebt[user] = (userShares * accRewardPerShare) / 1e18;
            payable(user).transfer(pending);
        }
    }
}

For production use, integrate this distributor with a staking contract that updates rewardDebt on every stake and unstake action. Consider adding emergency functions to pause deposits, a way to migrate to a new distributor, and events for all state changes to enable off-chain indexing. Audit the final implementation thoroughly, as flaws in reward math can lead to fund loss or exploitation. Resources like the Solidity by Example guide and OpenZeppelin's Contracts library provide essential security patterns for building robust staking systems.

The heart of a fee-sharing model is the distribution logic, which calculates each staker's rightful share of accumulated fees. This requires maintaining accurate accounting for two key metrics: the total amount of staked tokens and the cumulative rewards per token. A common and gas-efficient pattern is to track a virtual rewardsPerToken value that increments as fees are deposited, rather than updating every staker's balance individually. This value represents the amount of rewards earned per single staked token since the contract's inception.

When a user stakes tokens, we must snapshot the current rewardsPerToken value for them. This is stored in a mapping like userRewardPerTokenPaid[userAddress]. When rewards are claimed or new stakes are made, we calculate the user's pending rewards using the formula: pending = (userStake * (currentRewardsPerToken - userRewardPerTokenPaid)) / precisionFactor. This approach, known as reward debt accounting, minimizes state writes and gas costs by deferring calculations until interaction.

The distributeFees function is typically callable by a privileged address (e.g., the protocol's treasury or a dedicated distributor). When fees in the form of ERC-20 tokens are transferred to the contract, this function updates the global rewardsPerToken accumulator. The increment is calculated as: rewardsPerToken += (feeAmount * precisionFactor) / totalStaked. It's critical to perform this update before any state changes that affect totalStaked (like a new deposit) to ensure mathematical accuracy and prevent manipulation.

Here is a simplified core of the distribution logic in Solidity:

solidityCopy
// State variables
uint256 public totalStaked;
uint256 public rewardsPerTokenStored;
mapping(address => uint256) public userRewardPerTokenPaid;
mapping(address => uint256) public rewards;

function _updateReward(address account) internal {
    rewardsPerTokenStored = rewardPerToken();
    if (account != address(0)) {
        rewards[account] = earned(account);
        userRewardPerTokenPaid[account] = rewardsPerTokenStored;
    }
}

function earned(address account) public view returns (uint256) {
    return ((balanceOf(account) * (rewardPerToken() - userRewardPerTokenPaid[account])) / 1e18) + rewards[account];
}

The _updateReward function must be called in all state-changing functions like stake, unstake, and claimRewards.

Security considerations are paramount. Use Checks-Effects-Interactions pattern and reentrancy guards, especially when distributing external reward tokens. The precision factor (e.g., 1e18) must be large enough to minimize rounding errors, which inherently favor the contract by truncating remainders. For production, consider adding a minimum staking period or fee lockup to prevent flash-loan exploits where users stake and unstake rapidly to claim rewards without providing long-term value. Always audit the mathematical integrity of the distribution formulas.

A fee-sharing contract must be non-custodial and trust-minimized. The core logic should allow users to claim their accrued rewards at any time without relying on a privileged admin to trigger distributions. Use a pull-based payment pattern over push-based to avoid gas limit issues and reentrancy risks during batch payments. Accurately track rewards per staker using a cumulative reward per token method, similar to Uniswap V2's accPerShare, which prevents rounding errors and manipulation when users stake or unstake. Always use the checks-effects-interactions pattern to prevent reentrancy attacks when transferring funds.

The most significant risk is reward calculation manipulation. An attacker could deposit a large stake right before a fee distribution to claim a disproportionate share, then withdraw immediately after—a form of donation attack. Mitigate this by implementing a delayed reward eligibility mechanism, where new deposits only start earning after a set number of blocks, or by using a time-weighted average balance. Alternatively, snapshot the accPerShare at the moment of each user's action. Ensure your math uses fixed-point arithmetic with sufficient precision (e.g., Solidity's 1e18 scaling) to avoid truncation errors that could lock funds.

Fee collection itself introduces attack vectors. If fees are in ERC-20 tokens, ensure the contract safely handles fee-on-transfer and rebasing tokens by measuring balance changes instead of trusting transfer return values. For native ETH fees, use call with a reentrancy guard. The contract holding the fees is a high-value target; consider implementing a timelock or multisig for any administrative functions, such as adding new fee tokens or adjusting reward parameters. All state-changing functions must be protected with access controls like OpenZeppelin's Ownable or AccessControl.

Smart contract auditing is non-negotiable for financial logic. Key areas for auditors to review include: the reward accrual math for precision and overflow, the staking/unstaking flow for reentrancy and front-running, the fee collection mechanism for token compatibility, and all access controls. Use established libraries like OpenZeppelin for safe math and security primitives. Thorough unit and forked mainnet tests should simulate edge cases: rapid stake/unstake cycles, zero-value transfers, and the behavior with malicious ERC-20 tokens. Tools like Slither or MythX can perform automated analysis for common vulnerabilities.

Beyond the contract, consider the system's economic security. A model that shares 100% of fees immediately could be drained if the underlying protocol has a bug. A safer design might involve vesting or streaming rewards over time using a solution like Sablier. Transparency is critical: implement events for all key actions (Staked, Unstaked, RewardClaimed, FeesCollected) to allow users and integrators to verify the contract's behavior on-chain. Finally, plan for upgrades. Use a proxy pattern (UUPS or Transparent) to fix bugs, but ensure the upgrade mechanism itself is securely governed to prevent malicious takeovers.

Implementing a fee-sharing model is a powerful mechanism to align incentives between protocol users and stakers. The core architecture involves a fee accumulator contract that collects protocol revenue, a staking vault that tracks user deposits, and a distribution scheduler that calculates and disburses rewards based on a user's share of the total stake. Key decisions include choosing between on-chain fee collection via a designated contract function or off-chain aggregation with periodic settlement, and selecting a reward token (native gas token, protocol token, or a stablecoin).

For secure implementation, several critical patterns must be followed. Always use the Checks-Effects-Interactions pattern to prevent reentrancy attacks when transferring rewards. Implement a pull-over-push mechanism for distributions to avoid gas griefing and allow users to claim rewards at their convenience, which also mitigates risks associated with contracts that cannot receive tokens. Use a dedicated role-based access control system, such as OpenZeppelin's Ownable or AccessControl, to restrict critical functions like fee withdrawal and parameter updates. Thoroughly audit the mathematical logic for division and rounding to prevent precision loss or manipulation.

To move from theory to practice, start by forking and studying established implementations. Review the fee distribution contracts for Curve Finance's veCRV model or Aave's stkAAVE safety module, which are well-audited references. For development, use the Foundry or Hardhat frameworks for testing. Write comprehensive unit tests that simulate multiple reward cycles, varying stake amounts, and edge cases like zero stakers or maximum token supply. Consider integrating with a keeper network like Chainlink Automation or Gelato to trigger periodic reward distributions automatically.

After deploying your contracts, the next step is integration and monitoring. Develop a frontend interface that allows users to view their accrued rewards, stake/unstake, and claim fees. Use The Graph to index staking and distribution events for efficient querying. Implement monitoring alerts for critical events such as failed distributions or abnormal fee accumulation. For protocols with significant value, plan a phased rollout: begin with a testnet deployment, proceed to a guarded mainnet launch with timelocks on admin functions, and finally transition to a more decentralized governance model for parameter updates.

The long-term evolution of your fee-sharing model may involve adding features like tiered rewards for longer lock-ups, delegated staking for liquid staking tokens, or multi-token reward baskets. Continuously monitor gas efficiency, as distribution costs can become prohibitive. Engage with your community to iterate on the model based on real usage data. By building a transparent, secure, and sustainable reward mechanism, you create a stronger economic foundation for your protocol's growth and resilience.