Zum Hauptinhalt springen

Streaming Payroll Bookkeeping: So buchen Sie die sekündliche Gehaltsabgrenzung von Superfluid und Sablier

Veröffentlicht Zuletzt aktualisiert 9 Minuten LesezeitMike ThriftMike Thrift
Streaming Payroll Bookkeeping: So buchen Sie die sekündliche Gehaltsabgrenzung von Superfluid und Sablier

Irgendwo im Finance-Channel einer DAO beobachtet gerade ein Beitragender, wie sein Wallet-Guthaben in Echtzeit nach oben tickt – nicht einmal im Monat, nicht alle zwei Wochen, sondern jede einzelne Sekunde. Kein Zahltag. Kein Batch-Durchlauf. Nur eine Zahl, die leise wächst, während er arbeitet, und in dem Moment stoppt, in dem der Arbeitgeber den Stream kündigt.

Dies ist Streaming Payroll, und es ist längst keine reine Crypto-Twitter-Kuriosität mehr. Protokolle wie Superfluid und Sablier bewegen mittlerweile echte Vergütung für hunderte DAOs und Web3-Teams, und eine wachsende Zahl von Remote-First-Unternehmen experimentiert mit dem Modell für Auftragnehmer-Pauschalvergütungen. Es löst ein echtes Problem – keine Angst mehr vor der Frage "Ist der Payroll-Lauf durchgegangen?" –, aber es schafft ein Accounting-Problem, das kein Lehrbuch abdeckt: Wie verbucht man einen Lohnaufwand, der kein diskretes Zahlungsdatum hat, weil die Zahlung nie wirklich aufhört?

Was Streaming Payroll Wirklich Ist

Traditionelle Lohnabrechnung besteht aus einer Reihe von Pauschalereignissen: Arbeit wird zwei Wochen lang angesammelt, dann wird sie mit einer einzigen Transaktion abgerechnet. Streaming Payroll macht diese Lücke zunichte. Ein Arbeitgeber zahlt Gelder in einen Smart Contract ein und legt einen Satz fest – sagen wir 100 USDC pro Tag – und das Protokoll schreibt dem auszahlbaren Guthaben des Empfängers kontinuierlich etwa 0,00116 USDC pro Sekunde gut. Der Empfänger kann jederzeit das angesammelte Guthaben abheben; es wird erst "bezahlt", wenn er es abruft, aber alles läuft ständig im Hintergrund auf.

Die beiden dominierenden Protokolle verfolgen dabei unterschiedliche technische Ansätze:

Superfluid verpackt gewöhnliche ERC-20-Token in "Super Tokens" (wie USDCx) mit integrierter Streaming-Logik. Die balanceOf-Funktion des verpackten Tokens gibt eine sich kontinuierlich aktualisierende Zahl zurück, sodass das Guthaben einer Wallet in Echtzeit sichtbar steigt. Da die Token des Senders für die Dauer des Streams im Protokoll gesperrt sind, verlässt sich Superfluid auf externe "Liquidatoren", die die Puffer der Sender überwachen und Streams zwangsweise schließen, bevor das Guthaben des Senders auf Null fällt – und dafür eine Gebühr erhalten. Wenn Ihr Puffer zur Neige geht, werden die Streams Ihrer Mitarbeiter ohne Vorwarnung liquidiert.

Sablier, das das Modell 2019 mit zeitlich begrenzten Vesting-Streams ("closed-ended") einführte, bietet nun auch Sablier Flow – ein offenes, schuldenbasiertes Modell, das mit normalen ERC-20-Tokens funktioniert, ohne Verpackung oder Liquidatoren. Jeder Stream ist isoliert mit eigenem Guthaben, die Raten können während des Streams angepasst werden, und Streams können von jeder Seite pausiert, fortgesetzt oder dauerhaft beendet werden. Dies tauscht einige der Echtzeit-Guthabenanzeigen von Superfluid gegen eine einfachere Integration und Unabhängigkeit von der Infrastruktur Dritter (Liquidatoren) ein.

