merkl-primary-sources-2026-05-11

Merkl primary sources

Collected: 2026-05-11 UTC

Primary sources reviewed

• https://merkl.xyz/
  • Official homepage
  • Used to confirm Merkl’s self-description as an incentive platform and to anchor the product surface around distribution studio, app, and status tooling
• https://docs.merkl.xyz/merkl-mechanisms/technical-overview
  • Official technical overview
  • Used to confirm the core architecture: onchain campaign creation via Distribution Creator, offchain reward computation, merkle-root publication through Distributor, public reward files, and the 1–2 hour dispute window
• https://docs.merkl.xyz/merkl-mechanisms/reward-forwarding
  • Official reward-forwarding docs
  • Used to confirm that Merkl treats indirect holders behind staking contracts, vaults, Morpho markets, and Pendle positions as reward recipients through integrated forwarder logic and linked subcampaigns
• https://docs.merkl.xyz/merkl-mechanisms/customization-options
  • Official customization docs
  • Used to confirm the control surfaces around whitelists, blacklists, protocol filters, view-function gates, event-derived eligibility, token/NFT boosts, API boosts, privacy modes, and Merkl-team-managed wiring for some custom logic
• https://github.com/AngleProtocol/merkl-contracts
  • Official smart-contract repository
  • Used to confirm the contract split between DistributionCreator and Distributor and to anchor Merkl as a deployable incentive-distribution stack rather than only a hosted dashboard
• https://raw.githubusercontent.com/AngleProtocol/merkl-contracts/main/README.md
  • Repository README
  • Used to confirm the contract roles, operator-settable reward-token minimums and campaign fees, and the existence of audits

Notes

• Merkl cleared the bar because it is not just another “points and rewards” frontend; it decomposes incentive distribution into campaign-definition contracts, an offchain computation engine, merkle-root publication, dispute bots, forwarder integration, and optional API-driven eligibility/boost logic.
• The most important analytical split is between campaign funding and rule declaration onchain versus reward computation and proof serving offchain. Merkl explicitly says the engine reconstructs positions exhaustively from events and invariant checks rather than discretionary snapshots, but the engine is still a meaningful trust and operations surface.
• The dispute window is what keeps the system from collapsing into a pure trusted-operator model. Anyone can challenge a root by posting the dispute token, and Merkl emphasizes independent dispute bots as a security layer. That makes Merkl useful as a comparison class for oracle-style watcher systems as much as for emissions products.
• Reward forwarding is the strongest reason to keep the entry. It turns incentive distribution into a protocol-graph interpretation problem: the system must decide how rewards flow through vaults, staking wrappers, lending singletons, and Pendle-style token splits instead of merely paying the direct token holder.
• The customization docs show that Merkl is also a policy layer. Eligibility can depend on sanctions lists, World ID, smart-account creation events, holding-duration thresholds, protocol-level forwarding restrictions, or offchain APIs. That means the product is partly a programmable compliance-and-segmentation surface for incentive campaigns, not only a reward calculator.
• Several controls still sit with the operator or team: some custom hooks require Merkl team involvement, address remapping is team-managed, production dispute-bot code is not open sourced, and the public API/frontend are practical distribution chokepoints even when the underlying claims settle through onchain distributor contracts.
• This entry belongs in the active corpus because it gives the incentive-markets branch a missing compute-and-routing layer between raw token emissions and explicit bribing / vote-market systems.