CryptoLegacy: Security-First Approach to Asset Transfer and Recovery

CryptoLegacy secures assets by defining deterministic execution paths for transfer and recovery, without custody, manual intervention, or trust-based controls.

CryptoLegacy was designed from the start around the assumption that owner inability to act and execution failures are primary risks in self-custody systems. As a result, security is enforced through deterministic execution rules rather than reliance on trusted intermediaries or emergency controls.

CryptoLegacy Smart Contract Security

• CryptoLegacy smart contracts have undergone multiple independent security audits, with additional reviews and audits ongoing as the protocol evolves.

• A DAO-managed bug bounty program is planned to complement audits.

• You remain the sole owner of your personal CryptoLegacy contract. Control is limited to execution-relevant configuration only. There are no privileged backdoors or discretionary recovery mechanisms.

• Personal contracts do not custody assets. Assets remain in your own wallets during normal operation and are transferred only after:

  • inactivity timeouts and challenge periods complete, or

  • guardian confirmation thresholds and challenge periods are satisfied, or

  • recovery execution paths are used.

  • Note: the 6-month inactivity check-in and the 90-day Beneficiary Challenge are protocol-defined and fixed; the Guardians Challenge is configurable only within 0–30 days.

• Guardians do not have custody and cannot withdraw assets to arbitrary addresses. Recovery addresses provide a separate execution path and may, subject to predefined recovery thresholds and rules, transfer assets into the contract and withdraw remaining contract-held assets to new addresses, without reversing or modifying finalized transfers or claims.

• Personal contracts follow the Diamond Standard (EIP-2535) to allow modular execution extensions. Only approved execution plugins may be enabled, and core execution rules remain immutable.

• All plugins must be registered in the on-chain Plugin Registry and reviewed before activation. Plugin approval is governed through DAO-controlled processes rather than discretionary execution-time decisions.

• Core execution contracts are non-proxied, reducing upgrade-related risk. The Fee Registry is upgradeable due to its governance-linked role.

• Some external calls during execution are designed to use bounded gas and defensive patterns (for example via gas budgeting and try/catch) to reduce the risk of execution being blocked by hostile or misconfigured external contracts.

• Beneficiary claims do not rely on fees for correctness: the claim fee is treated as a voluntary donation and can be zero; fee settings do not change the beneficiary’s entitlement.

Threat Model

CryptoLegacy is designed to mitigate the following classes of risk:

• Loss of access or inability of the owner to act.

• Human coordination failures during recovery or transfer.

• Premature disclosure of asset information.

• Execution deadlocks caused by unavailable participants.

CryptoLegacy does not attempt to mitigate:

• Loss of all private keys, guardians, and recovery access simultaneously.

• Global blockchain halts or permanent network failures.

• Protocol-level failures of underlying blockchains or cross-chain infrastructure.

Execution Finality

Once an execution step completes on-chain, it is final:

• Completed transfers cannot be reversed.

• Completed claims cannot be canceled.

• Recovery applies only to assets that remain under contract control at the time of recovery execution.

CryptoLegacy intentionally avoids rollback or override mechanisms to preserve determinism and auditability.

Time-Based Assumptions

CryptoLegacy relies on blockchain timestamps for time-based execution, including inactivity timeouts, challenge periods, and lock durations. Minor timestamp variance does not affect correctness, but extreme reorgs or prolonged chain instability may delay execution.

Known Execution Failure Conditions

Execution will not proceed if any of the following conditions are met:

• Required confirmations or thresholds are not reached.

• A challenge period is still active.

• Assets were not approved for transfer in advance.

• (Fee/Access only) Lifetime NFT lock state and cross-chain messages (for NFT lock / referral sync) may delay fee-free updates or cross-chain synchronization. They do not change personal contract execution rules for asset transfer, claim, or recovery on the chain where the personal contract is deployed.

These conditions do not alter execution rules; they may only delay execution.

Configuration Risks

CryptoLegacy does not attempt to prevent all misconfiguration. Incorrect thresholds, unreachable guardians, missing recovery addresses, or insufficient approvals may result in execution paths that cannot complete. Users are responsible for validating their configuration before assets are at risk.

Guardian and Recovery Risks

Guardians and recovery addresses are powerful execution roles. Incorrect selection, loss of access, or collusion may result in delayed or unintended execution.

CryptoLegacy enforces technical limits but cannot evaluate human trust decisions.

Governance Scope and Limits

DAO governance cannot:

• Move user assets.

• Override execution rules.

• Cancel finalized transfers or claims.

• Access guardian or recovery execution paths.

Governance is intentionally limited to protocol parameters and critical infrastructure such as the Plugin Registry.

Upgrade Scope

The Fee Registry is upgradeable due to its governance-linked role.

The Plugin Registry contract itself is not upgradeable; governance controls only which plugins are added to or removed from the registry.

Personal CryptoLegacy contracts and their core execution logic are not upgradeable. Execution capabilities may be extended only through explicitly enabled plugins, without modifying core contract code.

Gas and Fee Responsibility

Users are responsible for providing sufficient gas and fees for execution. Failed or reverted transactions do not modify execution state.

Cross-Chain Messaging Limitations

Cross-chain execution depends on successful message delivery. Network congestion, bridge downtime, or misconfiguration may delay execution but cannot alter predefined rules or grant additional authority.

CryptoLegacy UI Security

• The CryptoLegacy interface is protected by Cloudflare to mitigate DNS spoofing, cache poisoning, and man-in-the-middle attacks.

• For maximum assurance, users can run the interface self-hosted, removing reliance on hosted frontends.

• A mirrored deployment is available on Arweave for censorship-resistant access.

CryptoLegacy Infrastructure Dependencies

• CryptoLegacy relies on RPC providers, SubQuery indexers, and APIs for usability, all of which can be overridden or replaced by the user.

• The interface is designed to be deployable on decentralized hosting platforms such as IPFS and Arweave.

• Infrastructure services do not participate in execution logic and cannot move assets or alter contract behavior.

Support Limitations

CryptoLegacy support cannot:

• Modify contract state.

• Recover lost keys.

• Change execution rules.

• Reverse on-chain actions.

Support assistance is limited to guidance and documentation.

Security Invariants

The following invariants are enforced by design:

• Assets are never held by the protocol during normal operation.

• No role has unilateral authority over execution.

• Execution cannot proceed without predefined conditions.

• Recovery cannot affect finalized execution.

Key Security Principle

CryptoLegacy does not attempt to “secure funds” through custody or intervention. Instead, it secures execution paths by ensuring that:

• rules are defined in advance,

• execution is deterministic,

• recovery does not rewrite history,

• and no actor can bypass protocol-defined conditions.