Is Merkl Safe? Inside Merkl's Security Model

A rewards system moves millions of dollars programmatically, to thousands of addresses on dozens of chains. The more value it moves, the bigger a target it becomes.

Securing it is not one feature. It is a stack of layers, each one covering a different way things can go wrong: a wrong computation, a compromised server or key, a user gaming the rules, a bug in a contract, or funds sitting where they don't need to be.

With $1.8B+ in rewards streamed through 70,000+ campaigns since 2023, Merkl has tested these layers at scale, and keeps strengthening them every day.

This article walks through each of them, and how together they let companies stream money through Merkl safely.

In short

• Every distribution goes through a dispute period before it goes live: independent dispute bots re-check it, and anyone can contest it onchain
• Rewards can only be claimed against what was computed and committed onchain, through open source, audited contracts
• Rewards are time-weighted, so the rules are hard to game
• Campaign creators keep control of their funds: the budget can stay in their own wallet until it is paid out to users, with no need to transfer it to Merkl
• Merkl is non-custodial: it only reads onchain activity, so users never deposit anything with Merkl, and Merkl doesn't need to know anything about them beyond a wallet address: no sign-up, no email

Why a payout engine is a target

The biggest hacks in crypto did not hit smart contract protocols. They hit bridges and exchanges: infrastructure built to move money programmatically, where the attack surface is every server, key and process, not one contract.

A rewards system sits in the same risk category. It holds budgets, computes who gets what and sends funds out, continuously. And it becomes a bigger target as the amounts it distributes grow.

Any system that moves funds onchain has to treat security as one of its biggest budget lines. Merkl is designed from that starting point, and a significant share of our resources goes into it. It sometimes makes us slower than we'd like, and without these self-imposed constraints we could ship a faster, smoother product. It's the right tradeoff.

There is also a second risk, which has nothing to do with hacking: people who game the eligibility rules to earn more than their share. We cover both below.

Every distribution can be challenged before it goes live

Merkl computes rewards offchain, which is what makes any rule possible, and pays them out onchain, so anyone can check who received what. Between the two, every update goes through the same path.

1. Computation: the Merkl engine reconstructs each participant's exact position from onchain events and computes every allocation. It also checks its results against onchain values and, if they diverge by more than 1%, reads each position directly onchain to correct them.
2. Commitment: the result is committed onchain as a single Merkle root, and the matching reward file is published on the Merkl status page. Anyone can see exactly which address receives what, for past and current distributions.
3. Dispute period: after each update, a dispute period of 1 to 2 hours runs before rewards become claimable. Several independent dispute bots, run by the Merkl team on separate infrastructure, fetch the reward file, recompute the root and check the allocation. Anyone can also contest an incorrect allocation onchain, which halts the update before it takes effect.
4. Claims by Merkle proof: rewards can only be claimed with a valid proof against the onchain root. The contract enforces exactly what was computed and published, nothing more.

This dispute mechanism is an onchain circuit breaker: an incorrect update can be stopped in hours, before any funds move. It is exactly the safeguard Compound's in-house contract was missing.

If a safety check fails or a data feed has an issue, the engine pauses instead of publishing wrong numbers, and a catch-up mechanism distributes all rewards retroactively at the next cycle. When speed and safety pull apart, Merkl picks safety.

Read how Merkl computes, publishes and secures rewards

An isolated, encrypted infrastructure

The dispute period protects against a wrong computation. Further layers, not all of them public, are designed to stop a compromised server, key or process from pushing a wrong distribution. The first set protects the system itself: how it runs, where secrets live and how data is stored.

Isolated production

Merkl services run as containerized workloads, with production isolated from development and staging. Only public gateways are exposed to the internet; internal services, databases and job runners are not directly reachable.

Secrets and keys

Credentials and signing keys live in dedicated secret management, never in the codebase. Keys used for onchain operations are scoped to production infrastructure, restricted to a single purpose and never accessed by human operators.

Data protection and encryption

All traffic to Merkl services, the Merkl App, Merkl Studio and the Merkl API, is encrypted with TLS, and plain HTTP is not served. All data is encrypted at rest, from production databases and backups to company endpoints and storage buckets. Merkl primarily processes public onchain data, such as addresses, positions and transactions, and the personal data it collects is limited and governed by its Privacy Policy. Merkl never holds user private keys or seed phrases: users interact through their own wallets.

Controlled access, reviewed code, constant monitoring

The second set covers the team and processes around the system: who can access it, how every change reaches production, and how issues are caught.

Access control

Access is granted on the principle of least privilege: each person at Merkl only gets the access their role requires, with scoped, per-service credentials. Passwords are avoided wherever possible in favor of zero-trust access and workload identities, and multi-factor authentication is enforced on the systems that manage code, infrastructure and deployments.

Secure development

Every change reaches production through a reviewed pull request, with automated tests and checks. Changes to reward computation are validated against reference test cases and sandbox environments before they reach production chains.

Monitoring

Every service emits logs and metrics, and the team is alerted on anomalies, failed jobs and onchain irregularities.

Built so the rules can't be gamed

The other risk is people who never touch the infrastructure, only the rules. Snapshot-based programs, including some run by large issuers, are gamed today: deposit just before the snapshot, withdraw right after, and collect a month of yield for capital that spent the rest of the period elsewhere.

