Смарт-контракти та відповідальність сторін

1) Введення

Смарт-контракт автоматизує виконання домовленостей, але не усуває юридичну відповідальність. Навпаки: код, чейндж-менеджмент і операційні процедури створюють нові зони ризику - від вразливостей і маніпуляцій оракулів до конфліктів при апгрейдах і форках мережі. Ця стаття дає структуру розподілу ролей і відповідальності та набір договірних/технічних заходів, які перетворюють «код як закон» на «код як частину правового режиму».

2) Ключові терміни та розмежування

Смарт-контракт - програмний код, що виконується в блокчейні за детермінованими правилами.
Оператор - юридична особа, яка розгортає/підтримує протокол або гру і визначає політику.
Розробник/студія - творець коду та/або смарт-контрактів.
Провайдери інфраструктури - оракули, мости, VRF/випадковість, індексатори, RPC.
Адмін-ключі/ролі - права на апгрейд, параметри, «pause/kill-switch».
DAO/грантоутримувачі - власники токенів/голосів, що беруть участь в управлінні.
Користувач/гравець - сторона, що взаємодіє з контрактом і несе ризики транзакцій/волатильності.

3) Модель розподілу відповідальності (хто за що відповідає)

Оператор платформи

відповідність локальним законам (iGaming/VASP/платіжні режими), KYC/AML/санкції;

публікація та актуалізація ToS, Risk Disclosures, Responsible Gaming;

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

Розробник/студія

якість коду, аудит і тестове покриття;

супровід апгрейдів і міграцій, безоп. зберігання секретів;

багбаунті, Responsible Disclosure, розбір пост-мортем.

Провайдери оракулів/мостів/VRF

SLO/доступність, коректність фідів і анти-маніпуляційні заходи;

договірні гарантії та межі відповідальності (cap), журнал інцидентів, SLA.

Валідатори/майнери/мережа

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

Користувач

самостійна оцінка ризиків, охорона приватних ключів, дотримання локальних законів;

бриджинг засобів і взаємодія з фронтендами/гаманцями третіх осіб.

DAO/тримачі токенів (якщо governance)

прийняття параметрів ризику (ліміти, комісії), схвалення апгрейдів, екстрені рішення.

4) «Код як закон» vs «Код як частина договору»

На практиці код - це виконавча частина договору: ToS і Політики визначають намір сторін, порядок врегулювання помилок, виключення і пріоритет текстової норми при конфлікті.

1. пріоритет інтерпретації (ToS> специфікація> код? або навпаки - з чіткими винятками);

2. як трактуються очевидні баги (mistake) і «непередбачені стани»;

3. коли допускається відкат/патч/пауза, і хто санкціонує дію.

5) Апгрейди, адмін-ключі та довіра

Прозорість ролей: перерахуйте адреси з правами'owner','admin','guardian', вкажіть, які методи доступні кожній ролі.
Timelock & multi-sig: затримки перед апгрейдом (наприклад, 24-72 години) і багатопідписні права знижують ризик зловживань.
Emergency pause/kill-switch: регламент використання, критерії (критична вразливість, компрометація оракула), процедура повідомлення та поновлення.
Proxy-контракти та міграції: документуйте процес, дозволяйте користувачам вийти до перемикання логіки (grace period).
Застереження про незмінність: якщо контракт on-chain immutable, вкажіть обмеження і наслідки (неможливість полагодити крит-баг без міграції активів).

6) Зовнішні залежності та каскадні ризики

Оракули цін і VRF: захист від маніпуляцій (TWAP, репліки, кворум джерел), договірні SLA і ліміти відповідальності.
Мости/бриджі: найбільші історичні втрати пов'язані з мостами - використовуйте ліміти TVL, страховку, поетапні ліміти виведення.
RPC/індексатори: дублювання провайдерів, health-checks і фолбеки.
Фронтенд/домен: захист від підміни (DNSSEC, subresource integrity), публічні адреси контрактів, офлайн-шлях взаємодії з контрактом.

7) Ризики та їх кваліфікація

Технічні: уразливості, помилки логіки, re-entrancy, переповнення, невірне округлення, MEV/фронт-раннінг.
Економічні: маніпуляція ринком/оракулом, «bank run», неспроможна токеноміка.
Операційні: втрата адмін-ключів, компрометація CI/CD, людський фактор.
Правові: недобросовісна реклама, відсутність ліцензії, порушення санкцій/AML, захист споживачів.
Форс-мажор web3: атаки на L1/L2, тривалий outage мережі, «безпечний» хард-форк, катастрофічні баги залежностей.

8) Обмеження та розподіл відповідальності (договірні пункти)

• Disclaimer ризиків (волатильність, смарт-контракти, сторонні залежності, ризик повної втрати коштів).
• Limitation of Liability (cap): обмеження сукупної відповідальності розміром комісій/виручки за X місяців або фіксованим cap.
• No consequential damages: виключення непрямих збитків (упущена вигода і т.п.).
• Assumption of risk: підтвердження усвідомленого прийняття ризиків користувачем.
• Indemnification: звільнення оператора від вимог, викликаних порушенням Користувачем закону/ToS.
• Force-majeure (web3-версія): збої мережі, атаки на консенсус, критичні вразливості залежностей, дії регуляторів.
• Right to suspend/pause: право тимчасово зупинити операції при загрозі безпеці.

9) Інцидент-менеджмент і компенсації

