Десь у фінансовому каналі 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) ледь впливає на сторону зарплати в бухгалтерській книзі.
Як тільки стрім виплачується в мінливому нативному токені, кожен період нарахування вимагає конвертації за справедливою ринковою вартістю. Податкові органи послідовні в основному принципі, навіть якщо механізми відрізняються: IRS розглядає зарплату у віртуальній валюті як звичайний дохід за справедливою ринковою вартістю на дату отримання (Повідомлення 2014-21), HMRC Великобританії вимагає утримання PAYE/NI з вартості в GBP, а керівництво ЄС розглядає зарплату в стейблкоїнах або токенах як дохід за їхньою еквівалентною вартістю при конвертації. Жодна з цих рамок не була написана з урахуванням "вартості, що отримується безперервно, секунда за секундою" — більшість команд зупиняються на справедливій ринковій вартості на момент виведення коштів (коли одержувач фактично отримує їх у своє розпорядження), оскільки це найближчий аналог традиційної дати виплати зарплати та єдина точка, де ринкова ціна є однозначною. Задокументуйте цей вибір у примітках до вашої облікової політики, тому що "ціну якої позначки часу ви використали" — це перше запитання, яке поставить аудитор.
Приклад із практики
Припустімо, DAO відкриває стрім Sablier Flow для учасника зі ставкою 3 000 USDC на місяць і закриває бухгалтерські книги щомісяця. Облік виявляється простішим, ніж здається, як тільки ви перестаєте думати "щосекунди" і починаєте думати "відома ставка, застосована протягом періоду":
- Стрім відкрито, закриття місяця 1: Дебет "Витрати на підрядника" 3 000 USDC, кредит "Стріми до сплати" 3 000 USDC. Жодних рухів готівки; ви визнаєте зобов'язання, яке виникло.
- Учасник виводить 1 800 USDC в середині місяця 2: Дебет "Стріми до сплати" 1 800 USDC, кредит "Скарбниця (USDC)" 1 800 USDC. Це погашення, а не витрати — витрати вже були обліковані, коли вони виникли.
- Роботодавець підвищує ставку до 3 500 USDC на місяць у середині місяця 2: Пропорційно розподіліть нарахування між двома ставками за цей місяць (наприклад, 15 днів за 3 000/міс. + 15 днів за 3 500/міс. ≈ 3 250 USDC), а не відкривайте другий рахунок "стріму". Зміна ставки — це метадані того самого зобов'язання, а не новий інструмент.
- Роботодавець скасовує стрім у середині місяця 3: Облікуйте остаточне нарахування за неповний місяць до позначки часу блоку скасування, потім залишок за "Стрімами до сплати" або виводиться остаточним зняттям, або, якщо учасник ніколи його не вимагає, залишається як зобов'язання, доки він це не зробить (або доки воно не буде офіційно втрачено згідно з відповідною угодою про грант/участь — не обнуляйте його в односторонньому порядку).
Якщо учаснику платять у мінливому токені замість стейблкоїна, додайте ще один рядок до кожного нарахування: вкажіть кількість токенів та їхній еквівалент у доларах США за справедливою ринковою вартістю на момент цього запису, оскільки вам знадобиться як зобов'язання, виражене в токенах (щоб знати, що ви насправді винні в мережі), так і витрати, виражені у фіатній валюті (для вашого звіту про прибутки та збитки та будь-яких розрахунків податкових утримань).
Поширені помилки
- Облік виведення коштів як витрат. Це найпоширеніша помилка — вона занижує витрати (і завищує фінансовий запас) за кожен період, коли одержувач не вимагає свій баланс, а потім скидає оманливо великі витрати в той період, коли він нарешті виводить кошти.
- Відкриття нового рахунку зобов'язань при кожній зміні ставки. Учасник, чию оплату коригували чотири рази на рік, не повинен мати чотири рядки, що захаращують план рахунків — змінюйте існуюче нарахування.
- Ігнорування комісій протоколу. Механізм ліквідатора Superfluid та будь-які комісії на рівні протоколу за створення або закриття стріму є реальними витратами, хоч і невеликими, і повинні бути в бухгалтерській книзі — їх легко пропустити, оскільки вони вираховуються автоматично, а не з'являються як окрема транзакція, яку помітив би бухгалтер.
- Сприйняття стрімінгових платформ як повноцінних систем розрахунку зарплати. Sablier та Superfluid безперервно переміщують гроші; жодна з них не подає податкові форми, не розраховує утримання та не займається класифікацією працівників. Більшість команд поєднують стрімінговий рівень з інструментом комплаєнсу, таким як Request Finance або Toku, або з традиційним провайдером розрахунку зарплати для працівників за формою W-2, і залишають сирі стріми протоколу для виплат підрядникам та грантів, де тягар комплаєнсу менший.
- Забування про граничний випадок неплатоспроможності. Якщо буфер відправника Superfluid вичерпується і ліквідатор примусово закриває стрім, це подія, яку ваші книги повинні відобразити — остаточне нарахування зупиняється на позначці часу ліквідації, а не на даті, коли ваш бухгалтер випадково помітив, що стрім мертвий.
Чому аудиторський слід насправді є недооціненою перевагою
Волатильність та ризик ліквідації привертають увагу, але реальна перевага для фінансових команд полягає в тому, що кожна подія стріму — початок, зміна ставки, пауза, виведення, скасування — є незмінною ончейн-транзакцією з позначкою часу та номером блоку. Це повна, захищена від підробки книга обліку зарплати, яка існує незалежно від того, чи згадав ваш бухгалтер її зареєструвати. Вона усуває ворожіння з рахунками, які переслідують ручний облік криптозарплати ("чи ми насправді відправили цьому учаснику їхній жовтневий платіж, чи транзакція тихо провалилася?").
Ця перевага окупиться лише в тому випадку, якщо ваші власні книги відображають ланцюг, а не суперечать йому. Бухгалтерські книги у звичайному тексті з контролем версій є природним вибором тут: ви можете створити щоденне або щомісячне завдання, яке читає події стріму безпосередньо з індексатора або субграфа та додає відповідні записи про нарахування до вашого файлу книги, захоплюючи хеш ончейн-транзакції в метаданих запису. Beancount.io дає вам саме це — формат бухгалтерського обліку у звичайному тексті, який ви можете генерувати та аудитувати програмно, з повною історією в git, так що рахунок зобов'язань "стріми до сплати" та його зміни ставок є настільки ж інспектованими, як і будь-яка інша частина вашої скарбниці. Якщо ви будуєте цю інтеграцію, документація розповідає про створення користувацьких структур рахунків та програмне генерування записів, а Fava надає вам інформаційну панель, щоб насправді бачити, як нарахування накопичується проти вашого грошового запасу в реальному часі — що для моделі розрахунку зарплати, повністю побудованої навколо реального часу, здається правильним способом спостерігати за цим.