Keep Custody with Token Wrappers

Distribute rewards with Merkl while the reward tokens stay in your treasury until users claim them.

In a standard campaign, you prefund the campaign: you deposit the full reward budget into the Merkl contracts at campaign creation.

Token wrappers remove this step. Merkl distributes a wrapper token instead of your reward token. When a user claims, the wrapper pulls the underlying token from your address and sends it to the user. Your budget stays in your treasury, multisig, or any address you control until the claim.

Merkl stays a distribution layer: it computes who earns what and publishes the Merkle proofs. It never holds your reward tokens.

Why keep custody

• No prefunding: you do not transfer the budget to a Merkl contract. You only spend what users claim.
• Unclaimed tokens stay with you: rewards that users never claim never leave your address.
• Control at any time: revoke the allowance to stop claims. Top up your address to extend the budget. No Merkl operation is necessary.
• Fits your governance: a multisig, a DAO vote, or any custom signer can give the approval.
• No change for users: users claim as usual and receive the underlying token. The wrapper is invisible to them.

Available wrappers

Merkl provides 4 audited wrappers:

• Pull-on-Claim: the standard custody-preserving wrapper. Tokens stay in your address. The wrapper pulls them through an ERC-20 allowance only when users claim. Use it for large airdrops, TGEs, rebasing tokens, and campaigns with an uncertain budget.
• aToken Unwrapper (Aave): the same pull-on-claim mechanism for Aave v3 aTokens. It withdraws from the Aave pool at claim time, so users receive the base asset.
• Auto-Vault (ERC-4626): pulls tokens from your address and deposits them into an ERC-4626 vault (e.g. Morpho, Euler) at claim time. Rewards compound in the vault and do not dilute its base yield.
• Native Token Unwrapper: distributes wETH and unwraps it to native ETH on claim.

Get started

1. Deploy a wrapper from Merkl Studio.
2. Submit a whitelisting request. You cannot use the wrapper in a campaign before Merkl whitelists it.
3. Mint wrapper tokens and create the campaign with the wrapper token as the reward token.
4. Approve the wrapper to spend the underlying token from your address.

For contracts, constructor arguments, and the onchain calls, read the token wrappers developer guide.

Time-gate 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. On that date, give the approval. The Merkl team then shows the token again, and users can claim.

Use this for TGEs, where tokens must become claimable only after a set date.

Example: renew a campaign without waiting for leftovers

Without a wrapper, you must wait for a campaign to end and recover its leftovers before you reuse them. With a Pull-on-Claim wrapper, you do not wait:

1. Launch a campaign with a budget of 100k wrapped tokens.
2. A few hours before the end, you see that only ~80k will be distributed. 20k will stay undistributed.
3. Create the renewal campaign immediately with another 100k wrapped tokens.
4. Do nothing with the 20k leftovers. They are wrapper tokens, so they are only accounting. No user claims them, so the wrapper never pulls the matching underlying tokens from your address.

Result: no downtime between campaigns, no idle capital, and no leftover recovery. Your treasury only pays for what users claim.

Other custom claim logic

A wrapper's onClaim hook can run any onchain action when a user claims. Other possible use cases:

• Vesting and slashing: enforce vesting schedules or penalties for early withdrawals.
• Time-locked transfers: issue non-transferable tokens that unlock after a set period.
• Redeemable tokens: distribute placeholder tokens that users redeem later for the real asset.