Часто задаваемые вопросы
Чёткие ответы о восстановлении, Хранителях, Бенефициарах, конфиденциальности, безопасности, комиссиях, NFT, гибкости и многом другом — CryptoLegacy FAQ.
Что такое Адреса восстановления?
Адреса восстановления — это один или несколько адресов, которые Владелец настраивает для выполнения действий Восстановления по заданному владельцем порогу подтверждений. Восстановление может дополнительно включать аутентификацию по паролю. Адреса восстановления хешируются вместе с паролем и остаются несвязанными с конкретным контрактом CryptoLegacy до тех пор, пока их не используют on-chain.
Метаданные активов, связанные с Восстановлением, шифруются отдельно для роли восстановления. Адреса восстановления могут в любой момент расшифровать эти метаданные, чтобы подготовить транзакции Восстановления. Одна только расшифровка не даёт доступ к активам и не позволяет делать переводы.
Адреса восстановления могут отменять активное голосование Хранителей и Период оспаривания, а также запускать заранее заданный on-chain процесс Восстановления. Этот процесс сначала переводит активы в контракт CryptoLegacy, а затем отправляет их на любой указанный адрес — строго по настроенным правилам.
Кто такие Бенефициары?
Бенефициары — это адреса, назначенные Владельцем для получения активов в Период распределения. Для каждого Бенефициара Владелец задаёт долю, опциональную задержку перед получением и период, в течение которого активы становятся доступными к получению постепенно. Эти параметры вместе определяют, как и когда активы станут доступными к получению.
Метаданные активов для Бенефициаров шифруются индивидуально для каждого Бенефициара. Бенефициары не видят балансы кошельков, метаданные активов или состояние контракта до тех пор, пока не будут выполнены условия распределения.
Если истекает 6-месячный период неактивности, любой Бенефициар может запустить 3-месячный Период оспаривания. Если Период оспаривания не отменён, Бенефициары могут расшифровать зашифрованные метаданные, запустить on-chain процесс перевода активов в контракт CryptoLegacy и получать активы постепенно по своим настроенным графикам.
Если включены одобренные плагины, Бенефициары также могут использовать заранее заданную логику плагинов в Период распределения. Все действия Бенефициаров выполняются строго по on-chain правилам и не дают прямого доступа к приватным ключам или неограниченного контроля над активами.
Кто такие Хранители?
Хранители — это адреса, которым разрешено обходить 6-месячный период неактивности и запускать распределение через голосование по заранее заданному порогу подтверждений.
Как только порог подтверждений достигнут, может начаться заданный Владельцем Период оспаривания (до 30 дней). В этот период Владелец или адрес восстановления может отменить процесс.
После Периода оспаривания любой Хранитель может запустить on-chain процесс, который переводит активы в контракт CryptoLegacy для распределения. Хранители не могут вывести активы на свои адреса или перенаправить их.
По умолчанию Бенефициары также выступают Хранителями: порог подтверждений 3 из 5 и Период оспаривания 30 дней.
Что означают Обычный период, Период оспаривания и Период распределения?
Это состояния контракта CryptoLegacy:
Обычный период — контракт активен, не хранит активы и раз в 6 месяцев требует on-chain транзакцию для подтверждения активности Владельца. В этот период Владелец сохраняет полный контроль и управляет активами напрямую в своих кошельках.
Период оспаривания — запускается, когда истекает 6-месячный период неактивности или когда Хранители голосованием обходят таймаут по заданному порогу подтверждений. Длится до 3 месяцев и может быть отменён Владельцем или адресом восстановления.
Период распределения — метаданные активов становятся доступными для расшифровки, и Хранители или Бенефициары могут запустить on-chain процесс перевода активов в контракт CryptoLegacy. Затем Бенефициары получают свои доли постепенно по настроенному графику. Адреса восстановления также могут выполнить процесс Восстановления и перевести все активы строго по правилам контракта.
Мои Бенефициары не знакомы с Web3, криптой и блокчейном. Это обязательное требование?
Нет.
Бенефициарам не нужен опыт в Web3 или блокчейне, чтобы участвовать в Периоде распределения. Они взаимодействуют только с заранее заданными сценариями контракта — например, расшифровывают метаданные и получают активы по настроенному графику.
Есть документация и подсказки в интерфейсе, которые объясняют нужные шаги. Все действия с активами выполняются протоколом автономно, строго по on-chain правилам.
В чём преимущества CryptoLegacy по сравнению с мультисиг-кошельками для восстановления и наследования?
Мультисиг-кошельки созданы для совместного контроля, а не для наследования. В них Бенефициарам нужно заранее держать ключи подписи. Это может рано раскрывать балансы и делает управление ключами критичным на длинной дистанции.
CryptoLegacy работает иначе:
Активы остаются в кошельках Владельца до тех пор, пока не наступят условия распределения. Это снижает раннее раскрытие балансов и убирает совместное хранение.
Правила распределения задаются заранее и исполняются on-chain. Когда распределение начинается, выполнение получается понятным и детерминированным.
Средства не “заперты” в общем кошельке. Это снижает риск навсегда потерять доступ из‑за утерянных, неактивных или недоступных ключей.
Восстановление вынесено в отдельный заранее заданный процесс Восстановления. Адреса восстановления могут выполнить полное Восстановление по правилам контракта, без общего доступа к средствам в Обычный период.
Это разные модели: мультисиг — про совместный доступ и координацию, а CryptoLegacy — про распределение по времени, Восстановление и жёсткое разделение ролей между Владельцем, Хранителями, адресами восстановления и Бенефициарами.
Чем CryptoLegacy отличается от физического разделения мнемоники?
Физическое разделение мнемоники — это когда seed-фразу делят на части и раздают нескольким людям на долгое хранение. Такой подход требует, чтобы все правильно координировались, понимали свою роль, годами хранили фрагмент и действовали честно, когда придёт время. Любая ошибка, потеря, недопонимание или отсутствие сотрудничества может навсегда заблокировать доступ к активам.
CryptoLegacy использует другую модель:
Никакого физического или цифрового “шаринга” мнемоники — seed-фразы и приватные ключи никогда не делятся, не копируются и не распределяются.
Нет требований к долгой координации — Бенефициарам, Хранителям и адресам восстановления не нужно хранить секреты, помнить процедуры или координироваться вне заранее заданных правил.
Исполнение по правилам, а не “на доверии” — переводы активов и действия Восстановления выполняются через заранее заданные on-chain процессы, а не через восстановление приватного ключа по договорённости людей.
Отдельный процесс Восстановления — Восстановление идёт по явной логике контракта, без ручных решений и без необходимости доверять людям в момент исполнения.
Эти подходы закрывают разные риски: физическое разделение мнемоники опирается на долгосрочную секретность, координацию и доверие между участниками, а CryptoLegacy вообще убирает распределение секретов и исполняет Восстановление и распределение через on-chain правила.
Как CryptoLegacy сравнить с юридическим наследованием?
Традиционное юридическое наследование передаёт права собственности, но в self-custody оно не решает две практические проблемы. Во‑первых, приватные ключи или аппаратные кошельки всё равно нужно где-то хранить, перевозить или раскрывать кому-то — а это неизбежные риски потери, копирования или злоупотреблений. Во‑вторых, исполнение зависит от процедур конкретной юрисдикции — судов, посредников и сроков. Это может быть долго, спорно и сложно, особенно между странами.
CryptoLegacy использует другую модель. Он не полагается на посредников для работы с ключами. Вместо этого Восстановление и распределение выполняются on-chain по заранее заданным правилам, независимо от судебных процессов в момент перевода. Юридическое наследование и CryptoLegacy закрывают разные уровни: право определяет “кто имеет право”, а CryptoLegacy даёт детерминированный механизм исполнения без раскрытия приватных ключей.
Как CryptoLegacy сравнить с наследованием или восстановлением на базе MPC?
В MPC-сетапах контроль над активами разделён между несколькими участниками, которые совместно подтверждают действия. Когда MPC используют для наследования, Бенефициары фактически становятся частью MPC-группы, которая должна одобрять переводы.
На практике это создаёт неопределённость. Часто непонятно, кто запускает восстановление, сколько участников должны сотрудничать, что делать, если кто-то недоступен, и как решать конфликты. Исполнение зависит от off-chain координации, доступности участников и их корректного поведения именно в момент, когда активы нужно перевести.
CryptoLegacy следует другой модели. Бенефициарам не нужно координировать использование ключей или участвовать в off-chain подтверждениях. Вместо этого Восстановление и распределение выполняются on-chain по заранее заданным правилам, с чёткими ролями, порогами подтверждений и условиями по времени.
Эти подходы опираются на разные предположения: MPC рассчитывает на активную координацию участников, а CryptoLegacy исходит из того, что координация может сорваться, и “зашивает” правила исполнения прямо в протокол.
Как CryptoLegacy сравнить с Shamir’s Secret Sharing?
Shamir’s Secret Sharing делит приватный ключ или мнемонику на несколько фрагментов. Чтобы восстановить исходный секрет, нужен порог фрагментов. В сценариях наследования эти фрагменты обычно раздают Бенефициарам или доверенным людям на долгое хранение.
На практике это похоже на физическое разделение мнемоники. Фрагменты нужно хранить годами, участники должны оставаться доступными, а кто-то должен организовать восстановление секрета. Если фрагменты потеряны, удерживаются или собраны неправильно, активы могут стать навсегда недоступными. Исполнение зависит от человеческой координации в момент Восстановления.
CryptoLegacy использует другую модель. Приватные ключи и мнемоники никогда не восстанавливаются и не раскрываются. Вместо сборки секрета Восстановление и распределение выполняются on-chain по заранее заданным правилам, порогам подтверждений и условиям по времени. Бенефициарам не нужно держать или объединять фрагменты, и в момент исполнения не требуется off-chain координация.
Эти подходы опираются на разные предположения: Shamir’s Secret Sharing рассчитывает на долгую доступность и сотрудничество участников, а CryptoLegacy предполагает, что координация может не сработать, и кодирует логику исполнения прямо в протокол.
Как CryptoLegacy обеспечивает безопасность смарт-контрактов?
CryptoLegacy использует персональные смарт-контракты, которые в Обычный период не держат активы. Это снижает поверхность атаки до тех пор, пока не наступят условия распределения или Восстановления.
Логика контракта намеренно минимальная и выполняет только заранее заданные действия. Протокол прошёл независимые аудиты безопасности, а все операции с активами завязаны на явные on-chain условия, а не на произвольные решения.
Активы остаются в кошельках Владельца до тех пор, пока распределение или Восстановление не будет запущено по правилам контракта. Протокол не держит и не управляет активами вне этих заранее заданных сценариев исполнения.
Как CryptoLegacy обеспечивает безопасность интерфейса?
Интерфейс CryptoLegacy не хранит приватные ключи или чувствительные данные об активах и не участвует в исполнении операций с активами. Вся критичная логика обеспечивается смарт-контрактами on-chain, а не фронтендом.
Хостed-интерфейс использует стандартные практики веб-безопасности и защиту от распространённых сетевых атак. Если вам нужен дополнительный контроль, фронтенд можно хостить самостоятельно. Это снижает зависимость от сторонней инфраструктуры, не меняя поведение контрактов.
Что будет, если я не отправлю обязательную транзакцию раз в шесть месяцев?
Если истечёт 6-месячный период неактивности, может быть запущен 3-месячный Период оспаривания. Период оспаривания могут начать Бенефициары или Хранители по заданному порогу подтверждений.
Во время Периода оспаривания процесс может быть отменён Владельцем или адресом восстановления. Если Период оспаривания завершится без отмены, начнётся Период распределения по заранее заданным правилам контракта.
После этого Хранители или Бенефициары могут запустить on-chain процесс, который переводит активы в контракт CryptoLegacy. Затем Бенефициары получают свои доли постепенно по настроенному графику, а адреса восстановления могут выполнить процесс Восстановления и перевести все активы так, как задано в правилах контракта.
Могу ли я хостить фронтенд CryptoLegacy самостоятельно?
Да.
Фронтенд CryptoLegacy можно хостить самостоятельно, используя опубликованный репозиторий. Это позволяет запускать интерфейс на своей инфраструктуре — например, на IPFS, Arweave или на приватном сервере — без зависимости от хостed-версии.
Самостоятельный хостинг не меняет поведение контрактов или логику исполнения. Все критичные действия по-прежнему обеспечиваются on-chain смарт-контрактами, независимо от того, где именно отдаётся интерфейс.
Как CryptoLegacy защищает приватность Бенефициаров и активов?
CryptoLegacy сделан так, чтобы ограничивать раскрытие информации и откладывать видимость до тех пор, пока не наступят условия распределения или Восстановления.
Каждый контракт CryptoLegacy использует свой уникальный адрес. Он не связан напрямую с кошельком Владельца или другими контрактами.
Адреса Бенефициаров, Хранителей и адреса восстановления хранятся как хеши. Это не даёт заранее связать их с конкретным контрактом, пока они не появятся on-chain.
Метаданные активов шифруются по ролям и могут быть расшифрованы только тогда, когда выполнены соответствующие on-chain условия.
В Обычный период активы остаются в кошельках Владельца. Контракт не держит средств и не раскрывает балансы или данные об активах до момента исполнения.
Приватность в CryptoLegacy обеспечивается разделением ролей, хешированными идентификаторами, зашифрованными метаданными и исполнением по правилам, а не “скрытием” через кастодиальные схемы или off-chain секретность.
Могут ли Бенефициары или Хранители получить ранний доступ к зашифрованным данным, если изучать блокчейн или код?
Зашифрованные метаданные публично видны on-chain, и их можно анализировать off-chain.
Но такие метаданные невозможно осмысленно расшифровать без соответствующих приватных ключей. И даже успешная расшифровка сама по себе не даёт возможности двигать активы. Все переводы активов всё равно завязаны на on-chain условия, пороги подтверждений и заранее заданные сценарии исполнения, определённые контрактом.
Просмотр фронтенда, самостоятельный хостинг интерфейса или аудит исходников не дают дополнительных прав сверх того, что и так публично видно on-chain. Интерфейс не хранит приватные ключи или незашифрованные данные об активах и не обходит криптографические или контрактные ограничения.
CryptoLegacy не опирается на “секретность” интерфейса для приватности. Он опирается на шифрование, разделение ролей и исполнение on-chain по правилам — принимая, что данные в блокчейне по дизайну публичны.
Но подтверждения и зашифрованные данные хранятся on-chain — разве это технически не доступно?
Да. Зашифрованные метаданные и данные подтверждений публично видны on-chain, и их можно анализировать off-chain.
Но техническая доступность не означает практический доступ или контроль. Зашифрованные данные нельзя осмысленно расшифровать без приватных ключей, а даже успешная расшифровка не позволяет вывести активы вне заранее заданных путей исполнения.
CryptoLegacy исходит из того, что данные в блокчейне публичны по умолчанию, и фокусируется на том, чтобы видимость не превращалась во власть. Восстановление и распределение могут выполняться только через заранее заданные on-chain правила, независимо от off-chain анализа или попыток реверс-инжиниринга.
Может ли CryptoLegacy поддерживать NFT и другие протоколы?
CryptoLegacy спроектирован как расширяемый через систему плагинов на базе Diamond Standard (EIP-2535).
Архитектура плагинов позволяет добавлять дополнительную логику исполнения, не меняя базовое поведение ядра. Это включает поддержку типов активов и интеграций с протоколами, выходящих за рамки простых переводов токенов.
На старте система плагинов уже есть. Поддержка NFT и дополнительные интеграции планируются и будут добавляться со временем через одобренные плагины. Регистрация и исполнение плагинов остаются под заранее заданными правилами и не меняют логику распределения.
Что если приватный ключ скомпрометирован?
Если приватный ключ скомпрометирован в Обычный период, Владелец может обновить конфигурацию контракта по заранее заданным правилам. Это может включать смену адреса Владельца, обновление адресов Бенефициаров или Хранителей, или изменение настроек Восстановления.
Как только начинается Период распределения, контроль Владельца приостанавливается и больше не может использоваться для изменения исполнения. На этом этапе переводы активов идут строго по заранее заданным правилам распределения или Восстановления, независимо от скомпрометированного ключа.
Бенефициары могут обновлять свои адреса для получения активов в Период распределения, если это разрешено логикой контракта. Ни одна роль не может использовать скомпрометированный ключ, чтобы обойти on-chain условия или изменить сценарии исполнения.
Что делать, если ключи возможно скомпрометированы и у меня нет доступа к устройствам или бэкапам?
В Обычный период можно использовать заранее заданные механизмы Восстановления в рамках конфигурации контракта.
Хранители могут запустить заранее заданный on-chain процесс перевода активов в контракт CryptoLegacy — с учётом порогов подтверждений и настроенного Периода оспаривания. Во время Периода оспаривания процесс может быть отменён Владельцем или адресом восстановления.
Адреса восстановления также могут выполнить процесс Восстановления по заранее заданным правилам. Этот процесс переводит активы в контракт CryptoLegacy и позволяет отправить их так, как задано в конфигурации Восстановления.
Все действия выполняются строго по on-chain правилам. Ни одна роль не может обойти пороги подтверждений, задержки по времени или условия исполнения.
Можно ли поставить контракт на паузу или снять с паузы?
В контракте CryptoLegacy есть механизм паузы, который блокирует переводы активов и другие действия исполнения.
Пока контракт на паузе, активы нельзя перемещать, и запуск Периода оспаривания блокируется. При этом Владелец всё ещё может менять конфигурацию контракта, включая настройки Бенефициаров, конфигурацию Хранителей, параметры Восстановления и другие опции, не связанные с исполнением, — согласно правилам протокола.
6-месячный период неактивности продолжает идти даже когда контракт на паузе. Чтобы не попасть в Период оспаривания, Владелец должен обновить 6-месячный таймер, отправив обязательную on-chain транзакцию подтверждения активности (и DAO-пожертвование, если применимо).
Если период неактивности уже истёк, Период оспаривания нельзя запустить, пока контракт на паузе. Но его можно будет запустить сразу после снятия с паузы.
Снятие с паузы возвращает исполнение в том же виде, по тем же on-chain условиям. Разрешения на токены можно отозвать в любой момент отдельно, вне механизма паузы.
Можно ли настроить графики получения активов для Бенефициаров?
Да.
Для каждого Бенефициара Владелец задаёт долю, опциональную задержку перед получением и период, в течение которого активы становятся доступными к получению постепенно. Эти параметры определяют, когда начинается получение активов и как именно доступ к ним “раскрывается” со временем.
Задержка перед получением — время ожидания, прежде чем Бенефициар сможет начать получать активы.
Период вестинга — срок, в течение которого активы становятся доступными к получению постепенно по заданному графику.
Параметры можно обновлять в Обычный период. Когда начинается Период распределения, параметры фиксируются и дальше исполняются on-chain строго по заданным правилам.
Какие DAO-пожертвования требуются в CryptoLegacy?
CryptoLegacy поддерживается за счёт DAO-пожертвований.
Фиксированное DAO-пожертвование нужно при деплое персонального контракта и при регулярном подтверждении активности с нужным интервалом.
Также может быть доступна опция безлимитного доступа по настройкам протокола. Она покрывает деплой контрактов и подтверждения активности в поддерживаемых сетях.
Что такое реферальный механизм и как он работает?
В CryptoLegacy есть опциональный реферальный механизм, чтобы учитывать доверенные рекомендации.
Если используется реферальный код, применяется заранее заданная скидка для того, кто деплоит контракт, а также заранее заданное начисление для владельца реферального кода — строго по правилам протокола.
Реферальные коды рассчитаны на приватное использование и доверенные ситуации, а не на публичное распространение или рост через кампании. Адреса для выплат, связанные с реферальными кодами, можно обновлять по конфигурации протокола.
Что будет, если core-команда не сможет поддерживать продукт?
CryptoLegacy не зависит от постоянного участия core-команды для исполнения логики контрактов.
После деплоя контракты CryptoLegacy работают автономно on-chain и не требуют централизованных сервисов для Восстановления или распределения. Фронтенд можно хостить самостоятельно, а с контрактами можно взаимодействовать напрямую on-chain, независимо от хостed-интерфейса.
Доступность кода и поддержка могут со временем меняться по правилам управления проектом, но уже деплоенные контракты остаются рабочими и продолжают исполнять заданные правила независимо от текущей поддержки команды.
Почему код контракта открыт, но под copyright и не выпущен под open-source лицензией?
Код контрактов CryptoLegacy публично читаемый, чтобы его можно было независимо проверить и аудитить.
При этом код распространяется под copyright, чтобы ограничить непроверенное переиспользование, клонирование или деплой в вводящих в заблуждение и небезопасных сценариях. Это снижает риск скамов, неправильно настроенных форков или неавторизованных деплоев, которые могут навредить пользователям.
Лицензирование и доступность кода могут со временем меняться по управлению проектом и мере зрелости. Но независимо от лицензии, уже деплоенные контракты продолжают автономно работать и исполнять свои правила on-chain.
Почему код интерфейса закрыт и обфусцирован?
Интерфейс CryptoLegacy не является границей безопасности. Он не хранит приватные ключи, расшифрованные метаданные активов и не имеет “власти” над исполнением. Вся критичная логика обеспечивается on-chain смарт-контрактами.
Код UI распространяется в обфусцированном виде, чтобы снизить риск фишинга, поддельных фронтендов и вводящих в заблуждение копий, которые могут заставить пользователя подписать нежелательные транзакции. Обфускация нужна, чтобы усложнить тривиальное копирование и модификации интерфейса в небезопасных контекстах, а не чтобы “заменить” криптографию или безопасность контрактов.
Пользователи могут хостить интерфейс сами или взаимодействовать с контрактами напрямую on-chain. Доступность кода UI и лицензирование могут со временем меняться по управлению проектом, но деплоенные контракты остаются полностью проверяемыми и исполняют правила независимо от фронтенда.
Last updated