
Keep custody of your tokens with token wrappers
Run Merkl campaigns without ever transferring your reward tokens — Merkl is just the distribution infrastructure, you stay in control of the fundsMerkl is infrastructure, not a custodian
In most Merkl setups, you prefund the campaign upfront by transferring your reward tokens to Merkl's distribution contracts. For large clients and specific setups, however, we offer a custody-preserving path where you never have to hand over the reward tokens. Merkl remains a distribution layer in both cases (it computes who deserves what and publishes the Merkle proofs), and in this custody-preserving setup the tokens stay in your treasury, multisig, or any address you control until the moment a user actually claims.
This is made possible by token wrappers: small contracts that wrap your reward token and pull the underlying funds from your address on claim via a standard ERC-20 allowance. From the user's perspective, nothing changes: they still claim the underlying token. From your perspective, the budget never leaves your control.

Why this matters
- No prefunding required. No upfront transfer to a Merkl contract. You only spend what's actually claimed.
- Unclaimed tokens stay with you. Users who never claim don't cost you anything, and leftovers remain in your treasury.
- Adjust at any time. Revoke the allowance to pause, or top up your treasury to extend. You don't need a Merkl operation to change course.
- Fits any governance process. The approval can come from a multisig, a DAO vote, or any custom signer, using the same pattern you already have.
How to deploy a wrapper
Deploy one directly from the Studio in a few clicks: Studio → Token Wrappers. Four templates are available:
- Pull-on-Claim: the standard custody-preserving wrapper. Tokens stay in your address, pulled on claim. Best for airdrops, TGEs, and campaigns with uncertain final spend.
- aToken Unwrapper (Aave): same mechanism, tailored for Aave v3 aTokens. Withdraws from Aave on claim so users receive the base asset.
- Auto-Vault (ERC-4626): pulls from your address and deposits into an ERC-4626 vault on claim, so rewards compound from day one.
- Native Token Unwrapper: distribute wETH, auto-unwrap to native ETH on claim.
Once deployed:
- Approve the wrapper contract to spend the underlying token from the address holding your treasury.
- Hold enough underlying tokens in that address to cover expected claims.
- Launch your campaign on Merkl using the wrapper as the reward token.
That's it: no token ever leaves your address unless a legitimate user claims it.
Practical example: renew campaigns without waiting for leftovers
A common pain point without wrappers: when a campaign is about to end, you can't recycle the undistributed budget into the next one until the current campaign closes and the leftovers are returned to your wallet. With a Pull-on-Claim wrapper, you sidestep the wait entirely.
Setup:
- Deploy a Pull-on-Claim wrapper for your reward token.
- Launch your first campaign with a 100k token budget using the wrapped token.
- One week later, the campaign has a few hours left and you can see only ~80k will be distributed, leaving 20k undistributed.
- Without a wrapper: you'd have to wait for the campaign to end, claim back the 20k leftovers, and only then launch the next campaign.
- With the wrapper: create the renewal campaign immediately with another 100k wrapped tokens. You know the 20k will become available later, so you're not double-funding: your treasury only needs to cover net claims.
- When the old campaign ends, claim the 20k leftovers and send them back to the Pull-on-Claim wrapper's address to top it up.
Net effect: zero downtime between campaigns, no idle capital, and no scrambling to top up at the wire.
Learn more
For the full technical breakdown, custom use cases, and time-gated claims for TGEs, read the token wrappers section of the Merkl docs.
Related Guides

Private LP Deals Through Merkl: Why and How
Run negotiated LP deals as private Merkl campaigns: neutral reward computation, real-time payment, funds deposited upfront, fully confidential.
How a Merkl campaign is built: understanding the configuration
Learn how every Merkl campaign is built from a configuration, with its two layers: standard fields and structured inputs, explained simply.