Discussion: Native Account Inheritance for TRON Accounts

[alichatme]

This issue is opened to discuss a proposal for adding native, protocol-level account inheritance functionality to the TRON network.

The proposal introduces a time-based inheritance mechanism that allows an inactive account’s assets to remain accessible through a designated inheritance key, without smart contracts and without exposing private keys.

Related Pull Request: #811

Your contributions will help improve and further mature this proposal.

[alichatme]

---

TIP: XXXX
Title: Native Account Inheritance Mechanism
Authors: Ali (@alichatme)
Status: Draft
Type: Core
Category: Account
Created: 2025-12-29
Discussions-To: #810

Abstract

This TIP introduces a native, optional, protocol-level inheritance mechanism for TRON accounts.

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 relying on smart contracts

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

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.

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

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

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

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 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 Permission that:

· 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 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

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.

Note: Merely configuring the delay does not grant the Inheritance Key transaction authority until the Owner inactivity condition is fulfilled.

Inheritance Key States

The Inheritance Key can exist in one of the following three states:

1. Disabled

· No delay is configured
· The key is completely inactive at the protocol level

2. Configured

· 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

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

Behavior After Activation

· 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 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

The Inheritance Key functions as a time-conditioned Active Permission.

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.

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

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

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 security model is not natively implemented in any existing blockchain.

Transparency

Each transaction may include a non-sensitive signer role identifier:

signature_role: owner

signature_role: inheritance

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

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.

[waynercheung]

Thank you for this innovative proposal. I have some questions regarding the technical implementation and security considerations:

Firstly, about the InheritanceKey Generation and Storage:

• How is the inheritance key generated? Is it derived from the owner's seed phrase, or is it a completely independent key pair?
• What are the recommended best practices for securely storing the inheritance key? Should it be stored separately from the owner key?
• Can the inheritance key be generated offline (cold storage scenario)?

[317787106]

It sounds interesting. Could you open a standard issue instead of a PR so it’s easier to read and discuss?

[alichatme]

@317787106
Thank you for the suggestion.
A standard Issue has already been opened for this topic to make reading and discussion more focused and accessible.

The Pull Request is created solely as the formal submission path in accordance with the TIP process. The proposal text is included there so that, if feedback is received from the community, we can iteratively refine and improve the proposal.

I would be happy to continue the discussion and receive your feedback in the Issue thread.

[alichatme]

@waynercheung
Thank you for your thoughtful and well-considered questions — they touch on one of the most important aspects of TRON’s security and key management model.
To clarify TRON’s key architecture:
Only the Owner Key exists at account creation.
Active keys are not created by default.
Defining an Active Permission (including any key used for inheritance) is a fully optional capability and can only be created or modified with a valid Owner Key signature. In this proposal, the Inheritance Key is defined as an Active Permission with protocol-enforced limitations.
From a protocol perspective, TRON does not impose any constraints on how Active keys are generated or stored. An Active Key may:

be derived from a seed phrase,

be generated as a completely independent key pair,

or be generated and stored offline (cold storage),

and there is no distinction between these approaches at the consensus or protocol level.
That said, from a security best-practice standpoint, we recommend generating the Inheritance Key as a fully independent Active Key, such that:

it shares no seed phrase or derivation path with the Owner Key,

it is preferably generated offline,

and it is stored separately from the Owner Key.

This approach minimizes shared failure domains, meaning that compromise of one key does not endanger the other, and aligns well with common threat models for long-term asset protection.
Importantly, this proposal intentionally does not mandate any specific key-generation or storage method. Since TRON securely supports all of these models and no protocol-level security issues have been identified for such scenarios, the Inheritance Key design remains flexible. This flexibility allows wallets, tools, and users to choose approaches aligned with their own threat models, while keeping the protocol itself neutral, simple, and forward-looking — as unnecessary constraints can hinder innovation and adaptability.

[waynercheung]

@alichatme
Thank you for the detailed clarification on TRON's key architecture and the flexibility of this design.

Your explanation makes it clear that the Inheritance Key is implemented as an optional Active Permission with protocol-enforced restrictions, which maintains backward compatibility while adding powerful functionality.

I'd like to better understand the protocol-enforced restrictions aspect:

Question: What specific restrictions will be enforced at the protocol level for the Inheritance Key?

Specifically:

• What operations will the Inheritance Key be allowed to perform? (e.g., transfer TRX, TRC20 tokens, NFTs, voting, staking?)
• What operations will be explicitly prohibited? (e.g., modifying the owner key, changing the inheritance configuration itself, creating new permissions?)
• Are these restrictions hardcoded in the protocol, or can the owner customize the permission scope when setting up the inheritance key?

Understanding the permission boundaries will help evaluate the security model and potential attack vectors.
And looking forward to seeing the detailed TIP draft!

Thank you!

[alichatme]

@waynercheung
Thank you for your precise, technical, and very constructive questions. Clarifying the access boundaries of the Inheritance Key is indeed one of the core goals of this design.

