Где-то прямо сейчас в финансовом канале 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 предоставляет панель мониторинга, чтобы в реальном времени видеть, как начисление растет по отношению к вашему денежному запасу — что для модели оплаты, полностью основанной на реальном времени, кажется правильным способом за этим наблюдать.