How CryptoLegacy Contract Periods and Guardian Controls Work

Explains the fixed 6-month check-in, 3-month challenge, and distribution phases. Guardians trigger protocol-defined execution paths when the owner cannot act, while recovery handles remaining assets.

CryptoLegacy Contract Statuses

• Normal (Active Status)

  • The contract is deployed and active but holds no assets.

  • Every 6 months, the contract owner confirms activity by sending an on-chain transaction.

  • This 6-month check-in interval is fixed and cannot be changed, ensuring a predictable execution schedule.

  • During Normal status, assets remain in Asset Holder addresses (external owner-controlled wallets).

  • While the owner remains active, no inactivity-based or guardian-based asset transfer execution can occur. Recovery-specific execution paths may remain available.

• Challenge Period (Fixed 3-Month Window)

  • If the owner misses the required 6-month check-in, any beneficiary may initiate a fixed 3-month challenge period.

  • During this period, the owner may restore normal operation by updating the inactivity timeout on-chain.

  • During the Challenge Period, no asset transfer into the CryptoLegacy contract is permitted via the inactivity-based or guardian-based execution paths. Execution proceeds to Distribution only if the challenge completes without being canceled.

  • If guardians are configured, a guardian-initiated execution path may be triggered via guardian confirmations, followed by a guardian challenge period (0–30 days), only if guardians act before the inactivity timeout expires.

  • The duration of the beneficiary challenge period is fixed and cannot be modified.

• Distribution Period

  • If the applicable challenge period completes without interruption, the contract enters Distribution.

  • During Distribution, pre-approved assets may be transferred from Asset Holder addresses into the CryptoLegacy contract via protocol-defined execution paths.

  • Any single beneficiary — or any single guardian, if guardians are configured and the guardian execution path has completed — may decrypt asset metadata and initiate transfers as permitted by the active execution path, and only for assets that were explicitly approved in advance.

  • Once assets are held by the contract, beneficiaries claim them according to predefined parameters:

    • Delay: The waiting period after distribution begins before a beneficiary can start claiming.

    • Duration: The time over which assets unlock gradually and can be claimed incrementally.

Guardians and Recovery Controls

Guardians

Guardians are on-chain verification roles used to trigger a protocol-defined execution path when the contract owner cannot act. They do not control assets, make discretionary decisions, or receive custody at any point.

The contract owner selects guardians and defines a confirmation threshold (e.g., 1-of-3, 2-of-3, 3-of-5). By default, beneficiaries act as guardians with a majority-based confirmation threshold (for example, 2-of-3). If fewer than two beneficiaries are configured, the threshold equals the number of beneficiaries.

The guardian challenge period is set to 30 days by default and may be adjusted by the owner within protocol-defined limits (0–30 days).

Guardian addresses are stored on-chain as hashes and are not directly linkable to a specific CryptoLegacy contract until they participate in a transaction.

Once the guardian confirmation threshold is reached and the guardian challenge period completes without interruption, any single guardian may decrypt the encrypted asset metadata and initiate transfer of pre-approved assets into the CryptoLegacy contract via the guardian execution path. Guardians never withdraw assets to their own addresses and never gain custody.

Recovery Addresses

Recovery addresses provide an always-available, separate protocol-defined execution path that allows control over remaining assets under protocol control to be restored if circumstances change. Recovery availability is not tied to contract periods, but its effects remain constrained by protocol execution rules and asset-level finality.

Recovery addresses are always able to decrypt encrypted asset metadata. They may, without waiting for beneficiary or guardian challenge periods, initiate transfers of pre-approved assets from Asset Holder addresses into the CryptoLegacy contract via the recovery execution path, and subsequently withdraw remaining contract-held assets to new addresses according to predefined recovery thresholds and rules.

Recovery does not interrupt, reverse, or modify transfers or claims that have already finalized. It applies only to assets that remain under contract control at the time of recovery execution.

Recovery addresses are stored on-chain as hashes and are not linkable to a specific CryptoLegacy contract until used. Optionally, a recovery password (secret) may be configured and cryptographically combined with the recovery address before hashing. In this case, knowledge of the private key alone is insufficient to associate the address with the CryptoLegacy contract or to execute recovery actions without the corresponding password.

When a recovery action is executed, the recovery address necessarily becomes visible on-chain as part of that transaction.

Additional Security Notes

Beneficiaries and guardians can decrypt encrypted asset metadata only after the relevant protocol-defined execution conditions are met, such as completion of a challenge period or satisfaction of guardian confirmation thresholds.

Recovery addresses are not subject to these timing constraints and may decrypt asset metadata at any time, while asset movement remains restricted to recovery-specific protocol-defined execution paths.

Encryption keys and metadata are validated in advance using test messages to ensure that execution can proceed correctly when required.

CryptoLegacy enforces clear role separation, deterministic execution rules, and on-chain verification, reducing reliance on coordination, discretion, or off-chain enforcement.