Summary: dGrants is best understood not as just another quadratic-funding front end, but as an attempt to decompose Gitcoin Grants into replaceable public infrastructure: an immutable onchain grant registry, IPFS-backed metadata, permissionless matching rounds, pluggable curation, public indexing, and forkable UI. Its reusable mechanism is the explicit separation between a permissionless registry and the curation layers needed to make that registry usable. That makes it a useful comparison class for Allo Protocol, Gitcoin Grants Stack, grant-list standards, and any public-goods funding system where the real power sits in indexing, eligibility, discovery, and round operation rather than in the matching formula alone.
What it does:
Proposes and implements a decentralized-grants architecture aimed at making Gitcoin-style grants more open, composable, and non-interventionist
Uses a minimal onchain grant registry that stores owner, recipient, and a metadata hash rather than a full mutable project record
Pushes rich grant metadata into content-addressed storage such as IPFS so grant records are tamper-evident and portable
Lets anyone create matching rounds with their own funding pools and custodians instead of reserving round creation to a single operator
Treats curation as a separate pluggable layer, including grant lists and even experimental prediction-market-based ranking
Relies on public indexing and a forkable web UI so community members can rebuild or replace discovery and browsing surfaces
Key claims:
The design spec explicitly describes dGrants as an alternative design for Gitcoin Grants focused on openness and non-intervention by the Gitcoin team, which is the clearest reason to catalog it as governance architecture rather than only an app
The spec’s objective list is analytically important because it names the target properties directly: permissionless participation, transparency, affordability, security, and composability
The architecture section separates core components — grant registry, rounds, checkout, curation, indexer, UI, and user store — showing that the project’s key insight is modularization of the grants stack rather than reinvention of quadratic funding itself
The grant-registry design is useful because it keeps onchain state minimal and immutable while moving descriptive project data to IPFS, making project identity portable but also making metadata availability and pinning part of the practical trust model
The rounds section says anyone can create a matching round, but the matching-pool custodian still has final say on distribution, which is a good reminder that decentralizing round creation does not eliminate operator power
The curation section is arguably the most valuable part of the design: it says users should be able to swap between curation strategies, including grant lists analogous to Uniswap token lists, rather than pretending a permissionless registry can solve spam and fraud by itself
The spec’s discussion of prediction-market curation is worth retaining even if it never became dominant, because it makes explicit that grant discovery can itself become an economic game layered on top of funding
The indexer and SPA sections show that the project treats public data access and forkable interfaces as first-class requirements, not as post-hoc developer conveniences
Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official repository README and the detailed ChainSafe design specification in the repo; see ../whitepapers/dgrants-primary-sources-2026-05-09.md.
Constitutional contrast: commons-stack is useful when the question is whether funding power lives in a forkable registry-and-round stack or in a thicker treasury-governance framework.
Failure-mode analogue: dGrants is a reminder that permissionless registries do not remove governance; they relocate it into grant lists, indexers, anti-spam filters, UI defaults, and whoever custodians matching pools.