Beide Modelle liegen auf einem Spektrum zwischen zeitlich begrenzten Streams (eine feste Einzahlung wird über einen festgelegten Zeitraum freigegeben – gut geeignet für Token-Vesting und Zuschussauszahlungen) und offenen Streams (kein festes Enddatum; der Arbeitgeber füllt bei Bedarf auf, und der Stream läuft, bis er gekündigt wird oder die Mittel ausgehen).

Das Accounting-Problem: Wann ist der Aufwand "verdient"?

Nach der periodengerechten Rechnungslegung (Accrual Accounting) wird der Lohnaufwand in dem Moment erfasst, in dem der Arbeitnehmer die Arbeit leistet, nicht wenn Geld fließt. Ein Streaming-Payment ist im Prinzip der reinste Ausdruck dieses Prinzips – das Hauptbuch sollte einfach die Abgrenzungsrate kontinuierlich verfolgen. In der Praxis denken die meisten Buchhaltungssysteme (und die meisten Buchhalter) in diskreten Perioden, daher muss ein Pro-Sekunde-Stream wieder in etwas diskretisiert werden, das ein Buchungssatz abbilden kann.

Der praktische Ansatz, auf den sich die meisten Finanzteams einigen:

  1. Behandeln Sie die Stream-Rate als eine bekannte, konstante Abgrenzung für die gesamte Zeit, in der sie unverändert läuft. Wenn einem Beitragenden 100 USDC/Tag gestreamt werden, buchen Sie eine tägliche (oder bei einfacheren Büchern monatliche) Abgrenzungsbuchung, die den Lohn-/Auftragnehmeraufwand belastet und eine Verbindlichkeit "Streams Payable" gutschreibt – Sie brauchen keine Pro-Sekunde-Buchungen; Sie brauchen eine Abgrenzung, die Ihrem Berichtsturnus entspricht.
  2. Korrektur bei Auszahlung. Wenn der Empfänger das angesammelte Guthaben tatsächlich beansprucht, ist das eine Begleichung der Verbindlichkeit, kein neuer Aufwand – "Streams Payable" wird verringert und das Treasury-Vermögenskonto wird gutgeschrieben. Dies spiegelt wider, wie Sie bereits reguläre, noch nicht gezahlte, periodengerecht abgegrenzte Löhne behandeln würden.
  3. Erkennen Sie die Ratenänderung, nicht einen neuen Stream, wenn eine Rate angepasst wird. Sowohl Sablier Flows einstellbare Rate als auch Superfluids Stream-Änderungsaufrufe erlauben es einem Arbeitgeber, den Pro-Sekunde-Fluss mitten im Stream zu ändern. Jede Änderung ist eigentlich nur eine neue Abgrenzungsrate, die ab diesem Block-Zeitstempel wirksam wird – buchen Sie sie als Änderung derselben Verbindlichkeit, nicht als neuen Posten, sonst zersplittert Ihr Abgleich in Dutzende von Mikro-Streams, die nie ganz aufgehen.

Die Feinheit, die viele überrascht: Der Aufwand wird auch dann abgegrenzt, wenn der Empfänger nie abhebt. Ein Beitragender, der einen Stream drei Monate lang unbeansprucht lässt, hat dennoch drei Monate echten Lohnaufwand gegenüber der Treasury verursacht – die Verbindlichkeit wurde nur noch nicht in bar beglichen. Die Abgrenzung zu überspringen, weil "nichts ausgezahlt wurde", ist der häufigste Fehler in DAO-Büchern, und es ist genau die Art von stillschweigender Überschätzung der finanziellen Reichweite (Runway), die eine Treasury-Prognose sprengt.

Fair Market Value: Der Teil, der immer noch einen Menschen erfordert

Wenn der Stream in einem Stablecoin auszahlt, bleibt die Buchhaltung nah an der konventionellen Barvergütung – 1 USDC ist genau 1 $ wert, und die Fair-Value-Richtlinien des FASB für Krypto-Assets (ASU 2023-08) kommen auf der Aufwandsseite des Hauptbuchs kaum zum Tragen.

