Розробка системи обліку стейкінг-винагород для податків

Стейкінг податки: де ламається ручний облік винагород

Ручний облік стейкінг-винагород ламається не через неуважність, а через механіку мережі.

Винагорода за делегуванням нараховується не однією транзакцією, а потоком подій: кожної епохи валідатор отримує частку від загальної емісії, розподіляє її між делегаторами за часткою в пулі, вираховує комісію та віддає залишок.

Якщо цифри збирають раз на місяць з експорту гаманця, частина цих подій не потрапляє у вибірку взагалі.

Перше джерело розбіжностей — різний час знімків. Залишок делегування фіксується на момент вивантаження, а винагорода нараховувалася за станом на закриття епохи.

Варто делегатору в цей проміжок збільшити або скоротити частку — розрахунок дасть не ту суму, яка фактично надійшла на адресу.

Друге — спліти та реінвестування. Пул може перенаправляти частину доходу між валідаторами, частина винагороди йде в автореінвест і взагалі не проходить через гаманець окремим рядком, а частина — у вивід.

Ручний облік нарахувань бачить лише виводи й втрачає реінвестовану частину, хоча це теж дохід, отриманий у звітному періоді.

Усе це спливає на звірці нарахувань валідатора: підсумок за журналом не сходиться із сумою переказів, що надійшли, і кожну епоху доводиться розбирати вручну. Розбіжності у звітності за такої схеми неминучі — розбираємо, як це закривається системним обліком.

Що дає автоматизація обліку винагород: ефекти в показниках

Автоматизація обліку винагород будується навколо індексації: служба читає блоки, витягує події нарахування й прив’язує кожну до адреси валідатора та гаманця, що делегував.

Курс на момент нарахування береться з ринкового джерела — CoinGecko — і зберігається в записі разом із хешем операції, кількістю та точним часом. Далі це не набір вивантажень, а єдиний реєстр нарахувань, де кожен рядок відновлюється до первинної події в мережі.

Ефект видно в підготовці звітного періоду. Раніше звірка відбувалася вручну: вивантаження з оглядача, зведення делегувань, перерахунок курсу заднім числом — на один період витрачалося 2-3 дні та 6-8 окремих операцій на кожен гаманець.

З реєстром період збирається одним запитом за 15-20 хвилин, частка ручних операцій падає приблизно втричі, а результат не залежить від того, хто саме веде розрахунок.

Окремо зникає клас помилок, який найдорожче обходиться під час перевірки: пропущені нарахування після ре-делегування, подвійний облік переказів між власними адресами та розбіжності курсу на межі періоду.

Реєстр зберігає зв’язок «нарахування — гаманець — період — курс», тому такі розбіжності виявляються на етапі завантаження, а не на звірці.

Підготовка звітності з делегування зводиться до агрегатів: суми за гаманцями та періодами, деталізація до операції, журнал змін за кожним записом. Будь-яку цифру у звіті можна розкрити до хешу й часу нарахування — це знімає основне питання під час перевірки, звідки взялася сума.

Стейкінг податки: порівняння підходів до обліку винагород

Винагороди за стейкінг надходять різними проводками: автокомпаунд, ручне зняття, ределегування, комісія валідатора. Від того, звідки система бере дані, залежить, чи зможе бухгалтерія підтвердити кожну суму та зіставити її з ціною на момент нарахування.

Ми збирали облік на трьох схемах і бачимо: вибір визначається не зручністю звіту, а тим, скільки мереж і типів операцій потрібно закрити.

Порівняння підходів

Якщо операції йдуть через одного провайдера й винагороди однотипні, достатньо вивантажень із вузлів.

Щойно з’являються ределегування, комісії пулів і кілька мереж, гібридна схема окуповує складність: розбіжності між нарахованим і фактично отриманим видно до звітного періоду, а не після.

Етапи впровадження системи обліку винагород

Порядок робіт вибудувано так, щоб на кожному кроці була точка для перевірки: спочатку зрозуміти, звідки беруться винагороди, потім зафіксувати їхній рух і лише потім будувати звітність.

Пропущений етап випливає розбіжністю вже на податковій звірці, коли період закрито й перевіряти дані повторно дорого.

