# Поширені запитання

## Що таке Адреси відновлення?

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

Метадані активів, пов’язані з Відновленням, шифруються окремо для ролі Відновлення. Адреси відновлення можуть розшифрувати ці метадані будь-коли, щоб підготувати транзакції Відновлення. Сам факт розшифрування не дає доступу до активів і не дозволяє робити перекази.

Адреси відновлення можуть скасувати активне голосування Хранителів і Період оскарження, а також запустити наперед визначений ончейн Процес відновлення. Спочатку цей процес переміщує активи в контракт CryptoLegacy, а потім переводить їх на будь-яку вказану адресу — строго за налаштованими правилами.

***

## Хто такі Бенефіціари?

Бенефіціари — це адреси, які Власник призначає для отримання активів у Період розподілу. Для кожного Бенефіціара Власник задає частку, необов’язкову Затримку перед отриманням і період вестингу — разом це визначає, як і коли активи стають Доступно до отримання.

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

Якщо спливає 6-місячний Період неактивності, будь-який Бенефіціар може запустити 3-місячний Період оскарження. Якщо Період оскарження не скасовано, Бенефіціари можуть розшифрувати зашифровані метадані, запустити ончейн-процес, який переміщує активи в контракт CryptoLegacy, і Отримувати активи поступово за своїми налаштованими графіками.

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

***

## Хто такі Хранителі?

Хранителі — це адреси, які мають право обійти 6-місячний Період неактивності та запустити розподіл через голосування за наперед визначеним порогом підтверджень.

Коли поріг підтверджень набрано, може застосовуватися налаштований Власником Період оскарження (до 30 днів). У цей час Власник або адреса відновлення можуть скасувати процес.

Після Періоду оскарження будь-який Хранитель може запустити ончейн-процес, який переміщує активи в контракт CryptoLegacy для розподілу. Хранителі не можуть виводити активи на свої адреси або перенаправляти їх.

За замовчуванням Бенефіціари діють як Хранителі з порогом 3 із 5 і Періодом оскарження 30 днів.

***

## Що означають Звичайний період, Період оскарження і Період розподілу?

Це стани контракту CryptoLegacy:

* **Звичайний період** — контракт активний, не тримає активів і вимагає періодичної ончейн-транзакції раз на 6 місяців для Підтвердження активності Власника. У цей час Власник має повний контроль і керує активами напряму у своїх гаманцях.
* **Період оскарження** — запускається, коли спливає 6-місячний Період неактивності або коли Хранителі голосують, щоб обійти таймаут за налаштованим порогом підтверджень. Триває до 3 місяців і може бути скасований Власником або адресою відновлення.
* **Період розподілу** — метадані активів стають доступними для розшифрування, а Хранителі або Бенефіціари можуть запустити ончейн-процес, який переміщує активи в контракт CryptoLegacy. Далі Бенефіціари поступово Отримують свої частки за налаштованим графіком розподілу. Адреси відновлення також можуть виконати Процес відновлення, щоб переказати всі активи відповідно до правил контракту.

***

## Мої Бенефіціари не шарять у Web3, крипті й блокчейні. Це обов’язково?

Ні.

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

Є документація та підказки в інтерфейсі, які пояснюють потрібні кроки. Усі дії з активами протокол виконує автономно за ончейн-правилами.

***

## Які переваги CryptoLegacy порівняно з multi-sig гаманцями для відновлення та передачі активів?

Мультисиг-гаманці (multi-sig) створені для спільного контролю, а не для передачі активів. Вони вимагають, щоб бенефіціари заздалегідь мали ключі підпису — це може рано «засвітити» баланси й робить керування ключами критичним на довгі роки.

CryptoLegacy працює інакше:

* Активи залишаються в гаманцях Власника, доки не виконані умови розподілу — без раннього розкриття балансів і без спільної опіки.
* Правила розподілу задаються наперед і виконуються ончейн — усе чітко й передбачувано, коли розподіл стартує.
* Кошти не заблоковані в спільному гаманці, тож менше ризику «назавжди втратити доступ» через загублені, неактивні або недоступні ключі.
* Відновлення йде окремим наперед визначеним Процесом відновлення: адреси відновлення можуть зробити повне Відновлення за правилами контракту, без потреби спільного доступу до коштів у Звичайний період.

