On-chain ERC-20 streaming and split routing for funding open-source projects and dependency trees. Per-second accounting with no escrow lockup — supporters fund a balance and Drips meters payouts to recipients (addresses, GitHub repos, or nested Drip Lists).
- 01retroactive public goods funding
- 02open-source dependency funding
- 03Drip Lists (split routes)
- 04continuous donations
- 05ecosystem grants
- pnpm add @drips-network/sdk viem
| Variable | Scope | Description |
|---|---|---|
| DRIPS_CHAIN_ID | Client | Numeric chain id. Drips is deployed on Ethereum mainnet, Optimism, Filecoin, Polygon, Base and a few others — confirm the address book in @drips-network/sdk. |
Use `@drips-network/sdk` for streaming + split routing. Create a `DripsClient` with a viem `publicClient`/`walletClient` for the target chain. Call `createDripList({ name, recipients: [{ accountId, weight }], description })` to mint a list NFT — recipients can be Ethereum addresses, GitHub repo URLs (resolved to a Repo Driver account), or other Drip List IDs. Fund with `setStreams({ tokenAddress, balanceDelta, newReceivers: [{ accountId, config }] })` where `config` packs amount-per-second + start + duration. Recipients call `collect(accountId, tokenAddress, transferTo)` to withdraw. Solvency is on-chain: if a sender's balance hits zero, the stream simply stops paying — there is no liquidation.
- ⚑Drips streams are not escrowed — once balance runs out, the stream stops mid-period; recipients must monitor solvency themselves.
- ⚑Per-second amounts are `uint160` packed with start/duration; the SDK rounds down — extremely small per-second rates round to 0 and emit a stream that pays nothing.
- ⚑GitHub-recipient identities are claimed via the Repo Driver by proving repo ownership (FUNDING.json + signed commit). Unclaimed funds accumulate but are uncollectable until the maintainer claims the account.
- ⚑Drip List NFTs are transferable — whoever owns the NFT can rewrite the splits. Treat ownership like a governance key.
- ⚑`squeezeStreams` lets a recipient pull pending balance from the sender's most recent cycle; if you forget to call it before `setStreams` the unsqueezed amount is lost to the protocol.