1. Аудит джерел даних. Інвентаризація: ноди та їхні програмні інтерфейси, гаманці й адреси, біржові та кастодіальні вивантаження, агрегатори. За кожним джерелом фіксуємо глибину історії та формат — машинне вивантаження, файл або лише ручний експорт.
2. Схема потоків винагород. Карта «джерело → адреса → власник → період → тип нарахування»: винагороди за стейкінг, комісії делегування, реінвестування та перекази між власними гаманцями позначаємо окремо, щоб не задвоювати дохід.
3. Налаштування збору нарахувань. Регулярне опитування джерел з ідемпотентним записом: повторний прохід не створює дублів. Окремо закриваємо прогалини в історії та переїзди адрес між гаманцями.
4. Звірка історичних періодів. Прогін на минулих періодах і порівняння з виписками та незалежними джерелами. Кожну розбіжність розбираємо до нуля із зазначенням причини — так перевіряються і логіка, і повнота даних.
5. Регламент податкових подій. Фіксуємо, що вважається моментом доходу, за яким курсом оцінюється нарахування на цю дату та як розділяються гаманці різних власників.
6. Передача регламентів і доступів. Схема даних, інструкції щодо вивантаження звіту за період, опис полів і порядок дій у разі збою джерела.

Далі звіт збирається за розкладом, а розбіжності видно на вході, а не в момент подання декларації.

Комплект документації та налаштувань, який ви отримуєте

Пакет документації — не звіт про виконану роботу, а робочий інструмент, за яким команда веде облік без нашої участі. Конфігурації та правила передаються в редагованому вигляді з версіонуванням: зміна параметра збору фіксується окремо від зміни даних. Нижче — що залишається у вас.

• Конфігурації збору винагород. Які адреси й гаманці входять до контуру, з якою періодичністю опитується мережа, скільки зберігається сирий лог і як підключити нове джерело.
• Схеми потоків винагород. Шлях від нарахування валідатору до зарахування на гаманець із позначкою моменту визнання доходу та точок, де сума ще не фінальна.
• Правила зіставлення адрес. Як пов’язати валідаторські, проміжні та користувацькі адреси з одним власником, включно з переадресацією та пулами з плаваючою часткою.
• Політики доступу до даних. Хто бачить повні суми, хто — лише агрегати, що потрапляє до журналу звернень і як видаються права на вивантаження.
• Регламент звірки. Періодичність, склад контрольних сум, поріг розбіжності для запуску розбору та шлях ескалації до відповідального за облік.
• Документація з обліку. Як формується звіт за період, як відображаються перекази та обмінні операції, як заводиться новий гаманець.

Документи звірено з фактичним станом системи на дату передачі: розбіжність між текстом і конфігурацією вважається дефектом, а не особливістю впровадження.

Кейс: як налагодили облік делегування перед перевіркою

До нас облік делегування вівся в ручних таблицях: вивантаження з оглядачів блоків, окремий CSV на кожен період, свій аркуш під кожного валідатора.

Під час підготовки до перевірки команда три тижні зводила нарахування з рухами за гаманцями, і частина періодів усе одно не сходилася — розбіжності випливали вже на зустрічі з перевіряльниками.

Перебудували основу: індексатор збирає події делегування та виплат із прив’язкою до валідатора, епохи й гаманця, а реєстр операцій зберігає зв’язок гаманця з юрособою та договором.

Нарахування фіксується за датою та курсом на момент отримання — через CoinGecko — тому податкова база рахується один раз і відтворювано, а не перераховується заднім числом.

Що вийшло на виході

Строк підготовки пакета для перевірки скоротився з трьох тижнів до трьох-чотирьох днів: вивантаження, звіт за періодами та звірка формуються одним запуском.

Частка періодів, де незалежна звірка до і після сходиться до останньої транзакції, зросла з двох третин до ста відсотків — розбіжності виявляються під час завантаження даних, а не в готовому звіті. Ручних операцій стало менше приблизно на вісімдесят відсотків.

Автоматика не скасовує перевірку людиною: залишаються нестандартні випадки — перекази між власними гаманцями, повернення з пулів, зміна валідатора всередині періоду. Але вони надходять окремим списком із готовим контекстом, і розбір займає хвилини замість днів.