Sobald der Stream in einem volatilen nativen Token auszahlt, erfordert jeder Abgrenzungszeitraum eine Umrechnung zum fairen Marktwert. Die Steuerbehörden sind sich in Bezug auf das zugrunde liegende Prinzip einig, auch wenn die Mechanismen unterschiedlich sind: Der IRS behandelt Vergütung in virtuellen Währungen als normales Einkommen zum fairen Marktwert am Tag des Erhalts (Notice 2014-21), die britische HMRC verlangt PAYE/NI-Einbehaltung auf den Gegenwert in GBP, und die EU-Richtlinien behandeln Vergütung in Stablecoins oder Token als Einkommen zu ihrem umgerechneten Gegenwert. Keiner dieser Rahmenwerke wurde mit dem Gedanken "Wert wird kontinuierlich, Sekunde für Sekunde, erhalten" entwickelt – die meisten Teams legen den FMV zum Zeitpunkt der Auszahlung (wenn der Empfänger tatsächlich die Verfügungsgewalt erhält) zugrunde, da dies dem traditionellen Zahltag am nächsten kommt und der einzige Zeitpunkt ist, an dem ein Marktpreis eindeutig ist. Dokumentieren Sie diese Wahl in Ihren Bilanzierungsgrundsätzen, denn "Welcher Zeitstempelpreis wurde verwendet?" ist die erste Frage, die ein Prüfer stellen wird.

Ein Durchgerechnetes Beispiel

Angenommen, eine DAO eröffnet einen Sablier Flow Stream für einen Beitragenden mit 3.000 USDC/Monat und schließt die Bücher monatlich. Die Buchhaltung ist einfacher, als es klingt, sobald man aufhört, "pro Sekunde" zu denken, und anfängt, "bekannter Satz, angewandt über einen Zeitraum" zu denken:

  • Stream öffnet, Monatsende 1: Soll: Auftragnehmeraufwand 3.000 USDC, Haben: Verbindlichkeiten aus Streams (Streams Payable) 3.000 USDC. Es ist kein Geld geflossen; Sie erfassen die aufgelaufene Verpflichtung.
  • Beitragender hebt Mitte Monat 2 1.800 USDC ab: Soll: Verbindlichkeiten aus Streams 1.800 USDC, Haben: Treasury (USDC) 1.800 USDC. Dies ist eine Begleichung, kein Aufwand – der Aufwand wurde bereits bei seiner Entstehung gebucht.
  • Arbeitgeber erhöht die Rate Mitte Monat 2 auf 3.500 USDC/Monat: Rechnen Sie die Abgrenzung für diesen Monat anteilig über die beiden Sätze (z. B. 15 Tage zu 3.000/Monat + 15 Tage zu 3.500/Monat ≈ 3.250 USDC) anstatt ein zweites "Stream"-Konto zu eröffnen. Die Ratenänderung sind Metadaten zu derselben Verbindlichkeit, kein neues Instrument.
  • Arbeitgeber kündigt den Stream Mitte Monat 3: Buchen Sie die letzte anteilige Monatsabgrenzung bis zum Kündigungs-Block-Zeitstempel. Der verbleibende Saldo der Verbindlichkeiten aus Streams wird entweder bei einer letzten Auszahlung ausgezahlt oder, falls der Beitragende ihn nie beansprucht, bleibt er als Verbindlichkeit bestehen, bis er ihn beansprucht (oder bis er gemäß der geltenden Zuschuss-/Beitragsvereinbarung formell verfällt – buchen Sie ihn nicht einfach einseitig auf Null).

Wenn der Beitragende in einem volatilen Token statt in einem Stablecoin bezahlt wird, fügen Sie jeder Abgrenzung eine weitere Zeile hinzu: Erfassen Sie die Token-Menge und ihren USD-äquivalenten FMV zum Zeitstempel dieser Buchung, da Sie sowohl die auf Token lautende Verbindlichkeit (um zu wissen, was Sie tatsächlich on-chain schulden) als auch den auf Fiat lautenden Aufwand (für Ihre GuV und etwaige Steuerabzugsberechnungen) benötigen.

