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.

A full TIP draft will be submitted following initial discussion.

[alichatme]

Related Pull Request: #811

Feedback and review from the community and maintainers are welcome and greatly appreciated.
Your contributions will help improve and further mature this proposal.

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