Autoclaim
How Merkl distributes rewards
Every Merkl campaign accrues rewards to users based on their on-chain activity. Getting those rewards into user wallets happens in one of two ways:
- Pull (default): Rewards accrue and are made claimable through a Merkle proof. Users visit the app (or your interface) and claim when they choose. They pay their own claim gas. This is how Merkl works out of the box.
- Push / Autoclaim (add-on): Merkl runs claiming for you in the background and pushes rewards directly to user wallets on a schedule you define. Users never have to claim, and you never have to build claiming into your product.
Neither model is strictly better; they serve different goals. Many partners run pull for their crypto-native power users and push for everyone else.
The Pull model
Rewards sit as claimable balances. The user triggers the claim.
Benefits
- Full transparency: Users see exactly how much they earned and actively claim it, which keeps them engaged with the app and creates a recurring touchpoint.
- Unclaimed rewards are recoverable: If a user never claims, or loses their keys, the rewards are not lost. You can recover and recycle unclaimed rewards back into the program instead of writing them off. Many teams end up effectively distributing less than they initially planned for, lowering their cost of capital.
- User-controlled tax timing: In jurisdictions where receiving or transferring rewards is a taxable event, the user decides when to trigger it by choosing when to claim.
- No gas cost to you: Users pay their own claim gas, so distribution carries no protocol-side transaction cost.
- Rewards only reach users who want them: Passive or dormant wallets do not receive dust, which reduces unnecessary sell pressure and keeps distribution clean. Dead wallets also do not claim the rewards.
The Push model (Autoclaim)
Merkl monitors claimable balances and submits the claim transactions itself, delivering rewards to user wallets automatically.
Benefits
- Excellent UX: No user action required. Rewards simply appear in wallets, which is ideal for onboarding non-crypto-native users and removing the friction that causes drop-off.
- No API integration needed: Merkl runs entirely in the background. On your side you only display the user's balance; there is no claim flow to build or maintain.
- Lower support burden: No "how do I claim" tickets, no stuck-claim troubleshooting.
Autoclaim features
Autoclaim is fully configurable so you control cost and behavior:
- Claim cadence: Choose how often Merkl pushes rewards (for example daily, weekly, or on a threshold).
- Minimum eligibility amount: Set a minimum dollar value per user before a claim fires, so you never spend more on gas than the reward is worth.
- Scope by campaign and reward: Apply Autoclaim only to the specific campaigns and reward tokens you choose.
- Audience targeting: Turn it on for all users, or for a defined subset (for example a segment or allowlist), and keep everyone else on pull.
Pricing
Autoclaim is priced on two separate lines:
- A tiered service fee: Merkl's managed infrastructure.
- Gas: passed through at cost.
Keeping them separate means you only pay for the gas actually spent, and gas-price swings never change your service fee.
Service tiers
| Tier | Platform fee / mo | Included claims / mo | Overage rate |
|---|---|---|---|
| Starter | $500 | 5,000 | $0.09 / claim |
| Growth | $2,500 | 30,000 | $0.07 / claim |
| Scale | $5,000 | 100,000 | $0.045 / claim |
| Enterprise | Custom | Custom | $0.02+ / claim |
The platform fee covers the off-chain infrastructure that runs claiming (monitoring, transaction execution, signing, and support) plus an included claim allotment. Claims beyond the allotment are billed at the tier's overage rate. Per-claim rates fall as you scale because fixed infrastructure is spread across more claims.
Gas
Gas is fronted by Merkl and passed through at cost plus a 50% handling fee. The handling fee covers:
- The cash-flow float.
- Failed or reverted transactions.
- Short-term gas-price movement between spend and invoice.
Gas is metered per transaction and reported per chain, so the line is fully auditable.
Billing
- Service fees are invoiced at the start of the month, in advance, for the month ahead.
- Gas is invoiced at the end of the month, in arrears, for gas actually consumed. If the subscription renews, that gas charge is combined onto the same invoice as the next month's service fee.
In practice you receive one invoice per cycle. For example, the invoice at the start of Month 2 contains Month 2's service fee plus Month 1's actual gas.