Häufige Fehler

  • Die Auszahlung als Aufwand buchen. Dies ist der mit Abstand häufigste Fehler – er führt zu einer Unterbewertung der Aufwendungen (und einer Überbewertung der finanziellen Reichweite) für jeden Zeitraum, in dem ein Empfänger sein Guthaben nicht beansprucht, und wirft dann in dem Zeitraum, in dem er es schließlich tut, einen irreführend hohen Aufwand an.
  • Für jede Ratenänderung ein neues Verbindlichkeitskonto eröffnen. Ein Beitragender, dessen Vergütung viermal im Jahr angepasst wurde, sollte nicht vier Posten haben, die den Kontenplan überladen – passen Sie die bestehende Abgrenzung an.
  • Protokollgebühren ignorieren. Superfluids Liquidatormechanismus und etwaige Protokollgebühren auf Stream-Erstellung oder -Schließung sind reale Ausgaben, egal wie gering, und gehören ins Hauptbuch – sie werden leicht übersehen, da sie automatisch abgezogen werden und nicht als separate Transaktion erscheinen, die ein Buchhalter bemerken würde.
  • Streaming-Plattformen als vollständige Lohnabrechnungssysteme behandeln. Sablier und Superfluid bewegen Geld kontinuierlich; keines von beiden reicht Steuerformulare ein, berechnet Lohnsteuer oder kümmert sich um die Arbeitnehmerklassifizierung. Die meisten Teams kombinieren die Streaming-Ebene mit einem Compliance-Tool wie Request Finance oder Toku oder mit einem traditionellen Lohnabrechnungsdienstleister für W-2-Angestellte und reservieren reine Protokoll-Streams für Auftragnehmer-Pauschalvergütungen und Zuschüsse, bei denen die Compliance-Last geringer ist.
  • Den Insolvenz-Grenzfall vergessen. Wenn der Puffer eines Superfluid-Senders aufgebraucht ist und ein Liquidator den Stream zwangsweise schließt, ist dies ein Ereignis, das Ihre Bücher widerspiegeln müssen – die endgültige Abgrenzung endet zum Liquidationszeitstempel, nicht zu dem Datum, an dem Ihr Buchhalter zufällig bemerkt, dass der Stream tot ist.

Warum der Prüfpfad eigentlich der unterschätzte Vorteil ist

Die Volatilität und das Liquidationsrisiko bekommen die Aufmerksamkeit, aber der wahre Gewinn für Finanzteams ist, dass jedes Stream-Ereignis – Start, Ratenänderung, Pause, Auszahlung, Kündigung – eine unveränderliche On-Chain-Transaktion mit einem Zeitstempel und einer Blocknummer ist. Das ist ein vollständiges, manipulationssicheres Lohnbuch, das existiert, egal ob Ihr Buchhalter daran gedacht hat, es zu protokollieren oder nicht. Es eliminiert die Ratespiele mit Zwischenkonten (Suspense Accounts), die manuelle Krypto-Payroll plagen ("Haben wir diesem Beitragenden tatsächlich seine Oktoberzahlung gesendet, oder ist die Transaktion stillschweigend fehlgeschlagen?").

Dieser Vorteil zahlt sich nur aus, wenn Ihre eigenen Bücher die Chain widerspiegeln, anstatt ihr zu widersprechen. Textbasierte, versionierte Hauptbücher sind hierfür ideal geeignet: Sie können einen täglichen oder monatlichen Job skripten, der Stream-Ereignisse direkt von einem Indexer oder Subgraph liest und die entsprechenden Abgrenzungsbuchungen an Ihre Hauptbuchdatei anhängt, wobei der On-Chain-Transaktions-Hash direkt in den Buchungsmetadaten erfasst wird. Beancount.io bietet Ihnen genau das – ein reines Text-Buchhaltungsformat, das Sie programmatisch erstellen und prüfen können, mit vollständiger Historie in Git, sodass ein Verbindlichkeitskonto "Streams Payable" und seine Ratenänderungen genauso überprüfbar sind wie jeder andere Teil Ihrer Treasury. Wenn Sie diese Integration aufbauen, führen die Dokumente durch benutzerdefinierte Kontostrukturen und die Erstellung skriptbasierter Buchungen, und Fava bietet Ihnen ein Dashboard, um den Aufbau der Abgrenzung gegen Ihren Cash-Runway in Echtzeit zu sehen – was sich für ein vollständig auf Echtzeit aufgebautes Gehaltsmodell wie die richtige Art anfühlt, es zu beobachten.

Diesen Artikel teilen