Крипто-краудфандинг: де ламається збір коштів
Класичний крипто-краудфандинг ламається на стику збору та витрачання коштів. Поки триває продаж токенів, схема виглядає струнко, але зібране сходиться в один гаманець проєкту: ключ у засновника, логіка витрат — у листуванні та таблиці.
Щойно збір коштів на блокчейні закрито, вкладник бачить рух транзакцій, але не бачить сенсу цих рухів.
Друге вузьке місце — ручні виплати. Кожен транш підряднику йде окремим підписом, суми та терміни узгоджуються вручну, а голосування за етапами живе окремо від казни.
Утримувачі токенів голосують «за» звіт за етапом, але результат ні до чого не зобов'язує: виплата все одно йде за рішенням команди. Між рішенням і переказом немає виконуваного контракту, який звірив би результат і лише потім розблокував наступний транш.
Прозорість розрахунків — третя слабка ланка. У реєстрі видно, що кошти пішли, але не видно, який етап закрито і яке голосування це дозволило.
Постфактум це перевіряється вручну — зіставленням звітів, хешів транзакцій та обговорень, а така перевірка не масштабується і не переконує нових учасників.
Ми розбираємо схему за ланками: де потрібен гаманець проєкту з розділеним управлінням, де — автоматична виплата за умовою, де — голосування, жорстко прив'язане до траншу. Нижче — як це влаштовано в платформах, які збираємо ми.
Що дає поетапне голосування та токени-підтвердження
Кошти збору не йдуть засновнику одним переказом — вони депонуються в контракті та розкриваються траншами. Кожен транш прив'язаний до етапу з заздалегідь описаним результатом: що має бути зроблено і чим це підтверджується.
Утримувачі токенів участі голосують, підтверджуючи або відхиляючи етап, і лише після цього контракт відкриває наступну частину коштів.
Роль невзаємозамінних токенів тут не декоративна. Токен фіксує внесок конкретного учасника, його вагу в голосуванні та права — частку в майбутніх надходженнях або доступ до закритих матеріалів проєкту.
Голос не можна накрутити покупкою: вага прив'язана до реально внесених коштів і зберігається в незмінній історії.
Ефект видно в трьох місцях. Спірні виплати перетворюються з листування на формальну процедуру з прозорим результатом — частка конфліктів, що доходять до арбітражу, падає.
Старт збору стає коротшим: правила розкриття та випуску токенів зафіксовані в контракті, тому платформа виходить до інвесторів без ручних узгоджень на кожному кроці. Звітність проєкту збирається сама — кожне голосування, транш і підтвердження залишаються публічним слідом.
Для інвесторів це різниця між «довіртеся нам» і перевірюваним процесом. Контракти розгортаємо в публічній мережі Ethereum, щоб історія траншів не залежала від нас, і закладаємо аварійний контур: завислий етап можна переголосувати, а невитрачені кошти — повернути учасникам.
Моделі крипто-краудфандингу: ескроу, пайова, поетапна
Три робочі схеми розрізняються не способом збору, а тим, хто і коли отримує доступ до грошей. Ескроу на смарт-контракті тримає кошти до виконання умов, а випуск через мультипідпис вимагає згоди кількох сторін — платформа, автор проєкту та незалежний арбітр.
Поетапна схема дробить суму на транші та розкриває кожен лише після підтвердження віх, пайова дає вкладнику частку в результаті, а не повернення.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Ескроу на смарт-контракті з мультипідписом | Збір під поставку, де потрібен контроль обох сторін та арбітраж спірних ситуацій | Вимагає явних умов розблокування; при спорі гроші стоять до рішення |
| Поетапна з голосуванням за віхами | Довгі проєкти з проміжними результатами: продукт, дослідження, будівництво | Потрібен кворум і захист від змови великих утримувачів токенів |
| Пайова | Продукт з прогнозованим доходом, де вкладник розділяє прибуток | Частка розмивається при нових раундах, звітність має бути регулярною |
Умовне розкриття коштів зручно комбінувати: базовий ескроу плюс поетапні транші — це нормальна практика, але кожна нова гілка логіки розширює поверхню аудиту.
Тому вибір схеми збору ми фіксуємо до старту кампанії: зміна моделі на живому зборі вимагає міграції випущених токенів і повторної перевірки контрактів, а не правки одного параметра.
Як ми будуємо платформу: етапи інженерної роботи
Порядок етапів задано не зручністю команди, а порядком ризиків: спочатку фіксуємо правила економіки проєкту, потім пишемо код.
Платформа крипто-краудфандингу розпоряджається коштами учасників, тому кожне рішення перевіряється на папері та в тестовому контурі до потрапляння в робочу мережу.
-
Аудит вимог та економіки. Розбираємо модель: як вважається збір, що відбувається при недоборі суми, як влаштовані повернення, комісії та ролі адміністраторів. Результат — узгоджений опис правил, спільний для коду та приймання.
-
Проєктування схеми розрахунків. Описуємо рух коштів, випуск токенів за внесок і голосування утримувачів за віхами: хто голосує, який поріг кворуму, що відбувається при спорі.
-
Розробка контрактів. Збори, токен, казна, голосування, права адміністратора та аварійні зупинки — модульно. Ключові шляхи закриваємо автотестами до підключення інтерфейсу.
-
Інтеграції та особистий кабінет. Гаманці, верифікація користувачів, платіжні канали, повідомлення та аналітика. Звіряємо дані кабінету та мережі до останньої транзакції.
-
Тестовий контур. Проганяємо сценарії, які ламають платформи в реальності: недобір, скасування проєкту, спірна віха, повторний вхід, подвійне голосування.
-
Приймання платформи. Кожне правило економіки — окремий сценарій звірки з вихідним описом; результати фіксуємо у звіті. Тільки після цього переносимо систему в робочу мережу.
-
Навчання та передача. Віддаємо документацію, інструкції для адміністраторів, доступи та порядок дій у нештатних ситуаціях — команда замовника веде платформу сама.
Пакет передачі: контракти, схеми та регламенти
Здача платформи — це не передача «доступу до панелі» і не закриті ключі в листуванні. Замовник отримує працюючу систему та повний комплект матеріалів, за яким його команда або інший підрядник зможе розвивати її без нас. Що саме фіксується в акті передачі:
- Вихідний код контрактів: логіка збору коштів, випуск та облік NFT-внесків, голосування за етапами, розподіл виплат і повернення при недосягненні мети — з тестами та скриптами розгортання на чисту мережу.
- Схема потоків коштів: шлях від внеску учасника до виплати отримувачу етапу, включно з адресами пулів, утриманнями платформи, умовами автоматичного повернення та точками, де потрібне підтвердження голосування.
- Правила доступу: матриця ролей — адміністратор, казначей, аудитор, голосуючий — з розподілом прав, порогами мультипідпису, затримкою на виконання критичних операцій та механізмом зупинки при інциденті.
- Документація платформи: опис модулів, формати метаданих і станів, параметри конфігурації мережі, інструкція з розгортання та порядок відновлення з резервної копії.
- Регламент оновлень: як викочується нова версія логіки через проксі, хто підписує зміну, скільки вона чекає до застосування, як переноситься стан і як виконується відкат до попередньої версії.
- Моніторинг та алерти: набір відстежуваних подій — надходження, відхилені виплати, спроби несанкціонованого виклику — з порогами повідомлень і порядком реакції на збій.
- Приймальні сценарії: перелік контрольних прогонів, на яких перевіряється кожна гілка логіки перед запуском і після кожного оновлення.
Комплект залишається у вас у репозиторії та внутрішній базі знань, а не в нашій інфраструктурі.
Кейс: збір коштів з розкриттям за етапами
Платформа збирала кошти на запуск продуктів: внески йшли до спільного пулу, гроші лежали на одній адресі, а виплати за етапами команда проводила вручну.
Утримувачі токенів бачили лише підсумковий звіт засновника — ні статусу етапу, ні підтвердження, що переказ пішов за призначенням.
Чого це коштувало замовнику
Кожна виплата етапу перетворювалася на листування: звіт у таблиці, звірка з юристом, два підписи. Узгодження займало від п'яти до дев'яти днів, а спірний етап зупиняв фінансування на тижні — при тому що наступні раунди вже були зібрані.
Ручні перерахування давали окремий клас відмов: неправильна адреса, повторний переказ і відсутність сліду, хто саме схвалив виплату.
Що перебудували
Для кожного етапу розгорнули окремий ескроу-контракт FundStage: зібране ділиться за етапами, а переказ відкривається лише голосуванням утримувачів токенів.
Вага голосу вважалася за часткою в пулі, поріг — кваліфікована більшість при обов'язковому кворумі, після прийняття працювало вікно оспорювання. Звіт за етапом публікується разом із транзакцією, тому підмінити документ заднім числом не можна.
Метрики до і після
Термін виплати етапу скоротився з шести днів до кількох годин: гроші йдуть одразу після голосування, без підписів і ручних перерахувань.
Частка етапів, прийнятих з першого голосування, — близько 80 %, кількість спірних виплат впала з кількох на місяць до поодиноких, а операцій з ключами вручну не залишилося взагалі.
Чим ескроу відрізняється від мультипідпису і що вибрати
Ескроу та мультипідпис вирішують одне завдання — не дати одній стороні забрати кошти одноосібно, але влаштовані по-різному. В ескроу гроші лежать на рахунку смарт-контракту, і право на виведення виникає з умови: голосування за етапом, підпис оракула, закінчення терміну.
У мультипідписі кошти лежать у спільному гаманці, а транзакцію випускають живі підписанти — наприклад, 3 з 5.
Межа проходить за джерелом рішення: ескроу відповідає на питання «чи виконана умова» кодом, мультипідпис — людьми, які вирішують, чи підписувати.
Звідси компроміс: ескроу передбачуваний і не вимагає довіри до посередника, але не оцінює якість роботи; мультипідпис гнучкіший, але повертає людський фактор і ризик змови підписантів.
У крипто-краудфандингу з поетапним голосуванням механізми поєднують. Основний пул тримає ескроу-контракт і видає транші за підсумками голосування утримувачів NFT, а мультипідпис стоїть над ним: призупинення при інциденті, спірний етап, повернення при скасуванні кампанії.
Поріг підписів підбирають так, щоб одна сторона не блокувала випуск: 2 з 3 для оперативних рішень, 4 з 7 — там, де в комітеті інвестори, засновник і незалежний арбітр.
Головний аргумент проти чистого ескроу — спірні ситуації: контракт не відрізняє брак від причіпки. Вихід — оракул або арбітражний комітет з мультипідписом плюс вікно оспорювання, протягом якого отримувач не виводить кошти.
Порогові схеми та умовне зберігання беремо з перевірених бібліотек, наприклад OpenZeppelin, а не пишемо логіку підписів з нуля.
Вибір механізму зводиться до трьох питань: чи формалізується умова виплати, хто арбітр при спорі і скільки учасників має домовитися.
Якщо умова перевіряється автоматично — достатньо ескроу; якщо потрібна оцінка або екстрене втручання — додаємо мультипідпис і описуємо процедуру в контракті заздалегідь.
Технічні сумніви перед запуском платформи
Питання, які найчастіше піднімають на захисті проєкту, стосуються не логіки продукту, а меж відповідальності: що залишиться в команди, якщо платформа переїде, як вважається голосування за віхами і що відбувається з внесками при недосягненні мети збору.
Нижче — короткі відповіді за кожним пунктом із зазначенням, що фіксується в контрактах, а що в документації.
Чи можна перенести готову платформу на нашу інфраструктуру?
Так. Контракти розгортаються у вибраній мережі та на ваших вузлах, веб-інтерфейс і сервіси читання історії подій піднімаються у вашому середовищі. Передаємо конфігурації, схему розгортання та порядок міграції стану — переписувати логіку не потрібно.
Як вважається голосування за віхами?
Голос прив'язаний до частки внеску і вважається за зрізом балансів на момент відкриття голосування — вплинути на результат заднім числом не можна.
Кошти за віхою розблоковуються лише після проходження порогу, а правило обліку тих, хто утримався, задається заздалегідь, без ручного втручання адміністратора.
Що відбувається з токенами при недосягненні мети збору?
Якщо поріг не зібрано в строк, контракт переходить у режим повернення: вкладник забирає кошти сам, платформа не розпоряджається ними односторонньо. Нерозподілені токени спалюються або залишаються заблокованими — вибране правило фіксується до старту і не змінюється заднім числом.
Як оновлюються контракти і що з правами утримувачів токенів?
Оновлення йде через контракт-обгортку із затримкою застосування: зміни спочатку видні утримувачам, потім набирають чинності. Адміністративні ролі обмежені — у команди немає доступу до коштів кампаній, а права утримувачів описані прямо в інтерфейсі.
Обговоримо задачу і повернемося з оцінкою та планом
Для оцінки проєкту потрібні вхідні дані, а не загальний опис ідеї: «платформа для збору коштів» і «платформа з поетапним голосуванням утримувачів» — це різні архітектури, різний обсяг робіт і різний клас ризиків. Надішліть те, що вже є: опис механіки, таблиці розподілу, макети, чернетки контрактів.
- Економіка токена: раунди, розподіл часток, графік розблокування, кому і за що нараховуються токени.
- Голосування за етапами: хто голосує, як вважається вага голосу, який кворум потрібен і що відбувається зі зібраними коштами при відхиленні етапу.
- Шар NFT: що саме токенізується — частка, нагорода чи доступ; чи потрібен вторинний ринок і відрахування з перепродажів.
- Мережа та гаманець: сумісність з вибраною мережею, де зберігаються ключі користувачів, чи потрібні поповнення звичайними грошима.
- Ролі та доступи: адміністратор, підписанти виплат, хто може призупинити кампанію, вимоги перевірки учасників.
- Обмеження: юрисдикція, терміни, інтеграції з поточними системами та обов'язкові перевірки безпеки коду.
Після розбору ми повертаємося зі схемою: які контракти та ролі потрібні, як влаштований життєвий цикл кампанії, де точки контролю коштів. З цього збираємо план етапів — від прототипу до перевірки перед запуском, з порядком робіт і критеріями приймання на кожному кроці.
Опишіть задачу — обговоримо вхідні дані, повернемося з оцінкою проєкту, планом етапів і датою старту робіт.