In this proposal, the Inheritance Key is defined as a time-conditioned Active Permission, but with strict limitations that are enforced directly at the protocol and consensus validation level — not at the wallet, UI, or smart contract layer.

Allowed operations for the Inheritance Key

Once the inactivity time condition of the owner is met, the Inheritance Key is allowed to perform all operational actions available to a standard Active Permission, including (but not limited to):

Transferring TRX

Transferring TRC10 and TRC20 tokens

Interacting with NFTs

Freezing and unfreezing resources

Staking and claiming rewards

Voting and participating in governance

Directly invoking smart contracts

In general, any operation that a normal Active Key is permitted to perform and that results in a verifiable state change at the account or network level.

The purpose of this access level is to ensure full usability of assets without requiring any involvement from the Owner Key.

Explicitly prohibited operations

The Inheritance Key is protocol-level and non-bypassably restricted (within the rules of network consensus and validation) from performing the following actions:

Modifying or replacing the Owner Key

Changing the account’s permission structure

Creating, deleting, or editing permissions

Modifying inheritance settings (including resetting the time condition, changing the inheritance key, or disabling inheritance)

Any administrative operation that requires Owner Permission

In simple terms, the Inheritance Key has no governance or administrative authority over the account and remains a strictly limited operational key.

These restrictions ensure that the Inheritance Key can never obtain ultimate control of the account — either before or after activation.

Enforcement model

These restrictions are:

Hardcoded in the protocol validation logic

Independent of wallet implementations, user interfaces, or smart contracts

Not customizable, expandable, or reducible by the account owner

This design choice is intentional in order to minimize the attack surface, keep the behavior of the Inheritance Key fully analyzable and auditable by all nodes, prevent dangerous or unintended user misconfigurations, and ensure uniform, predictable, and transparent behavior across the network.

As a result, the Inheritance Key is deliberately designed with a constrained, explicit, and non-customizable scope to preserve Owner Key security and full compatibility with TRON’s existing permission architecture.

At the same time, the owner can always use the Owner Key to update, replace, or fully disable the inheritance configuration at any point.

Thank you again for your valuable feedback and insightful technical questions. I’d be happy to continue this discussion and go deeper into technical details if helpful.

[lxcmyf]

@alichatme
How does the inheritance key differ from the existing Active permissions in the protocol layer?
Is it a new permission type or a restricted subset of Active permissions?
Will a new PermissionType be introduced?

[alichatme]

@lxcmyf
Thank you for the precise, well-placed, and highly technical question. This goes directly to the core design rationale of the proposal and helps clarify its architectural boundaries.
In this design, the Inheritance Key is not a new PermissionType, and no new PermissionType is introduced to the protocol. Instead, the Inheritance Key is implemented as an existing standard Active Permission, whose validity and behavior are defined by a time-based condition and a set of protocol-enforced restrictions.
More specifically:
From a data structure and permission architecture perspective, the Inheritance Key fully reuses the existing Active Permission
No new PermissionType is added
No breaking change is introduced to TRON’s current permission model
The key difference lies in the validation logic, not in the permission type itself.
Under this proposal:
A specific Active Permission is designated as the “Inheritance Key”
Until the owner inactivity condition is satisfied, this permission is considered inactive at the protocol validation layer
Once the time condition is met, the same Active Permission becomes valid, but with strict, non-bypassable protocol-level restrictions
These restrictions permanently prohibit any Owner-level operations, including modification of the Owner Key, changes to the permission structure, or alteration of inheritance configuration.
Therefore, the Inheritance Key can be accurately described as:
A behavioral subset of Active Permission
Not a new permission type
And not a user-customizable permission class
This approach is intentionally chosen to:
Preserve full compatibility with TRON’s existing permission architecture
Avoid introducing new PermissionTypes or protocol migrations
Keep implementation simple, analyzable, and auditable
Allow existing wallets and tooling to support the feature without fundamental changes
As a result, the inheritance mechanism is implemented by adding time-conditioned validation logic, rather than defining a new PermissionType at the protocol level.

[halibobo1205]

Here are some questions:

1. How does the time-based inheritance mechanism work in detail?

   • What are the conditions under which an account is considered "inactive," and how is inactivity determined?

2. What are the use cases for this inheritance mechanism?

• What types of accounts or user groups is this feature primarily intended for?
• In what scenarios would users choose to use this time-based inheritance mechanism instead of the existing Active permissions?

[alichatme]

