Summary: Merkl is best understood not as a simple liquidity-mining dashboard or a generic points tool, but as a programmable reward-computation and routing layer for crypto incentive campaigns. Its architecture splits campaign creation and budget deposit onchain from reward computation offchain: campaign creators define rules through the Distribution Creator contract, the Merkl engine reconstructs user positions from protocol events and invariant checks, reward results are compressed into a merkle root and posted onchain through the Distributor contract, and a public dispute window with watcher bots sits between computation and final claimability. The mechanism that makes Merkl especially worth cataloging is reward forwarding: it does not just reward direct token holders, but can trace reward eligibility through staking wrappers, vaults, lending singletons, and other integrated contracts so incentives follow the effective economic exposure rather than the immediately visible address.
What it does:
Lets DAOs and other campaign creators deposit tokens onchain and define time-bounded incentive campaigns through the Distribution Creator contract
Computes user reward allocations offchain from campaign rules, protocol events, and periodic invariant checks instead of discretionary snapshotting
Publishes chain-level merkle roots to a Distributor contract so users can claim many campaign rewards efficiently from one aggregated root
Inserts a 1–2 hour dispute period after reward publication, during which watchers can challenge an incorrect root by posting the dispute token
Supports reward forwarding so indirect holders behind integrated contracts such as staking wrappers, Morpho markets, vaults, or selected Pendle positions can receive rewards attributed through protocol-specific logic
Exposes campaign-level policy controls such as whitelists, blacklists, protocol filters, privacy modes, token/NFT boosts, event-based gating, and API-based dynamic boost or eligibility hooks
Key claims:
The official technical overview describes Merkl as a system where campaign rules are declared onchain, the Merkl engine computes rewards from onchain and offchain data, and the resulting merkle root is pushed onchain for transparent claims, which is the clearest evidence that Merkl is a compute-and-publication layer rather than only an app UI.
Merkl explicitly says the engine tracking is exhaustive and does not rely on discretionary snapshots. Instead it reconstructs positions from events and uses invariant checks to reconcile protocols where events alone are insufficient. That is analytically important because it frames Merkl as an accounting engine with protocol-integration risk, not just a distributor contract.
The dispute process is a major control surface. Newly posted roots remain unclaimable during the dispute period, anyone can challenge by sending the dispute token, a valid dispute revokes the root, and Merkl runs independent dispute bots for redundancy. This makes the security model closer to watcher-based verification infrastructure than to a pure trusted database.
Reward forwarding is the strongest distinctive mechanism in the docs. Merkl says integrated forwarders automatically redirect rewards from the holding contract toward underlying users and can create linked subcampaigns across nested liquidity routes. That turns incentive design into a graph-mapping problem across protocols, not just a flat emissions table.
The customization docs reveal that Merkl is also a policy engine. Campaigns can be filtered by address sets, protocol-level forwarding rules, sanctions-oracle checks, World ID, smart-account deployment events, holding duration, NFT or token boosts, and even external API-returned boosts, which makes Merkl a segmentation and compliance layer for incentive programs as much as a rewards calculator.
Despite the onchain claim path, several practical chokepoints remain centralized or operator-heavy: some custom integrations require Merkl team involvement, address remapping is team-managed, production dispute-bot code is not public, and integrated frontends / APIs remain the easiest route for proofs and campaign visibility.
Merkl is a strong comparison class for Aura, Hidden Hand, Votemarket, Royco, and Boost Protocol because it sits at a different layer of the incentive stack: less about pricing governance influence directly, more about defining, computing, verifying, and routing who actually counts for a reward campaign.
Whitepaper: No canonical standalone Merkl whitepaper surfaced in this pass. The strongest primary materials were the official docs pages for technical overview, reward forwarding, and customization, plus the official smart-contract repository; see ../whitepapers/merkl-primary-sources-2026-05-11.md.