Drips primary sources — 2026-05-09

What I reviewed

• Official docs:
  • https://docs.drips.network/
• Official repositories:
  • https://github.com/drips-network
  • https://raw.githubusercontent.com/drips-network/app/main/README.md
  • https://raw.githubusercontent.com/drips-network/contracts/master/README.md

Key takeaways from primary sources

• Drips is best categorized as dependency-directed open-source funding infrastructure rather than as a generic donation app. The docs repeatedly center software dependencies, maintainers, and recurring support.
• The core mechanism is the combination of sender-controlled Drip Lists and receiver-controlled maintainer/dependency splits. Money does not stop at one recipient; it can keep flowing down a dependency graph.
• GitHub repositories function as fundable project identities even before maintainers claim them, which means registry/legibility power sits partly in the GitHub mapping layer, not only in wallet ownership.
• Drip Lists are an important separate control surface because ecosystems and donors can publish their own curated lists, and other users can fund those lists instead of constructing raw recipient sets from scratch.
• The docs’ monthly split cadence matters analytically: Drips is not just real-time streaming in the Superfluid sense, but a system where continuous inflow configuration and periodic graph settlement coexist.
• The app README broadens the picture beyond the raw protocol by highlighting RetroPGF and bounty-style use cases, showing that Drips can act both as a primitive and as an ecosystem-program operating surface.
• The contracts README confirms the protocol layer is about streaming and splitting ERC-20 tokens on EVM chains, while the docs emphasize the application-level open-source dependency thesis.

Specific source signals worth retaining

• Docs landing page / introduction: strongest articulation of Drips as support for open-source projects with built-in dependency splitting.
• Docs flow description: says anyone can create a Drip List for up to 200 GitHub repositories, Ethereum addresses, or other Drip Lists, and that distributions are automatically split on a periodic schedule.
• Docs project-claim flow: shows repositories can be funded while unclaimed, then later claimed by maintainers who define maintainers and dependencies.
• Docs dependency-tree explanation: clearest expression of the project’s main mechanism — a global dependency tree that routes support toward upstream software.
• App README: confirms one-time and continuous funding, dependency forwarding, Drip Lists, and end-to-end RetroPGF round support.
• Contracts README: confirms the protocol is an EVM ERC-20 streaming-and-splitting system rather than only a hosted funding site.
• GitHub organization overview: useful confirmation that Drips maintains app, contracts, docs, indexer, and query-layer repositories, i.e. a fuller protocol stack rather than a single web frontend.

Why this entry belongs in the corpus

• Drips is a strong addition because it represents a genuinely different answer to public-goods funding: route money through dependency structure instead of only through grant rounds, impact attestations, or project registries.
• It complements Allo, Gitcoin Grants Stack, Karma GAP, Hypercerts, and Open Source Observer by covering the layer where capital follows maintained software graphs and donor curation rather than milestone memory or impact evaluation.
• The reusable insight is that public-goods funding can centralize not only in allocators and evaluators, but also in whoever defines dependency edges, publishes curated funding lists, controls project-identity mappings, and decides payout cadence.