Policy & Playbook: контактні канали, терміни первинного повідомлення (наприклад, Т + 24ч), статуси, апдейти.
Сегментація інцидентів: 'P0/P1/P2'за впливом на засоби/доступність.
Компенсаційні механізми: пул резерву, страхування, грантові компенсації через DAO, пріоритет реституції постраждалим.
Пост-мортем: публічний звіт з таймлайном, root cause, коригувальні заходи.
Bug Bounty & Responsible Disclosure: застереження про сумлінне розкриття, канали, рівні винагород.

10) Governance и DAO

Кому належить відповідальність? Якщо рішення приймає DAO, зафіксуйте юридичне «представництво» (foundation/LLC/асоціація) і його роль.
Кворум і emergency-потоки: окремі пороги для критичних дій; делегати-вартові (guardians) для швидкого реагування.
Конфлікт інтересів: розкриття афілійованості розробників/валідаторів/оракулів.
Арбітраж спорів DAO ↔ користувачі: попереднє медіаційне вікно, потім - арбітраж/суд.

11) Юрисдикція, застосовне право і вирішення спорів

Вибір права (governing law) + форум (арбітраж/суд, місце, мова, процедура).
Диспозитивні норми споживчого права: в B2C частина умов може перевизначатися правом країни користувача.
Онлайн-арбітраж/ODR: допустимо як швидкий механізм при невеликих спорах.
Комбіновані моделі: технічна реституція on-chain + офчейн-арбітраж для оцінки збитку.

12) Конфіденційність та персональні дані

Якщо є акаунти/КУС: Privacy Policy, GDPR-основи, DPIA, мінімізація даних, терміни зберігання.
Он-чейн-дані публічні: пропишіть ризики deanonymization, рознесіть PII офчейн.
Збір телеметрії фронтенда - тільки з легітимним підставою і opt-out/consent, де потрібно.

13) Комплаєнс-мінімум для криптоігр/протоколів з реальною цінністю

Ліцензії/реєстрації: iGaming/VASP/MSB/платіжні режими по гео.
KYC/AML/санкції: рівні, джерела коштів, Travel Rule (якщо застосовується).
Реклама: вікові фільтри, дисклеймери, заборона обіцянок, що вводять в оману.
Податки: облік GGR/комісій, курсових різниць, токен-казначейства.

14) Документація та артефакти (тримати актуальними)

Terms of Service + Risk Disclosure + Responsible Gaming (якщо застосовується).
Smart-contract Specs (інваріанти, межі параметрів, апгрейд-процедури).
Admin/Keys Policy (multi-sig, timelock, зберігання, ротація).
Security Policy (аудити, тести, bug bounty, SCA/SSA).
Incident Response Policy + шаблон повідомлення користувачів.
Oracle/Bridge SLA + контрактні ліміти відповідальності.
Change Log & Post-mortems (публічний репозиторій змін).

15) Матриця відповідальності (приклад RACI)

16) Чек-лист запуску (короткий)

1. Визначити ролі/адреси з правами, включити timelock + multi-sig.
2. Описати апгрейд-процедуру і «pause/kill-switch» в ToS і в README репозиторію.
3. Провести незалежний аудит, включити багбаунті, опублікувати звіт.
4. Законтрактувати оракули/мости з SLA і лімітами TVL/виводу.
5. Налаштувати моніторинг інваріантів (TVL, дисбаланси пулів, затримки оракулів).
6. Прописати Risk Disclosures, ліміти відповідальності (cap), force-majeure.
7. Затвердити Incident Policy і шаблон повідомлень, резерв на компенсації.
8. Верифікувати комплаєнс (ліцензії, KYC/AML, санкції, податки, реклама).
9. Підготувати міграційний план (grace period) на випадок крит-апгрейду.
10. Періодично проводити game-day/chaos-тести і пост-мортеми.

17) Шаблонні пункти для ToS/Політик (начерки формулювань)

• «Оператор та/або призначені зберігачі (guardians) має право застосувати тимчасове призупинення виконання смарт-контрактів у випадках виявлення критичних вразливостей, з подальшим публічним звітом і планом відновлення».

• "Зміни логіки контрактів здійснюються через timelock не менше N годин; адреси адміністраторів та історія змін публікуються в репозиторії/на сайті".

• «Сукупна відповідальність Оператора за цією Угодою обмежена сумою комісій/платежів, фактично сплачених Користувачем за останні N місяців, і не включає непрямі збитки».

• «Сторони не несуть відповідальності за затримки/невиконання, викликані збоями базової мережі, атаками на консенсус, критичними дефектами зовнішніх оракулів/мостів, діями державних органів».

• «Взаємодія зі смарт-контрактами пов'язана з ризиком повної і безповоротної втрати активів внаслідок вразливостей коду, помилок конфігурації, маніпуляцій ринком».

(Узгодьте формулювання з локальним юристом; для B2C можливі обов'язкові застереження про права споживачів.)

18) Глосарій

Timelock - затримка перед вступом змін в силу.
Multi-sig - багатопідписний контроль адмін-операцій.
Kill-switch/Pause - екстрена зупинка виконання контрактів.
Invariant monitoring - автоматичні перевірки ключових властивостей протоколу.
RACI - матриця розподілу відповідальності.

Висновок

Юридична стійкість смарт-контрактів будується на трьох стовпах: (1) ясні ролі і межі відповідальності, відображені в публічних політиках і ToS; (2) технічна дисципліна - апгрейди через timelock/multi-sig, аудит, моніторинг інваріантів, інцидент-менеджмент; (3) надійні домовленості з провайдерами зовнішніх залежностей і коректні застереження про відповідальність і форс-мажор. Поєднання цих елементів знижує ймовірність спірних ситуацій і задає передбачувану модель поведінки сторін навіть в умовах невизначеності web3.