Summary: Drips is best understood not as a donation widget, but as a dependency-directed funding protocol that turns open-source projects, curated funding lists, and software dependencies into a graph for routing ERC-20 support over time. Its reusable mechanism is the split between sender-controlled Drip Lists and maintainer-controlled dependency / maintainer splits, with funds periodically cascading down that graph instead of stopping at the most visible repository. That makes Drips a useful comparison class for public-goods funding systems, retroPGF tooling, and any protocol that claims to fund open source according to real software reliance rather than only committee selection.
What it does:
Lets anyone create a Drip List that routes ERC-20 funding across up to 200 GitHub repositories, Ethereum addresses, or other Drip Lists
Supports one-time donations and ongoing token streams, with distributions periodically split across the configured recipient graph
Lets maintainers claim GitHub repositories as projects, assign maintainer payouts, and define dependency splits so upstream libraries receive a share of inflows
Treats unclaimed GitHub repositories as fundable objects before maintainers onboard, so dependency funding can start before a project creates an account
Exposes a graph structure where one Drip List can fund another list, and projects can themselves split earnings to dependencies, creating recursive routing across software stacks
Includes adjacent application flows such as Drips Wave for recurring bounty-style funding rounds and RetroPGF-style program support in the app layer
Key claims:
The docs explicitly frame Drips around funding open-source projects and their dependencies, which matters because the protocol is trying to route money by software relationship rather than by one-off grant applications alone
The core mechanism is dependency splitting: maintainers do not just receive funds, they can forward percentages of earnings to dependencies, causing capital to propagate through a global dependency tree over time
Drip Lists are a separate control surface from projects themselves, which means ecosystems, companies, and individuals can impose their own curation layer on top of the protocol by deciding which repositories or lists deserve recurring funding
The docs say lists and projects can each include up to 200 split receivers, which is analytically useful because it shows Drips is built around bounded but fairly rich curator-maintained graphs rather than an unstructured donation free-for-all
Unclaimed repositories can already be funded and listed as dependencies, which separates project legibility from maintainer participation and makes GitHub identity a meaningful registry layer in the system
The contracts README emphasizes streaming and splitting ERC-20 tokens at the protocol layer, while the app README adds end-user flows like RetroPGF rounds, showing that Drips combines a reusable payments primitive with a more opinionated public-goods product layer
The docs include an unusually strong decentralization disclaimer: the protocol is described as autonomous and non-custodial, with no entity controlling funds, which is important when comparing it against grant platforms and managed ecosystem programs that keep more operator discretion
Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official docs plus the official app and contracts repositories; see ../whitepapers/drips-primary-sources-2026-05-09.md.
Closest public-goods funding contrast: allo-protocol if the question is programmable allocation versus dependency-routed support.
Measurement and legibility counterpart: open-source-observer is the cleaner comparison when the real issue is which projects or dependencies get rendered visible enough to fund.
Registry-and-curation analogue: dgrants is still the sharpest reminder that an open base layer does not remove the need for curation, discovery, and operator defaults.
Failure-mode analogue: Drips can market itself as neutral dependency funding, but list maintainers, dependency split authors, and GitHub-identity mappings still decide which software graph becomes economically visible.