钱按区块往前流：ERC-1620 资金流的字段结构与双向确认

工资月付、订阅年付，本质都是“钱随时间转移”。区块链让小额高频支付的成本骤降，于是有人提出：为什么不把一次性付款改成一门按时间流动的水管？ERC-1620 在 2018 年 11 月 24 日给出一套接口化答案，按 ercs 仓库记录状态为 Stagnant。它的动机部分特意提到可逆 ICO：投资款不一次性交给项目方，而是锁进合约按时间释放，项目停摆时投资人能拿回大比例未流动的资金。

一条流由什么构成

标准把流拆成结构体：sender 出资方地址、recipient 收款方地址、tokenAddress 使用的 ERC-20 代币地址、balance 流内剩余资金，再加两组子结构——Timeframe 记录起始区块 start 与结束区块 stop，Rate 记录每次流动的量 payment 和流动间隔 interval。计量单位是区块高度而不是时间戳，这意味着流的推进速度跟随出块节奏，网络节奏变了，日历意义上的“每天多少”也会漂移，读流参数时要换算。标准建议流不接收以太币，只用 ERC-20 兼容代币。

取钱与清算的分工

balanceOf(流编号, 地址) 查某地址在这条流里可取的额度。withdraw(流编号, 金额) 允许收款人提取全部或部分可用资金，标准限定只有收款人能调。redeem(流编号) 则是清算动作：把流剩余资金按已流动与未流动分配给收款人和出资人双方，标准建议任何一方可发起——到期或提前终止时，谁动手都不影响分配规则，这消除了“等对方先操作”的博弈。条款可以改：update 由一方提出新条款，另一方用 confirmUpdate 表态度，双方都确认后才生成新流并触发 LogExecuteUpdate；任何一方都可用 revokeUpdate 撤回对方提出的修改。事件层面还留了一处标准原文自身的疏漏：update 一节把函数名和事件对应关系写得与 confirmUpdate 互相穿插，读者需要对照实现理解，这本身就是早期草案的痕迹。

风险都写在参数里

流的余额按区块线性流失，payment 除以 interval 就是每块流速；估错出块间隔、设错结束区块，钱的消耗速度就和预期不符。条款协商机制假设双方有合作意愿，标准也承认这一点：修改条款靠共识执行， Stake 低的场景下拒绝合作是真实风险。另外流的“可逆”只到合约记账为止——已经流进收款人钱包的部分不会因为项目后来出问题而自动回流。

从 RICO 到水管：设计取舍与两处原文事故

动机部分交代的背景比接口本身更能说明意图。可逆 ICO 的概念在 2018 年 Devcon4 被提出：投资款不该一次性归项目方支配，而应锁在合约里按时间释放，项目停摆时投资人拿回尚未流动的大部分。ERC-1620 就是把这类“钱随时间走”的协议动作接口化。设计说明还交代了被淘汰的备选：支付通道和 Plasma 链都被考虑过，最终因为“假设太密”而放弃——与其把安全性押在尚未成型的扩容层上，不如先定义最简单的流结构。

两处原文事故值得一看，它们是这个接口长期停在 Stagnant 的原因之一。条款变更一节里，confirmUpdate 的函数签名被误写成 update、revokeUpdate 一节又误写成 confirmUpdate，三个函数共用同一段参数，只能靠上下文分辨谁是谁；getStream 的返回值清单也把 startBlock、stopBlock、payment、interval 平铺在一起，和结构体定义并非严格对应。实现者若照抄文档接口，会掉进签名歧义。功能层面再补一句：修改条款可以换代币地址、改结束区块、调流速与间隔，但改的实质是把“未来流动”重新约定一遍，已按旧条款流走的部分不追溯；redeem 的分账规则保证到期时双方都不用抢在对方前动手，任何一人都能触发清算并按已流与未流分钱。读这份标准的实用结论：凡以区块计速的协议，日历预算都要按出块间隔换算后再签。

它能说明的是一种按区块计量的分期支付结构，不能说明任何用工或投资安排公平。本文为机制说明，不构成任何投资建议。