How CryptoLegacy Works

CryptoLegacy defines on-chain execution rules for asset transfer and recovery when the owner cannot act. Execution is configured in advance and triggered by timeouts or guardian confirmations.

General Overview

CryptoLegacy is built around a single protocol-defined execution lifecycle that governs what happens to assets when the owner cannot act. The process starts with contract creation and configuration, but assets always remain in Asset Holder addresses (external owner-controlled wallets) until predefined execution conditions are met. Asset movement during the Normal Period is possible only via recovery-specific execution paths.

First, the owner creates a personal contract, configures beneficiaries, guardians, and recovery options, approves specific assets for transfer, and encrypts asset metadata. This information remains hidden — beneficiaries and guardians cannot see balances, wallets, or asset details prior to the applicable execution phase. Beneficiaries cannot trigger asset transfers while the owner remains active. Guardians may initiate the guardian execution path under predefined on-chain conditions.

As long as the owner periodically updates the inactivity timeout on-chain, the protocol remains in Normal operation. If the timeout expires, a Beneficiary-Initiated Challenge applies. If guardians initiate execution under predefined conditions before inactivity expires, a Guardian-Initiated Challenge applies, bounded by a guardian challenge period (0–30 days). If this process completes without interruption, approved assets may be transferred into the CryptoLegacy contract via the inactivity-based or guardian-based execution paths after the applicable challenge period completes uncancelled, according to protocol-defined execution rules.

Once assets are inside the contract, beneficiaries claim them according to predefined rules. Claims execute independently and are final at the asset level. Recovery remains available as a separate protocol-defined execution path that may (a) transfer pre-approved assets from Asset Holder addresses (external owner-controlled wallets) into the contract and (b) withdraw contract-held assets to new recipient addresses, without reversing or modifying finalized transfers or claims.

The sections below describe each part of this lifecycle in detail — transfer, recovery, execution extensions, and customization — and how they interact within the same execution model.

Transfer

Step 1: Setup

Create a personal smart contract and pay the required protocol fee (DAO donation in the interface). Configure beneficiaries as part of the execution parameters, including their shares, delays, and distribution schedules.

Approve asset transfers and encrypt asset metadata for each beneficiary via the interface for later protocol execution. Every six months, the inactivity timeout is extended via an on-chain transaction.

Assets remain in Asset Holder addresses (external owner-controlled wallets) during normal operation. Asset movement during the Normal Period is possible only via recovery-specific execution paths. Transfer via inactivity-based or guardian-based execution paths becomes possible only after predefined protocol execution conditions are met: either the inactivity timeout expires and the subsequent challenge period completes, or guardians (if configured) reach the required confirmation threshold and the guardian challenge period (up to 30 days) completes. Recovery addresses (if configured) provide an independent execution path that can (a) transfer pre-approved assets from Asset Holder addresses (external owner-controlled wallets) into the contract and (b) withdraw contract-held assets to new recipient addresses according to predefined rules, without reversing or modifying completed or finalized claims.

Step 2: Challenge

If the inactivity timeout expires, a beneficiary may initiate a fixed three-month challenge period. During this period, the owner may reset the timeout and cancel the beneficiary-initiated challenge.

If the challenge period completes without interruption, the contract enters the Distribution phase. After Distribution has begun, any single beneficiary — and, if guardians are configured, any single guardian — may decrypt the asset metadata and initiate transfer of only the pre-approved assets from Asset Holder addresses (external owner-controlled wallets) into the CryptoLegacy contract, as permitted by the active execution path.

Step 3: Distribution

Beneficiaries claim assets according to their configured shares and schedules. Once distribution begins, individual claims execute independently and cannot be reversed or modified by the owner, and assets cannot be withdrawn using owner-only operational authority.

During the distribution period, beneficiaries may switch their beneficiary address (beneficiary hash) used for claiming, as permitted by the protocol. Assets remain held in the CryptoLegacy contract until claimed.

Recovery remains available via pre-configured recovery addresses and may apply both to (1) transferring pre-approved assets from Asset Holder addresses (external owner-controlled wallets) into the contract and (2) withdrawing remaining contract-held assets to new recipient addresses, without interrupting, reversing, or modifying claims that have already finalized.

Recovery

Step 1: Add Guardians and Recovery

Guardian and recovery plugins may be enabled during contract creation or added later during the Normal Period. By default, if no explicit guardians are set, beneficiaries act as guardians with a majority-based approval threshold (for example, 2-of-3) and a default guardian challenge period of 30 days. The owner may replace the guardian set, adjust confirmation thresholds, and configure the guardian challenge period within protocol-defined limits.

