From 75df3d0d0a9ff71ecf49c0e740ec7bf7afaa7ab7 Mon Sep 17 00:00:00 2001 From: alichatme Date: Mon, 29 Dec 2025 21:50:02 +0330 Subject: [PATCH 01/11] Add TIP draft header for native account inheritance --- tip-XXXX.md | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 tip-XXXX.md diff --git a/tip-XXXX.md b/tip-XXXX.md new file mode 100644 index 0000000..5bbb130 --- /dev/null +++ b/tip-XXXX.md @@ -0,0 +1,8 @@ +TIP: XXXX +Title: Native Account Inheritance Mechanism +Authors: Ali (@alichatme), ChatGPT +Status: Draft +Type: Core +Category: Account +Created: 2025-12-29 +Discussions-To: https://github.com/tronprotocol/tips/issues/810 From 0e225b88f394651b2ab32de3f59dce489f6871aa Mon Sep 17 00:00:00 2001 From: alichatme Date: Mon, 29 Dec 2025 22:48:14 +0330 Subject: [PATCH 02/11] Add full draft of native account inheritance TIP --- tip-XXXX.md | 216 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 216 insertions(+) diff --git a/tip-XXXX.md b/tip-XXXX.md index 5bbb130..a75937f 100644 --- a/tip-XXXX.md +++ b/tip-XXXX.md @@ -6,3 +6,219 @@ Type: Core Category: Account Created: 2025-12-29 Discussions-To: https://github.com/tronprotocol/tips/issues/810 + +Abstract + +This TIP proposes a native, optional, protocol-level account inheritance mechanism for the TRON network. +The mechanism allows users to define a time-based inheritance key that can access account assets after a prolonged period of owner inactivity, without revealing private keys, without smart contracts, without additional gas fees, and without dependency on specific wallets or off-chain services. + +In addition to inheritance, this mechanism can function as a secure access recovery solution in cases such as permanent loss of seed phrases, cognitive illness, coma, or long-term incapacity. + +Motivation + +In current blockchain architectures, ownership and access to assets are entirely dependent on possession of private keys. +If the owner experiences any of the following situations: + +Death + +Long-term unconsciousness or coma + +Cognitive diseases (e.g., Alzheimer’s) + +Permanent loss or forgetting of the seed phrase or private key + +the associated digital assets become permanently inaccessible. + +Existing solutions suffer from critical drawbacks: + +Sharing seed phrases compromises security + +Smart-contract-based inheritance introduces exploit and bug risks + +Wallet-based solutions are centralized, non-standard, and non-portable + +There is a strong need for a native, protocol-level solution that: + +Preserves full owner security during lifetime + +Prevents irreversible loss of assets + +Avoids legal, technical, or usability complexity + +Requires no smart contracts or trust assumptions + +Specification +Account Roles + +Each TRON account MAY optionally define an additional key role: + +Owner Key + +Primary account authority + +Always valid and active + +Inheritance Key + +Defined and managed exclusively by the Owner Key + +Inactive by default + +Becomes valid only after a protocol-defined inactivity condition is met + +The Owner Key is never disabled or revoked by inheritance activation. + +Inheritance Delay + +An optional parameter is stored in the native account state: + +inheritance_delay + +Minimum: 6 months + +Maximum: 240 months (20 years) + +This value represents the required duration of owner inactivity before inheritance activation. + +Owner Activity Definition + +A new native account field is introduced: + +last_owner_activity_timestamp + +This timestamp MUST be updated when a valid on-chain transaction is executed that: + +Is signed by the Owner Key + +Results in a verifiable state change + +Including, but not limited to: + +Asset transfers + +Voting + +Freeze / unfreeze operations + +Staking and unstaking + +Reward withdrawal + +Direct smart contract invocations signed by the Owner Key + +Receiving assets without Owner Key signature MUST NOT update this timestamp. + +Inheritance Activation Logic + +During transaction signature validation, the protocol evaluates: + +(current_time - last_owner_activity_timestamp) >= inheritance_delay + +If true, the Inheritance Key is considered valid for transaction authorization. + +Activation of the Inheritance Key DOES NOT disable or invalidate the Owner Key. + +Behavior After Activation + +Once the inheritance condition is met: + +The Inheritance Key MAY sign transactions + +The Owner Key: + +Remains fully valid + +MAY reset the inactivity timer + +MAY modify the inheritance delay + +MAY replace or disable the inheritance key + +This design ensures no irreversible or point-of-no-return state is introduced. + +Permission Model Integration + +The Inheritance Key operates as a restricted authority equivalent to an Active permission, with protocol-enforced limitations. + +The Inheritance Key: + +MAY initiate asset transfers + +MAY stake, unstake, and manage resources + +MAY interact with smart contracts + +The Inheritance Key MUST NOT: + +Modify Owner permissions + +Change account permission structure + +Replace or revoke the Owner Key + +Access or recover private keys or seed phrases + +Security Considerations + +The mechanism introduces no shared secrets + +No private key material is exposed + +No smart contracts are involved + +All logic is enforced at the consensus/protocol layer + +The Owner Key always retains ultimate control + +This design minimizes attack surface and eliminates common inheritance exploit vectors. + +Transparency + +Each transaction MAY include a non-sensitive role identifier: + +signature_role: owner +signature_role: inheritance + +This allows public auditability and prevents ambiguity without leaking sensitive data. + +Wallet UX Considerations + +Wallets SHOULD display the following read-only information: + +Inheritance feature status (enabled / disabled) + +Configured inheritance delay + +Remaining time until potential activation + +All inheritance configuration is managed as native account metadata and does not require user interaction with gas fees or smart contracts. + +Special Scenarios +Long-Term Incapacity + +The protocol relies solely on cryptographic inactivity. +A minimum delay of six months provides sufficient protection against accidental activation. + +Physical Restriction or Detention + +In most scenarios, sending a minimal transaction remains possible. +Failure to do so is interpreted as implicit consent. + +Key Loss or Cognitive Decline + +The Inheritance Key provides a secure recovery path without compromising owner security. + +Backwards Compatibility + +Fully optional + +No behavior changes for existing accounts + +No smart contract dependency + +Compatible with existing TRON permission architecture + +Conclusion + +This TIP introduces a simple yet foundational protocol feature that prevents permanent loss of digital assets on TRON. +By combining security, simplicity, and user sovereignty, native account inheritance can become a defining advantage of the TRON network. From 80b4d221d633c7d63245e66d3b4a1ef10ea342ef Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 1 Jan 2026 10:59:02 +0330 Subject: [PATCH 03/11] Update tip-XXXX.md --- tip-XXXX.md | 286 ++++++++++++++++++++-------------------------------- 1 file changed, 112 insertions(+), 174 deletions(-) diff --git a/tip-XXXX.md b/tip-XXXX.md index a75937f..766f9fb 100644 --- a/tip-XXXX.md +++ b/tip-XXXX.md @@ -8,217 +8,155 @@ Created: 2025-12-29 Discussions-To: https://github.com/tronprotocol/tips/issues/810 Abstract - -This TIP proposes a native, optional, protocol-level account inheritance mechanism for the TRON network. -The mechanism allows users to define a time-based inheritance key that can access account assets after a prolonged period of owner inactivity, without revealing private keys, without smart contracts, without additional gas fees, and without dependency on specific wallets or off-chain services. - -In addition to inheritance, this mechanism can function as a secure access recovery solution in cases such as permanent loss of seed phrases, cognitive illness, coma, or long-term incapacity. - +This TIP introduces a native, optional, protocol-level inheritance mechanism for all TRON network accounts. +This mechanism allows account owners to define a time-based Inheritance Key for their account, which provides operational access to the account’s assets only if cryptographic inactivity of the Owner Key is detected and after a predefined delay period explicitly set by the owner has elapsed. +The Inheritance Key operates: +Without exposing or compromising the Owner Key +Without relying on smart contracts +Without additional gas or fee requirements +Without dependency on any specific wallet or off-chain service +and is implemented natively at the protocol level as an intrinsic part of TRON accounts. +In addition to inheritance use cases, this mechanism also serves as a secure access recovery path, even for the owner themselves, in situations such as permanent loss of the Seed Phrase, cognitive diseases (e.g., Alzheimer’s), coma, long-term incapacity, or unexpected incidents that prevent access to the primary account key. Motivation - -In current blockchain architectures, ownership and access to assets are entirely dependent on possession of private keys. -If the owner experiences any of the following situations: - -Death - +In current blockchain architectures, ownership and access to assets are entirely dependent on possession of a private key or Seed Phrase. +If any of the following conditions occur: +Death of the owner Long-term unconsciousness or coma - -Cognitive diseases (e.g., Alzheimer’s) - -Permanent loss or forgetting of the seed phrase or private key - -the associated digital assets become permanently inaccessible. - -Existing solutions suffer from critical drawbacks: - -Sharing seed phrases compromises security - -Smart-contract-based inheritance introduces exploit and bug risks - -Wallet-based solutions are centralized, non-standard, and non-portable - -There is a strong need for a native, protocol-level solution that: - -Preserves full owner security during lifetime - +Memory-related illnesses such as Alzheimer’s +Permanent loss, theft, or destruction of the private key or Seed Phrase +the associated digital assets become permanently and irreversibly inaccessible. +Existing solutions suffer from significant drawbacks: +Sharing a Seed Phrase severely weakens security +Smart contract–based inheritance mechanisms are vulnerable to bugs and exploits +Wallet-based solutions are often centralized, non-standard, and unreliable +Entrusting recovery phrases even to close relatives carries substantial risk +Therefore, the network requires a native protocol-level solution that: +Fully preserves owner security during their lifetime while guaranteeing asset availability for beneficiaries Prevents irreversible loss of assets - -Avoids legal, technical, or usability complexity - -Requires no smart contracts or trust assumptions - +Avoids legal complexity, technical fragility, and poor user experience +Does not rely on smart contracts or trust in third parties Specification Account Roles - -Each TRON account MAY optionally define an additional key role: - -Owner Key - -Primary account authority - -Always valid and active - +Every TRON account has an Owner Key that: +Acts as the primary authority of the account +Is always valid and active +This TIP introduces an additional key role: Inheritance Key - -Defined and managed exclusively by the Owner Key - -Inactive by default - -Becomes valid only after a protocol-defined inactivity condition is met - -The Owner Key is never disabled or revoked by inheritance activation. - +Can only be enabled, disabled, or replaced by the Owner Key +Exists by default for all accounts, but is initially disabled +Has an independent Seed Phrase distinct from the Owner Key +Structurally functions as a time-based Active Permission +The existence of the Inheritance Key at the protocol level is mandatory, while enabling it is entirely optional and requires explicit Owner Key authorization. +Merely configuring the delay and enabling the Inheritance Key does not grant transaction authority until the inactivity condition is fulfilled. +Inheritance Key States +The protocol defines three explicit and auditable states: +1. Disabled +No delay configured +The key is completely inactive at the protocol level +2. Configured +Delay period is defined and signed by the Owner Key +Owner inactivity countdown has started +The key is not yet authorized to sign transactions +3. Active +Owner inactivity condition for the configured delay is satisfied +The Inheritance Key is authorized to sign transactions with Active Permission scope +Activation of the Inheritance Key never disables or restricts the Owner Key. +Explicit Responsibility Separation +Protocol / Network Responsibilities +Maintain the Inheritance Key state and parameters +Enforce activation logic during transaction validation +Apply protocol-level permission restrictions +Record the signer role for each transaction +Wallet Responsibilities +Display Inheritance Key status in read-only mode +Display configured delay period +Display remaining time until activation +Avoid implementing any security logic outside the protocol +User (Owner) Responsibilities +Decide whether to enable or disable inheritance +Configure the delay period +Securely store or distribute the Inheritance Key Seed Phrase to trusted parties Inheritance Delay +A native account parameter: -An optional parameter is stored in the native account state: inheritance_delay - -Minimum: 6 months - +Minimum: 1 month Maximum: 240 months (20 years) - -This value represents the required duration of owner inactivity before inheritance activation. - Owner Activity Definition +A new native field: -A new native account field is introduced: last_owner_activity_timestamp - -This timestamp MUST be updated when a valid on-chain transaction is executed that: - -Is signed by the Owner Key - -Results in a verifiable state change - -Including, but not limited to: - +This value is updated only when: +A transaction is signed by the Owner Key +The transaction causes a verifiable on-chain state change +Including (but not limited to): Asset transfers - Voting - Freeze / unfreeze operations - -Staking and unstaking - +Stake / unstake Reward withdrawal - -Direct smart contract invocations signed by the Owner Key - -Receiving assets without Owner Key signature MUST NOT update this timestamp. - +Voting actions requiring owner authorization +Smart contract interactions +Note: Receiving assets or any activity not signed by the Owner Key does not update this timestamp. Inheritance Activation Logic +During transaction validation: -During transaction signature validation, the protocol evaluates: (current_time - last_owner_activity_timestamp) >= inheritance_delay - -If true, the Inheritance Key is considered valid for transaction authorization. - -Activation of the Inheritance Key DOES NOT disable or invalidate the Owner Key. - +If the condition is satisfied, the Inheritance Key is considered valid for authorization. Behavior After Activation - -Once the inheritance condition is met: - -The Inheritance Key MAY sign transactions - -The Owner Key: - -Remains fully valid - -MAY reset the inactivity timer - -MAY modify the inheritance delay - -MAY replace or disable the inheritance key - -This design ensures no irreversible or point-of-no-return state is introduced. - +The Owner Key retains full control +The Owner may at any time: +Disable the Inheritance Key +Reconfigure the delay and re-enable it +Permanently delete the existing Inheritance Key and replace it with a completely new one +Note: Activation of the Inheritance Key never creates an irreversible or point-of-no-return state. Permission Model Integration - -The Inheritance Key operates as a restricted authority equivalent to an Active permission, with protocol-enforced limitations. - -The Inheritance Key: - -MAY initiate asset transfers - -MAY stake, unstake, and manage resources - -MAY interact with smart contracts - -The Inheritance Key MUST NOT: - +The Inheritance Key is authorized to: +Transfer assets +Stake, unstake, and manage resources +Vote and claim rewards +Interact with smart contracts +Perform swaps +The Inheritance Key is not authorized to: Modify Owner permissions - -Change account permission structure - +Change the account permission structure Replace or revoke the Owner Key - -Access or recover private keys or seed phrases - +Access or recover any Seed Phrase Security Considerations - -The mechanism introduces no shared secrets - -No private key material is exposed - +There is no shared material between the Owner Key and the Inheritance Key or their Seed Phrases +If an account is accessed via the Inheritance Key, it remains bound to all Owner-defined account settings No smart contracts are involved - -All logic is enforced at the consensus/protocol layer - -The Owner Key always retains ultimate control - -This design minimizes attack surface and eliminates common inheritance exploit vectors. - +All logic is enforced at the consensus / protocol layer +Delayed Security Layer +Even if the Inheritance Key Seed Phrase is compromised: +No operational access is possible before the Owner inactivity delay expires +This protocol-level delay: +Prevents immediate asset theft +Gives the Owner sufficient time to react and replace the Inheritance Key +This security model is not natively implemented in any existing blockchain. Transparency +Each transaction may include a non-sensitive signer role identifier: -Each transaction MAY include a non-sensitive role identifier: signature_role: owner signature_role: inheritance - -This allows public auditability and prevents ambiguity without leaking sensitive data. - Wallet UX Considerations - -Wallets SHOULD display the following read-only information: - -Inheritance feature status (enabled / disabled) - -Configured inheritance delay - -Remaining time until potential activation - -All inheritance configuration is managed as native account metadata and does not require user interaction with gas fees or smart contracts. - -Special Scenarios -Long-Term Incapacity - -The protocol relies solely on cryptographic inactivity. -A minimum delay of six months provides sufficient protection against accidental activation. - -Physical Restriction or Detention - -In most scenarios, sending a minimal transaction remains possible. -Failure to do so is interpreted as implicit consent. - -Key Loss or Cognitive Decline - -The Inheritance Key provides a secure recovery path without compromising owner security. - +Wallets should support: +Enabling, disabling, configuring delay +Deleting and replacing the Inheritance Key +And display: +Inheritance Key status (Disabled / Configured / Active) +Configured delay period +Remaining time until activation +Automatic timer reset after each Owner Key activity Backwards Compatibility - Fully optional - No behavior changes for existing accounts - No smart contract dependency - -Compatible with existing TRON permission architecture - +Fully compatible with TRON’s existing permission architecture Conclusion - -This TIP introduces a simple yet foundational protocol feature that prevents permanent loss of digital assets on TRON. -By combining security, simplicity, and user sovereignty, native account inheritance can become a defining advantage of the TRON network. +This TIP introduces a foundational protocol-level capability that prevents permanent loss of digital assets on the TRON network. +By combining security, predictability, and user sovereignty, native account inheritance can become a strategic and distinguishing advantage for the TRON ecosystem. From 318bba1bb0c943705a95b953875ad7f0896eee71 Mon Sep 17 00:00:00 2001 From: alichatme Date: Tue, 16 Jun 2026 08:04:11 +0330 Subject: [PATCH 04/11] Update tip-XXXX.md --- tip-XXXX.md | 298 +++++++++++++++++++++++++++++++++------------------- 1 file changed, 192 insertions(+), 106 deletions(-) diff --git a/tip-XXXX.md b/tip-XXXX.md index 766f9fb..ad0b4cc 100644 --- a/tip-XXXX.md +++ b/tip-XXXX.md @@ -1,162 +1,248 @@ +--- TIP: XXXX Title: Native Account Inheritance Mechanism -Authors: Ali (@alichatme), ChatGPT +Authors: Ali (@alichatme) Status: Draft Type: Core Category: Account Created: 2025-12-29 Discussions-To: https://github.com/tronprotocol/tips/issues/810 - -Abstract +--- +# Abstract This TIP introduces a native, optional, protocol-level inheritance mechanism for all TRON network accounts. + This mechanism allows account owners to define a time-based Inheritance Key for their account, which provides operational access to the account’s assets only if cryptographic inactivity of the Owner Key is detected and after a predefined delay period explicitly set by the owner has elapsed. -The Inheritance Key operates: -Without exposing or compromising the Owner Key -Without relying on smart contracts -Without additional gas or fee requirements -Without dependency on any specific wallet or off-chain service + +## The Inheritance Key operates: + +. Without exposing or compromising the Owner Key +. Without relying on smart contracts +. Without additional gas or fee requirements +. Without dependency on any specific wallet or off-chain service + and is implemented natively at the protocol level as an intrinsic part of TRON accounts. -In addition to inheritance use cases, this mechanism also serves as a secure access recovery path, even for the owner themselves, in situations such as permanent loss of the Seed Phrase, cognitive diseases (e.g., Alzheimer’s), coma, long-term incapacity, or unexpected incidents that prevent access to the primary account key. -Motivation + +In addition to inheritance use cases, this mechanism also serves as a secure access recovery path, even for the owner themselves, in situations such as + +. permanent loss of the Seed Phrase +. cognitive diseases (e.g., Alzheimer’s), coma, long-term incapacity +. or unexpected incidents that prevent access to the primary account key. + + +# Motivation + In current blockchain architectures, ownership and access to assets are entirely dependent on possession of a private key or Seed Phrase. + If any of the following conditions occur: -Death of the owner -Long-term unconsciousness or coma -Memory-related illnesses such as Alzheimer’s -Permanent loss, theft, or destruction of the private key or Seed Phrase + +. Death of the owner +. Long-term unconsciousness or coma +. Memory-related illnesses such as Alzheimer’s +. Permanent loss, theft, or destruction of the private key or Seed Phrase + the associated digital assets become permanently and irreversibly inaccessible. + Existing solutions suffer from significant drawbacks: -Sharing a Seed Phrase severely weakens security -Smart contract–based inheritance mechanisms are vulnerable to bugs and exploits -Wallet-based solutions are often centralized, non-standard, and unreliable -Entrusting recovery phrases even to close relatives carries substantial risk + +. Sharing a Seed Phrase severely weakens security +. Smart contract–based inheritance mechanisms are vulnerable to bugs and exploits +. Wallet-based solutions are often centralized, non-standard, and unreliable +. Entrusting recovery phrases even to close relatives carries substantial risk + Therefore, the network requires a native protocol-level solution that: -Fully preserves owner security during their lifetime while guaranteeing asset availability for beneficiaries -Prevents irreversible loss of assets -Avoids legal complexity, technical fragility, and poor user experience -Does not rely on smart contracts or trust in third parties -Specification -Account Roles + +. Fully preserves owner security during their lifetime while guaranteeing asset availability for beneficiaries +. Prevents irreversible loss of assets +. Avoids legal complexity, technical fragility, and poor user experience +. Does not rely on smart contracts or trust in third parties + + +# Specification + +## Account Roles + Every TRON account has an Owner Key that: -Acts as the primary authority of the account -Is always valid and active -This TIP introduces an additional key role: + +. Acts as the primary authority of the account +. Is always valid and active + +## This TIP introduces an additional key role: + Inheritance Key -Can only be enabled, disabled, or replaced by the Owner Key -Exists by default for all accounts, but is initially disabled -Has an independent Seed Phrase distinct from the Owner Key -Structurally functions as a time-based Active Permission + +. Can only be enabled, disabled, or replaced by the Owner Key +. Exists by default for all accounts, but is initially disabled +. Has an independent Seed Phrase distinct from the Owner Key +. Structurally functions as a time-based Active Permission + The existence of the Inheritance Key at the protocol level is mandatory, while enabling it is entirely optional and requires explicit Owner Key authorization. + Merely configuring the delay and enabling the Inheritance Key does not grant transaction authority until the inactivity condition is fulfilled. -Inheritance Key States + +## Inheritance Key States + The protocol defines three explicit and auditable states: + 1. Disabled + No delay configured The key is completely inactive at the protocol level -2. Configured -Delay period is defined and signed by the Owner Key + +2. Configured Delay + +period is defined and signed by the Owner Key Owner inactivity countdown has started The key is not yet authorized to sign transactions + 3. Active -Owner inactivity condition for the configured delay is satisfied -The Inheritance Key is authorized to sign transactions with Active Permission scope -Activation of the Inheritance Key never disables or restricts the Owner Key. -Explicit Responsibility Separation -Protocol / Network Responsibilities -Maintain the Inheritance Key state and parameters -Enforce activation logic during transaction validation -Apply protocol-level permission restrictions -Record the signer role for each transaction -Wallet Responsibilities -Display Inheritance Key status in read-only mode -Display configured delay period -Display remaining time until activation -Avoid implementing any security logic outside the protocol -User (Owner) Responsibilities -Decide whether to enable or disable inheritance -Configure the delay period -Securely store or distribute the Inheritance Key Seed Phrase to trusted parties + +. Owner inactivity condition for the configured delay is satisfied +. The Inheritance Key is authorized to sign transactions with Active Permission scope +. Activation of the Inheritance Key never disables or restricts the Owner Key. + + +# Explicit Responsibility Separation + +## Protocol / Network Responsibilities + +. Maintain the Inheritance Key state and parameters +. Enforce activation logic during transaction validation +. Apply protocol-level permission restrictions +. Record the signer role for each transaction + +## Wallet Responsibilities + +. Display Inheritance Key status in read-only mode +. Display configured delay period +. Display remaining time until activation +. Avoid implementing any security logic outside the protocol + +## User (Owner) Responsibilities + +. Decide whether to enable or disable inheritance +. Configure the delay period +. Securely store or distribute the Inheritance Key Seed Phrase to trusted parties Inheritance Delay -A native account parameter: +### A native account parameter: -inheritance_delay +. inheritance_delay Minimum: 1 month Maximum: 240 months (20 years) -Owner Activity Definition -A new native field: +## Owner Activity Definition +A new native field: last_owner_activity_timestamp -This value is updated only when: -A transaction is signed by the Owner Key -The transaction causes a verifiable on-chain state change -Including (but not limited to): -Asset transfers -Voting -Freeze / unfreeze operations -Stake / unstake -Reward withdrawal -Voting actions requiring owner authorization -Smart contract interactions + +### This value is updated only when: + +. A transaction is signed by the Owner Key +. The transaction causes a verifiable on-chain state change + +### Including (but not limited to): + +. Asset transfers +. Voting +. Freeze / unfreeze operations +. Stake / unstake +. Reward withdrawal +. Voting actions requiring owner authorization +. Smart contract interactions + Note: Receiving assets or any activity not signed by the Owner Key does not update this timestamp. -Inheritance Activation Logic -During transaction validation: +### Inheritance Activation Logic + +During transaction validation: (current_time - last_owner_activity_timestamp) >= inheritance_delay + If the condition is satisfied, the Inheritance Key is considered valid for authorization. -Behavior After Activation -The Owner Key retains full control -The Owner may at any time: -Disable the Inheritance Key -Reconfigure the delay and re-enable it -Permanently delete the existing Inheritance Key and replace it with a completely new one + +### Behavior After Activation + +. The Owner Key retains full control + +### The Owner may at any time: + +. Disable the Inheritance Key +. Reconfigure the delay and re-enable it +. Permanently delete the existing Inheritance Key and replace it with a completely new one + Note: Activation of the Inheritance Key never creates an irreversible or point-of-no-return state. -Permission Model Integration + +### Permission Model Integration + The Inheritance Key is authorized to: -Transfer assets -Stake, unstake, and manage resources -Vote and claim rewards -Interact with smart contracts + +. Transfer assets +. Stake, unstake, and manage resources +. Vote and claim rewards +. Interact with smart contracts Perform swaps -The Inheritance Key is not authorized to: -Modify Owner permissions -Change the account permission structure -Replace or revoke the Owner Key -Access or recover any Seed Phrase -Security Considerations + +### The Inheritance Key is not authorized to: + +. Modify Owner permissions +. Change the account permission structure +. Replace or revoke the Owner Key +. Access or recover any Seed Phrase + + +# Security Considerations + There is no shared material between the Owner Key and the Inheritance Key or their Seed Phrases -If an account is accessed via the Inheritance Key, it remains bound to all Owner-defined account settings -No smart contracts are involved -All logic is enforced at the consensus / protocol layer -Delayed Security Layer + +## If an account is accessed via the Inheritance Key + +. it remains bound to all Owner-defined account settings +. No smart contracts are involved +. All logic is enforced at the consensus / protocol layer + +## Delayed Security Layer + Even if the Inheritance Key Seed Phrase is compromised: + No operational access is possible before the Owner inactivity delay expires -This protocol-level delay: -Prevents immediate asset theft -Gives the Owner sufficient time to react and replace the Inheritance Key + +### This protocol-level delay: + +. Prevents immediate asset theft +. Gives the Owner sufficient time to react and replace the Inheritance Key + This security model is not natively implemented in any existing blockchain. -Transparency -Each transaction may include a non-sensitive signer role identifier: +## Transparency + +Each transaction may include a non-sensitive signer role identifier: signature_role: owner + signature_role: inheritance -Wallet UX Considerations + +## Wallet UX Considerations + Wallets should support: + Enabling, disabling, configuring delay Deleting and replacing the Inheritance Key And display: -Inheritance Key status (Disabled / Configured / Active) -Configured delay period -Remaining time until activation -Automatic timer reset after each Owner Key activity -Backwards Compatibility -Fully optional -No behavior changes for existing accounts -No smart contract dependency -Fully compatible with TRON’s existing permission architecture -Conclusion + +. Inheritance Key status (Disabled / Configured / Active) +. Configured delay period +. Remaining time until activation +. Automatic timer reset after each Owner Key activity + +## Backwards Compatibility + +. Fully optional +. No behavior changes for existing accounts +. No smart contract dependency +. Fully compatible with TRON’s existing permission architecture + +## Conclusion + This TIP introduces a foundational protocol-level capability that prevents permanent loss of digital assets on the TRON network. + By combining security, predictability, and user sovereignty, native account inheritance can become a strategic and distinguishing advantage for the TRON ecosystem. From b027ad4b33f1ee13a4844abf753c8fe12fc5fb4b Mon Sep 17 00:00:00 2001 From: alichatme Date: Tue, 16 Jun 2026 08:12:37 +0330 Subject: [PATCH 05/11] Update tip-XXXX.md --- tip-XXXX.md | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) diff --git a/tip-XXXX.md b/tip-XXXX.md index ad0b4cc..b6fb6fc 100644 --- a/tip-XXXX.md +++ b/tip-XXXX.md @@ -29,6 +29,123 @@ In addition to inheritance use cases, this mechanism also serves as a secure acc . or unexpected incidents that prevent access to the primary account key. +# Rationale + +Designing a native inheritance mechanism at the protocol level, rather than relying on smart contracts or off-chain solutions, is the result of a deliberate trade-off analysis between security, usability, decentralization, and prevention of irreversible asset loss. + +## 1. Why Protocol-Level Instead of Smart Contracts? + +Smart contract–based inheritance solutions suffer from fundamental limitations: + +. Vulnerability to bugs and upgrades: +Smart contracts can be hacked, and malicious upgrades can bypass inheritance logic. + +· Gas dependency: Activation requires the beneficiary to pay gas – which may be impossible if the beneficiary lacks sufficient TRX. + +· No native permission integration: +Smart contracts cannot distinguish between true Owner Key inactivity versus simple non-use of a specific contract. + +· Incomplete access to consensus truth: Smart contracts intentionally do not have access to the full, consensus-verifiable history of Owner Key activity (votes, freezes, permission updates, governance actions). This is a deliberate VM security property, not an implementation flaw. + +By implementing inheritance natively in the TRON protocol, all accounts automatically possess the potential for inheritance, and activation carries zero additional gas overhead. + +## 2. Why Not Key Sharing or Multi-Signature? + +· Sharing Seed Phrase: Irreversibly compromises security. A trusted party could access assets at any time without delay. + +· Multi-signature: This is a mechanism for simultaneous trust distribution, not time-based recovery. The owner must permanently grant signing power to other parties from day one, which means loss of exclusive control. + +The proposed model ensures that during the owner's active lifetime, the Inheritance Key provides zero access, preserving full unilateral control. + +## 3. Rationale for the Time-Based Delay Model + +The delay period (minimum 1 month, maximum 20 years) serves two critical security functions: + +. Detection window: If the Inheritance Key Seed Phrase is compromised, the delay gives the owner time to react before any theft can occur. + +. Proof of true inactivity: Short delays risk premature activation during travel or temporary disengagement, causing false inheritance events. +The 1-month minimum balances practical usability (beneficiaries do not wait indefinitely) with security (no immediate post-loss exploitation). + +## 4. Delayed Security Layer Against Inheritance Key Seed Exposure + +Even if the Inheritance Key Seed Phrase is exposed, no operational access is possible before the inactivity delay expires. This is a native protocol-level security layer not implemented in any other blockchain. + +## 5. Why No Smart Contract Involvement in the Permission Model? + +Restricting the Inheritance Key from modifying Owner permissions or account structure is a deliberate design choice to preserve Owner Sovereignty. Even after the Inheritance Key becomes active: + +· The owner retains full ability to disable inheritance. +· The owner can reclaim exclusive control at any time. + +This prevents a "hostile inheritance" scenario where a beneficiary could lock out a returning owner. + +## 6. Comparison with Other Blockchains + +No major Layer 1 blockchain (Bitcoin, Ethereum, Solana, BNB Chain, or TRON itself) currently implements a native, protocol-level, time-delayed inheritance mechanism with independent key material. Existing approaches are either centralized, legal wills (unenforceable on-chain), or vulnerable to smart contract hacks. + +This TIP positions TRON as a first mover in solving the permanent asset loss problem without compromising self-custody. + +## 7. Why the Inheritance Key Seed Must Be Independent from the Owner Key + +If the Inheritance Key were derived from the Owner Key, compromising the Owner Key would simultaneously compromise inheritance security. By maintaining fully independent seed phrases: + +· No mathematical relationship exists between the two keys. + +· The owner can rotate or replace the Inheritance Key without changing the Owner Key. + +· Even if the Inheritance Key is leaked, the owner's day-to-day assets remain safe during the delay period. + +## 8. Protocol Necessity (Response to "Why Must This Be at Protocol Layer") + +The necessity lies in this reality: "The last valid activity of the Owner Key is a consensus fact, not a reliable application-level signal." No smart contract can deterministically and safely verify: + +· Whether the Owner Key has truly been inactive + +· Whether activity occurred outside the contract (vote, freeze, permission update) + +· Whether a transaction was actually signed by the Owner Key or by another Active Permission + +Smart contracts intentionally lack access to this level of information – this is a VM security feature, not a flaw. Consequently, any smart contract–based solution will inevitably suffer from either: + +· False positives (incorrect activation), + +· False negatives (failure to activate when needed), + +· Or reliance on off-chain assumptions. + +Therefore, this capability sits exactly at the boundary of what the protocol must define – neither above nor below. + +## 9. Protocol Maintenance Cost and Complexity + +This proposal: + +· Introduces no new signature paths + +· Grants no new power to any key + +· Adds only a conditional check inside existing signature validation + +· Is fully optional and disabled by default + +Its maintenance and complexity profile remains at the level of existing permission primitives (Owner/Active, multi-signature), not at the level of behavioral policy systems. + +## 10. Handling Edge Cases: Owner Returns After Activation + +The specification explicitly allows the owner to: + +· Disable the Inheritance Key + +· Reconfigure the delay period + +· Replace the Inheritance Key entirely + +No irreversible state is created – even after activation. + +## 11. Rationale for Updating last_owner_activity_timestamp Only on Owner-Signed State-Changing Transactions + +Updating the timestamp on any transaction (including receiving assets) would cause trivial activities to reset the inheritance timer indefinitely, defeating the purpose of inheritance. Only actions that require the owner's explicit cryptographic signature and alter on-chain state represent meaningful "proof of life" from the owner's key. Receiving assets is a passive event and does not demonstrate owner awareness or intent. + + # Motivation In current blockchain architectures, ownership and access to assets are entirely dependent on possession of a private key or Seed Phrase. From 97243e732c65a13c7af3ade761a6d4ccbfd5cdf1 Mon Sep 17 00:00:00 2001 From: alichatme Date: Tue, 16 Jun 2026 12:44:33 +0330 Subject: [PATCH 06/11] Update tip-XXXX.md --- tip-XXXX.md | 36 +++++++++++++++++++++++++----------- 1 file changed, 25 insertions(+), 11 deletions(-) diff --git a/tip-XXXX.md b/tip-XXXX.md index b6fb6fc..a12bfed 100644 --- a/tip-XXXX.md +++ b/tip-XXXX.md @@ -9,24 +9,38 @@ Created: 2025-12-29 Discussions-To: https://github.com/tronprotocol/tips/issues/810 --- # Abstract -This TIP introduces a native, optional, protocol-level inheritance mechanism for all TRON network accounts. -This mechanism allows account owners to define a time-based Inheritance Key for their account, which provides operational access to the account’s assets only if cryptographic inactivity of the Owner Key is detected and after a predefined delay period explicitly set by the owner has elapsed. +This TIP introduces a native, optional, protocol-level inheritance mechanism for TRON accounts. -## The Inheritance Key operates: +Under this proposal, every TRON account is capable of supporting a dedicated Inheritance Key at the protocol level. The Inheritance Key is disabled by default and becomes operational only if explicitly configured by the account owner. + +The owner may configure an inheritance delay period and assign an Inheritance Key. If no valid Owner Key activity occurs during the configured delay period, the Inheritance Key becomes active and may operate within the scope of a restricted Active Permission. + +### The Owner Key always remains the ultimate authority of the account. At any time, including after inheritance activation, the owner may: + +. Disable the Inheritance Key + +. Modify or reset the inheritance delay + +. Replace the existing Inheritance Key with a completely new one + +Activation of the Inheritance Key never disables, replaces, or reduces the authority of the Owner Key. + +### The inheritance mechanism operates: + +. Without exposing or sharing the Owner Key -. Without exposing or compromising the Owner Key . Without relying on smart contracts -. Without additional gas or fee requirements -. Without dependency on any specific wallet or off-chain service -and is implemented natively at the protocol level as an intrinsic part of TRON accounts. +. Without dependency on any specific wallet implementation + +. Without dependency on off-chain services + +Configuration, activation, deactivation, and replacement of the Inheritance Key are native protocol-level account operations and do not require deployment of smart contracts or any inheritance-specific fees. -In addition to inheritance use cases, this mechanism also serves as a secure access recovery path, even for the owner themselves, in situations such as +Transactions executed through an active Inheritance Key remain subject to TRON's normal bandwidth, energy, and fee rules. -. permanent loss of the Seed Phrase -. cognitive diseases (e.g., Alzheimer’s), coma, long-term incapacity -. or unexpected incidents that prevent access to the primary account key. +Beyond inheritance scenarios, this mechanism can also function as a secure recovery path for account owners in situations such as loss of private keys, loss of seed phrases, cognitive impairment, long-term incapacity, or other events that prevent access to the primary account credentials. # Rationale From 9fbcd9ea414b68b476aac4dd1f4ca15fe1314733 Mon Sep 17 00:00:00 2001 From: alichatme Date: Tue, 16 Jun 2026 18:36:59 +0330 Subject: [PATCH 07/11] Update tip-XXXX.md --- tip-XXXX.md | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 74 insertions(+), 2 deletions(-) diff --git a/tip-XXXX.md b/tip-XXXX.md index a12bfed..393e9e1 100644 --- a/tip-XXXX.md +++ b/tip-XXXX.md @@ -155,9 +155,81 @@ The specification explicitly allows the owner to: No irreversible state is created – even after activation. -## 11. Rationale for Updating last_owner_activity_timestamp Only on Owner-Signed State-Changing Transactions +## 11. Rationale for Updating last_owner_activity_timestamp -Updating the timestamp on any transaction (including receiving assets) would cause trivial activities to reset the inheritance timer indefinitely, defeating the purpose of inheritance. Only actions that require the owner's explicit cryptographic signature and alter on-chain state represent meaningful "proof of life" from the owner's key. Receiving assets is a passive event and does not demonstrate owner awareness or intent. +The "last_owner_activity_timestamp" is updated only when a transaction meets all of the following criteria: + +. Successfully authorized through the account's Owner Permission, +. Successfully passes protocol validation requirements, +. Executes successfully and results in a committed on-chain state change. + +This definition intentionally excludes: + +· Failed or reverted transactions, even when authorized through the Owner Permission, because they do not produce a committed state change. + +· Execution failures, VM exceptions, contract reverts, resource exhaustion failures (e.g., OUT_OF_ENERGY), insufficient balance failures, and any other transactions that do not result in a committed state change. + +· Read-only calls (e.g., view/pure functions), because they do not alter state. + +· Transactions rejected during protocol validation, including invalid signatures, malformed transactions, or authorization failures. + +· Passive events, such as receiving assets, because they do not demonstrate owner intent or awareness. + +Rationale for this strict definition: + +· Preventing trivial resets: If failed transactions, passive receipts, or non-state-changing operations updated the timestamp, inheritance could be postponed indefinitely, defeating the mechanism's purpose. + +· Consensus alignment: Only successful state-changing transactions provide an unambiguous, verifiable proof of owner activity that all consensus participants can independently verify. + +· Security: This ensures that the inactivity condition reflects genuine owner absence rather than accidental activity, failed execution attempts, or automated interactions that do not represent meaningful owner participation. + +By keeping the definition narrow and deterministic, the protocol maintains a clear, auditable, and consensus-safe boundary for what constitutes "Owner activity." + +## 12. Interaction with Existing Permission System and Multi-Signature + +The Inheritance Key is designed as a time-conditioned Active Permission and is fully integrated into TRON's existing permission architecture. + +· Active Permissions: The Inheritance Key reuses the existing Active Permission structure. No new PermissionType is introduced. + +· Multi-Signature Compatibility: Existing multi-signature behavior and validation rules remain unchanged. The inheritance mechanism does not modify or bypass any existing multisig security model. + +· Owner Supremacy: Owner Permission always remains the highest authority. The Owner may disable, reconfigure, or replace the Inheritance Key at any time, including after activation. + +This design ensures that the inheritance mechanism remains fully compatible with TRON's existing permission framework while preserving all current security guarantees. + +## 13. Inheritance Key as an Extension of the Existing Permission System + +This proposal does not introduce a separate account-control path. + +· Structurally, the Inheritance Key is implemented as a standard Active Permission already supported by TRON accounts. + +· The only addition occurs at the protocol validation layer, where a time-based condition determines whether this specific Active Permission is currently authorized. + +· Existing permission attributes, including weights, thresholds, and operation scopes, remain fully applicable. + +As a result, the inheritance mechanism extends the existing permission architecture rather than introducing a parallel authorization model. + +## 14. Simultaneous Owner and Inheritance Transactions in the Same Block + +If Owner-authorized and Inheritance-authorized transactions appear within the same block: + +· Standard deterministic transaction execution rules defined by the TRON protocol apply. + +· The transaction processed first determines the resulting account state for subsequent transactions within that block. + +· No inheritance-specific ordering rules are introduced. + +This approach preserves protocol simplicity, predictability, and compatibility with existing multi-key account behavior. + +## 15. Fee and Resource Clarification: Configuration vs. Transaction Execution + +A distinction must be made between inheritance configuration and transaction execution. + +· Configuration, activation, deactivation, replacement, or delay-period updates of the Inheritance Key are native account-management operations and do not require any inheritance-specific fees, smart-contract deployment costs, or additional protocol charges beyond standard protocol account-management behavior. + +· However, any transaction submitted through an active Inheritance Key consumes normal TRON resources, including bandwidth, energy, and applicable transaction fees, exactly as any other Active Permission transaction. + +This distinction is important: the inheritance mechanism itself introduces no additional operational cost, while all on-chain actions performed through the Inheritance Key continue to follow TRON's standard resource and fee model. # Motivation From 8638647ae6f632f770dbfaa329766426c01099c9 Mon Sep 17 00:00:00 2001 From: alichatme Date: Tue, 16 Jun 2026 22:16:51 +0330 Subject: [PATCH 08/11] Update tip-XXXX.md --- tip-XXXX.md | 54 ++++++++++++++++++++++++++++++----------------------- 1 file changed, 31 insertions(+), 23 deletions(-) diff --git a/tip-XXXX.md b/tip-XXXX.md index 393e9e1..2018816 100644 --- a/tip-XXXX.md +++ b/tip-XXXX.md @@ -264,44 +264,52 @@ Therefore, the network requires a native protocol-level solution that: ## Account Roles -Every TRON account has an Owner Key that: +### Every TRON account has an Owner Permission that: -. Acts as the primary authority of the account -. Is always valid and active +· Acts as the primary authority of the account +· Is always valid and active -## This TIP introduces an additional key role: +This TIP introduces an additional key role: -Inheritance Key +## Inheritance Key -. Can only be enabled, disabled, or replaced by the Owner Key -. Exists by default for all accounts, but is initially disabled -. Has an independent Seed Phrase distinct from the Owner Key -. Structurally functions as a time-based Active Permission +· Can only be enabled, disabled, or replaced through the Owner Permission +· Is displayed in a dedicated Inheritance Key slot +· Exists for all accounts, but is initially disabled and unconfigured +· Has an independent Seed Phrase distinct from the Owner Key +· Structurally functions as a time‑based Active Permission -The existence of the Inheritance Key at the protocol level is mandatory, while enabling it is entirely optional and requires explicit Owner Key authorization. +After implementation of this proposal, every TRON account natively supports a dedicated Inheritance Key slot. This slot is disabled by default and remains unconfigured until explicitly configured through the Owner Permission. -Merely configuring the delay and enabling the Inheritance Key does not grant transaction authority until the inactivity condition is fulfilled. +Note: Merely configuring the delay does not grant the Inheritance Key transaction authority until the Owner inactivity condition is fulfilled. ## Inheritance Key States -The protocol defines three explicit and auditable states: +The Inheritance Key can exist in one of the following three states: -1. Disabled +### 1. Disabled -No delay configured -The key is completely inactive at the protocol level +· No delay is configured +· The key is completely inactive at the protocol level -2. Configured Delay +### 2. Configured -period is defined and signed by the Owner Key -Owner inactivity countdown has started -The key is not yet authorized to sign transactions +· An inactivity delay period is defined and confirmed through the Owner Permission +· Immediately after configuration, the Owner inactivity countdown begins +· The key is not yet authorized to sign transactions until the configured delay period expires +· After any valid Owner activity (successful state‑changing transactions confirmed through the Owner Permission), the countdown timer resets to the full configured delay period -3. Active +### 3. Active -. Owner inactivity condition for the configured delay is satisfied -. The Inheritance Key is authorized to sign transactions with Active Permission scope -. Activation of the Inheritance Key never disables or restricts the Owner Key. +· The Owner inactivity condition for the configured delay has been satisfied +· The Inheritance Key is authorized to sign transactions with Active Key scope +· Activation of the Inheritance Key never disables or restricts the Owner Permission +· At any time – even after activation – the Owner can, through the Owner Key, perform the following actions: + · Disable the Inheritance Key + · Reconfigure the delay period (and thereby reset the timer) + · Replace the existing Inheritance Key with a completely new key + +Note: Replacing the Inheritance Key automatically cancels and replaces the previous Inheritance Key configuration. The account always has exactly one Inheritance Key slot, which can be disabled, configured, or active. # Explicit Responsibility Separation From 9a9d61265bd62a4089e599c6f9504d4501b4eb53 Mon Sep 17 00:00:00 2001 From: alichatme Date: Wed, 17 Jun 2026 00:35:20 +0330 Subject: [PATCH 09/11] Update tip-XXXX.md --- tip-XXXX.md | 93 +++++++++++------------------------------------------ 1 file changed, 18 insertions(+), 75 deletions(-) diff --git a/tip-XXXX.md b/tip-XXXX.md index 2018816..8e82f5f 100644 --- a/tip-XXXX.md +++ b/tip-XXXX.md @@ -312,93 +312,36 @@ The Inheritance Key can exist in one of the following three states: Note: Replacing the Inheritance Key automatically cancels and replaces the previous Inheritance Key configuration. The account always has exactly one Inheritance Key slot, which can be disabled, configured, or active. -# Explicit Responsibility Separation -## Protocol / Network Responsibilities +## Behavior After Activation -. Maintain the Inheritance Key state and parameters -. Enforce activation logic during transaction validation -. Apply protocol-level permission restrictions -. Record the signer role for each transaction - -## Wallet Responsibilities - -. Display Inheritance Key status in read-only mode -. Display configured delay period -. Display remaining time until activation -. Avoid implementing any security logic outside the protocol - -## User (Owner) Responsibilities - -. Decide whether to enable or disable inheritance -. Configure the delay period -. Securely store or distribute the Inheritance Key Seed Phrase to trusted parties -Inheritance Delay - -### A native account parameter: - -. inheritance_delay -Minimum: 1 month -Maximum: 240 months (20 years) - -## Owner Activity Definition - -A new native field: -last_owner_activity_timestamp - -### This value is updated only when: - -. A transaction is signed by the Owner Key -. The transaction causes a verifiable on-chain state change - -### Including (but not limited to): - -. Asset transfers -. Voting -. Freeze / unfreeze operations -. Stake / unstake -. Reward withdrawal -. Voting actions requiring owner authorization -. Smart contract interactions - -Note: Receiving assets or any activity not signed by the Owner Key does not update this timestamp. - -### Inheritance Activation Logic - -During transaction validation: - -(current_time - last_owner_activity_timestamp) >= inheritance_delay - -If the condition is satisfied, the Inheritance Key is considered valid for authorization. - -### Behavior After Activation - -. The Owner Key retains full control +· The Owner Key retains full control over account assets and Inheritance Key settings. ### The Owner may at any time: -. Disable the Inheritance Key -. Reconfigure the delay and re-enable it -. Permanently delete the existing Inheritance Key and replace it with a completely new one +· Disable the Inheritance Key +· Reconfigure the inactivity delay and reconfigure the Inheritance Key +· Replace the existing Inheritance Key with a new key, regardless of its current state + +After replacement, the new Inheritance Key is disabled by default until configured again. Note: Activation of the Inheritance Key never creates an irreversible or point-of-no-return state. -### Permission Model Integration +## Permission Model Integration + +The Inheritance Key functions as a time-conditioned Active Permission. -The Inheritance Key is authorized to: +Once activated, the Inheritance Key is authorized to perform any operation permitted by its assigned Active Permission scope, weights, thresholds, and operation set, exactly as defined by TRON's existing permission system. -. Transfer assets -. Stake, unstake, and manage resources -. Vote and claim rewards -. Interact with smart contracts -Perform swaps +### The Inheritance Key is NOT authorized to: -### The Inheritance Key is not authorized to: +· Modify Owner permissions +· Change the account permission structure +· Replace or revoke the Owner Key +· Access or recover any Seed Phrase +· Change its own inheritance state, delay configuration, activation status, or replacement settings -. Modify Owner permissions -. Change the account permission structure -. Replace or revoke the Owner Key -. Access or recover any Seed Phrase +All inheritance-related configuration operations remain exclusively under the control of the Owner Key. # Security Considerations From a16028f2d0d55c23959bc95cff813ff16e330281 Mon Sep 17 00:00:00 2001 From: alichatme Date: Wed, 17 Jun 2026 01:52:05 +0330 Subject: [PATCH 10/11] Update tip-XXXX.md --- tip-XXXX.md | 244 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 244 insertions(+) diff --git a/tip-XXXX.md b/tip-XXXX.md index 8e82f5f..16eca6f 100644 --- a/tip-XXXX.md +++ b/tip-XXXX.md @@ -344,6 +344,250 @@ Once activated, the Inheritance Key is authorized to perform any operation permi All inheritance-related configuration operations remain exclusively under the control of the Owner Key. +# Threat Model + +Overview + +This section analyzes the threat landscape relevant to the Inheritance Key mechanism. + +The design assumes that: + +- The TRON network operates correctly according to consensus rules. +- The Owner Key remains secure during the owner's active lifetime. +- The primary objective of the mechanism is to provide account recovery and inheritance capabilities without introducing new attack vectors that could compromise account security. + +## 1. Assets Protected + +The Inheritance Key mechanism protects the following assets: + +- Owner Key sovereignty — the Owner Key remains the ultimate authority at all times. +- Account assets — TRX, TRC10, TRC20 tokens, NFTs, staking positions, and other account-controlled resources. +- Account permissions — the permission structure cannot be modified by the Inheritance Key. +- Seed Phrase confidentiality — the Owner Seed Phrase is never exposed to the Inheritance Key or to third parties. +- +## 2. Threat Actors and Capabilities + +External Attacker + +Capabilities: + +- Attempts to steal the Inheritance Key Seed Phrase. +- Attempts to compromise the Owner Key. +- Attempts to exploit protocol implementation flaws. + +Malicious Beneficiary + +Capabilities: + +- Possesses the Inheritance Key Seed Phrase entrusted by the owner. +- Attempts to gain access before the inactivity delay expires. + +Owner (Compromised or Incapacitated) + +Capabilities: + +- May become cognitively impaired. +- May become incapacitated. +- May make configuration mistakes. + +Network-Level Adversary + +Capabilities: + +- Attempts transaction censorship. +- Attempts transaction ordering manipulation. +- Attempts consensus-level attacks. + +## 3. Threat Analysis and Mitigations + +### 3.1. Compromise of the Inheritance Key Seed Phrase + +Threat + +An attacker obtains the Inheritance Key Seed Phrase through theft, phishing, malware, social engineering, or physical access. + +Mitigation + +- The Inheritance Key remains inactive until the configured inactivity delay expires. +- The protocol rejects all Inheritance Key transactions before activation. +- The delay period provides a detection and response window for the owner. +- The owner may disable, replace, or reconfigure the Inheritance Key at any time before activation. + +Residual Risk + +Low. + +The attacker must wait through the entire delay period while the owner may remain active and revoke the compromised key. + +### 3.2. Compromise of the Owner Key + +Threat + +An attacker obtains control of the Owner Key or its Seed Phrase. + +Mitigation + +- The Inheritance Key is cryptographically independent from the Owner Key. +- No seed material is shared between the two keys. +- Compromise of the Owner Key does not automatically compromise the Inheritance Key. + +Important Limitation + +Once an attacker gains effective control of the Owner Key, they possess the highest authority available within the account and may modify account configuration, including Inheritance Key settings. + +This mechanism is not intended to protect against Owner Key compromise. + +Residual Risk + +High. + +Owner Key compromise remains a catastrophic event, consistent with the security model of existing blockchain accounts. + +### 3.3. Malicious Beneficiary Attempting Early Access + +Threat + +A beneficiary entrusted with the Inheritance Key attempts to access assets before the owner's actual inactivity. + +Mitigation + +- Activation is enforced entirely by the protocol. +- The inactivity condition must be satisfied before any Inheritance Key transaction becomes valid. +- The owner can disable or replace the Inheritance Key at any time prior to activation. + +Residual Risk + +Low. + +The protocol deterministically prevents premature access. + +### 3.4. False Inactivity Due to Automated Activity + +Threat + +Assets are managed through automated systems, while the owner rarely signs transactions directly, potentially leading to inactivity detection despite continued asset management. + +Mitigation + +- Only successful Owner Key–signed state-changing transactions update the inactivity timer. +- Automated activity performed without Owner Key signatures does not reset the timer. +- Owners may configure longer inactivity periods to match their intended usage patterns. + +Residual Risk + +Low. + +This behavior is intentional and reflects the protocol's explicit definition of Owner activity. + +### 3.5. Transaction Ordering Conflicts + +Threat + +Owner-signed and Inheritance-signed transactions appear near the activation boundary and are included in the same block. + +Mitigation + +- Standard deterministic transaction ordering rules defined by the TRON protocol apply. +- Account state transitions are determined by the order in which transactions are executed. +- No special-case consensus rules are required. + +Residual Risk + +Low. + +Behavior remains deterministic and fully auditable. + +### 3.6. Denial of Service or Censorship + +Threat + +An adversary attempts to prevent activation or execution of valid Inheritance Key transactions. + +Mitigation + +- The mechanism is enforced directly by consensus. +- No external services, relayers, or off-chain infrastructure are required. +- Resistance to censorship is equivalent to that of the underlying TRON network. + +Residual Risk + +Low. + +The mechanism inherits the censorship resistance of the network itself. + +### 3.7. False Activation Through Timestamp Manipulation + +Threat + +An adversary attempts to manipulate timestamps to prematurely activate the Inheritance Key. + +Mitigation + +- Timestamp validation remains governed by existing TRON consensus rules. +- Activation relies on consensus-accepted timestamps. +- No single participant can arbitrarily alter activation timing without violating consensus. + +Residual Risk + +Negligible. + +The mechanism relies on the same timestamp trust assumptions already used throughout the protocol. + +### 3.8. Misconfiguration of the Inheritance Delay + +Threat + +The owner accidentally configures an excessively short inactivity delay, increasing the risk of premature activation. + +Mitigation + +- The protocol enforces a minimum delay period. +- The Owner Key may disable, replace, or reconfigure the Inheritance Key at any time. +- Activation never overrides or restricts Owner Key authority. + +Residual Risk + +Low. + +Configuration choices remain under the owner's control and can be corrected at any time. + +## 4. Assumptions + +This threat model assumes that: + +1. The TRON consensus mechanism functions correctly. +2. The Owner Key is initially generated and stored securely. +3. The Inheritance Key Seed Phrase is generated and stored securely. +4. Users understand the configuration options provided by the mechanism. + +## 5. Limitations + +This mechanism does not protect against: + +- Owner Key compromise. +- Social engineering attacks that convince the owner to authorize malicious transactions. +- Physical coercion. +- Legal coercion. +- User mismanagement of secret material. +- Incorrect operational security practices. + +Users remain responsible for protecting both the Owner Key and the Inheritance Key according to their individual threat models. + +### Security Summary + +The Inheritance Key mechanism is designed to address long-term account inaccessibility while preserving Owner sovereignty and minimizing new attack surfaces. + +The security model intentionally guarantees: + +- No access before the inactivity delay expires. +- No reduction of Owner authority. +- No dependency on smart contracts. +- No dependency on off-chain services. +- No irreversible account state transitions. + +The mechanism therefore provides a protocol-level recovery and inheritance primitive while preserving TRON's existing security assumptions. + + # Security Considerations There is no shared material between the Owner Key and the Inheritance Key or their Seed Phrases From b75a522b8b13c9738bda751caa2a1f2c71c49e85 Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 18 Jun 2026 09:11:39 +0330 Subject: [PATCH 11/11] Update tip-XXXX.md --- tip-XXXX.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/tip-XXXX.md b/tip-XXXX.md index 16eca6f..fb03c08 100644 --- a/tip-XXXX.md +++ b/tip-XXXX.md @@ -41,8 +41,8 @@ Configuration, activation, deactivation, and replacement of the Inheritance Key Transactions executed through an active Inheritance Key remain subject to TRON's normal bandwidth, energy, and fee rules. Beyond inheritance scenarios, this mechanism can also function as a secure recovery path for account owners in situations such as loss of private keys, loss of seed phrases, cognitive impairment, long-term incapacity, or other events that prevent access to the primary account credentials. - - +___ +___ # Rationale Designing a native inheritance mechanism at the protocol level, rather than relying on smart contracts or off-chain solutions, is the result of a deliberate trade-off analysis between security, usability, decentralization, and prevention of irreversible asset loss. @@ -230,8 +230,8 @@ A distinction must be made between inheritance configuration and transaction exe · However, any transaction submitted through an active Inheritance Key consumes normal TRON resources, including bandwidth, energy, and applicable transaction fees, exactly as any other Active Permission transaction. This distinction is important: the inheritance mechanism itself introduces no additional operational cost, while all on-chain actions performed through the Inheritance Key continue to follow TRON's standard resource and fee model. - - +___ +___ # Motivation In current blockchain architectures, ownership and access to assets are entirely dependent on possession of a private key or Seed Phrase. @@ -258,8 +258,8 @@ Therefore, the network requires a native protocol-level solution that: . Prevents irreversible loss of assets . Avoids legal complexity, technical fragility, and poor user experience . Does not rely on smart contracts or trust in third parties - - +___ +___ # Specification ## Account Roles @@ -342,8 +342,8 @@ Once activated, the Inheritance Key is authorized to perform any operation permi · Change its own inheritance state, delay configuration, activation status, or replacement settings All inheritance-related configuration operations remain exclusively under the control of the Owner Key. - - +___ +___ # Threat Model Overview @@ -586,8 +586,8 @@ The security model intentionally guarantees: - No irreversible account state transitions. The mechanism therefore provides a protocol-level recovery and inheritance primitive while preserving TRON's existing security assumptions. - - +___ +___ # Security Considerations There is no shared material between the Owner Key and the Inheritance Key or their Seed Phrases