Security at Merkl

How Merkl protects customer data, funds, and systems: architecture, encryption, access control, secure development, and incident response

Merkl is the onchain distribution infrastructure used by stablecoin issuers, fintechs, exchanges, tokenized funds, and DeFi protocols to send rewards to their users. Security is a precondition for that role. This page describes how Merkl protects customer data, funds, and systems.

Merkl's security model rests on three principles:

Non-custodial for users — users keep full control of their assets; Merkl only processes claims.
Transparency — every distribution result is published before it takes effect, and anyone can contest it.
Defense in depth — layered controls across contracts, infrastructure, and processes.

Custody model

For users, Merkl is non-custodial. Users keep full control of their assets and only interact with Merkl to claim rewards. Merkl never holds user funds or keys: for users, Merkl adds no smart contract risk beyond what is already involved in their underlying onchain activity.

For program managers, control depends on the campaign setup. In a standard campaign, the reward budget is deposited into the audited Merkl contracts at campaign creation. Program managers who want to keep control of their funds can distribute through a token wrapper: funds stay under their control, exposure is limited to a revocable token approval or credit delegation, and they can stop the distribution at any time.

Smart contract security

Open source: the Merkl contracts (DistributionCreator, Distributor) are publicly available on GitHub.
Audited: contract audits, along with deployed addresses per chain, are published in the developer documentation.
Merkle-proof claims: rewards are claimable only with a valid merkle proof against the onchain root, so the contract enforces exactly what was computed and published.

Transparent reward computation

Every distribution result is public and contestable before it takes effect:

Public reward files: each onchain reward update publishes the matching reward file on the Merkl status page. Anyone can inspect exactly which address receives what, for past and current distributions.
Dispute period: after each reward update, a 1–2 hour dispute period runs before rewards become claimable. During this window, anyone can contest an incorrect allocation onchain, which halts the distribution before it takes effect. See Disputes.
Independent dispute bots: the Merkl team operates several independent dispute bots on separate infrastructure. They re-verify every published reward file and provide redundancy against a compromise of the update process.

Data protection and encryption

Encryption in transit: all traffic to Merkl services (Merkl App, Merkl Studio, Merkl API) is encrypted with TLS. Plain HTTP is not served.
Encryption at rest: production databases and backups are encrypted at rest.
Minimal personal data: Merkl primarily processes public onchain data (addresses, positions, transactions). The personal data Merkl collects is limited and governed by the Privacy Policy.
No key custody: Merkl never holds user private keys or seed phrases. Users interact through their own wallets.

Infrastructure security

Isolated production environment: Merkl services run as containerized workloads on Kubernetes, with production isolated from development and staging.
Gateway-fronted services: only public gateways are exposed to the internet. Internal services, databases, and job runners are not directly reachable.
Secrets management: credentials and signing keys are stored in dedicated secret management, never in the codebase.
Monitoring and alerting: all services emit structured logs and metrics. The team monitors production continuously and is alerted on anomalies, failed jobs, and onchain irregularities.

Access control

Least privilege: access to production systems is restricted to the engineers who operate them, with scoped, per-service credentials.
Strong authentication: multi-factor authentication is enforced on the systems that manage code, infrastructure, and deployments.
Key segregation: keys used for onchain operations are segregated from application infrastructure and restricted to their single purpose.

Secure development

Peer review: every change reaches production through a reviewed pull request.
Continuous integration: automated tests, type checks, and linting run on every change before deployment.
Staged rollouts: changes to reward computation are validated against reference test cases and sandbox environments before they reach production chains.
External review: security researchers are encouraged to test Merkl through the Bug Bounty Program, with rewards of up to $100,000.

Incident response and responsible disclosure

Dedicated channel: report vulnerabilities to [email protected]. Machine-readable contact information is published at app.merkl.xyz/.well-known/security.txt (RFC 9116).
Bug bounty: the Bug Bounty Program rewards responsible disclosure, up to $100,000 for critical vulnerabilities.
Onchain circuit breaker: the dispute mechanism can revoke an incorrect merkle root before rewards become claimable, containing computation incidents before funds move.
Triage and remediation: the team acknowledges valid reports, prioritizes by severity, and keeps reporters informed of remediation progress.

Compliance and privacy

Legal entity: Merkl is operated by Angle Labs, Inc.
Policies: the Privacy Policy and Terms of Service are publicly available.
Due diligence: for security questionnaires, audit reports, or compliance documentation, contact [email protected].