Why is this entity important for governed agent execution?
It defines one of the control points that keeps autonomous behavior within explicit authority and risk limits.
Glossary Entry
What is The Inheritance Protocol?
DeAgenticAI's Inheritance Protocol is a time-locked mechanism that transfers custody to designated beneficiaries if an owner check-in period elapses without confirmation.
Overview
The Inheritance Protocol addresses a gap every institutional asset manager with on-chain exposure eventually confronts: what happens to assets and agent operations when a key signatory becomes unavailable? In traditional finance, succession procedures provide established answers. In crypto, the default answer has historically been nothing — unless the owner made explicit arrangements in advance. The Inheritance Protocol changes that by making succession a policy-governed, cryptographically enforced sequence rather than a manual contingency.
The Inheritance Protocol operates as part of Layer 8 of the Agentic Control Plane stack. DeAgenticAI’s Agentic Control Plane enforces cryptographic policy over AI agent authority — separating what an agent can do from what it is authorized to do — in Web3 and enterprise financial environments. Within that architecture, the Inheritance Protocol is a time-locked key share release mechanism built into the MPC governance layer — the only capability of this type natively available in any MPC custody infrastructure.
How does it work?
-
1
Beneficiary designation
The account owner designates one or more beneficiaries at setup — individuals, institutions, or trusted executors — authorized to take custody under the conditions defined in the succession policy.
-
2
Check-in policy configuration
The owner or a designated guardian confirms the account's active status at a defined interval: weekly, monthly, or quarterly depending on the account's risk profile. Intervals and conditions are set in Policy DSL rules — using the same governance expressiveness that governs operational agent transactions.
-
3
Grace period initiation
If the check-in period elapses without confirmation, the protocol does not immediately transfer custody. It first sends escalated notifications to all registered contacts, allowing the owner or guardian to intervene and restart the cycle.
-
4
Graduated escalation
If no response is received during a separately configurable grace period — set by the organization, not hard-coded by the vendor — the protocol advances to the succession step.
-
5
Policy-governed custody transfer
The beneficiary's key share replacement is released under the governance rules specified at setup. Organizations can require multiple beneficiary confirmations, mandate legal documentation triggers, or route succession through a trusted institutional executor — all enforced at the MPC governance layer just as operational transactions are.
Why does this matter?
The Inheritance Protocol provides "the assurance that an AUM loss event does not occur because a key signatory becomes unavailable" — a capability no current MPC wallet or custody infrastructure offers natively.
For RWA fund managers under MiCA and DORA: the succession sequence creates an auditable institutional continuity mechanism that compliance teams can document. The Policy DSL governance layer — configurable to multi-beneficiary confirmation, legal documentation triggers, or executor routing — maps directly to the operational resilience requirements both regulations impose.
For enterprise CTOs: a hardware security model with no succession path is a key person concentration risk that internal audit and legal due diligence will surface. The Inheritance Protocol resolves it within the same policy architecture governing all other agent operations.
Organisations without a native succession mechanism should evaluate AI agent compliance and continuity planning before key person risk becomes an operational liability.
Frequently Asked Questions
How does this connect to policy and signing?
This concept should map directly to policy evaluation and the final execution boundary where authorization is enforced.
Where should teams reference this term?
Use it consistently in solution pages, compare pages, and technical guides so the internal knowledge graph remains coherent.