把订阅变成链上资金流
Drips 是一个运行在以太坊上的协议:组织和个人可以直接、公开地资助自己依赖的开源项目。它和普通捐款的差别在时间维度——赞助可以是一次性的,也可以是”每周 X 枚代币”的连续流,按秒结算。设定流速、锁定押金,协议随时间把押金一段段释放给受助方;随时可以停止,已流出的部分不退还。
对收款方,这种结构与订阅制收入类似,但没有中心化计费系统:谁在给你供款、流速多少,全部在链上公开可查。项目主页上那个”支持”按钮背后的嵌入图,读的就是这份链上状态。

依赖转发:钱像水一样往下游流
Drips 的一个特色是把开源依赖关系写进资金路径:维护者可以设定把收到的供款按百分比自动转发给自己依赖的软件包。资助一个上层项目,资金会顺着依赖树向底层扩散,形成”水往下流”的公共物品资助网络。官方还把它用于端到端运行 RetroPGF 式的资助轮次,从申报名单到分发全部在协议里完成。
对 NFT 与创作者场景,同样的流式原语可以承载会员费、连载订阅这类按期计费——收款地址是一个 Drips 账户,而不是一次次催款链接。
流式资助的失败模式
公开资助网络也有它的阴影面:靠 Drips 给一个伪装活跃的仓库供款,钱可能顺着伪造的依赖标识流向农场地址——仓库改名、依赖仿冒(typosquatting)是开源供应链的经典攻击,资助层同样中招。反制办法是把供款对象绑定到经过验证的仓库标识与合约地址白名单,定期复查下游转发路径。协议能证明”钱按规则流”,证明不了”规则指向真项目”,这一层责任在使用者。
与订阅制产品的对照表
SaaS 订阅靠续费按钮与自动扣款,平台掌握取消入口;Drips 的流没有对方这一说:供款人单方配置、单方停止,收款方既不能涨价也不能催缴。收入侧的稳定性因此完全来自自愿延续,这对内容型创作者意味着公开流水会暴露热度曲线——好与坏都写在链上。
押金、流速与停止的账
流式支付的钱从哪里来?设定流速时要一次性锁定押金,押金余额决定这条流还能流多久,余额耗尽流自动停。想流得更久就补押金;不想流了就改配置停止——已结算给对方的部分是终局,协议没有”撤回赞助”功能。
这带来两个容易被忽略的细节。第一,停止的时点决定成本:发现项目停更后越晚动手,白流的部分越多。第二,流的状态需要监控:押金耗尽前没有自动提醒义务,官方工具会显示剩余时长,但盯盘责任在出资人自己。
给创作者侧的账
如果你是收款方,Drips 的流式收入有两笔要算进预期:流进账是持续发生的,入账时刻、单期金额都由配置决定,报税与对账系统要按周期聚合而不是等一张大账单;依赖转发的百分比对所有入账无差别生效,意味着上游给你的资助有一部分会自动漏向你的依赖——对开源维护者这是伦理加分项,对个人创作者则要想清楚比例设多少。另外,Drips 的资助关系是公开的,谁在给你供款、供多少链上可见,这在隐私敏感的场合是优点也可能是负担,上流之前把”被看见”这件事想明白。
上手与排错要点
用 Drips 供款前确认三件事:你支持的仓库地址或账户地址无误(仓库改名或转移会改变标识);所选 ERC-20 在 Drips 支持列表内;押金金额对应的流时长符合预算。取消路径都在协议配置里完成,不需要对方配合,也不依赖任何客服。作为收款方,配置依赖转发比例前先确认下游地址,转发比例对所有入账生效,无法针对单一出资人豁免。
流式协议的具体资产与网络支持会更新,以 2026 年 8 月 Drips 官方仓库与文档为准。本文只解释机制,不构成任何投资或资助建议。
发表评论
还没有评论,来说两句吧。
评论区为展示样式,提交不会被处理。