Ergens in het financiële kanaal van een DAO is nu een bijdrager getuige van hoe hun portemonnee-saldo in realtime omhoog tikt — niet één keer per maand, niet om de twee weken, maar elke seconde. Geen betaaldatum. Geen batchverwerking. Gewoon een getal dat rustig groeit terwijl ze werken, en stopt zodra de werkgever de stroom annuleert.
Dit is streaming payroll, en het is geen crypto-Twitter-curiositeit meer. Protocollen zoals Superfluid en Sablier verplaatsen nu echte compensatie voor honderden DAO's en Web3-teams, en een groeiend aantal remote-first bedrijven experimenteert met het model voor vergoedingen aan freelancers. Het lost een echt probleem op — geen "is de loonrun wel doorgegaan" angst meer — maar het creëert een boekhoudkundig probleem waar geen enkel leerboek over gaat: hoe boek je een loonkost die geen discrete betaaldatum heeft, omdat de betaling nooit echt stopt?
Wat Streaming Payroll Echt Is
Traditionele payroll is een reeks eenmalige gebeurtenissen: werk hoopt zich op gedurende twee weken, waarna een enkele transactie het afhandelt. Streaming payroll overbrugt die kloof. Een werkgever stort fondsen in een smart contract en stelt een tarief in — zeg 100 USDC per dag — en het protocol crediteert continu het opneembare saldo van de ontvanger met ongeveer 0,00116 USDC per seconde. De ontvanger kan op elk moment opnemen wat er is opgebouwd; er is niets "betaald" totdat ze het opnemen, maar alles verdient constant op de achtergrond.
De twee dominante protocollen hanteren verschillende technische benaderingen:
Superfluid wikkelt gewone ERC-20-tokens om in "Super Tokens" (zoals USDCx) met ingebouwde streaminglogica. De balanceOf-functie van het omwikkelde token retourneert een continu bijgewerkt getal, waardoor het saldo van een portemonnee zichtbaar in realtime stijgt. Omdat de tokens van de afzender in het protocol zijn vergrendeld voor de duur van de stroom, vertrouwt Superfluid op off-chain "liquidators" die de buffers van afzenders monitoren en stromen geforceerd sluiten voordat het saldo van een afzender op nul komt — en een vergoeding verdienen voor het doen. Als je buffer opdroogt, worden de stromen van je werknemers zonder waarschuwing geliquideerd.
Sablier, die het model pionierde met closed-ended vesting stromen in 2019, biedt nu ook Sablier Flow aan — een open-ended, schuld-tracking model dat werkt met gewone ERC-20-tokens, zonder omwikkeling of liquidators. Elke stroom is geïsoleerd met een eigen saldo, tarieven kunnen halverwege de stroom worden aangepast, en stromen kunnen worden gepauzeerd, hervat of permanent beëindigd door beide partijen. Dit ruilt een deel van Superfluid's realtime saldoweergave in voor eenvoudigere integratie en geen afhankelijkheid van externe liquidator-infrastructuur.
Beide modellen bevinden zich op een spectrum tussen closed-ended stromen (een vaste storting die over een vaste duur wordt verworven — goed geschikt voor token-vesting en subsidie-uitkeringen) en open-ended stromen (geen vaste einddatum; de werkgever vult aan indien nodig, en de stroom loopt totdat deze wordt geannuleerd of de fondsen opraken).
Het Boekhoudkundige Probleem: Wanneer is de Uitgave "Verworven"?
Onder accrual accounting wordt loonkost erkend wanneer de werknemer presteert, niet wanneer geld beweegt. Een streaming betaling is in principe de zuiverst mogelijke uitdrukking van dat principe — het grootboek moet gewoon het opbouwpercentage continu volgen. In de praktijk denken de meeste boekhoudsystemen (en de meeste accountants) in discrete perioden, dus een per-seconde stroom moet worden gediscretiseerd naar iets dat een grootboekpost kan vertegenwoordigen.
De praktische benadering waar de meeste financiële teams op uitkomen:
- Behandel het stroomtarief als een bekende, constante opbouw zolang het ongewijzigd loopt. Als een bijdrager 100 USDC/dag ontvangt, boek dan een dagelijkse (of, voor lichtere boeken, maandelijkse) opbouwpost die loon-/freelancerkosten debiteert en een "te betalen stromen" verplichting crediteert — je hebt geen per-seconde posten nodig; je hebt een opbouw nodig die past bij je rapportagecadans.
- Stel af bij opname. Wanneer de ontvanger het opgebouwde saldo daadwerkelijk claimt, is dat een afwikkeling van de verplichting, geen nieuwe uitgave — het verlaagt "te betalen stromen" en crediteert de treasury-activarekening. Dit weerspiegelt hoe je al reguliere opgebouwde-niet-betaalde loonkosten zou behandelen.
- Erken de tariefwijziging, niet een nieuwe stroom, wanneer een tarief wordt aangepast. Sablier Flow's aanpasbare tarief en Superfluid's stroom-wijzigingsoproepen stellen een werkgever in staat om het per-seconde tarief halverwege de stroom te wijzigen. Elke wijziging is eigenlijk gewoon een nieuw opbouwpercentage dat van kracht wordt vanaf die block-timestamp — log het als een wijziging van dezelfde verplichting, niet als een nieuw regeltje, of je reconciliatie zal fragmenteren in tientallen micro-stromen die nooit helemaal kloppen.
De subtiliteit die mensen in de val lokt: de kosten lopen op, zelfs als de ontvanger nooit opneemt. Een bijdrager die drie maanden van een stroom laat staan zonder te claimen, heeft nog steeds drie maanden echte loonkosten gegenereerd tegen de treasury — de verplichting is gewoon nog niet in contanten afgewikkeld. Het overslaan van de opbouw omdat "er niets is uitbetaald" is de meest voorkomende fout in DAO-boekhoudingen, en het is precies het soort stille overschatting van de runway dat een treasury-voorspelling laat ontploffen.
Fair Market Value: Het Deel Dat Nog Steeds een Mens Vereist
Als de stroom uitbetaalt in een stablecoin, blijft de boekhouding dicht bij conventionele loonkosten in contanten — 1 USDC is $1 waard, punt, en de fair-value-richtlijn voor crypto-activa (ASU 2023-08) van de FASB komt nauwelijks in het spel aan de loonkostenkant van het grootboek.
Zodra de stroom uitbetaalt in een volatiele native token, vereist elke opbouwperiode een fair-market-value-conversie. Belastingdiensten zijn consistent over het onderliggende principe, zelfs waar de mechanieken verschillen: de IRS behandelt virtuele-valuta lonen als gewoon inkomen tegen fair market value op de ontvangstdatum (Notice 2014-21), de Britse HMRC vereist PAYE/NI-inhouding op de GBP-equivalente waarde, en EU-richtlijnen behandelen stablecoin- of tokenlonen als inkomen tegen hun conversie-equivalente waarde. Geen van deze kaders is geschreven met "waarde continu ontvangen, seconde voor seconde" in gedachten — de meeste teams kiezen voor de FMV op het moment van opname (wanneer de ontvanger daadwerkelijk bezit neemt), omdat dat de dichtste analogie is van een traditionele betaaldatum en het enige punt waar een marktprijs ondubbelzinnig is. Documenteer die keuze in je boekhoudkundige beleidsnotities, want "wiens tijdstempelprijs heb je gebruikt" is de eerste vraag die een auditor zal stellen.
Een Uitgewerkt Voorbeeld
Stel dat een DAO een Sablier Flow-stroom opent voor een bijdrager van 3.000 USDC/maand, en de boeken maandelijks sluit. De boekhouding is eenvoudiger dan het klinkt zodra je stopt met denken "per seconde" en begint met denken "bekend tarief, toegepast over een periode":
- Stroom geopend, maand 1 afsluiting: Debet Freelancerkosten 3.000 USDC, credit Te Betalen Stromen 3.000 USDC. Er is geen contant geld verplaatst; je erkent de verplichting die is opgebouwd.
- Bijdrager neemt 1.800 USDC op halverwege maand 2: Debet Te Betalen Stromen 1.800 USDC, credit Treasury (USDC) 1.800 USDC. Dit is een afwikkeling, geen uitgave — de uitgave was al geboekt toen deze opbouwde.
- Werkgever verhoogt het tarief naar 3.500 USDC/maand halverwege maand 2: Proportioneer de opbouw over de twee tarieven voor die maand (bijv. 15 dagen op 3.000/mnd + 15 dagen op 3.500/mnd ≈ 3.250 USDC) in plaats van een tweede "stroom"-rekening te openen. De tariefwijziging is metadata op dezelfde verplichting, geen nieuw instrument.
- Werkgever annuleert de stroom halverwege maand 3: Boek de laatste gedeeltelijke maandopbouw tot aan de annulering-block-timestamp, en het resterende saldo van Te Betalen Stromen wordt ofwel weggesluisd in een laatste opname, of, als de bijdrager het nooit claimt, blijft het als een verplichting staan totdat hij het doet (of totdat het formeel wordt verbeurdverklaard onder de toepasselijke subsidie-/bijdragerovereenkomst — beëindig het niet eenzijdig op nul).
Als de bijdrager wordt betaald in een volatiele token in plaats van een stablecoin, voeg dan nog een regel toe aan elke opbouw: leg zowel de tokenhoeveelheid als de USD-equivalente FMV op dat tijdstip vast, omdat je zowel de in token luidende verplichting (om te weten wat je daadwerkelijk on-chain verschuldigd bent) als de in fiat luidende uitgave (voor je P&L en eventuele belastinginhoudingsberekening) nodig hebt.
Veelgemaakte Fouten
- De opname boeken als de uitgave. Dit is de meest voorkomende fout — het onderschat uitgaven (en overschat de runway) voor elke periode waarin een ontvanger hun saldo niet claimt, en dumpt dan een misleidend grote uitgave in de periode waarin ze uiteindelijk opnemen.
- Een nieuwe verplichtingsrekening openen per tariefwijziging. Een bijdrager wiens loon vier keer in een jaar is aangepast, zou niet vier regeltjes moeten hebben die het rekeningschema vervuilen — wijzig de bestaande opbouw.
- Protocolkosten negeren. Superfluid's liquidator-mechanisme en eventuele protocolkosten op stroomcreatie of -sluiting zijn echte uitgaven, hoe klein ook, en horen in het grootboek — ze zijn gemakkelijk te missen omdat ze automatisch worden afgetrokken in plaats van als een aparte transactie te verschijnen die een boekhouder zou opmerken.
- Streamingplatforms behandelen als volledige loonsystemen. Sablier en Superfluid verplaatsen geld continu; geen van beiden dient belastingformulieren in, berekent inhoudingen, of behandelt werknemersclassificatie. De meeste teams koppelen de streaminglaag aan een compliance-tool zoals Request Finance of Toku, of aan een traditionele loonprovider voor W-2-werknemers, en houden ruwe protocolstromen voor bijdragersvergoedingen en subsidies waar de compliance-last lichter is.
- De insolventie-randgeval vergeten. Als de buffer van een Superfluid-afzender opraakt en een liquidator de stroom forceert, is dat een gebeurtenis die je boeken moeten weerspiegelen — de laatste opbouw stopt op het liquidatietijdstip, niet op welke datum je boekhouder ook maar merkt dat de stroom dood is.
Waarom de Audit Trail Eigenlijk het Ondergewaardeerde Voordeel is
De volatiliteit en het liquidatierisico krijgen de aandacht, maar de echte winst voor financiële teams is dat elke stroomgebeurtenis — start, tariefwijziging, pauze, opname, annulering — een onveranderlijke on-chain transactie is met een tijdstempel en een blocknummer. Dat is een complete, fraudebestendige loonadministratie die bestaat, of je boekhouder er nu aan dacht om het te loggen of niet. Het elimineert de suspense-rekening raadspelletjes die handmatige crypto-payroll plagen ("hebben we die bijdrager hun oktoberbetaling daadwerkelijk gestuurd, of faalde de transactie stil?").
Dat voordeel betaalt zich alleen uit als je eigen boeken de keten weerspiegelen in plaats van deze tegen te spreken. Plain-text, versiebeheerde grootboeken zijn hier een natuurlijke pasvorm: je kunt een dagelijkse of maandelijkse taak scripten die stroomgebeurtenissen direct van een indexer of subgraph leest en de bijbehorende opbouwposten aan je grootboekbestand toevoegt, met de on-chain transactiehash vastgelegd in de metadata van de post. Beancount.io geeft je precies dat — een plain-text boekhoudformaat dat je programmatisch kunt genereren en auditen, met volledige geschiedenis in git, zodat een "te betalen stromen" verplichtingsrekening en zijn tariefwijzigingen net zo inspecteerbaar zijn als elk ander deel van je treasury. Als je deze integratie bouwt, lopen de docs door aangepaste rekeningstructuren en gescripte postgeneratie, en Fava geeft je een dashboard om de opbouw daadwerkelijk in realtime te zien opbouwen tegen je cash-runway — wat, voor een loonmodel dat volledig rond realtime is gebouwd, aanvoelt als de juiste manier om het te bekijken.