Listen to this page
Legacy Voice Guide · TROPTIONS + Deepgram
Documentation
Every concept used in the Legacy Vault Protocol, defined clearly for owners, executors, beneficiaries, and engineers.
A sovereign estate address on the protocol, formatted as `name.legacy`. The root identity that parents all vaults, documents, and wallet registrations for an individual or entity.
A logical container within a namespace that holds encrypted documents, wallet references, and associated release policies. One namespace may contain many vaults (e.g. Primary Estate, Digital Assets, Business Interests).
A programmable multi-condition gate that must be fully satisfied before beneficiaries receive access to vault contents. Conditions can include death certificates, executor confirmation, attorney attestation, guardian quorum, and time-delay periods.
A release mechanism requiring multiple independent verifications — typically 5 conditions — before access is granted. Prevents any single party from unilaterally releasing vault contents.
A designated individual (often an attorney, trustee, or trusted family member) authorised to trigger the vault release process. Executors must verify their identity via verifiable credentials before any release begins.
A person or entity designated to receive access to specific vault contents after the release policy conditions are satisfied. Beneficiaries receive scoped decryption keys — only for their designated allocation.
An independent party (often legal counsel or a trusted institution) whose attestation signature is required as part of the release policy. Guardians form a quorum to prevent coercion of any single party.
A threshold-signature scheme among multiple guardians (e.g. 2-of-3) required before a release can proceed. Protects against executor coercion, fraud, or incapacitation of any single guardian.
The infrastructure layer of the Legacy Vault Protocol responsible for namespace anchoring, validator consensus, cross-chain relaying, and policy enforcement. Implemented as a Rust/Axum node network with modular crates.
The on-chain registry crate on Layer 0 that maps `.legacy` namespace identifiers to their owner public key, vault tree root, and policy hash. All namespace registrations are anchored here.
A cryptographic commitment stored on Layer 0 that binds a vault's contents (document CIDs, policy hash, wallet registry root) to a specific block. Any tampering with vault contents invalidates the anchor.
A content-addressed identifier (IPFS CID) that uniquely identifies an encrypted document stored on IPFS. The CID is deterministic — if the document changes, the CID changes, making tampering detectable.
InterPlanetary File System — a distributed content-addressed storage network used by the protocol to store encrypted vault documents. Only CIDs are stored on-chain; document contents never appear in the blockchain.
The symmetric encryption algorithm used to encrypt vault documents client-side before upload. AES-256-GCM provides both confidentiality and authenticity — the server and IPFS nodes never see plaintext.
The root encryption key from which per-vault and per-document keys are derived. The master key is held only by the vault owner and (optionally) a designated key recovery trustee. Never stored on the server.
A Layer 0 network participant that validates namespace registrations, policy state transitions, and cross-chain relayer proofs. Validators must stake and can be slashed for double-signing or equivocation.
A Layer 0 crate that bridges wallet ownership proofs across multiple blockchains (Ethereum, Bitcoin, Solana, XRPL, Stellar, Cosmos, Polkadot, Polygon). Allows the protocol to verify wallet ownership without holding private keys.
A per-namespace, per-vault directory of cross-chain wallet addresses whose ownership has been cryptographically verified. The registry is anchored on Layer 0 and cannot be modified without the namespace owner's key.
A W3C-standard cryptographically signed credential that proves a claim about an identity (e.g. that a person is the designated executor) without revealing unnecessary personal information. Used for executor and guardian identity verification.
The Layer 0 crate responsible for evaluating whether all release conditions are met and emitting a release authorisation event. The policy engine is the sole source of truth for release state transitions.
A government-issued document confirming the death of the vault owner. In the protocol, a certified copy is uploaded by the executor; its document hash is anchored on Layer 0 as proof of the triggering event.
A cryptographically signed statement by a designated party (attorney, guardian, or executor) confirming that a specific condition has been met. Attestations are stored as signed messages anchored on Layer 0.
A mandatory time delay (typically 30 days) that begins after all other release conditions are met. During this period, any beneficiary may contest the release. Designed to mirror probate court notice requirements.
An immutable, tamper-evident log of all vault actions anchored on Layer 0. Every document upload, member change, executor action, and policy state transition is recorded with a timestamp and block reference.
The legal process through which a court validates a will and oversees asset distribution. The Legacy Vault Protocol is designed to complement — not replace — probate proceedings. Vault access granted by the protocol must still comply with applicable estate law.
The HTTP 402 Payment Required micro-payment protocol used by Legacy Vault Protocol for metered API services such as verification, document notarisation, and cross-chain relay. Payments are settled via the Apostle Chain.
The private blockchain (chain ID 7332, Rust/Axum) used as the settlement layer for x402 micro-payments within the Legacy Vault Protocol ecosystem. Supports ATP, UNY, USDF, XRP, and XLM assets.
Apostle Protocol Token — the native asset of the Apostle Chain used for gas and x402 service payments within the Legacy Vault Protocol. 18 decimal places.