> For the complete documentation index, see [llms.txt](https://docs.cryptolegacy.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cryptolegacy.app/russkii/scenarii-ispolzovaniya/glava-3-gibkost-bystro-menyayushiesya-investicii.md).

# Глава 3 — Гибкость: быстро меняющиеся инвестиции

CryptoLegacy остаётся стабильным при изменении активов и стратегий, позволяя портфелю развиваться между сетями без блокировки средств и пересборки логики хранения или наследования.

Боб обожал исследовать новые возможности в блокчейне — минтить NFT, стейкать токены, добавлять ликвидность в разных сетях и пробовать свежие DeFi‑протоколы. По мере роста портфеля главной проблемой становился не доступ, а непрерывность: как инвестировать свободно, но при этом сохранить понятную и постоянную модель восстановления и наследования.

* **Мультисиг-кошельки или MPC:** Боб экспериментировал с мультисигами как с резервным вариантом и для наследования. Но каждая новая сеть или протокол требовали новой конфигурации и новой координации. Потеря доступа означала зависеть от других ровно в самый неподходящий момент. Со временем обычные действия превращались в лишнюю операционку.
* **Передача мнемоники:** Разделить сид‑фразу поначалу казалось простым решением. Но чем больше становился портфель, тем более хрупкой становилась схема. Каждый новый кошелёк, протокол или сеть требовали обновлений, объяснений и ручной координации. Маленькие недосказанности и пропуски постепенно превращались в реальный риск.
* **Традиционное юридическое хранение (юристы, нотариусы, трастовые компании):** Обновлять юридические документы под каждую новую инвестицию — долго и дорого. Бумажные процессы просто не успевали за ончейн‑активностью и добавляли новые риски для безопасности.
* **Кастодиальные платформы:** Сначала кастодиальные сервисы выглядели гибко. Они скрывали сложность, давали единый интерфейс и упрощали кроссчейн‑активность. Но эта гибкость держалась на внешних правилах, юрисдикциях и операционных решениях, на которые Боб не мог повлиять. Менялись условия — мог измениться и доступ, причём без ончейн‑гарантий и без заранее заданных путей восстановления.

Поэтому Боб и выбрал CryptoLegacy.

С CryptoLegacy Боб продолжил инвестировать, не блокируя активы и не меняя свои привычные сценарии «на каждый день». Его средства оставались в его собственных кошельках. Контракты CryptoLegacy не хранят активы — они лишь задают разрешения и правила исполнения. Новые кошельки можно было подключать просто выдав разрешение на переводы на тех же заранее определённых условиях.

Выходя в новые блокчейны, Боб переиспользовал одну и ту же конфигурацию Бенефициаров и Восстановления. Контракты разворачивались с одинаковой логикой — не через перенос активов, а через копирование правил. Это позволяло сразу защищать новые инвестиции, не переобсуждая доверие и не переделывая наследование каждый раз.

Система плагинов CryptoLegacy поддерживала эту гибкость, но в чётких границах. В период распределения Бенефициары могли взаимодействовать с активами только через те действия, которые Боб явно разрешил — стейкинг, свап или закрытие позиций — и при этом не получали контроля над таймингом, порогами подтверждений или правилами исполнения. Плагины расширяли «что можно сделать», а не «кто принимает решения».

Планируемые кроссчейн‑инструменты работают по тому же принципу. Активы смогут перемещаться между средами только при выполнении условий протокола — с сохранением переходов состояний, порогов подтверждений и временных ограничений между сетями.

Если бы Боб когда‑нибудь потерял доступ, Адреса восстановления давали бы заранее заданный путь, чтобы вернуть контроль над оставшимися активами — без предварительной заморозки средств и без ограничений на то, как именно устроен его портфель.

CryptoLegacy не оптимизировал инвестиции. Он гарантировал, что свобода инвестиций не будет достигаться ценой непрерывности.

Боб мог менять стратегии, сети и протоколы без блокировки активов, без пересборки хранения и без добавления новых допущений по доверию сверх того, что он уже определил.

**Ваши ключи. Ваша крипта. Ваша гибкость.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.cryptolegacy.app/russkii/scenarii-ispolzovaniya/glava-3-gibkost-bystro-menyayushiesya-investicii.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.