Чим відрізняється облік винагород під час делегування від власного валідатора?

Різниця починається з того, хто формує винагороду. Під час делегування виплату робить пул: він збирає винагороду за блоки, утримує свою комісію та розподіляє залишок між учасниками пропорційно до частки.

Власник власного валідатора отримує нарахування напряму від мережі, без посередника та без чужого утримання.

Звідси різні джерела даних про нарахування. Для делегування потрібні звіти власника пулу та історія вхідних переказів — суми надходять пачками й не збігаються з епохами мережі один в один.

Для власного валідатора джерело одне: журнал адреси, де видно кожне нарахування, штраф за пропуск блоку та момент виводу.

Розподіл винагород за пулами додає тонкощів: в одних періодах утримується одна комісія, в інших — інша, і рівна частка дає різну суму на виході.

Тому облік винагород власного валідатора будується на первинних даних мережі, а делегування майже завжди потребує звірки двох контурів — що нарахував пул і що фактично дійшло на адресу.

Для податкової бази це принципово. Під час делегування дохід фіксується за фактом надходження, за власного валідатора — за моментом нарахування. Змішувати ці події в одному реєстрі не можна: база розійдеться з випискою за адресою, і обґрунтувати суми під час перевірки буде нічим.

Технічні сумніви: простої, форки та зміна пулів

Простій валідатора — не пропуск у звіті, а окремий період із нульовою дохідністю та штрафом за невиконані обов’язки. Журнал подій консенсусного шару розбираємо за інтервалами й присвоюємо кожному статус: активний, у черзі на вихід, офлайн.

Винагорода нараховується лише в першому випадку, а санкція за простій зменшує базу — у звіті це два різні рядки, а не одне сальдо.

Форк змінює правила нарахування та переписує історичні баланси. Перед активацією оновлення знімаємо снапшот стану та звіряємо з публічними оглядачами мережі, наприклад Beaconcha.in.

Граничні періоди розбираємо точково — за подіями депозитів і виводів, без повного перерахунку всієї історії.

Зміна пулу розриває джерело даних: до переходу винагороди йшли від одного оператора, після — від іншого, з іншою комісією та графіком виплат. Зберігаємо прив’язку валідатора до пулу за періодами, тому підсумок збирається з відрізків, а не усереднюється за весь строк.

Реінвестування — часта причина подвійного обліку: винагорода, автоматично додана до стейку, виглядає і як дохід, і як новий депозит. Позначаємо такі події окремим типом — наступний період рахується від збільшеної бази, податок не нараховується двічі.

Пул заднім числом перерахував винагороди — переписувати минулий період?

Заводимо коригувальний запис із датою первісного нарахування. Звітність залишається незмінною, а розбіжність видно окремим рядком.

Обговоримо задачу: які дані потрібні для оцінки

Щоб повернутися з оцінкою, а не з уточнювальними питаннями, достатньо одного листа з вступними даними. Нижче — що саме надіслати; якщо частина відомостей недоступна, так і напишіть — підкажемо, чим замінити.

• Перелік мереж, активів і валідаторів, де розміщено кошти, включно з позиціями, закритими всередині періоду.
• Джерела відомостей про винагороди: вивантаження з клієнтського гаманця або консолі, відповіді оглядачів блоків, звіти пулів і валідатор-сервісів, листи про розподіл.
• Формат і повнота даних: CSV або JSON за періодами, сирі нарахування, а не лише зведення за місяць — за агрегатами не відновити дату та ціну кожної виплати.
• Адреси гаманців і пулів на всьому горизонті, з усіма проміжними та зміненими адресами.
• Рух коштів: перекази між власними гаманцями, реінвестування, вивід — інакше винагороди задвоюються під час зведення.
• Поточна методика обліку: на яку дату та за якою величиною фіксується винагорода, що вже потрапило до звітності та що визнано спірним.
• Вимоги приймальної сторони: формат звіту, рівень деталізації, які рядки перевіряються в першу чергу.

Отримавши цей набір, ми фіксуємо межі робіт і повертаємося з порядком і строками: звірка та нормалізація даних, узгодження методики розрахунку, складання звіту, передача вам і супровід правок. Опишіть задачу — повернемося з оцінкою та планом робіт.