@halibobo1205
Thank you for your precise and practical questions. They directly address the core design principles of the time-based inheritance mechanism and its security model.
How the Time-Based Inheritance Mechanism Works
In this proposal, an Inheritance Key is defined as a time-conditioned Active Permission that becomes valid only after a specific protocol-level condition is met. This condition is the cryptographic inactivity of the Owner Key for a preconfigured duration (inheritance_delay).
At the protocol layer, a native account field is introduced (conceptually equivalent to last_owner_activity_timestamp). This field must be updated only when:
A valid on-chain transaction
Is signed by the Owner Key
And results in a verifiable state change
Receiving assets or any event that does not involve an Owner Key signature does not update this timestamp.
When the elapsed time between the current network time and the last recorded Owner Key activity exceeds the configured inheritance_delay, the Inheritance Key is considered valid during transaction signature validation at the protocol level.
Conditions for Considering an Account “Inactive”
Account inactivity is defined exclusively by the absence of cryptographic activity from the Owner Key. No off-chain signals, subjective judgments, or external processes are involved. This design ensures that:
The decision is fully objective, deterministic, and verifiable
No reliance on legal, social, or off-chain institutions is required
Network consensus remains the sole authority for status determination
Use Cases and Target Users
This feature is designed for a broad range of users, including:
Regular users seeking long-term protection of digital assets
Individuals concerned about loss of access due to illness, aging, or unforeseen events
Long-term holders who want a native, decentralized mechanism to manage access risk
Difference from Existing Active Permissions
While existing Active Permissions require continuous manual management and explicit owner decisions, the time-based inheritance mechanism operates automatically based on inactivity. It is intended as a complementary safeguard, not a replacement for existing permission models.
Additional Security Scenario: Seed Phrase Exposure
Beyond inheritance and owner incapacity, this mechanism provides an additional security benefit.
If a private key or seed phrase associated with the Inheritance Key is exposed, the key remains protocol-level inactive until the inactivity condition is satisfied. During this period, the exposed key has no operational capability.
This protocol-enforced delay gives the legitimate owner time to:
Transfer assets to a new account with a different seed, or
Disable or replace the Inheritance Key using the Owner Key
This effectively introduces a native delayed-security layer that prevents immediate asset theft, without relying on smart contracts or off-chain services.
To the best of my knowledge, a security model based on cryptographic inactivity combined with protocol-enforced time delay has not yet been widely implemented natively at the consensus layer in public blockchains, and could represent a meaningful innovation for the TRON network.
Thank you again for your thoughtful questions. I would be glad to continue the discussion and explore further technical details.

[alichatme]

We would like to express our sincere appreciation to the TRON community and all contributors who participated in the Q&A process with precise, thoughtful, and technically sound questions.
Your feedback encouraged us to revisit the proposal with greater care and clarity, resulting in a more thoroughly reviewed and refined document in which the roles and responsibilities of the network, wallets, and users are explicitly and clearly defined, and the technical, security, and execution aspects of the design are presented in a transparent and structured manner.
Accordingly, a revised version of the proposal has been prepared with the goal of improving clarity, reducing ambiguity, and facilitating comprehensive technical review.
We kindly invite all community members to re-examine the updated proposal and share any remaining questions, concerns, or technical considerations that may not have been previously addressed, so that together we can further evolve this concept into a mature, well-defined, and implementation-ready design for the network.
We sincerely thank everyone in advance for their constructive collaboration, expert insights, and valuable feedback.
All comments and suggestions are warmly welcomed and highly appreciated.
With sincere thanks

[alichatme]

@waynercheung
Thank you for your thoughtful and technical question — it touches on an important architectural distinction.

In the revised proposal, the Inheritance Key is not introduced as a new permission type, nor does it add a new PermissionType at the protocol level.

Instead, it is explicitly designed as a restricted and time-conditioned form of an existing Active Permission, fully aligned with TRON’s current permission architecture.

More specifically:
The protocol continues to recognize the same existing permission categories (Owner / Active).

The Inheritance Key is a designated Active Permission that is subject to additional protocol-level validation logic based on owner inactivity and a predefined delay.

Until the inactivity condition is satisfied, this permission is considered inactive during transaction validation.

Once activated, it behaves like a standard Active Permission within a strictly limited and non-configurable operational scope, as defined by the protocol.

No new PermissionType is introduced, and no changes are made to the fundamental permission model.

This approach was chosen deliberately to:

Preserve full backward compatibility

Avoid expanding the permission surface area

Minimize protocol complexity and attack vectors

Ensure consistent and predictable behavior across all nodes

The updated proposal now clearly documents this distinction and the rationale behind reusing Active Permission semantics rather than introducing a new permission class.

We kindly invite you to review the revised version of the proposal, where these architectural decisions are described in more detail.
If any questions, edge cases, or implementation concerns remain after reviewing the updated draft, we would be very happy to continue the discussion.

Thank you again for your constructive engagement and valuable input.

[alichatme]

@bretk1989
Thank you very much for your thoughtful participation and for raising precise and insightful technical questions.

Following the community feedback received during the discussion, the proposal has undergone a comprehensive revision to improve clarity and structure. Many of the points raised have now been addressed more explicitly in the updated version, with clearer definitions of the mechanism, scope, and intended use cases.

We kindly invite you to review the revised proposal and, if you have any remaining questions, concerns, or additional technical considerations, to continue the discussion by sharing them directly in the same Issue. This helps ensure that the conversation remains transparent, structured, and accessible to the entire community.

We sincerely appreciate your constructive engagement and valuable input, and we look forward to continuing the discussion.