Drips

Summary

Drips is an EVM protocol and app for streaming and splitting ERC-20 tokens, built to make open-source software funding flow like water through a dependency graph. It emerged from the Radicle/Radworks ecosystem (the decentralized code-collaboration project co-founded by Eleftherios Diakomichalis) as "Radicle Drips." V1 (launched in early 2022 at v1.drips.network) focused on creator memberships: fans dripped funds to creators in exchange for NFT community tokens, with 17 NFT-gated communities launched. V2, deployed to Ethereum mainnet on July 13, 2023, pivoted decisively to open-source dependency funding: sponsors stream funds to "Drip Lists" of up to 200 GitHub repositories, Ethereum addresses, or other Drip Lists, and each recipient can forward a percentage of everything it receives to its own dependencies — recursively building what Drips calls a "global dependency tree." ENS, the Ethereum Foundation, Filecoin (FIL-RetroPGF-2), Scroll, UNICEF, and Octant have used it for dependency funding, RetroPGF payouts, and hackathon rewards. It remains an active, ongoing protocol supported by Radworks.

Design (Mechanism)

The V2 protocol (audited via a $90,500 Code4rena contest in January 2023) is organized around three layers:

• Core streaming and splitting. Drips.sol implements per-second ERC-20 streaming with fixed accounting cycles (mainnet uses a 7-day cycle); Splits.sol lets any account redirect a configured percentage of all funds it receives to other accounts. Streams accumulate off the critical path and are collected periodically, keeping gas costs amortized rather than per-payment.
• Driver-based identity. Rather than tying accounts to addresses, the protocol uses abstract account IDs managed by "driver" contracts, each controlling a range of IDs: AddressDriver (plain Ethereum addresses), NFTDriver (transferable account ownership via NFTs), ImmutableSplitsDriver (frozen split configurations), and — the key innovation — RepoDriver, which assigns a fundable account ID to any GitHub repository. Maintainers claim a repo's accumulated funds by proving control (placing a FUNDING.json in the repo, verified via oracle), meaning projects can receive money before anyone has claimed them.
• Drip Lists and recursive splitting. A Drip List assigns percentage shares across up to 200 recipients. Funds streamed to the list are split to recipients monthly (last Thursday); claimed projects then split a maintainer-configured share onward to their own dependency lists, and so on down the tree. A Caller contract batches operations and supports signed permissions.

The contracts use an EIP-1967 transparent proxy with pause/upgrade governance (Managed.sol), GPL-3.0 licensed, with an Immunefi bug bounty. On top of the protocol, the app added RetroPGF tooling (nomination, voting, automated onchain payouts) and, by Q4 2024, gasless claiming and multi-network support, deploying to Filecoin mainnet for FIL-RetroPGF-2 (January 2025 payouts) and later Metis.

Outcome

Ongoing. Drips found real institutional adopters rather than retail virality: ENS streamed $50,000 USDC over six months to seven critical dependencies (e.g., libraries ENS relies on), publicized on the ENS blog; Radworks proposed ~$1M over a year to dependencies of its own ecosystem at V2 launch; Filecoin chose Drips as the distribution rail for FIL-RetroPGF-2 — the protocol's first non-Ethereum deployment; Scroll used it for hackathon voting and payouts; Octant and the Ethereum Foundation ran dependency-funding programs through it. The team has continued shipping through 2024–2025 (multi-network infrastructure, "Wave" PR-reward programs). No exploits of the V2 protocol have been publicly reported. Aggregate network-wide funds distributed: Unknown / not found. V1's creator-membership model was quietly retired (archived at v1.drips.network) — a real pivot, though not a protocol failure.

Why it worked

• It funds the graph, not just the node. Recursive splitting means a donation to a visible project automatically reaches the invisible libraries underneath it — directly attacking the "roads and bridges" problem where infrastructure maintainers capture none of the value above them.
• Claimable-before-claimed accounts. RepoDriver's oracle-based GitHub identity lets sponsors fund any repository immediately; money waiting onchain is a strong incentive for maintainers to show up and claim, solving the cold-start coordination problem.
• Streaming fits salaries. Continuous per-second flows match how maintenance work is actually consumed (continuously), unlike lumpy grants, and cancellability lowers sponsor commitment risk.
• Institutional wedge. Selling to DAOs and foundations (ENS, Filecoin, Scroll) with treasuries and public-goods mandates proved a better fit than chasing individual donors.

Limitations and criticisms

• The V1 creator-membership product did not find traction and was abandoned in favor of the dependency-funding pivot — a costly early pivot, even though the eventual product found its footing.
• Adoption remains dependent on a handful of crypto-native institutional sponsors; there is little evidence of organic, broad-based funding from commercial consumers of open source, and total flows (tens to hundreds of thousands of dollars per program) are small relative to the scale of the FOSS sustainability gap.
• Monthly split cadence and Ethereum mainnet gas costs add friction for small recipients; the team's gasless claiming and multi-chain work is an implicit acknowledgment.
• Drips itself is sustained by Radworks (RAD treasury) rather than protocol revenue — the funder of public goods is itself treasury-subsidized.

Lessons

• Make the dependency graph a first-class financial object. Percentage-based recursive splits are a simple, composable primitive that converts one donation into supply-chain-wide funding — a genuinely novel mechanism versus flat donation platforms.
• Let funds arrive before identity. Escrowing money against an oracle-resolvable identifier (a GitHub repo) inverts the usual onboarding order and creates pull, not push, adoption for recipients.
• Pivot from consumers to institutions when funding public goods. Individual patronage (V1 memberships) underperformed; treasuries with explicit public-goods mandates became the real customers.
• Driver-based account abstraction ages well. Separating account IDs from addresses let the same core contracts support addresses, NFTs, and GitHub repos — and later new chains — without redesign.
• Distribution rails are a product. Drips' RetroPGF payout tooling (Filecoin, Scroll) shows that the "last mile" of grant programs — voting to onchain payment — is itself a defensible niche.

Redesign (EDITORIAL — hypothesis, not fact)

This section is editorial speculation, not documented fact. Drips' binding constraint is sponsor demand, not mechanism design. A redesign could target the commercial consumers of open source rather than crypto treasuries: (1) a "dependency tax" SDK that lets companies attach a small percentage of cloud or SaaS spend to their lockfile's actual dependency tree, computed automatically from package manifests rather than hand-curated 200-item lists; (2) matching-market mechanics — quadratic or cap-and-match pools layered on Drip Lists so institutional money multiplies small individual streams instead of substituting for them; (3) publishing claimed-versus-unclaimed escrow balances as a public leaderboard to convert waiting funds into recruitment pressure on maintainers; and (4) moving default deployment to a low-fee L2 with mainnet only as a settlement option, shortening the split cadence from monthly to weekly so small recipients feel the flow. The recursive-split primitive is sound; the redesign problem is demand aggregation.