CryptoLegacy: Privacy Is Important for Execution When the Owner Cannot Act

CryptoLegacy protects privacy by encrypting sensitive data locally and recording it on-chain. Decrypted data is usable only within protocol-defined execution paths when the owner cannot act.

We believe privacy is crucial for execution in situations where the owner cannot act. CryptoLegacy operates within an architecture where assets are approved from external wallets to a personal CryptoLegacy contract, while the protocol is designed so that sensitive information is not exposed through standard interfaces and remains encrypted unless protocol-defined execution conditions are satisfied.

Privacy in CryptoLegacy is achieved by separating data visibility from execution authority. Encrypted data may exist on-chain, but it does not grant custody, control, or execution rights. Asset movement remains strictly governed by predefined on-chain execution paths and required approvals.

As a result, sensitive data is not revealed prematurely in the interface, and asset-related information remains encrypted until the protocol reaches a state where the conditions required for a specific execution path are satisfied.

Key Privacy Principles

• Names, Beneficiaries, Guardians, Recovery addresses, Asset Holders (wallet addresses), ERC20 token addresses, and public encryption keys are stored locally in the user’s browser.

• Owner backups are encrypted using the owner’s public encryption key and recorded on-chain as encrypted transaction events in a separate backup contract.

• Asset-holder wallet addresses and token addresses required for asset transfer are encrypted individually for each Beneficiary, Guardian, and Recovery address using their respective public encryption keys and recorded on-chain as encrypted transaction events in the CryptoLegacy contract.

• All encryption is performed client-side using wallet-derived encryption keys. Private keys and encryption seeds are never transmitted or stored on-chain.

Encrypted data recorded on-chain is publicly visible but cannot be decrypted without recreating the corresponding encryption key through a wallet signature. Visibility of encrypted data does not grant execution authority.

Data Availability by Role

Encrypted asset data becomes usable only within protocol-defined execution paths and never grants authority by itself:

• Beneficiaries can decrypt asset transfer data only after the applicable challenge period has completed and Distribution has begun.

• Guardians can decrypt asset transfer data only after reaching the required confirmation threshold and completion of the guardian challenge period.

• Recovery addresses may decrypt asset transfer data at any time, while asset movement remains restricted to recovery-specific protocol-defined execution paths under the defined recovery thresholds.

• The owner may decrypt owner backup data at any time by recreating the encryption key through wallet signature.

Decryption is an off-chain operation and does not modify protocol state or grant execution authority.

To ensure correctness, CryptoLegacy provides a mechanism for verifying encryption through test messages, allowing users to confirm decryption capability in advance without exposing asset data or granting execution authority.

Execution Routing and Privacy

CryptoLegacy enforces execution strictly through protocol-defined on-chain execution paths. In the current architecture, assets are approved directly to the personal CryptoLegacy contract and transferred according to the active execution period and role permissions.

In addition to this direct model, the protocol defines an intent-based execution mechanism implemented via a shared execution router and a dedicated plugin. This mechanism allows the owner to predefine permitted asset transfers as hashed execution intents, without revealing wallet or token relationships in plaintext on-chain.

Execution intents:

• do not grant execution authority,

• do not bypass challenge periods, thresholds, or role checks,

• serve only as deterministic constraints evaluated during execution.

Under this model:

• The owner registers hashed execution intents in the personal CryptoLegacy contract.

• Detailed transfer parameters (wallet addresses, tokens, signatures, and related metadata) are delivered to the relevant roles through encrypted on-chain messages.

• When execution is permitted by the protocol, Beneficiaries, Guardians, or Recovery roles execute transfers via the plugin, which forwards validated executions to the shared router.

• The router verifies intent digests, validates signatures, and performs transfers strictly according to protocol-defined rules.

This routing mechanism does not grant additional authority and does not bypass execution constraints. It exists to reduce on-chain linkability between wallets and contracts while preserving deterministic execution and auditability.

Compatibility with Previous Encryption Formats

CryptoLegacy supports backward compatibility with previously encrypted data formats. Legacy payloads generated using deprecated wallet encryption methods can be distinguished by their encoding format and are handled using the appropriate decryption logic.

Newly encrypted data includes an explicit version marker, allowing the system to reliably detect the encryption method and apply the correct cryptographic procedure.

Security Considerations

Privacy in CryptoLegacy is achieved through protocol design, not through obscurity or trust assumptions.

• Encrypted data may be publicly visible but does not grant asset access or execution authority.

• Decryption is performed off-chain and does not affect protocol execution logic.

• Asset transfers remain strictly constrained by on-chain approvals, thresholds, and execution paths.

By combining client-side encryption, local data storage, and deterministic on-chain execution, CryptoLegacy provides practical privacy for execution and recovery in situations where the owner cannot act, without compromising self-custody or protocol safety.