Це два різні підходи: multisig — про спільний доступ і координацію, а CryptoLegacy — про розподіл у часі, Відновлення та чітке розділення ролей між Власником, Хранителями, Адресами відновлення і Бенефіціарами.

***

## Чим CryptoLegacy відрізняється від фізичного «шерингу» мнемоніки?

Фізичний шеринг мнемоніки — це коли seed phrase (фразу відновлення) ділять на частини й роздають різним людям на довге зберігання. Такий підхід вимагає, щоб усі учасники правильно скоординувались, розуміли свою роль, роками безпечно зберігали свій фрагмент і чесно діяли, коли настане час. Будь-яка помилка, втрата, непорозуміння або відсутність співпраці можуть назавжди заблокувати доступ до активів.

CryptoLegacy використовує іншу модель:

* Немає фізичного чи цифрового шерингу мнемоніки — фрази відновлення та приватні ключі ніколи не діляться, не копіюються й не розповсюджуються.
* Немає вимоги до довготривалої координації — Бенефіціари, Хранителі та Адреси відновлення не мають зберігати секрети, пам’ятати процедури або координувати дії поза наперед заданими правилами.
* Виконання за правилами, а не «збирання на довірі» — перекази активів і дії Відновлення виконуються через наперед визначені ончейн-процеси, а не через відновлення приватного ключа за домовленістю людей.
* Окремий Процес відновлення — Відновлення реалізоване прямо логікою контракту, без ручних рішень і без «довіри в моменті».

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

***

## Як CryptoLegacy порівнюється з юридичним спадкуванням?

Класичне юридичне спадкування передає право власності, але в self-custody воно не вирішує дві практичні проблеми. По-перше, приватні ключі або апаратні гаманці все одно доведеться десь зберігати, перевозити або комусь розкривати — а це неминучі ризики втрати, копіювання або зловживань. По-друге, виконання залежить від процедур конкретної юрисдикції — суди, посередники й терміни — і це може бути повільно, спірно або складно, якщо є кілька країн.

CryptoLegacy працює інакше: він не покладається на посередників для роботи з ключами. Натомість Відновлення та розподіл виконуються ончейн за наперед визначеними правилами — без прив’язки до судових процесів у момент передачі. Юридичне спадкування й CryptoLegacy закривають різні «шари»: закон визначає права, а CryptoLegacy дає детермінований механізм виконання переказів без розкриття приватних ключів.

***

## Як CryptoLegacy порівнюється з MPC-відновленням або MPC-спадкуванням?

У схемах на базі MPC (multi-party computation) контроль над активами розділяється між кількома учасниками, які разом авторизують дії. Коли MPC використовують для передачі активів, Бенефіціари фактично стають частиною MPC-групи, яка має погоджувати перекази.

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

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

Ці підходи виходять із різних припущень: MPC покладається на активну координацію між людьми, а CryptoLegacy закладає, що координація може зламатися, і кодує правила виконання прямо в протоколі.

***

## Як CryptoLegacy порівнюється з Shamir’s Secret Sharing?

Shamir’s Secret Sharing ділить приватний ключ або мнемоніку на кілька фрагментів, і потрібен поріг фрагментів, щоб відновити початковий секрет. У сценаріях передачі активів ці фрагменти зазвичай роздають Бенефіціарам або довіреним сторонам на довге зберігання.

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

CryptoLegacy працює інакше. Приватні ключі та мнемоніки ніколи не відновлюються й не розкриваються. Замість «склеювання секрету» Відновлення та розподіл виконуються ончейн за наперед заданими правилами, порогами та часовими умовами. Бенефіціарам не потрібно зберігати або поєднувати фрагменти, і в момент виконання не потрібна офчейн-координація.

Ці підходи виходять із різних припущень: Shamir’s Secret Sharing розраховує на довготривалу доступність і співпрацю людей, а CryptoLegacy закладає, що координація може зламатися, і кодує логіку виконання прямо в протоколі.

***

## Як CryptoLegacy забезпечує безпеку смартконтрактів?

CryptoLegacy використовує персональні смартконтракти, які у Звичайний період не тримають коштів — це зменшує поверхню атаки до того, як настануть умови розподілу або Відновлення.

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

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

