Secure Asset Data Transfer with CryptoLegacy

CryptoLegacy encrypts asset metadata client-side with wallet-derived keys and records it on-chain. Data is usable only through protocol-defined execution paths, preserving privacy and self-custody.

CryptoLegacy provides confidentiality by never storing sensitive asset-holder information — such as wallet addresses or token specifics — in plaintext within the smart contract state. Instead, asset-related metadata is encrypted client-side and recorded on-chain as encrypted payloads in transaction events, while asset movement itself relies strictly on protocol-defined execution paths and required on-chain approvals.

Encryption keys are derived directly from the user’s Ethereum wallet through a signature-based mechanism. This ensures that encryption and decryption capabilities remain fully under user control and never require exposing private keys or relying on custodial services.

Encrypted On-chain Data

CryptoLegacy uses a signature-derived asymmetric encryption system based on modern elliptic curve cryptography (X25519 with authenticated encryption). The encryption process works as follows:

• A user signs a fixed, domain-specific message with their Ethereum wallet.

• The signature deterministically derives a virtual encryption key pair.

• The public encryption key may be shared or recorded.

• The private key is never stored or transmitted and can be recreated only by re-signing the same message.

Encrypted payloads are stored on-chain as hexadecimal-encoded data in transaction events. Although publicly visible, they cannot be decrypted without recreating the corresponding encryption key pair via the original wallet signature.

CryptoLegacy uses two distinct types of encrypted messages, each with a clearly defined purpose.

Message Type 1: Asset Transfer Data (Role-Specific)

The first message type contains only the information required to transfer assets from external wallets into the CryptoLegacy contract. These messages include:

• Asset-holder wallet addresses

• Token contract addresses

This data is required by:

• Beneficiaries

• Guardians

• Recovery addresses

Each message of this type is encrypted individually for the recipient role, using that role’s public encryption key. This ensures that each beneficiary, guardian, or recovery address can decrypt only the asset transfer data intended for them and only when the relevant protocol-defined execution conditions are satisfied.

These messages do not include:

• Other beneficiaries or roles

• Nicknames or labels

• Full contract configuration

Their sole purpose is enabling protocol-defined asset transfer execution.

Message Type 2: Owner Backup Data

The second message type is intended exclusively for the contract owner and serves as an encrypted backup of the full contract configuration.

This message may include:

• Beneficiary, guardian, and recovery addresses

• Public encryption keys for all roles

• Optional nicknames or labels

• Asset-holder wallet addresses

• Token contract addresses

This data is encrypted using the owner’s own public encryption key and can only be decrypted by the owner through recreating the corresponding encryption key pair.

Owner backup data does not grant execution authority and does not affect protocol behavior. Its purpose is recoverability, continuity across devices, and protection against local data loss.

Data Access and Availability

Encrypted asset data remains inaccessible to roles without the appropriate encryption keys; protocol conditions restrict how decrypted data may be used.

• 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.

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.

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

It is safe to publicly disclose:

• Public encryption keys

• Ephemeral public keys

• Nonces and encrypted payloads

Critical security assumptions rely on:

• The integrity of the wallet signature used to derive encryption keys

• The user’s responsibility not to sign the encryption message on untrusted websites

Encrypted data alone does not grant asset access, execution authority, or custody, and decryption does not modify protocol state. Asset transfers remain strictly governed by on-chain approvals and protocol-defined execution paths.

CryptoLegacy combines deterministic on-chain execution with client-side encryption to ensure privacy, self-custody, and long-term reliability in managing and transferring digital assets.