Automated sovereign-to-bank protocol for instant digital asset succession
The Automated Sovereign-to-Bank Protocol addresses probate latency in digital asset succession by implementing a synchronous API handshake and cryptographic key re-sharding, enabling secure and instantaneous asset transfer.
Patent Information
- Authority / Receiving Office
- GB · GB
- Patent Type
- Applications
- Current Assignee / Owner
- JACLYN MARIE PEARCE
- Filing Date
- 2026-03-26
- Publication Date
- 2026-06-10
AI Technical Summary
Traditional estate succession processes for digital assets are plagued by probate latency, leading to significant financial risk and liquidity gaps due to manual, paper-based methods.
An Automated Sovereign-to-Bank Protocol utilizing a synchronous API handshake and cryptographic key re-sharding to facilitate an Instant Asset Release, ensuring non-repudiable and automated transfer of digital assets.
The protocol significantly reduces probate latency, ensuring secure and instantaneous transfer of digital assets, mitigating financial risk and maintaining asset integrity.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
ro Box 100 Sovereign Mortality Registry r Box 102 Box 104 Automated Handshake Engine Private Banking Vault Arrow 101 Arrow 103 Signal Arrow 101 Instant Asset Release Box 106 Nominated Successor Access ISJ ro Automated Sovereign-to-Bank Protocol for Instant Digital Asset Succession Automated Sovereign-to-Bank Protocol for Instant Digital Asset Succession Technical Problem: Traditional estate succession relies on manual, paper-based probate processes that result in "Probate Latency," often lasting several months. For volatile digital assets recognised under the Property (Digital Assets etc) Act 2025, this delay creates significant financial riskand a "liquidity gap" forexecutors and beneficiaries. Technical Solution: The present invention provides an Automated Sovereign-to-Bank Protocolthat utilises a synchronous API handshake and cryptographic key re-shardingto effectuate an Instant Asset Release (105). This removes the need for manual court intervention by creating a non-repudiable, automated link between a government death registry and private custodial infrastructure. Definitions For the purposes of this disclosure, the following technical and legal terms are defined in accordance with the Digital Verification Services (DVS)Trust Framework 1.0 (March 2026) and the Data (Use and Access) Act 2025: • Statutory Register (100): Refers to an Authoritative Attribute Provider as defined under the DVS Trust Framework, specifically a government-held dataset (e.g., General Register Office or HMRC) authorized to issue verified mortality attributes. • Synchronous Attribute Exchange: Refers to the real-time, automated transmission of a verified data attribute (e.g., "Deceased: Yes") between the Statutory Register and the Handshake Engine (102). • Relying Party (104): Refers to the financial institution or Private Banking Custodial Vault that relies on the verified attribute to trigger the automated succession of digital property. • Control: Refers to the technical power to exclude others and transfer digital assets as a constitutive element of ownership defined by the Property (Digital Assets etc) Act 2025. Description 1. The Synchronous Attribute Exchange The Automated Handshake Engine (102) facilitates a Synchronous Attribute Exchange between the Statutory Register (100) and the Relying Party (104). This engine acts as a protocol translator that converts authoritative government data into a format compatible with private banking ledgers. • Advanced Challenge-Response Architecture: The connection between the Statutory Register (100) (acting as the Authoritative Attribute Provider) and the Engine (102) utilises an asymmetric cryptographic handshake. Upon receipt of a connection request, the Engine (102) generates a unique, one-time cryptographic nonce. The Statutory Register (100) must sign this nonce using a government-issued private key stored within a Hardware Security Module (HSM), ensuring that the Verified Mortality Attribute is both current and non-repudiable. This prevents "replay attacks" where a stale death certificate could be used to trigger an unauthorised succession. • Attribute Payload: The "Verified Mortality Attribute" is defined as a structured data packet (e.g., JSON or XML) containing a unique Sovereign Death Certificate UID, the decedent’s National Identifier, and a timestamp, signed by the Authoritative Attribute Provider. Multi-Tenant Ledger Scalability The Automated Handshake Engine (102) is configured with a high-concurrency architecture capable of interfacing with multiple heterogeneous Relying Party bank ledgers simultaneously. By utilising a modular 'adapter' framework, the Engine (102) performs real-time protocol translation across diverse private banking infrastructures, allowing for the concurrent processing of mortality attributes fora plurality of Nominated Successors (106) across different financial institutions. 2. The Verification Layer (Multi-Factor Authorisation) To prevent "accidental" asset transfers and mitigate the legal risk of intermeddling under UK law, the system includes a modular Verification Layer. • Legal Interlock: This layer is configured to require a digital signature from an Authorised Practitioner (600)—such as a registered solicitor or licensed executor—using a hardware security module (HSM) or PIV card before the Succession Protocol (103) is released. • Smart Escrow State: Upon receipt of a Verified Mortality Attribute, the Engine (102) may initiate a "Conditional Vesting" state. In this state, assets are computationally earmarked for the Nominated Successor (106) but remain in a read-only "Escrow" status for a predetermined "Liability Buffer" period (e.g., 24 hours) to allow for automated fraud detection. • Proof of Identity: The system requires the Nominated Successor (106) to complete a Biometric OIDC (OpenlD Connect) flow to match their identity against preauthenticated credentials, ensuring the Relying Party provides "Control" to the exact individual designated by the decedent. 3. The Succession Protocol (103) This is the core "technical effect" of the invention. It isn't just a notification; it is an automated command sequence. • Cryptographic Key Re-sharding: The Succession Protocol (103) executes a mathematical re-sharding of the access credentials within the Relying Party (104) Private Banking Vault. Utilising a Shamir’s Secret Sharing (SSS) or similar threshold scheme, the decedent’s original access shards are computationally invalidated. Simultaneously, the Engine (102) generates a new set of $n$ shards, where a minimum of $k$ shards are required for control, and assigns these to the Nominated Successor (106). This ensures that "Control" as defined by the Property (Digital Assets etc) Act 2025 is transferred without the full private key ever existing in a vulnerable, unencrypted state in system memory. • Atomic Transactions: To ensure financial integrity, the transfer of "Control" over assets recognised under the Property (Digital Assets etc) Act 2025 is handled as an atomic transaction—meaning it either completes fully or fails entirely, preventing assets from being "stuck" mid-transfer. 3.1 Statutory Alignment with Digital Property Control The core technical effect of the Succession Protocol (103) is the automated transfer of "Control" as a constitutive element of ownership defined by the Property (Digital Assets etc) Act 2025. • Atomic Re-assignment: By executing a mathematical re-sharding of access credentials (e.g., via Shamir’s Secret Sharing), the protocol ensures that the decedent’s original access is computationally invalidated at the exact moment the successor’s access is generated. • Probate Latency Mitigation: This process allows for the lawful transfer of digital property via contractual nomination between the account holder and the Relying Party (104). 4. Error Handling and State Persistence • The Rollback Mechanism: To maintain the integrity of assets recognised under the Property (Digital Assets etc) Act 2025, the Relying Party (104) utilises a "Two-Phase Commit" (2PC) protocol. If the cryptographic key rotation in the Vault (104) is interrupted by a network timeout or hardware failure, the system automatically reverts all database changes to prevent unauthorised or partial access. • Cooldown and Rate Limiting: To protect the Synchronous Attribute Exchange from synchronisation errors, the Handshake Engine (102) implements a logic gate that prevents immediate back-to-back retries, ensuring the Statutory Register (100) has time to resolve any upstream data latencies. • The Manual Override Path: While the system is "Instant" by design, the Verification Layer provides a secure "trapdoor" for human intervention in the event of persistent protocol failures, ensuring legal compliance and asset safety. 4.1 Alternative Embodiments While the primary embodiment focuses on a verified mortality attribute, the Automated Handshake Engine (102) and Succession Protocol (103) are architecturally capable of processing other high-trust statutory attributes. This includes, but is not limited to, the automated transfer of control triggered by a verified Power of Attorney, a Certificate of Mental Incapacity, or a Court-Ordered Insolvency Status. In such embodiments, the Relying Party (104) executes the same Atomic Reassignment (56) of cryptographic access shards within the Private Banking Vault to ensure the continuous and legal management of digital property recognized under the Property (Digital Assets etc) Act 2025. Automated Sovereign-to-Bank Protocol for Instant Digital Asset Succession
Claims
1. An automated digital succession system forthe instant transfer of custodial control of digital property recognized under the Property (Digital Assets etc) Act 2025, the system comprising:• A Statutory Register (100) acting as an Authoritative Attribute Provider configured to transmit a cryptographically signed verified mortality attribute via a Synchronous Attribute Exchange;• An Automated Handshake Engine (102) situated within a secure custodial firewall and comprising a processor and memory configured to:o Authenticate the source of the attribute via a synchronous handshake with the Authoritative Attribute Provider;o Process the attribute through a Verification Layer requiring multi-factor authorization; ando Trigger a Succession Protocol (103) upon successful verification;• A Private Banking Custodial Vault (104) acting as a Relying Party configured to receive the Succession Protocol (103) and execute an automated re-assignment of access credentials, thereby providing Instant Asset Release (105) to a Nominated Successor (106).
2. Amended Claim 2: A system as in Claim 1, wherein the Verification Layer is configured to execute a Smart Escrow State, characterised by:• The computational earmarking of digital assets forthe Nominated Successor (106) upon receipt of the Verified Mortality Signal (101);• A programmable Liability Buffer period during which the assets are held in a read-only state; and• A requirement for a digital credential check and cryptographic signature from an Authorised Practitioner (600) to release the assets from escrow.
3. A system as in Claim 1, wherein the Succession Protocol (103) is configured to perform an atomic re-assignment of cryptographic keys within the Private Banking Custodial Vault (104) to remove manual probate latency.
4. A method for providing Instant Asset Release (105) to a Nominated Successor (106) using the system of Claim 1, characterised by the use of a sovereign API to automate the transfer of control of digital assets.
5. A system as in Claim 3, further comprising an automated Exception Handler configured to:• Execute a state-rollback of the Private Banking Vault (104) to a last-known-secure configuration if the Succession Protocol (103) fails to confirm an atomic completion;• Initiate a cooldown period of a predetermined duration before attempting a secondary automated retry of the Handshake Engine (102); and• Transmit a critical exception alert to a system administrator or digital trustee if the automated retry fails to achieve Instant Asset Release (105)6. A system as in Claim 1, further comprising a Secondary Ingestion Gateway (600) configured to:• Receive a Digitally Signed Death Certificate from an authenticated nonsovereign entity, including a funeral director or medical practitioner, via a secure API;• Validate the digital signature against a registry of authorised practitioners to generate a Verified Mortality Signal (101); and• Input the signal into the Automated Handshake Engine (102) for the automated transfer of custodial control via the Succession Protocol (103).
7. A system as in Claim 1, wherein the Automated Handshake Engine (102) comprises a multitenant gateway configured to:• Concurrently map a single verified mortality attribute from the Authoritative Attribute Provider to a plurality of distinct Relying Party Private Banking Custodial Vaults (104); and• Translate the protocol across diverse internal data ledger formats to achieve simultaneous transfer of custodial control and Instant Asset Release (105) across multiple financial institutions.
8. A system as in Claim 1, wherein the digital property recognised under the Property (Digital Assets etc) Act 2025 further comprises tokenised fiat currency or Central Bank Digital Currencies (CBDCs), such that the Succession Protocol (103) executes the transfer of monetary control via the same cryptographic key re-assignment used for non-monetary digital assets.
9. A system as in Claim 5, further comprising a Heuristic Anomaly Detector configured to cross-reference the Verified Mortality Signal (101) against real-time telemetry data from the decedent’s associated banking applications ; wherein the Succession Protocol (103) is automatically suspended and a Critical Exception Alert is generated if high-velocity user activity is detected within a predetermined window of the Sovereign Death Certificate timestamp.
10. A system as in Claim 1, wherein the Succession Protocol (103) is configured to generate an Immutable AuditTrace, comprising:• A cryptographically hashed log of the Verified Mortality Signal (101) timestamp;• The biometric authentication metadata of the Nominated Successor (106); and• The unique identifier of the Authorised Practitioner (600) who validated the transfer.
11. A system as in Claim 1, wherein the transfer of custodial control is executed as a Contractual Beneficiary Nomination, bypassing manual probate latency by fulfilling the "Control" requirements of the Property (Digital Assets etc) Act 2025 through automated cryptographic re-sharding.