***

## Як CryptoLegacy забезпечує безпеку UI?

Інтерфейс CryptoLegacy не зберігає приватні ключі або чутливі дані про активи й не бере участі у виконанні операцій з активами. Уся критична логіка примусово виконується ончейн смартконтрактами, а не фронтендом.

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

***

## Що буде, якщо я не надішлю потрібну транзакцію раз на шість місяців?

Якщо спливає 6-місячний Період неактивності, може бути запущений 3-місячний Період оскарження. Оскарження можуть запускати Бенефіціари або Хранителі відповідно до налаштованого порога підтверджень.

Під час Періоду оскарження процес може скасувати Власник або адреса відновлення. Якщо Період оскарження завершується без скасування, починається Період розподілу за наперед визначеними правилами контракту.

Тоді Хранителі або Бенефіціари можуть запустити ончейн-процес, який переміщує активи в контракт CryptoLegacy. Далі Бенефіціари поступово Отримують свої частки за налаштованим графіком розподілу, а адреси відновлення можуть виконати Процес відновлення, щоб переказати всі активи так, як задано конфігурацією контракту.

***

## Чи можу я хостити фронтенд CryptoLegacy самостійно?

Так.

Фронтенд CryptoLegacy можна хостити самостійно, використовуючи опублікований репозиторій. Самостійний хостинг дає змогу запускати інтерфейс на своїй інфраструктурі — наприклад, на IPFS, Arweave або приватному сервері — без залежності від хостованого фронтенду.

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

***

## Як CryptoLegacy захищає приватність Бенефіціарів і активів?

CryptoLegacy спроєктований так, щоб мінімізувати розкриття інформації й відкладати видимість до моменту, коли виконані умови розподілу або Відновлення.

* Кожен контракт CryptoLegacy має свою унікальну адресу, яка напряму не прив’язана до гаманця Власника або до інших контрактів.
* Адреси Бенефіціарів, Хранителів і Адрес відновлення зберігаються як хеші — це не дає завчасно пов’язати їх із конкретним контрактом, доки їх не використають ончейн.
* Метадані активів шифруються окремо для кожної ролі й можуть бути розшифровані лише тоді, коли виконані відповідні ончейн-умови.
* У Звичайний період активи залишаються в гаманцях Власника. Контракт не тримає коштів і не розкриває баланси чи дані активів до моменту виконання.

Приватність у CryptoLegacy забезпечується розділенням ролей, хешованими ідентичностями, зашифрованими метаданими та виконанням за правилами — а не «маскуванням» через кастодіальні або офчейн-механізми.

***

## Чи можуть Бенефіціари або Хранителі отримати доступ до зашифрованих даних раніше, просто аналізуючи блокчейн або код?

Зашифровані метадані публічно видимі ончейн і можуть аналізуватися офчейн.

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

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

CryptoLegacy не покладається на «секретність» або обмеження фронтенду для приватності. Він покладається на шифрування, розділення ролей і виконання за ончейн-правилами, приймаючи те, що дані в блокчейні за замовчуванням публічні.

***

## Але ж підтвердження та зашифровані дані зберігаються ончейн — хіба це не означає, що технічно до них є доступ?

Так. Зашифровані метадані та дані підтверджень публічно видимі ончейн і можуть аналізуватися офчейн.

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

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

***

## Чи може CryptoLegacy підтримувати NFT та інші протоколи?

CryptoLegacy спроєктований як розширюваний через систему плагінів на базі Diamond Standard (EIP-2535).

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

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

***

## Що буде, якщо приватний ключ скомпрометовано?

Якщо приватний ключ скомпрометовано у Звичайний період, Власник може оновити конфігурацію контракту за наперед визначеними правилами. Це може включати зміну адреси Власника, оновлення адрес Бенефіціарів або Хранителів чи налаштувань Відновлення.

Коли починається Період розподілу, контроль Власника призупиняється і вже не може використовуватися для зміни виконання. На цьому етапі перекази активів ідуть строго за наперед визначеними правилами розподілу або Відновлення — незалежно від скомпрометованого ключа.

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

***

