在某个 DAO 的财务频道里，一位贡献者正看着自己的钱包余额实时上涨——不是每月一次，不是每两周一次，而是每秒一次。没有发薪日。没有批量处理。只有一个数字在他们工作时安静地增长，并在雇主取消流式支付的瞬间停止。
这就是流式薪资，它已不再只是加密推特上的新奇事物。Superfluid 和 Sablier 等协议如今为数以百计的 DAO 和 Web3 团队处理实际薪酬，越来越多以远程为先的公司正在试验这种模式来支付合同工津贴。它解决了一个真实问题——不再有“薪资发放是否成功”的焦虑——但它也制造了一个没有任何教科书涉及到的会计问题：你如何记录一笔没有具体付款日期的工资费用，因为这笔付款实际上从未停止？
流式薪资实际上是什么
传统的薪资是一系列一次性事件：工作应计两周，然后一笔交易结清。流式薪资则消除了这种间隙。雇主将资金存入智能合约并设定一个费率（例如每天 100 USDC），协议会以大约每秒 0.00116 USDC 的速度持续贷记收款人的可提取余额。收款人可以随时提取已累积的任何金额；在提取之前，没有任何“已支付”的款项，但所有金额都在后台持续产生。
两种主流协议对此采取了不同的技术方法：
Superfluid 将普通的 ERC-20 代币包装成内置流式逻辑的“超级代币”（如 USDCx）。包装后的代币的 balanceOf 函数会返回一个持续更新的数字，因此钱包余额会实时可见地增长。由于发送者的代币在流持续期间被锁定在协议中，Superfluid 依赖链下的“清算人”来监控发送者的缓冲资金，并在发送者余额归零之前强制关闭流——并为此赚取费用。如果你的缓冲资金耗尽，你员工的流将在毫无预警的情况下被清算。
Sablier 于 2019 年率先提出封闭式归属流模型，如今也提供 Sablier Flow——一种开放的、基于债务追踪的模型，可与普通 ERC-20 代币配合使用，无需包装或清算人。每个流都有独立的余额，费率可以在流中间调整，任何一方都可以暂停、恢复或永久终止流。这在一定程度上牺牲了 Superfluid 的实时余额显示功能，换来了更简单的集成方式，并且不依赖于第三方清算人基础设施。
这两种模型都处于一个封闭式流（固定存款在固定期限内归属——非常适合代币归属和补助发放）和开放式流（没有固定结束日期；雇主根据需要补充资金，流会一直运行直到被取消或资金耗尽）之间的光谱上。
会计问题：何时确认费用“已赚取”？
根据权责发生制会计，工资费用应在员工履行工作时确认，而不是在现金流动时。流式支付在原则上，是该原则最纯粹的表达方式——账簿应该只是持续追踪应计费率。但实际上，大多数记账系统（以及大多数会计师）都是以离散周期来思考的，因此每秒流需要被离散化，以便用分录来表示。
大多数财务团队采用的实用方法是：
- 将流费率视为已知的、恒定的应计项，只要它未被修改并持续运行。如果贡献者获得每天 100 USDC 的流式支付，则按每日（或为减轻账簿负担，按月）做一笔应计分录，借记工资/合同工费用，贷记“应付流式款项”负债——你不需要每秒做分录；你需要一个与你的报告周期相匹配的应计项。
- 在提取时进行实际调整。 当收款人实际申领已应计余额时，这是负债的结算，而不是新的费用——减少“应付流式款项”，并贷记资金库资产账户。这与你处理常规“已应计但未支付薪资”的方式类似。
- 在费率调整时，将其识别为费率变更，而非新流。 Sablier Flow 的可调整费率和 Superfluid 的流修改调用都允许雇主在流中间更改每秒流量。每次更改实际上只是一个新的应计费率，从该区块时间戳起生效——将其记录为同笔负债的修正案，而不是全新的明细项目，否则你的对账将会碎成几十个微流，永远无法平衡。
让许多人困惑的细微差别是：即使收款人从不提取，费用也会应计。 如果一位贡献者让三个月的流式付款未申领，那么实际上已经产生了三个月的真实工资费用，这些费用是由资金库承担的——只是负债尚未以现金结算。因为“什么都没支付出去”而跳过应计，是 DAO 账簿中最常见的错误，并且正是那种会悄无声息地夸大可用资金，最终导致资金库预测崩溃的问题。
公允市价：仍需要人工判断的部分
如果流式支付的是稳定币，那么会计处理接近于传统的现金薪资——1 USDC 价值 1 美元，完全确定，而 FASB 关于加密资产公允价值指引 (ASU 2023-08) 在账本的薪资这一侧几乎用不上。
一旦流式支付的是价格波动剧烈的原生代币，每个应计周期都需要进行公允市价转换。尽管具体机制可能不同，但税务机关在基本原则上是统一的：美国国税局将虚拟货币工资视为按收到日公允价值计算的普通收入（通知 2014-21），英国 HMRC 要求按英镑等值价值计算 PAYE/NI 预扣税，欧盟指引则将以稳定币或代币形式支付的工资按等值换算价值确认为收入。这些框架都不是为了应对“价值以每秒为单位连续接收”的情况而编写的——大多数团队会选择以提取时刻（即收款人实际获得保管权时）的公允市价为准，因为这是最接近传统发薪日的参照点，也是唯一一个市场价格明确无误的时点。在你的会计政策说明中记录这一选择，因为“你用的是哪个时间戳的价格？”，这是审计师会问的第一个问题。
一个具体示例
假设一个 DAO 向一位贡献者开设了每月 3,000 USDC 的 Sablier Flow 流，并以月度为单位结账。一旦你不再思考“每秒”，转而思考“已知费率，应用于一个时间段”，记账其实比听起来要简单：
- 流开启，第一月末结账： 借记合同工费用 3,000 USDC，贷记应付流式款项 3,000 USDC。没有现金流动；你确认的是已应计的债务。
- 贡献者在第二月中旬提取 1,800 USDC： 借记应付流式款项 1,800 USDC，贷记资金库（USDC）1,800 USDC。这是一笔结算，不是费用——费用在应计发生时已经预订。
- 雇主在第二个月中途将费率提高到每月 3,500 USDC： 按当月两种费率的占比计算应计项（例如，15 天按每月 3,000 计算 + 15 天按每月 3,500 计算 ≈ 3,250 USDC），而不是开设第二个“流”账户。费率变更是同笔负债的元数据，而非新的工具。
- 雇主在第三个月中旬取消流： 预订截止到取消区块时间戳的最终部分月份应计项。然后，剩余的应付流式款项余额要么通过最终提取被清空，要么（如果贡献者从未申领）作为负债保留，直到他们申领为止（或被根据任何适用的补助/贡献者协议正式没收——不要单方面将其归零）。
如果贡献者获得的是价格波动剧烈的代币而非稳定币，则需要在每个应计项中增加一行：同时记录代币数量和该分录时间戳对应的美元等值公允市价，因为你既需要以代币计价的负债（以了解你实际在链上欠了多少），也需要以法币计价的费用（用于你的损益表和任何税务预扣计算）。
常见错误
- 将提取视为费用。 这是最常见的错误——对于收款人未申领余额的每个期间，这会低估费用（并夸大可用资金），然后在收款人最终提款的期间，将一笔误导性的巨额费用计入。
- 每次费率变更都开设一个新的负债科目。 一位工资在一年内被调整了四次的贡献者，不应有四个项目弄乱会计科目表——应修改现有的应计项。
- 忽略协议费用。 Superfluid 的清算人机制以及任何创建或关闭流时产生的协议级费用，无论多小，都是真实费用，应记入账簿——它们很容易被忽略，因为它们会自动扣除，而不会作为记账员会注意到的单独交易出现。
- 将流式平台视为完整的薪资系统。 Sablier 和 Superfluid 持续转移资金；但两者都不提交税表、计算预扣税或处理工人分类。大多数团队会将流式层与 Request Finance 或 Toku 等合规工具，或传统的薪资服务提供商（针对 W-2 员工）结合使用，而将原始协议流保留用于合规负担较轻的合同工津贴和补助金。
- 忘记破产边缘情况。 如果 Superfluid 发送者的缓冲资金耗尽，且清算人强制关闭流，你的账簿需要反映这一事件——最终应计项在清算时间戳停止，而不是在你记账员碰巧注意到流已失效的那一天。
为何审计追溯实际上是常被低估的优势
波动性和清算风险备受关注，但对于财务团队来说，真正的收获在于：每个流事件——开启、费率变更、暂停、提取、取消——都是一个带有时间戳和区块编号的不可变链上交易。这是一个完整的、防篡改的薪资账簿，无论你的记账员是否记得记录它。它消除了困扰手动加密薪资的待摊账户猜测游戏（“我们真的给那位贡献者发了一月份的工资吗？还是交易悄无声息地失败了？”）。
只有当你的账簿与链上信息一致而非矛盾时，这种优势才能发挥作用。纯文本、版本控制的账簿非常适合于此：你可以编写一个每日或每月任务，直接从索引器或子图中读取流事件，并将相应的应计分录附加到你的账簿文件中，同时在分录元数据中捕获链上交易哈希。Beancount.io 正好为你提供了这一点——一种纯文本记账格式，你可以以编程方式生成和审计，完整的 git 历史记录，使得“应付流式款项”负债科目及其费率变更与资金库的其他任何部分一样可审查。如果你正在构建这种集成，文档 详细介绍了自定义账户结构和脚本化分录生成，而 Fava 则为你提供了一个仪表板，让你能够实时看到应计项如何对你的现金资金库产生影响——对于完全围绕“实时”构建的薪资模型来说，这感觉是正确的方式来观察它。