CryptoLegacy Plugins Extend Contract Functionality

CryptoLegacy contracts use modular, audited execution plugins registered on-chain to extend allowed actions without changing core execution rules or authority boundaries.

CryptoLegacy contracts use the Diamond standard (EIP-2535) so that all personal contracts execute the same core protocol logic. Instead of deploying a unique smart contract with custom code for each user, CryptoLegacy deploys a standardized contract shell and attaches audited plugins that implement specific execution actions.

In practice, this means that the rules governing execution periods, role authority, timing, and asset movement are identical across all personal contracts and are enforced by the same underlying logic. No personal contract can introduce custom execution paths, shortcuts, or special-case behavior through custom code.

Differences between personal contracts arise only from configuration set by the owner — such as which plugins are enabled, which roles are assigned, what confirmation thresholds apply, and which execution actions are permitted during Distribution. These differences affect what actions are allowed, not how the protocol itself behaves.

This model avoids the risks of bespoke contract logic while making the system easier to audit, upgrade, and reason about. All security-critical behavior remains consistent and predictable, while plugins provide controlled extensibility within protocol-defined execution paths.

Adding and Managing Execution Plugins

Contract owners may add or replace execution plugins by submitting on-chain transactions to their personal CryptoLegacy contract during the Normal Period. Each requested plugin is validated against the on-chain Plugin Registry before it can be enabled.

Plugins are registered through protocol-defined governance and security review processes. The registry enforces that only approved plugins can be activated, without discretionary intervention at execution time.

Execution plugins operate under explicit confirmation thresholds. Each plugin defines the number of confirmations required for its actions to execute within existing protocol-defined execution paths (for example, 1-of-N or M-of-N beneficiary confirmations). These thresholds are part of the execution constraints and are enforced on-chain.

Some plugins require a locked Lifetime NFT to be enabled, depending on the permissions they introduce.

Plugin Governance and Thresholds

In addition to execution plugins, CryptoLegacy supports protocol-defined meta-plugins that govern how other plugins may be added within existing execution paths.

A contract owner may enable a dedicated plugin during the Normal Period that allows beneficiaries to add new execution plugins during the Distribution phase. This capability exists only if such a plugin was explicitly configured in advance and is strictly constrained by predefined confirmation rules.

For example, a contract owner may initially require a 3-of-5 beneficiary confirmation threshold to approve changes to plugin installation rules. Using that same threshold, beneficiaries may approve a rule change that lowers the threshold for future plugin additions (e.g., to 2-of-5). Once approved, the new threshold becomes the active execution rule for adding plugins.

Beneficiaries cannot remove existing plugins and cannot exceed protocol-defined execution constraints set during the Normal Period.

Plugin Security Model

• All plugins must be registered in the on-chain Plugin Registry.

• Plugins are reviewed and audited by independent security firms before registration.

• Plugins follow a minimal execution-scope design to reduce complexity and attack surface.

• Users interact only with their personal contracts when enabling plugins; no shared custody or external control is introduced.

• The Plugin Registry is designed to be progressively decentralized. Registry participation does not grant execution authority or discretionary control over personal contracts.

Available Plugins

• Base Plugin Provides the core execution logic shared by all CryptoLegacy contracts.

• Trusted Guardians Plugin Implements guardian-specific execution logic within existing protocol-defined guardian execution paths, allowing transfers to proceed under predefined conditions without waiting for inactivity timeouts.

• Recovery Plugin Implements recovery-specific execution paths using hashed recovery addresses to withdraw remaining contract-held assets according to predefined recovery rules.

Future Plugins

• Lido Plugin Enables protocol-specific staking actions during distribution.

• Aave Plugin Enables protocol-specific lending and withdrawal actions during distribution.

• Uniswap Position Closure Plugin Allows authorized closure of Uniswap NFT positions held by the contract.

• Uniswap Swap Plugin Enables token swaps within predefined execution constraints.

• Beneficiary Execution Plugin Allows beneficiaries to perform additional execution actions, including enabling further plugins, only if explicitly permitted by a preconfigured plugin and subject to predefined confirmation thresholds.

• NFT Legacy Plugin Enables NFT-specific transfer and handling logic during distribution.

Plugins extend which execution actions are permitted within protocol-defined execution paths. They do not grant custody, discretionary authority, or the ability to override core execution rules, timing, or finality.