Token Holding Campaigns

Reward users based on their ERC20 token balance over time, supporting AMMs, lending protocols, perpetual DEXes, and any protocol that issues receipt tokens.

Merkl enables the creation of token holding campaigns (also known as ERC20 campaigns), where users earn rewards based on their token balance over time.

At their simplest, these campaigns function like traditional StakingRewards contracts. However, Merkl's high customizability and advanced forwarding mechanisms enable token holding campaigns to support far more flexible and complex use cases, going well beyond the limitations of standard staking systems.

Campaign Design

Distribution Type

In Token Holding Campaigns, users holding an incentivized ERC20 token in their wallet earn rewards based on their balance. How these rewards are allocated depends on the distribution and scoring types and the customization options chosen by the campaign creator.

For example, in a variable reward rate campaign, rewards are distributed proportionally to each user's share of the total token supply. If a user holds 1% of the total supply over a given period, they are eligible to receive 1% of the rewards distributed during that time.

Applications

Token Holding Campaigns are highly versatile, supporting a wide range of DeFi use cases.

Any protocol that issues receipt tokens when users interact with it is automatically supported by Merkl. This includes:

• Constant product AMMs: Uniswap V2, SushiSwap, and similar liquidity pools
• Lending and borrowing protocols: Platforms that emit receipt and debt tokens (ERC20 tokens) such as Aave. Lenders can be rewarded based on their lending amount over time, and borrowers based on their borrowing amount
• Perpetual DEXes: Perp protocols that issue receipt tokens to depositors in trading vaults

Idle Liquidity Rewards

A common application of Token Holding Campaigns is rewarding idle liquidity on a lending venue: paying a fixed APR on the unborrowed balance sitting in a pool, market, or vault.

• Setup: whitelist the contract(s) holding the incentivized token. On Aave, this is the single aToken contract for the market. On Morpho, this is the singleton contract, and Merkl reads every market that uses the token.
• Tracking: Merkl reads the time-weighted idle balance of the token across the whitelisted contracts, down to the block, and pays the configured APR on that balance.
• Cost control: the reward is paid on idle balance only, so cost scales down automatically as utilization rises. At 100% utilization, the idle balance is 0 and nothing is paid.
• Forwarding: rewards reach depositors pro-rata, including those who access the venue through vaults or other third-party wrappers, via Merkl's reward forwarding.

This mechanism suits any token issuer who wants to bound incentive spend to a self-generated yield source, such as a stablecoin issuer redistributing reserve income: the payout never exceeds the target APR, so spend stays capped by design.

Use the idle liquidity campaign template in Merkl Studio to set one up directly. For a deeper walkthrough of this mechanism applied to stablecoin reserve yield, see the Distribute yield with Merkl guide.

Merkl API Integration

The logic for reward computation is independent from the API logic used to compute APRs and TVLs for the associated opportunity.

For the protocol it integrates, the Merkl system can automatically recognize whether a given ERC20 token originates from a specific protocol, and then compute the associated TVL and APR if a campaign is running on it.

If you are unsure whether the Merkl API will properly recognize your token as coming from your protocol before creating a campaign, please contact us on the Merkl Discord by opening a BD ticket to discuss the integration process.