Множинне володіння і ролі

1) Поняття і цілі

Множинне володіння - це модель, при якій актив/сервіс/домен управляється декількома суб'єктами з різними частками, правами та обов'язками. Ролі фіксують, що учасник може робити (operate, configure, curate, audit, withdraw), в яких межах (ліміти/квоти), з якими гарантіями (S-застави, R-репутація) і в якому контексті (гео, ризик, QoS).

• поєднати інвестиції та операційну експертизу без монополій;
• забезпечити прозорий розподіл виручки/ризику;
• забезпечити керовану еволюцію (апгрейди, лістинги, тарифи).

2) Таксономія володіння

1. Пайове (Equity/Fractional): фіксовані відсотки участі; дивіденди/голоси ∝ частці.
2. Пай-пули (Pool/Syndicate): «кап-таблиця» пулу, керована через RNFT часткою.
3. Спільне управління (Co-ownership): загальний ресурс (кластер/GPU/бридж) з SLA і квотами.
4. Делеговане (Delegated Ops): право на операцію передається «оператору» під вето/ліміти.
5. Ліцензійне (Franchise/Licensing): право використовувати бренд/механіку за тарифи.
6. Тимчасове/вестингове: частки і права розкриваються за графіком (кліф/вестинг).
7. Мульти-чейн володіння: актив і права розподілені між доменами (локальна R-репутація, переносяться RNFT-права).

3) Ролі та матриця прав

• Owner (фінансовий власник): економічні права, апрув великих угод.
• Operator (експлуатація): щоденні дії, SLO/SLA відповідальність.
• Maintainer (апгрейди/релізи): право змінювати конфіги/версії (під фіч-прапорами).
• Curator/Moderator: якість контенту/правил.
• Treasurer: розподіл доходів/компенсацій.
• Auditor/Regulator: перевірки, звіти, стоп-крани по комплаєнсу.
• Oracle/Validator: підтвердження подій, участь у консенсусі.

4) Контракти відносин (RNFT)

RNFT - невзаємозамінний «паспорт» відносин: чиї частки, які права, ліміти, KPI, відповідальність, вихід.

• 'parties []'( суб'єкти, DID/VC),'role _ bindings []','shares []'
• `rights/limits` (ABAC), `quorum/veto`, `fees/revshare`
• `S-stake`, `slashing_rules`, `SLA/KPI`
• 'vesting/cliff','transferability'( зазвичай - ні),'exit _ rules'
• `dispute/escrow`, `governance_version`, `sunset`

5) Частки, голоси і кворуми

5. 1 Модель голосів

[
\text{VotePower}_i(q) = \text{Share}_i \cdot f_R(R_i, q) \cdot f_S(S_i, q) \cdot f_C(\text{context}),
]

де (f_R) - модифікатор репутації, (f_S) - облік застави, (f_C) - контекст (ризик/гео/QoS). Коридор модифікації, напр., ([0. 8; 1. 2]) - щоб «сирий капітал» не домінував без якості.

5. 2 Кворуми і вето

Кворум: '> = Q%'сумарною VotePower.
Спеціальний кворум: для критичних дій (security/конфіденційність) вище.
Вето Auditor/Regulator: тимчасово блокує дію, запускає перевірку.
Sunset-правки: тимчасові зміни політик → авто-відкат, якщо не підтверджені.

6) Економіка: розподіл доходів і витрат

[
\ text {Payout} i =\underbrace {\beta _ i\cdot\text {NetRev}} {\text {частка/акціонер}}
; + ;\underbrace {\gamma _ {i, r }\cdot\text {OpsBonus}} {\text {операційні KPI}}
;-; \underbrace{\pi{i}\cdot \text{Penalty}}{\text{штрафы/SLA}},
]

де (\beta _ i) - частка володіння, (\gamma {i, r}) - бонус за роллю (r) (наприклад, Operator), (\pi _ i) - частка відповідальності за порушення.

• Pro-rata: пропорційно часткам.
• Usage-based: за фактичним споживанням.
• Risk-based: підвищені частки витрат для ролей з високим ризиком.

7) Делегування та обмежувачі

• ліміти (обсяг/сума/частота), QoS клас, гео-політики;
• «двоключовий режим»: Operator виконує, Owner/Auditor має вето;
• журнал операцій, оборотне делегування, auto-revoke при інциденті.

8) Конфлікти і диспути

Типи: економічні (payout), процедурні (кворум), якісні (SLA), комплаєнс.
Процес: ескроу депозиту, арбітри (список в RNFT), терміни, докази (підписані логи, мерклі-батчі), результати (компенсація/слешинг/роль-бан/амністія).
Fail-closed: при суперечці з безпеки/комплаєнсу - стоп-крани.

