Frequently Asked Questions
Clear answers on Recovery, Guardians, Beneficiaries, privacy, security, fees, NFTs, flexibility, and more - CryptoLegacy FAQ.
What are Recovery Addresses?
Recovery addresses are one or more addresses configured by the owner to execute recovery actions under an owner-defined approval threshold. Recovery can optionally include additional password-based authentication. Recovery addresses are hashed together with the password and remain unlinkable to a specific CryptoLegacy contract until they are used on-chain.
Recovery-related asset metadata is encrypted per recovery role. Recovery addresses can decrypt this metadata at any time to prepare recovery transactions. Decryption alone does not grant access to assets or allow transfers.
Recovery addresses can cancel active Guardian voting and Challenge periods, and can initiate the predefined on-chain recovery process. This process first moves assets into the CryptoLegacy contract and then transfers them to any specified address, strictly according to the configured rules.
Who are the Beneficiaries?
Beneficiaries are addresses designated by the owner to receive assets during the Distribution period. For each Beneficiary, the owner defines a share, an optional delay, and a distribution period, which together determine how and when assets become claimable.
Beneficiary-related asset metadata is encrypted individually per Beneficiary. Beneficiaries have no visibility into wallets balances, asset metadata, or contract state until distribution conditions are met.
If the 6-month inactivity timeout expires, any Beneficiary may initiate a 3-month Challenge period. If the Challenge period is not canceled, Beneficiaries can decrypt the encrypted metadata, trigger the on-chain process that moves assets into the CryptoLegacy contract, and claim assets gradually according to their configured schedules.
If approved plugins are enabled, Beneficiaries may also use the predefined plugin logic during Distribution. All Beneficiary actions are executed strictly according to on-chain rules and do not grant direct access to private keys or unrestricted control over assets.
Who are the Guardians?
Guardians are addresses authorized to bypass the 6-month inactivity timeout and initiate distribution by voting according to a predefined approval threshold.
Once the threshold is reached, an owner-configured Challenge period (up to 30 days) may apply. During this period, the owner or a recovery address can cancel the process.
After the Challenge period, any Guardian may trigger the on-chain process that moves assets into the CryptoLegacy contract for distribution. Guardians cannot withdraw assets to their own addresses or redirect them.
By default, Beneficiaries act as Guardians with a 3-of-5 approval threshold and a 30-day Challenge period.
What do Normal, Challenge, and Distribution periods mean?
They represent the states of a CryptoLegacy contract:
Normal — The contract is active, holds no assets, and requires a periodic on-chain transaction every 6 months to confirm owner activity. During this period, the owner retains full control and manages assets directly in their wallets.
Challenge — Triggered when the 6-month inactivity timeout expires or when Guardians vote to bypass the timeout according to the configured approval threshold. This period lasts up to 3 months and may be canceled by the owner or a recovery address.
Distribution — Asset metadata becomes decryptable, and Guardians or Beneficiaries may trigger the on-chain process that moves assets into the CryptoLegacy contract. Beneficiaries then claim their shares gradually according to the configured distribution schedule. Recovery addresses may also execute the recovery flow to transfer all assets according to the contract rules.
My Beneficiaries aren't familiar with web3, crypto, and blockchain. Is this a requirement?
No.
Beneficiaries do not need prior Web3 or blockchain experience to participate in the Distribution process. They interact only with predefined contract flows, such as decrypting metadata and claiming assets according to the configured schedule.
Documentation and interface guidance are available to explain required steps. All asset-related actions are executed autonomously by the protocol according to on-chain rules.
What are the advantages of CryptoLegacy over multi-sig wallets for recovery and inheritance?
Multi-signature wallets are designed for shared control, not for inheritance. They require beneficiaries to hold signing keys in advance, which can expose balances early and make key management critical over long periods.
CryptoLegacy uses a different approach:
Assets remain in the owner’s wallets until distribution conditions are met, avoiding early balance exposure and shared custody.
Distribution rules are defined in advance and enforced on-chain, providing clear, deterministic execution when distribution begins.
Funds are not locked in a shared wallet, reducing permanent lock-out risks caused by lost, inactive, or unavailable keys.
Recovery is handled through a separate, predefined recovery flow, allowing recovery addresses to execute a full recovery according to contract rules, without requiring shared access to funds during normal operation.
The two models serve different purposes: multisig focuses on shared access and coordination, while CryptoLegacy focuses on time-based distribution, recovery, and strict role separation between owner, guardians, recovery addresses, and beneficiaries.
How is CryptoLegacy different from physical mnemonic sharing?
Physical mnemonic sharing involves splitting a wallet’s recovery phrase and distributing parts of it to multiple people for long-term storage. This approach requires all participants to coordinate correctly, understand their role, retain their fragment securely over long periods, and act honestly when the time comes. Any mistake, loss, misunderstanding, or lack of cooperation can permanently block access to assets.
CryptoLegacy follows a different model:
No physical or digital sharing of mnemonics — recovery phrases and private keys are never split, copied, or distributed.
No long-term coordination requirements — beneficiaries, guardians, and recovery addresses do not need to store secrets, remember procedures, or coordinate actions outside predefined rules.
Rule-based execution instead of trust-based assembly — asset transfers and recovery actions are executed through predefined on-chain processes, not by reconstructing a private key through human agreement.
Dedicated recovery flow — recovery is handled through explicit contract logic, removing the need for manual decision-making or trust at the time of execution.
The two approaches address different risks: physical mnemonic sharing relies on long-term secrecy, coordination, and trust between participants, while CryptoLegacy removes secret distribution entirely and enforces recovery and distribution through on-chain rules.
How does CryptoLegacy compare to legal inheritance?
Traditional legal inheritance transfers legal ownership, but in self-custody it does not solve two practical problems. First, private keys or hardware wallets must eventually be stored, transported, or disclosed to someone, which introduces unavoidable risks of loss, copying, or misuse. Second, execution depends on jurisdiction-specific procedures—courts, intermediaries, and timelines—which can be slow, disputed, or hard to coordinate across countries.
CryptoLegacy uses a different model: it does not rely on intermediaries to handle keys. Instead, recovery and distribution are executed on-chain according to predefined rules, independent of court processes at the moment of transfer. Legal inheritance and CryptoLegacy address different layers: legal systems define rights, while CryptoLegacy provides a deterministic mechanism for executing transfers without exposing private keys.
How does CryptoLegacy compare to MPC-based inheritance or recovery?
In MPC-based setups, control over assets is split across multiple participants who collectively authorize actions. When MPC is used for inheritance, beneficiaries effectively become part of the MPC group responsible for approving transfers.
In practice, this creates ambiguity. It is often unclear who initiates recovery, how many participants must cooperate, what happens if some beneficiaries are unavailable, or how disagreements are resolved. Execution depends on off-chain coordination, participant availability, and correct behavior at the exact moment assets need to be transferred.
CryptoLegacy follows a different model. Beneficiaries are not required to coordinate key usage or participate in off-chain approval flows. Instead, recovery and distribution are executed on-chain according to predefined rules, with clear roles, thresholds, and time-based conditions defined in advance.
The two approaches address different assumptions: MPC relies on active coordination between participants, while CryptoLegacy assumes that coordination may fail and encodes execution rules directly into the protocol.
How does CryptoLegacy compare to Shamir’s Secret Sharing?
Shamir’s Secret Sharing splits a private key or mnemonic into multiple fragments, requiring a threshold of fragments to reconstruct the original secret. In inheritance scenarios, these fragments are typically distributed to beneficiaries or trusted parties for long-term storage.
In practice, this creates similar challenges to physical mnemonic sharing. Fragments must be stored securely for long periods, participants must remain available, and someone must eventually coordinate the reconstruction process. If fragments are lost, withheld, or combined incorrectly, assets can become permanently inaccessible. Execution depends on human coordination at the exact moment recovery is needed.
CryptoLegacy follows a different model. Private keys and mnemonics are never reconstructed or revealed. Instead of reassembling a secret, recovery and distribution are executed on-chain according to predefined rules, thresholds, and time-based conditions. Beneficiaries do not need to hold or combine secret fragments, and no off-chain coordination is required at execution time.
The two approaches address different assumptions: Shamir’s Secret Sharing assumes long-term availability and cooperation of participants, while CryptoLegacy assumes that coordination may fail and encodes execution logic directly into the protocol.
How does CryptoLegacy ensure the smart contract security?
CryptoLegacy uses personal smart contracts that are fundless during normal operation, reducing the attack surface before any distribution or recovery conditions are met.
Contract logic is intentionally minimal and executes only predefined actions. The protocol has undergone independent security audits, and all asset-related operations are gated by explicit on-chain conditions rather than discretionary logic.
Assets remain in the owner’s wallets until distribution or recovery is triggered according to the contract rules. No assets are held or managed by the protocol outside these predefined execution flows.
How does CryptoLegacy ensure the security of UI?
CryptoLegacy’s interface does not store private keys or sensitive asset data and does not participate in asset execution. All critical logic is enforced by smart contracts on-chain, not by the frontend.
The hosted interface is delivered using standard web security practices and protections against common network-level attacks. For users who require additional control, the frontend can be self-hosted, reducing reliance on third-party infrastructure without changing contract behavior.
What happens if I don’t send the required transaction every six months?
If the 6-month inactivity timeout expires, a 3-month Challenge period may be initiated. The Challenge can be started by Beneficiaries or Guardians according to the configured approval threshold.
During the Challenge period, the process may be canceled by the owner or a recovery address. If the Challenge period completes without cancellation, Distribution begins according to the predefined contract rules.
At that point, Guardians or Beneficiaries may trigger the on-chain process that moves assets into the CryptoLegacy contract. Beneficiaries then claim their shares gradually according to the configured distribution schedule, while recovery addresses may execute the recovery flow to transfer all assets as defined by the contract.
Can I host the CryptoLegacy frontend myself?
Yes.
The CryptoLegacy frontend can be self-hosted using the published repository. Self-hosting allows users to run the interface on their own infrastructure, such as IPFS, Arweave, or a private server, without relying on the hosted frontend.
Self-hosting does not change contract behavior or execution logic. All critical actions remain enforced by on-chain smart contracts, independent of where the interface is served.
How does CryptoLegacy protect the privacy of Beneficiaries and assets?
CryptoLegacy is designed to limit information disclosure and delay visibility until distribution or recovery conditions are met.
Each CryptoLegacy contract uses its own unique address, which is not directly linked to the owner’s wallet or to other contracts.
Beneficiary, Guardian, and Recovery addresses are stored as hashes, preventing early association with a specific contract until they are used on-chain.
Asset-related metadata is encrypted per role and can be decrypted only when the corresponding on-chain conditions are satisfied.
During normal operation, assets remain in the owner’s wallets. The contract holds no funds and does not expose balances or asset data prior to execution.
Privacy in CryptoLegacy is enforced through role separation, hashed identities, encrypted metadata, and rule-based execution, rather than through custodial obfuscation or off-chain secrecy.
Can Beneficiaries or Guardians access encrypted data early by inspecting the blockchain or code?
Encrypted metadata is publicly visible on-chain and can be analyzed off-chain.
However, encrypted metadata cannot be meaningfully decrypted without the corresponding private keys, and decryption alone does not grant the ability to move assets. All asset transfers remain gated by on-chain conditions, approval thresholds, and contract-defined execution flows.
Inspecting the frontend, self-hosting the interface, or reviewing the source code does not provide additional access beyond what is already publicly visible on-chain. The interface does not store private keys or plaintext asset data, and it does not bypass cryptographic or contract-level enforcement.
CryptoLegacy does not rely on obscurity or frontend restrictions for privacy. It relies on encryption, role separation, and rule-based on-chain execution, accepting that blockchain data is public by design.
But approvals and encrypted data are stored on-chain — isn’t it technically accessible?
Yes. Encrypted metadata and approval data are publicly visible on-chain and can be analyzed off-chain.
However, technical availability does not imply practical access or control. Encrypted data cannot be meaningfully decrypted without private keys, and even successful decryption does not allow assets to be moved outside predefined execution paths.
CryptoLegacy assumes that blockchain data is public by default and focuses on ensuring that visibility does not translate into authority. Recovery and distribution can only be executed through predefined on-chain rules, regardless of off-chain analysis or reverse engineering.
Can CryptoLegacy support NFTs and other protocols?
CryptoLegacy is designed to be extensible via a plugin system based on the Diamond Standard (EIP-2535).
The plugin architecture allows additional execution logic to be introduced without modifying core contract behavior. This includes support for asset types and protocol interactions beyond basic token transfers.
At launch, the plugin system is in place, while support for NFTs and additional protocol integrations is planned to be introduced through approved plugins over time. Plugin registration and execution remain subject to predefined rules and do not alter distribution logic.
What happens if a private key is compromised?
If a private key is compromised during the Normal period, the owner can update contract configuration according to the predefined rules. This may include changing the owner address, updating Beneficiary or Guardian addresses, or adjusting recovery configuration.
Once the Distribution period begins, owner control is suspended and cannot be used to alter execution. At this stage, asset transfers proceed strictly according to the predefined distribution or recovery rules, independent of the compromised key.
Beneficiaries may update their receiving addresses during Distribution, as allowed by the contract logic. No role can use a compromised key to bypass on-chain conditions or alter execution flows.
What can I do if my keys are potentially compromised and I don't have access to my devices or backups?
During the Normal period, predefined recovery mechanisms may be used according to the contract configuration.
Guardians can initiate the predefined on-chain process to move assets into the CryptoLegacy contract, subject to approval thresholds and the configured Challenge period. During the Challenge period, the process may be canceled by the owner or a recovery address.
Recovery addresses can also execute the recovery flow according to the predefined rules. This flow moves assets into the CryptoLegacy contract and allows them to be transferred as defined by the recovery configuration.
All actions are executed strictly according to on-chain rules. No role can bypass approval thresholds, time delays, or execution conditions.
Can I pause or unpause the contract?
The CryptoLegacy contract includes a pause mechanism that prevents asset transfers and other execution actions.
While the contract is paused, assets cannot be moved, and Challenge initiation is blocked. The owner may still update contract configuration, including Beneficiary settings, Guardian configuration, recovery parameters, and other non-execution options according to the protocol rules.
The inactivity timeout continues to elapse while the contract is paused. To avoid entering the Challenge state, the owner must refresh the 6-month inactivity timeout by submitting the required on-chain update transaction (and DAO donation, if applicable).
If the inactivity timeout has already expired, a Challenge period cannot be initiated while the contract is paused, but may be initiated immediately after the contract is unpaused.
Unpausing restores execution under the same on-chain conditions. Token approvals can be revoked independently at any time, outside of the pause mechanism.
Can I customize Beneficiary distribution schedules?
Yes.
For each Beneficiary, the owner defines a share, an optional delay, and a distribution period. These parameters determine when asset claiming begins and how assets become claimable over time.
Delay — the waiting period before a Beneficiary can start claiming assets.
Distribution period — the duration over which assets become claimable gradually according to the configured schedule.
Distribution parameters can be updated by the owner during the Normal period. Once Distribution begins, these parameters are fixed and enforced on-chain according to the configured rules.
What fees does CryptoLegacy require?
CryptoLegacy is sustained through DAO donations.
A fixed donation is required when deploying a personal contract and when refreshing the inactivity timeout at the required interval.
An alternative unlimited-access option may be used according to the protocol configuration, covering contract deployments and timeout updates across supported chains.
What is the referral mechanism, and how does it work?
CryptoLegacy includes an optional referral mechanism intended to account for trusted introductions.
When a referral code is used, a predefined discount is applied to the deploying party, and a predefined allocation is attributed to the referral code holder according to the protocol rules.
Referral codes are intended for private use and trusted contexts, not for public distribution or growth campaigns. Payout addresses associated with referral codes can be updated according to the protocol configuration.
What happens if the core team is unable to support the product?
CryptoLegacy does not rely on continuous involvement of a core team for contract execution.
Once deployed, CryptoLegacy contracts operate autonomously on-chain and do not depend on centralized services to execute recovery or distribution logic. The frontend can be self-hosted, and contracts can be interacted with directly on-chain, independent of any hosted interface.
Code availability and maintenance may evolve over time according to the project’s governance, but deployed contracts remain functional and enforce their predefined rules regardless of ongoing team support.
Why is the contract code open, but under copyright and not released under an open-source license?
The CryptoLegacy contract code is publicly readable to allow independent review and auditing.
At the same time, the code is distributed under copyright to limit unverified reuse, cloning, or deployment in misleading or unsafe contexts. This approach is intended to reduce the risk of scams, misconfigured forks, or unauthorized deployments that could harm users.
Licensing and code availability may evolve over time according to the project’s governance and maturity. Regardless of licensing, deployed contracts continue to operate autonomously and enforce their rules on-chain.
Why is the UI code closed and obfuscated?
The CryptoLegacy interface is not a security boundary. It does not store private keys, decrypted asset metadata, or execution authority. All critical logic is enforced by on-chain smart contracts.
The UI code is distributed in an obfuscated form to reduce the risk of phishing, spoofed frontends, and misleading replicas that could prompt users to sign unintended transactions. Obfuscation is used to limit trivial reuse or modification of the interface in unsafe contexts, not as a substitute for cryptographic or contract-level security.
Users may self-host the interface or interact with the contracts directly on-chain. UI code availability and licensing may evolve over time according to the project’s governance, but deployed contracts remain fully auditable and enforce their rules independently of the frontend.
Last updated