Somewhere in a DAO's finance channel right now, a contributor is watching their wallet balance tick upward in real time — not once a month, not every two weeks, but every single second. No pay date. No batch run. Just a number that quietly grows while they work, and stops the instant the employer cancels the stream.
This is streaming payroll, and it's no longer a crypto-Twitter curiosity. Protocols like Superfluid and Sablier now move real compensation for hundreds of DAOs and Web3 teams, and a growing number of remote-first companies are experimenting with the model for contractor stipends. It solves a real problem — no more "did the payroll run go through" anxiety — but it creates an accounting problem nobody's textbook covers: how do you book a wage expense that has no discrete payment date, because the payment never actually stops?
What Streaming Payroll Actually Is
Traditional payroll is a series of lump-sum events: work accrues for two weeks, then a single transaction settles it. Streaming payroll collapses that gap. An employer deposits funds into a smart contract and sets a rate — say, 100 USDC per day — and the protocol continuously credits the recipient's claimable balance at roughly 0.00116 USDC per second. The recipient can withdraw whatever has accrued at any moment; nothing is "paid" until they pull it, but everything is earning constantly in the background.
The two dominant protocols take different technical approaches to this:
Superfluid wraps ordinary ERC-20 tokens into "Super Tokens" (like USDCx) with built-in streaming logic. The wrapped token's balanceOf function returns a continuously updating number, so a wallet's balance visibly climbs in real time. Because the sender's tokens are locked in the protocol for the stream's duration, Superfluid relies on off-chain "liquidators" who monitor senders' buffers and forcibly close streams before a sender's balance hits zero — earning a fee for doing so. If your buffer runs dry, your employees' streams get liquidated without warning.
Sablier, which pioneered the model with closed-ended vesting streams in 2019, now also offers Sablier Flow — an open-ended, debt-tracking model that works with plain ERC-20 tokens, no wrapping or liquidators required. Each stream is isolated with its own balance, rates can be adjusted mid-stream, and streams can be paused, resumed, or permanently ended by either party. This trades some of Superfluid's real-time balance display for simpler integration and no dependency on third-party liquidator infrastructure.
Both models sit on a spectrum between closed-ended streams (a fixed deposit vests over a fixed duration — well suited to token vesting and grant disbursement) and open-ended streams (no fixed end date; the employer tops up as needed, and the stream runs until it's cancelled or funds run out).
The Accounting Problem: When Is the Expense "Earned"?
Under accrual accounting, wage expense is recognized as the employee performs work, not when cash moves. A streaming payment is, in principle, the purest possible expression of that principle — the ledger should just track the accrual rate continuously. In practice, most bookkeeping systems (and most accountants) think in discrete periods, so a per-second stream needs to be discretized back down to something a ledger entry can represent.
The practical approach most finance teams land on:
- Treat the stream rate as a known, constant accrual for as long as it runs unmodified. If a contributor is being streamed 100 USDC/day, book a daily (or, for lighter-weight books, monthly) accrual entry debiting wage/contractor expense and crediting a "streams payable" liability — you don't need per-second entries; you need an accrual that matches your reporting cadence.
- True up on withdrawal. When the recipient actually claims the accrued balance, that's a settlement of the liability, not a new expense — draining "streams payable" and crediting the treasury asset account. This mirrors how you'd already handle regular accrued-payroll-not-yet-paid.
- Recognize the rate change, not a new stream, when a rate is adjusted. Sablier Flow's adjustable rate and Superfluid's stream-modification calls both let an employer change the per-second flow mid-stream. Each change is really just a new accrual rate taking effect from that block timestamp forward — log it as an amendment to the same liability, not a fresh line item, or your reconciliation will fragment into dozens of micro-streams that never quite tie out.
The subtlety that trips people up: the expense accrues even if the recipient never withdraws. A contributor who lets three months of a stream sit unclaimed still generated three months of real wage expense against the treasury — the liability just hasn't been settled in cash yet. Skipping the accrual because "nothing was paid out" is the single most common mistake in DAO books, and it's exactly the kind of quiet overstatement of runway that blows up a treasury forecast.
Fair Market Value: The Part That Still Requires a Human
If the stream pays in a stablecoin, the accounting stays close to conventional cash payroll — 1 USDC is worth $1, full stop, and the FASB's fair-value guidance for crypto assets (ASU 2023-08) barely comes into play for the wage side of the ledger.
The moment the stream pays in a volatile native token, every accrual period requires a fair-market-value conversion. Tax authorities are consistent on the underlying principle even where the mechanics differ: the IRS treats virtual-currency wages as ordinary income at fair market value on the date received (Notice 2014-21), the UK's HMRC requires PAYE/NI withholding on the GBP-equivalent value, and EU guidance treats stablecoin or token wages as income at their conversion-equivalent value. None of these frameworks were written with "value received continuously, second by second" in mind — most teams settle on the FMV at the moment of withdrawal (when the recipient actually takes custody), since that's the closest analog to a traditional pay date and the only point where a market price is unambiguous. Document that choice in your accounting policy notes, because "which timestamp's price did you use" is the first question an auditor will ask.
A Worked Example
Say a DAO opens a Sablier Flow stream to a contributor at 3,000 USDC/month, and closes the books monthly. The bookkeeping is simpler than it sounds once you stop thinking "per second" and start thinking "known rate, applied over a period":
- Stream opens, month 1 close: Debit Contractor Expense 3,000 USDC, credit Streams Payable 3,000 USDC. No cash has moved; you're recognizing the obligation that accrued.
- Contributor withdraws 1,800 USDC mid-month-2: Debit Streams Payable 1,800 USDC, credit Treasury (USDC) 1,800 USDC. This is a settlement, not an expense — the expense was already booked when it accrued.
- Employer raises the rate to 3,500 USDC/month partway through month 2: Prorate the accrual across the two rates for that month (e.g., 15 days at 3,000/mo + 15 days at 3,500/mo ≈ 3,250 USDC) rather than opening a second "stream" account. The rate change is metadata on the same liability, not a new instrument.
- Employer cancels the stream mid-month-3: Book the final partial-month accrual up to the cancellation block timestamp, then the remaining Streams Payable balance either gets swept out in a final withdrawal or, if the contributor never claims it, sits as a liability until they do (or until it's formally forfeited under whatever grant/contributor agreement governs it — don't just zero it out unilaterally).
If the contributor is being paid in a volatile token instead of a stablecoin, add one more line to each accrual: capture the token quantity and its USD-equivalent FMV at that entry's timestamp, since you'll need both the token-denominated liability (to know what you actually owe on-chain) and the fiat-denominated expense (for your P&L and any tax withholding calculation).
Common Mistakes
- Booking the withdrawal as the expense. This is the single most common error — it understates expenses (and overstates runway) for every period a recipient doesn't claim their balance, then dumps a misleadingly large expense in whatever period they finally do withdraw.
- Opening a fresh liability account per rate change. A contributor whose pay was adjusted four times in a year should not have four line items cluttering the chart of accounts — amend the existing accrual.
- Ignoring protocol fees. Superfluid's liquidator mechanism and any protocol-level fees on stream creation or closure are real expenses, however small, and belong in the ledger — they're easy to miss because they're deducted automatically rather than showing up as a separate transaction a bookkeeper would notice.
- Treating streaming platforms as full payroll systems. Sablier and Superfluid move money continuously; neither files tax forms, calculates withholding, or handles worker classification. Most teams pair the streaming layer with a compliance tool like Request Finance or Toku, or with a traditional payroll provider for W-2 employees, and reserve raw protocol streams for contributor stipends and grants where the compliance burden is lighter.
- Forgetting the insolvency edge case. If a Superfluid sender's buffer runs out and a liquidator force-closes the stream, that's an event your books need to reflect — the final accrual stops at the liquidation timestamp, not at whatever date your bookkeeper happens to notice the stream is dead.
Why the Audit Trail Is Actually the Underrated Benefit
The volatility and liquidation risk get the attention, but the real win for finance teams is that every stream event — start, rate change, pause, withdrawal, cancellation — is an immutable on-chain transaction with a timestamp and a block number. That's a complete, tamper-evident payroll ledger that exists whether or not your bookkeeper remembered to log it. It eliminates the suspense-account guessing games that plague manual crypto payroll ("did we actually send that contributor their October payment, or did the transaction fail silently?").
That advantage only pays off if your own books mirror the chain instead of contradicting it. Plain-text, version-controlled ledgers are a natural fit here: you can script a daily or monthly job that reads stream events directly from an indexer or subgraph and appends the corresponding accrual entries to your ledger file, with the on-chain transaction hash captured right in the entry metadata. Beancount.io gives you exactly that — a plain-text accounting format you can generate and audit programmatically, with full history in git, so a "streams payable" liability account and its rate changes are as inspectable as any other part of your treasury. If you're building this integration, the docs walk through custom account structures and scripted entry generation, and Fava gives you a dashboard to actually see the accrual build up against your cash runway in real time — which, for a payroll model built entirely around real time, feels like the right way to watch it.