# Розділ 2 — Безпека: як зберегти свої активи в безпеці в будь-якій ситуації

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

* **Multisig-гаманці або MPC:** Збої в координації — реальний ризик. Якщо один ключ загубиться або буде скомпрометований, активи можуть «зависнути» або, навпаки, стати вразливими. А залежність від кількох підписантів ще й додає людський фактор: конфлікти та банальну недоступність у потрібний момент.
* **Передача мнемонічної фрази (mnemonic):** Просто, але крихко. Достатньо, щоб один фрагмент витік або загубився — і втрата може бути миттєвою та незворотною.
* **Традиційне юридичне зберігання (юристи, нотаріуси, трастові компанії):** Передаючи резервні копії або ключі посередникам, ви створюєте нові точки атаки. Документи можна скопіювати, загубити або використати не за призначенням, а юридичні процедури не вміють виконувати on-chain дії.

Саме тому Аліса обрала CryptoLegacy.

З CryptoLegacy Аліса зберігала повний контроль, поки була активною. Її активи залишалися в її власних гаманцях і ніколи не депонувалися в контракти третіх сторін. Система працювала як наперед задана машина станів: доки Аліса залишалася активною, ніхто інший не міг ініціювати перекази чи рухати активи.

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

Хранителі не мали прямого доступу до коштів і не бачили баланси. Навіть якщо акаунт Хранителя зламали б, це не дало б можливості миттєво щось «виконати». Їхня роль зводилася до того, щоб додати своє підтвердження для переходу між станами — а не отримати контроль.

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

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

Згодом Аліса одужала. Скориставшись наперед визначеним механізмом Відновлення, вона повернула контроль над активами, які ще залишалися в контракті. Перекази, що вже відбулися, були незворотними, але жодні додаткові активи не були «оголені» або переміщені завчасно.

CryptoLegacy не прибрав ризики повністю. Але він зменшив критичні сценарії відмови на рівні дизайну:

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

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

**Твої ключі. Твоя крипта. Твоя безпека.**