## Що робити, якщо ключі потенційно скомпрометовані, а доступу до пристроїв або бекапів немає?

У Звичайний період можна використати наперед задані механізми Відновлення відповідно до конфігурації контракту.

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

Адреси відновлення також можуть виконати Процес відновлення за наперед визначеними правилами. Цей процес переміщує активи в контракт CryptoLegacy і дозволяє переказати їх так, як задано конфігурацією Відновлення.

Усі дії виконуються строго за ончейн-правилами. Жодна роль не може обійти пороги підтверджень, тайм-делі або умови виконання.

***

## Чи можу я поставити контракт на паузу або зняти з паузи?

Контракт CryptoLegacy має механізм паузи, який блокує перекази активів та інші дії виконання.

Поки контракт на паузі, активи не можуть бути переміщені, а запуск Періоду оскарження заблокований. Власник все ще може оновлювати конфігурацію контракту — зокрема налаштування Бенефіціарів, конфігурацію Хранителів, параметри Відновлення та інші опції, що не є «виконанням», — відповідно до правил протоколу.

Період неактивності продовжує спливати навіть коли контракт на паузі. Щоб не перейти в стан оскарження, Власник має оновити 6-місячний Період неактивності, надіславши потрібну ончейн-транзакцію Підтвердження активності (і DAO-пожертву, якщо застосовується).

Якщо Період неактивності вже сплив, Період оскарження не можна запустити, поки контракт на паузі, але його можна запустити одразу після зняття з паузи.

Зняття з паузи відновлює виконання за тими ж ончейн-умовами. Дозволи токенів (approve) можна відкликати окремо будь-коли — незалежно від механізму паузи.

***

## Чи можу я налаштувати графіки розподілу для Бенефіціарів?

Так.

Для кожного Бенефіціара Власник задає частку, необов’язкову Затримку перед отриманням і період вестингу. Ці параметри визначають, коли починається отримання активів і як саме активи стають Доступно до отримання з часом.

* **Затримка перед отриманням** — період очікування перед тим, як Бенефіціар зможе почати Отримувати активи.
* **Період вестингу** — тривалість, протягом якої активи стають Доступно до отримання поступово за налаштованим графіком.

Параметри розподілу можна змінювати Власником у Звичайний період. Коли починається Період розподілу, ці параметри фіксуються й примусово виконуються ончейн за заданими правилами.

***

## Які DAO-пожертви потрібні CryptoLegacy?

CryptoLegacy підтримується через DAO-пожертви.

Фіксована DAO-пожертва потрібна під час розгортання персонального контракту і під час оновлення Періоду неактивності в потрібні інтервали.

Також може бути доступна опція «безлімітного доступу» згідно з конфігурацією протоколу — вона покриває розгортання контрактів і оновлення таймауту на підтримуваних мережах.

***

## Що таке реферальний механізм і як він працює?

У CryptoLegacy є необов’язковий реферальний механізм, який задуманий для обліку довірених рекомендацій.

Коли використовується реферальний код, для того, хто розгортає контракт, застосовується наперед задана знижка, а наперед задана частка нараховується власнику реферального коду відповідно до правил протоколу.

Реферальні коди призначені для приватного використання в довірених контекстах, а не для публічного поширення чи «ґроус»-кампаній. Адреси виплат, прив’язані до реферальних кодів, можна оновлювати відповідно до конфігурації протоколу.

***

## Що буде, якщо core-команда не зможе підтримувати продукт?

CryptoLegacy не залежить від постійної участі core-команди для виконання логіки контрактів.

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

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

***

## Чому код контрактів відкритий для перегляду, але під copyright і не під open-source ліцензією?

Код контрактів CryptoLegacy публічно читабельний, щоб його можна було незалежно перевіряти й аудіювати.

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

Ліцензування й доступність коду можуть змінюватися з часом відповідно до управління проєктом і його зрілості. Незалежно від ліцензії, вже розгорнуті контракти продовжують автономно працювати ончейн і виконувати свої правила.

***

## Чому код UI закритий і обфускований?

Інтерфейс CryptoLegacy не є «межою безпеки». Він не зберігає приватні ключі, розшифровані метадані активів або повноваження на виконання. Уся критична логіка примусово виконується ончейн смартконтрактами.

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

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