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

robot
Генерація анотацій у процесі

Потенційні пастки відповідності в операціях Web3 проектів

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

Проблема відповідальності в аутсорсингу послуг

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

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

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

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

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

Юридичний випадок 2024 року показує, що якщо є користувачі з США, які використовують платформу або інфраструктуру, розташовану в США, то американське законодавство може бути застосоване, навіть якщо платформа стверджує, що не має американських суб'єктів. Це свідчить про те, що регулятори не визнають заяву про "безнаціональність", оскільки, якщо існує зв'язок між користувачами та технологією, відповідальність може бути відстежена.

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

Публікація в ланцюзі не означає відсутність управління

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

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

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

Висновок

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

Web3 інвестиційний посібник | Відповідність (07): Які поширені, але "небезпечні" моделі управління існують у Web3 проектах?

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 5
  • Репост
  • Поділіться
Прокоментувати
0/400
BearWhisperGodvip
· 6год тому
Аутсорсинг – це обман! Зняв штани і пускає газ
Переглянути оригіналвідповісти на0
RugResistantvip
· 08-10 23:20
червоні прапори всюди в цій схемі аутсорсингу... SEC не сліпі, люди
Переглянути оригіналвідповісти на0
SleepyValidatorvip
· 08-10 23:20
Лежачи, також слід звертати увагу на Відповідність.
Переглянути оригіналвідповісти на0
BtcDailyResearchervip
· 08-10 23:17
Одразу видно, що це не відповідає вимогам.
Переглянути оригіналвідповісти на0
AllInAlicevip
· 08-10 23:10
Від аутсорсингу не втекти, SEC все ще може зловити кого завгодно.
Переглянути оригіналвідповісти на0
  • Закріпити