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

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

Питання відповідальності за послуги аутсорсингу

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

У реальних прикладах, Комісія з цінних паперів і бірж США (SEC) під час розслідування певного проєкту, проаналізувавши записи електронної пошти, операційні траєкторії та кадрову інформацію, визнала, що його структура аутсорсингу не ефективно ізолює відповідальність. Також Комісія з цінних паперів і ф'ючерсів Гонконгу зазначила, що якщо основні рішення все ще контролюються одним і тим же реальним контролером, навіть якщо бізнес аутсорсинг, це не вважається незалежною діяльністю.

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

Регуляторні труднощі з реєстрацією в багатьох місцях і розподіленими вузлами

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

Нещодавні випадки показують, що якщо існують місцеві користувачі або інфраструктура, регулятори можуть стверджувати про юрисдикцію. Регулятори з кількох країн та регіонів вимагають розкриття "фактичного місця управління" та "фактичного місця проживання основних керівників".

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

Публікація в ланцюгу не означає, що немає управління

Деякі технічні команди вважають, що, як тільки смарт-контракт буде розгорнуто, він відділяється від проєкту, намагаючись уникнути відповідальності через "децентралізовану доставку". Але регулятори не підтримують цю точку зору. Вони більше зосереджені на офлайновій поведінці, такій як хто ініціює маркетинг, організовує розміщення, контролює шляхи обігу тощо.

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

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

Висновок

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