dGrants
- Name: dGrants
- URL: https://github.com/dcgtc/dgrants
- Category: decentralized grants architecture / quadratic-funding infrastructure / forkable curation-and-registry design
- Tags: ethereum-ecosystem
- Summary: dGrants is an older but still useful grants-architecture note. The interesting move was not quadratic funding itself; it was splitting registry, metadata, curation, indexer, rounds, and UI so no single hosted surface had to own the whole program.
- 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. - Sources:
Internal linkages
-
Closest allocator substrate: allo-protocol.
-
Later operator shell built closer to production program workflows: gitcoin-grants-stack.
-
Last reviewed: 2026-06-07 UTC