Additional Features
Important features of Merkl campaigns
Beyond campaign types, distribution methods, and customization options, Merkl offers several advanced features to enhance campaign flexibility and reward management.
❌ Blacklisting
Blacklisting excludes specific addresses from receiving rewards.
If a forwarder is blacklisted, all associated users are also ineligible.
Example of a staking contract blacklist:
A user holds 10 USDA but has staked 6 USDA in a blacklisted staking contract (forwarder).
Only the 4 USDA in the user’s wallet qualifies for rewards.
✅ Whitelisting
Whitelisting restricts rewards to a specific address or set of addresses (e.g., forwarders, or individual users).
Example of Uniswap V3 whitelisting:
A campaign incentivizes LPs in a Uniswap V3 pool with three forwarders — here Automated Liquidity Managers.
The campaign creator whitelists only two forwarders and one user address.
Result:
Only liquidity providers using the two approved forwarders or the whitelisted user will receive rewards
Rewards are distributed normally among whitelisted addresses based on liquidity share.
Whitelisting overrides blacklisting. If an address is whitelisted, all other addresses are automatically blacklisted.
If multiple campaigns run on the opportunity (e.g. Uniswap v4 ETH-USDC), some may have whitelists while others do not. This means that, for the same opportunity, the users receiving rewards can differ.
Users should check the campaign details on the opportunity page to confirm eligibility requirements.
🔥 Run Multiple Campaigns on the Same Opportunity
Merkl allows multiple campaigns to be created simultaneously for the same pool or set of actions.
Why is this useful?
Co-incentives: Different parties can independently add incentives to the same opportunity.
Flexible Stacking: Multiple campaigns can run alongside each other on the same pool or token, supporting different incentive structures.
⏳ Campaigns of Any Duration
Merkl campaigns can run for any length of time, from as short as one hour to as long as six months (or more).
This flexibility allows for:
Short-term boosts (e.g., flash incentives for new launches).
Long-term, sustained incentive programs for ongoing ecosystem growth.
🎭 Infinite Customizability with Token Wrappers
Merkl campaigns can distribute tokens with custom properties, known as token wrappers, to introduce advanced incentive mechanisms.
Examples of Token Wrapper Use Cases:
Vesting & Slashing Conditions: Add vesting schedules or penalties for early withdrawals.
Non-Prefunded Campaigns: Instead of preloading tokens, rewards are pulled from a multisig when users claim (more below)
Time-Locked Transfers: Issue non-transferable tokens that unlock after a set period.
Redeemable Tokens: Distribute placeholder tokens that can be redeemed later.
Merkl provides a suite of template contracts for token wrappers in the Merkl GitHub repository so anyone can build its own token wrapper. Some templates have already been audited by Merkl partners!
Non-Prefunded Campaigns
Non-prefunded campaigns allow you to distribute rewards without transferring tokens upfront. Instead, tokens are pulled from your multisig when users claim.
Contract: PullTokenWrapperAllow.sol
Advantages
Invisible to users: When claiming, users receive the underlying token directly—the wrapper mechanism is fully abstracted. We typically name wrapper tokens with the same name and symbol as the underlying token, ensuring users see no difference in the UI.
Custody retained: Tokens remain in your multisig until users claim. Typically if your tokens are rebasing tokens, this allows you to retain the rebasing yield before tokens are claimed
Controlled exposure: Your allowance determines maximum claimable amount, and how much your multisig and protocol is exposed to Merkl
Flexible timing: Control when rewards become claimable by setting allowance. We can hide the token from the UI and API until you decide to show it as claimable.
Disadvantages
Balance management required: If your multisig lacks sufficient balance or allowance, users cannot claim—this can be misleading for users
How It Works
Deployment: We deploy the wrapper contract and set your address as admin
Minting: Mint wrapper tokens to your address by calling:
Campaign setup: Use the wrapper token address as the reward token when creating your campaign. Typically if you do an airdrop, you'll need to enter the wrapper token as the address of the reward token in your airdrop file
Funding: Before users can claim, ensure your multisig has:
Sufficient balance of the underlying token
Approved the wrapper contract to spend the underlying token
Progressive Distribution
You can enable claiming gradually by increasing your allowance incrementally, rather than approving the full amount upfront. This gives you fine-grained control over token distribution timing.
For end users, the experience is seamless—they claim the underlying token directly, with the wrapper logic abstracted away.
🌍 Cross-Chain Campaigns
Merkl allows you to incentivize activity on one chain while distributing rewards on another.
How It Works:
Activity is tracked on Chain A (e.g., a protocol running on Arbitrum).
Rewards remain claimable on Chain B (e.g., distributed token stays on Ethereum): the chain where the token is claimable is the chain where the campaign was created
Why is this useful?
Efficient token management: Keeps governance tokens on a single chain, reducing the need for bridging.
Cross-chain flexibility: Supports protocols that operate on multiple chains without fragmenting incentives.
Important considerations:
Some smart contracts on the chain you are incentivizing activity may not exist on the chain where users can claim their reward (or may exist at a different address):
Affected addresses will be unable to claim rewards in this case
Solution: As a campaign manager, you should blacklist any ineligible addresses to prevent reward loss. Or you can reallocate rewards (more below) of addresses that cannot claim to an address controlled by the same provider that can claim its rewards
◀️ Retroactive Campaigns
You can create campaigns in the past to reward OG users. It can start and end in the past or it can end in the future.
Campaign Management
Campaign managers can perform several actions on their live and past campaigns, including:
Last updated