Summary: Karma GAP is best understood not as a generic grants dashboard, but as an onchain reporting and public grant-memory layer that links project identities, grant records, milestones, updates, and impact attestations through Ethereum Attestation Service schemas. Its reusable mechanism is the conversion of messy grant reporting into portable, structured attestations that communities, evaluators, and future funders can read without depending on one forum thread or one grants platform. That makes Karma GAP a useful comparison class for Hypercerts, Open Source Observer, grants ops tooling, and any ecosystem where reputational power comes from deciding how work, progress, proof, and impact become legible.
What it does:
Lets builders create a persistent project profile representing the team or initiative behind multiple grants
Links grants from different communities and networks back to that shared project identity so funding history accumulates in one place
Stores grant details, milestones, milestone updates, regular grant updates, and impact attestations as structured onchain data using EAS schemas
Gives grant managers and communities a public surface for reviewing progress, proof of work, and historical performance instead of relying on scattered forum posts and external links
Supports multi-network deployment across ecosystems such as Optimism, Arbitrum, Celo, Scroll, and Lisk
Publishes contracts and SDK surfaces showing that the protocol is meant to be used as infrastructure, not only through Karma’s own frontend
Key claims:
Karma’s docs explicitly define the problem as scattered grant reporting, weak reputation portability, and lack of permissionless structured data for evaluating grantee impact
The protocol’s core mechanism is EAS-backed structured reporting: grant details, milestones, milestone updates, grant updates, and impact attestations are all treated as onchain records rather than informal narrative posts
The strongest design choice is the split between a long-lived project profile and multiple linked grants, because it turns grant performance into portable identity/reputation rather than one-program-local history
The docs emphasize that communities are not required to use Karma’s interface and may build their own, which means Karma is trying to become a data/attestation substrate rather than only a reporting app
Builder-facing docs repeatedly describe milestone verification and proof-of-work review, showing that practical authority still sits with evaluators, grant managers, and community verification norms even when reporting is put onchain
Karma positions impact attestations as future-funding inputs, which makes the protocol useful as a reputational memory layer for retroactive and forward-looking grant programs
The supported-networks and add-grant flows show that cross-ecosystem identity portability is part of the product thesis: one project can accumulate grants from multiple communities and networks under one public profile
Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official docs plus the official gap-contracts repository; see ../whitepapers/karma-gap-primary-sources-2026-05-09.md.