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.

🔥 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

Token wrappers let you attach custom logic to reward distribution. Instead of sending tokens directly, Merkl distributes a wrapper token whose onClaim hook fires when a user claims, executing arbitrary on-chain actions (pulling funds, depositing into a vault, unwrapping, etc.).

Example use cases:

• Vesting & slashing: Enforce vesting schedules or penalties for early withdrawals.
• Non-prefunded campaigns: Tokens are pulled from a multisig at claim time — no upfront deposit required.
• Auto-vault deposits: Deposit into an ERC-4626 vault (e.g. Morpho, Euler) at claim time, so rewards autocompound from the moment they are claimed without diluting base vault yield.
• Native token unwrapping: Campaign distributes wETH, automatically unwrapped to native ETH on claim.
• Time-locked transfers: Issue non-transferable tokens that unlock after a set period.
• Redeemable tokens: Distribute placeholder tokens redeemable later for the real asset.

Setting up token wrappers

Merkl provides audited template contracts in the Merkl GitHub repository for anyone to build their own wrapper.

You can deploy a wrapper directly from Merkl Studio. The following types are available:

• Pull-on-Claim — Tokens stay in your address and are pulled via ERC-20 allowance only when recipients claim. Useful for large airdrops, rebasing tokens, and campaigns with uncertain budgets.
• aToken Unwrapper (Aave) — Same pull-on-claim mechanism, tailored for Aave v3 aTokens: withdraws from the Aave pool at claim time so claimants receive the base asset.
• Auto-Vault (ERC-4626) — Pulls tokens from your address and deposits them into an ERC-4626 vault at claim time. Ideal when rewards should compound inside the vault rather than dilute its base yield.
• Native Token Unwrapper — Distributes wETH but automatically unwraps to native ETH on claim.

Once these wrappers are deployed, all you need to do:

• Approve the wrapper contract to spend the underlying token.
• Hold the underlying tokens in your address.

Time-gating claims for airdrops

The Pull-on-Claim wrapper supports time-gated claims: ask Merkl to hide the token from the app until a specific date. When that date arrives, run the approval and our team will unhide the token, enabling users to claim.

This is particularly useful for TGEs where tokens must only become claimable after a set date. From the user's perspective, only the underlying token appears in their wallet; the wrapper is invisible.

🌍 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:

• Overriding live campaigns
• Cancelling existing campaigns
• Reallocating unclaimed rewards from past campaigns