Recovery addresses are configured separately and may require multiple approvals according to the selected recovery threshold. All recovery addresses are stored on-chain as hashes and cannot be linked to a specific CryptoLegacy contract until they are used in a transaction.

Step 2: Guardian-Initiated Transfer

Guardians may perform an emergency transfer under predefined conditions as an alternative protocol-defined execution path, without waiting for the six-month inactivity timeout. Once the required guardian confirmation threshold is reached, the guardian challenge period (up to 30 days, as configured by the owner) begins. During this period, the owner or a recovery execution path may cancel the guardian execution path, subject to protocol-defined authority checks.

If the guardian challenge period completes without interruption, any single guardian may decrypt the encrypted asset metadata and initiate transfer of only the pre-approved assets from Asset Holder addresses (external owner-controlled wallets) into the CryptoLegacy contract, as defined by the protocol. Guardians never have direct access to assets and cannot withdraw funds to arbitrary recipient addresses or perform transfers outside protocol-defined destinations.

Step 3: Distribution and Recovery

Beneficiaries claim assets according to the configured shares and schedules. Once distribution begins, individual claims execute independently and cannot be reversed or modified by the owner. Once Distribution has begun, the owner no longer has authority to perform owner-only operational actions.

Recovery remains available only via pre-configured recovery addresses and may (a) transfer pre-approved assets from Asset Holder addresses (external owner-controlled wallets) into the contract and (b) withdraw remaining contract-held assets to new recipient addresses, without interrupting, reversing, or modifying claims that have already finalized. Recovery addresses are stored as hashes and become linkable to a specific CryptoLegacy contract only when used on-chain.

Execution Extensions

Step 1: Add Execution Plugins

While assets remain in the owner’s wallets during normal operation, the owner retains full control over those assets outside the CryptoLegacy contract. Asset management during this phase is entirely off-contract and unrestricted.

The contract owner may add protocol-approved execution plugins to the CryptoLegacy contract during the Normal Period. These plugins do not grant custody and may only operate on assets once they are held by the CryptoLegacy contract, and only within protocol-defined execution paths. They define which execution actions may be performed later once assets are transferred into the CryptoLegacy contract, within protocol-defined constraints.

Examples of supported actions include token swaps, staking (e.g. Lido), and protocol-specific actions exposed through approved execution plugins.

Step 2: Allow Beneficiaries to Add Plugins

The owner may add a dedicated plugin that allows beneficiaries to add additional execution plugins during the distribution phase. This capability is governed by predefined confirmation rules set in advance by the owner.

For example, the owner may initially require a 3-of-5 beneficiary confirmation threshold to approve changes to plugin installation rules. Beneficiaries may then, using that same 3-of-5 threshold, approve a rule change that sets a new confirmation threshold of 2-of-5 for future plugin additions, within the same protocol-defined execution path. Once approved, the 2-of-5 threshold becomes the active execution rule for adding plugins.

Beneficiaries cannot remove existing plugins and cannot exceed protocol-defined execution constraints.

Step 3: Execute Actions During Distribution

During the distribution phase, beneficiaries may use authorized execution plugins to perform allowed actions on assets held in the CryptoLegacy contract. Each action is subject to the confirmation thresholds defined for that plugin.

Asset claims continue independently according to predefined shares and schedules. Execution plugins extend what actions may be executed, not who controls assets or how distribution proceeds.

Customization

Step 1: Enable Extended Execution Logic via Plugins

CryptoLegacy supports customization through execution plugins that extend the set of allowed actions without modifying the core execution model. These plugins do not introduce arbitrary logic and cannot grant new owner powers, alter fixed protocol timing parameters, or affect execution finality. They cannot modify fixed protocol timing parameters or execution finality, and may modify thresholds or distribution-related rules only where explicitly permitted by the protocol.

Examples of supported extensions include NFT transfers, closing Uniswap NFT positions, fixed-amount distributions alongside share-based claims, or protocol-specific execution logic exposed through audited plugins.

Step 2: Allow Beneficiaries to Enable Additional Logic

The contract owner may preconfigure a plugin that allows beneficiaries to enable additional execution plugins during the distribution phase. This capability is subject to predefined confirmation thresholds and execution constraints.

Beneficiaries cannot introduce new execution paths beyond those allowed by the protocol, cannot modify core execution rules, and cannot add or remove beneficiaries or recovery addresses.

Step 3: Plugin Verification and Security

All execution plugins must be registered in the on-chain Plugin Registry. The registry enforces allowlist-based admission of protocol-approved plugins.

This model ensures that customization expands execution capabilities without introducing discretionary control or unapproved code paths outside the predefined protocol boundaries.