Merkl tracks every balance change and rewards the area under the curve: how much each participant held, multiplied by how long. There is no snapshot to time, and capital parked for a few minutes earns a few minutes of rewards. On lending markets, campaigns can also reward only the part of deposits not already earning interest from borrowers, so the same dollar is never paid twice.

Read how time-weighted scoring works

Control for campaign creators

For teams funding a campaign, how much control they keep depends on how the campaign is set up.

• Standard campaigns: the reward budget is deposited into the audited Merkl contracts when the campaign is created, and distributed from there.
• Keep custody of your budget: teams that want to keep control of their funds can distribute through a token wrapper. The budget stays in their own wallet until users receive their rewards, exposure is limited to a revocable token approval or credit delegation, and they can stop the program at any time.

Read how to keep custody of your budget

Non-custodial for users

With Merkl, users never deposit their funds into Merkl. Their assets stay where they already are, in their own wallet, an app or the protocol that runs the campaign, and they keep using them exactly as they would without rewards.

Merkl tracks that activity onchain and computes the rewards offchain. Users only interact with Merkl to receive what they earned, and with autoclaim, rewards land in their wallet without any action on their side. Merkl never holds user funds or private keys, so it adds no smart contract risk beyond the one users already take in the protocols they use.

That is a design choice. Holding user funds would add a layer of custody, and with it a new attack surface. Merkl was built to avoid it entirely.

Users should still assess the protocols they deposit into. Merkl rewards activity in those protocols, it does not secure them.

A public audit trail

Every reward update is published, and every payout lands onchain. Campaign creators and their auditors can check who received what, and when, without having to trust our word for it.

Audited, open source contracts

The Merkl contracts, DistributionCreator and Distributor, are open source and publicly available on GitHub. Funds only move through these audited contracts.

• Code4rena: audits in 2023 and a dedicated Merkl audit completed in January 2026.
• Halborn: audit of the Stellar contracts, April 2026.

Audit reports and deployed addresses for every chain are published in the developer documentation.

Proven at scale

Merkl has streamed $1.8B+ in rewards across 60+ chains, through 70,000+ campaigns for 1,000+ companies. The same infrastructure handled a $634M USDC airdrop for Stable and Hourglass, with $500M claimed within the first 20 hours. Read the case study.

Key takeaways

• Every distribution goes through a dispute period before it goes live: independent dispute bots re-check it, and anyone can contest it onchain.
• The infrastructure is isolated and encrypted, with single-purpose keys, and strict access control, reviewed code and constant monitoring cover the team and processes around it.
• Time-weighted rewards remove the snapshot games that drain many incentive programs.
• Campaign creators can keep their budget in their own wallet, and users never deposit anything with Merkl.
• Every payout lands onchain through audited, open source contracts. None of these layers is ever finished: each one is tested, monitored and improved continuously.

FAQs

Is Merkl safe?

Merkl is designed to keep reward budgets out of reach of attackers, pay every user exactly what they earned, and make the eligibility rules hard to game. Every distribution is published and goes through a dispute period before it goes live, during which independent dispute bots re-check it and anyone can contest it onchain. Its infrastructure is isolated and encrypted, and its contracts are open source and audited. Rewards are calculated on time-weighted positions, so no one can earn them by depositing just before a deadline and withdrawing right after.

Is Merkl audited?

Yes. The Merkl contracts, DistributionCreator and Distributor, are open source and have been audited by Code4rena, most recently in a dedicated Merkl audit completed in January 2026, and by Halborn for the Stellar contracts in April 2026. Reports are published in the developer documentation.

Is Merkl custodial? Does Merkl hold my funds?

Not for users. Merkl only reads onchain activity: users keep their assets in their own wallet or in the protocol running the campaign, and never deposit anything with Merkl. For campaign creators, the budget is either deposited into the audited Merkl contracts or kept in their own wallet through a token wrapper.

How does Merkl check rewards before they go live?

Merkl computes every allocation from onchain data and checks its results against onchain values. Each distribution is then committed onchain and published on the Merkl status page, and a 1 to 2 hour dispute period runs before it goes live. During that window, independent dispute bots re-check the distribution, and anyone can contest an incorrect allocation onchain, which halts it before any funds move.

How does Merkl prevent users from gaming rewards?

Merkl tracks every balance change and rewards how much each user held and for how long, instead of relying on snapshots. There is no snapshot to time, so depositing just before a deadline and leaving right after earns almost nothing. On lending markets, campaigns can also reward only the part of deposits not already earning interest from borrowers.

Can I keep custody of my reward budget?

Yes. With a token wrapper, the budget stays in your own wallet until users receive their rewards. Your exposure is limited to a revocable token approval or credit delegation, and you can stop the program at any time.

Does Merkl collect personal data?

Receiving rewards through Merkl requires no sign-up and no email: a wallet address is enough. Beyond public onchain data, the Merkl App and Merkl Studio use standard cookies: strictly necessary ones to make the interfaces work, and analytics cookies to understand aggregate usage, which users can refuse. Details are in the Privacy Policy, and Merkl never holds private keys or seed phrases.

How do I report a vulnerability?

Email [email protected] or use the contact details published in security.txt. The team acknowledges valid reports, prioritizes them by severity and keeps reporters informed until they are fixed.