9) Крос-чейн переносимість

Права/ліміти переносяться як RNFT-знімки через месенджинг (state proofs).
Репутація R залишається локальною; переносяться тільки верифіковані бейджі агрегатів ("SLA≥99. 9%/90d»).
Фінальність і challenge: виплати і апгрейди враховують віконні затримки і ризик реорг.
Consistency: при розбіжності політик діє більш сувора.

10) Комплаєнс, приватність, аудит

DID/VC: креденшли ролей/прав, що перевіряються; мінімізація ПДн.
ZK-пруфи: підтвердження порогів (вік/гео/капітал) без розкриття.
Аудит-журнали: незмінні, підписані; експорт для регулятора.
Податки/утримання: вбудовані в Rewards Router, звіти і ретеншн.

11) Спостережуваність та операційні SLO

Метрики: uptime/latency per роль, error budget, час апрува пропозалів, частка успішних релізів без відкату, час нарахування виплат.
Дашборди: Ownership Overview (кап-таблиця), Roles Heatmap (навантаження/якість), Disputes & Slashing, Payouts & Cost, Governance Queue.
Алерти: перевищення лімітів делегування, деградація SLO операторів, аномалії розподілів.

12) Анти-фрод і анти-колюзія

Сибіл/кільця голосів: граф-аналіз, TrustRank, ліміти на взаємні апруви.
Рольове перевантаження: перевірка «непересічності» (наприклад, Auditor ≠ Treasurer).
Фармінг RNFT-бонусів: приховані контрольні завдання якості.
Страховий фонд: S-застави і загальна каса на інциденти (з прозорим поповненням).

13) Плейбук впровадження (за кроками)

1. Картування активу/сервісу: цінність, ризики, необхідні ролі.
2. Проектування ролей і ABAC: дії, ліміти, гео/комплаєнс, QoS.
3. Кап-таблиця і голоси: частки, модифікатори R/S, кворуми/вето.
4. RNFT-шаблони: Owner/Operator/Maintainer/Treasurer/Auditor; vesting/exit/dispute.
5. Економіка: формули розподілу доходів/витрат, бонуси за KPI.
6. Безпека: мультисиг/2-of-N, stop-крани, логи і підписи.
7. Спостережуваність: дашборди/алерти, SLO для ролей, аудит-брехня.
8. Пілот: обмежений домен, canary-апгрейди, стрес-тести диспутів.
9. 治理: процедури зміни часток/прав, sunset-правки.
10. Масштабування та крос-чейн: синхронізація RNFT, фінальність/податки.

14) KPI моделі множинного володіння

Операційка: p95 часу апрува пропозалів, безвідкатні релізи%, MTTR по інцидентах.
Економіка: маржа/повідомлення, Cost-to-Serve/учасник, точність і своєчасність виплат.
Справедливість: FairnessIndex за квотами/споживанням, індекс Гіні голосів/доходів.
Якість: SLA-брейки/1k подій за ролями, точність модерації/оракулів.
治理: участь у голосуваннях, швидкість параметр-конвергенції, частка вето-подій.

15) Чек-лист прод-готовності

• Визначено ролі та ABAC-матриці з лімітами/вето
• Сформована кап-таблиця, кворуми, модифікатори R/S
• Оформлені RNFT-шаблони (vesting, exit, dispute, audit)
• Налаштовані формули ревшера і розподілу витрат
• Реалізовані мультисиг, stop-крани, журнали та підписи
• Включені KYC/KYB (VC), ZK-пруфи порогів, податкові утримання
• Запущені дашборди та алерти за ролями/SLO/платежами
• Проведено пілот і ретрокалібрування кворумів/ваг
• Налаштована крос-чейн синхронізація RNFT і фінальності

16) Глосарій

RNFT: контракт відносин/прав/лімітів, KPI і процедур.
R (Reputation): непередавана репутація якості/довіри.
S (Stake): забезпечувальна застава; джерело слешингу/компенсацій.
ABAC: доступ за атрибутами (роль, гео, ризик, QoS).
Sunset: тимчасова правка політики з авто-відкатом.
Cap-table: розподіл часток власників.
Veto / Quorum: механізми контролю рішень.

17) Підсумок

Множинне володіння і ролі - це конструктор спільної відповідальності: частки задають економіку, ролі - операцію, RNFT - юридико-технічну зв'язність, а R/S - дисципліну і справедливість. Така модель дає масштабоване управління активами і сервісами в мультичейн-екосистемі: прозорі права, передбачувані виплати, швидкі апгрейди і контрольовані ризики.