Repository navigation
Discussion: Native Account Inheritance for TRON Accounts #810
Description
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.
Activity
alichatme commentedon Dec 29, 2025
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:
Activation of the Inheritance Key never disables, replaces, or reduces the authority of the Owner Key.
The inheritance mechanism operates:
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:
Smart contracts can be hacked, and malicious upgrades can bypass inheritance logic.
Smart contracts cannot distinguish between true Owner Key inactivity versus simple non-use of a specific contract.
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?
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:
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:
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:
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:
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:
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:
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:
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:
This definition intentionally excludes:
Rationale for this strict definition:
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.
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.
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:
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.
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:
the associated digital assets become permanently and irreversibly inaccessible.
Existing solutions suffer from significant drawbacks:
Therefore, the network requires a native protocol-level solution that:
Specification
Account Roles
Every TRON account has an Owner Permission that:
This TIP introduces an additional key role:
Inheritance Key
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
2. Configured
3. Active
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 may at any time:
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:
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:
1. Assets Protected
The Inheritance Key mechanism protects the following assets:
2. Threat Actors and Capabilities
External Attacker
Capabilities:
Malicious Beneficiary
Capabilities:
Owner (Compromised or Incapacitated)
Capabilities:
Network-Level Adversary
Capabilities:
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
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
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
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
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
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
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
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
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:
5. Limitations
This mechanism does not protect against:
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:
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
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:
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:
Backwards Compatibility
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 commentedon Dec 30, 2025
Thank you for this innovative proposal. I have some questions regarding the technical implementation and security considerations:
Firstly, about the InheritanceKey Generation and Storage:
317787106 commentedon Dec 30, 2025
It sounds interesting. Could you open a standard issue instead of a PR so it’s easier to read and discuss?
alichatme commentedon Dec 30, 2025
@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 commentedon Dec 30, 2025
@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 commentedon Dec 31, 2025
@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:
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 commentedon Dec 31, 2025
@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 commentedon Dec 31, 2025
@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 commentedon Dec 31, 2025
@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 commentedon Dec 31, 2025
Here are some questions:
How does the time-based inheritance mechanism work in detail?
What are the use cases for this inheritance mechanism?
alichatme commentedon Dec 31, 2025
@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 commentedon Jan 1, 2026
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 commentedon Jan 1, 2026
@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 commentedon Jan 1, 2026
@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.
waynercheung commentedon Jan 2, 2026
@alichatme
Thank you for revising the proposal based on community feedback. It's great to see the iterative improvement process.
However, I cannot find the updated/revised TIP document you mentioned. Could you please:
Having the complete technical specification publicly available will allow all interested developers to:
Once the detailed specification is available, the community can provide much more comprehensive and constructive feedback.
Looking forward to reviewing the updated proposal!
25 remaining items
alichatme commentedon Jan 8, 2026
@yanghang8612
Thank you for your thoughtful and technically grounded feedback. We appreciate the architectural clarity of your comment and would like to address the core concern directly, strictly from a consensus and protocol-design perspective.
The necessity of a protocol-level solution here is not a matter of developer convenience or design preference, but a concrete technical reality:
“The last valid activity of the Owner key is a consensus fact, not a reliable application-level signal.”
Any solution implemented outside the protocol must inevitably:
Infer owner activity indirectly
Rely on indexers, logs, or off-chain assumptions
Or adopt an incomplete and subjective definition of “activity”
By contrast:
Only the protocol can unambiguously determine which signature was valid
Only the protocol knows which permission (Owner vs Active) was actually used
Only the protocol can define “Owner inactivity” in a fully consensus-safe manner
This is not a question of data accessibility, but of consensus scope.
Smart contracts intentionally execute in an isolated VM context and do not have access to the full, consensus-verifiable account activity history (e.g., votes, freezes, permission updates, governance actions).
If this predicate is not defined at the protocol level, any higher-layer solution will inevitably suffer from:
false positives,
bypass vectors,
or unverifiable off-chain assumptions.
No. This TIP:
Makes no economic decisions
Performs no asset distribution
Resolves no disputes or social policies
It defines a single, minimal consensus condition:
“If the Owner key has had no valid consensus-recognized activity for a specified period.”
Temporal conditions alone do not constitute business logic.
What turns logic into business logic is dependence on subjective interpretation or social governance, which is explicitly absent here.
Because no smart contract can deterministically and consensus-safely verify that:
The Owner key has or has not been active at the account level
Activity occurred outside the contract’s execution context
Permission updates, votes, or freezes took place
This limitation is not a flaw — it is a deliberate security property of the VM design.
As a result, any contract-based approach is necessarily:
incomplete,
overly permissive,
or dependent on off-chain trust assumptions.
This TIP is explicitly designed to eliminate that attack surface.
Because:
No new signature paths are introduced
No key gains authority beyond standard Active Permission
The Owner key always remains supreme and recoverable
No irreversible or locked state is created
In practice, this mechanism transforms an ambiguous and risky state (owner absence) into an explicit, bounded, and auditable consensus condition.
This proposal is:
Fully optional
Disabled by default
Backward-compatible with all existing accounts
Its maintenance cost is therefore comparable to existing consensus primitives, not to policy-heavy or socially governed mechanisms.
Final Summary
This TIP does not attempt to encode human, legal, or social judgments into consensus.
It introduces a minimal consensus primitive that:
Cannot be reliably defined outside the protocol
And without which all higher-layer solutions remain unsafe or incomplete
We believe this lies precisely at the boundary of what the protocol should define — no more, and no less.
We sincerely appreciate your analysis and welcome continued technical discussion.
yanghang8612 commentedon Jan 8, 2026
@alichatme
You’re still conflating “most authoritative place” with “necessary place.”
Yes — the protocol is the only layer that can perfectly observe Owner activity. That does not imply the protocol must expose that as a primitive.
Your argument reduces to: higher layers are imperfect, therefore consensus must absorb the policy.
That is exactly how protocols accumulate permanent complexity.
A few concrete points:
“Consensus fact” ≠ “consensus responsibility”
Many facts are consensus-visible (balances, votes, transfers, call traces).
We do not promote all of them into first-class protocol semantics. We deliberately keep consensus minimal and push interpretation upward.
Accuracy alone is not the criterion. Necessity is. You still haven’t shown a failure that actually breaks the system if this is not native.
Imperfect application logic is not a justification for protocol expansion
Oracles are imperfect. Governance is imperfect. Cross-chain bridges are imperfect.
We accept this and isolate the risk at the application layer instead of baking policies into consensus.
If “not perfectly safe” were sufficient to justify protocol changes, the protocol would never stop growing.
This is not “just a predicate” — it’s a state machine
You introduce:
new persistent account state,
time-dependent activation,
recovery semantics,
conflict handling,
and special-case validation paths.
That is behavioral logic, regardless of whether it moves assets or resolves disputes.
Optionality does not make protocol changes cheap
Every node must:
implement it,
validate it,
maintain it forever,
and reason about it during upgrades and forks.
Optional for users is not optional for the network.
The bar for protocol inclusion is higher than “this is safer”
It must be:
required for consensus safety, or
required to prevent systemic failure, or
required to preserve core invariants.
This proposal satisfies none of those. It improves a user-level recovery workflow.
That makes it a good candidate for wallets, contracts, or frameworks — not for consensus.
Until you can demonstrate that the network itself is unsafe or incomplete without this feature, the correct layer for it remains above the protocol.
alichatme commentedon Jan 22, 2026
@yanghang8612
Thank you sincerely for the architectural depth and clarity of this critique.
You are pointing precisely at the core boundary of this discussion: the difference between what the protocol can observe and what the protocol must be responsible for.
We will address that point directly.
If this mechanism is implemented above the protocol, there is no way to determine with consensus certainty:
whether the Owner has truly been inactive,
whether activity occurred outside the contract (vote, freeze, permission update, direct transfer),
whether a transaction was actually signed by the Owner Key or by another Active Permission.
Smart contracts, indexers, and off-chain logic simply do not have access to this level of consensus truth.
As a result, any higher-layer solution will inevitably suffer from one of the following:
false positives (incorrect activation),
false negatives (failure to activate when required),
reliance on off-chain assumptions.
This is not a quality limitation. It is a fundamental limitation in the ability to define the problem correctly outside the protocol layer.
This TIP does not decide where assets go, who the heir is, or resolve disputes.
It only introduces a single additional validation condition:
a time condition on when an existing Active Permission is considered valid by the signature verification logic.
Conceptually, this belongs to the same family as Owner/Active separation and multisig: defining under what conditions a signature is considered valid.
There is no economic, social, or interpretive decision being made.
Only a single consensus fact is evaluated:
whether any valid transaction signed by the Owner Key has occurred within a defined time window.
From a consensus perspective, this is no more “business logic” than nonce rules, basic timelocks, or expiration checks.
The presence of time does not make something application logic — interpretation does.
The necessity is here:
Without this primitive, no higher-layer solution can solve this problem safely without external assumptions.
That is precisely the bar that justifies inclusion at the protocol layer.
Not convenience. Not preference. Not philosophical purity.
But because:
outside the protocol, the problem cannot be defined correctly in the first place.
This proposal:
introduces no new signature path,
grants no new power to any key,
and only adds a conditional check inside existing signature validation.
Its maintenance and complexity profile remains at the level of existing permission primitives, not behavioral policy systems.
Conclusion
This is not a disagreement about architectural taste.
The real question is:
Does a problem exist whose correct and safe definition is impossible outside the protocol?
We argue that in this case, the answer is yes.
And for that reason, this capability sits exactly at the boundary of what the protocol must define — not above it, and not below it.
halibobo1205 commentedon Mar 17, 2026
Hi @alichatme, thanks for raising this discussion! To help move it forward more effectively, could you please update the issue description to follow the standard TIP format? You can refer to the template here: https://github.com/tronprotocol/tips/blob/master/template.md — covering sections like Abstract, Motivation, Specification, and Rationale will make it much easier for the community to review and provide structured feedback. Thanks!
alichatme commentedon Apr 19, 2026
@halibobo1205
Thank you for your time; I’m glad the proposal has received attention from you and the respected TRON community.
Unfortunately, due to being very busy, I haven’t been able to maintain a consistent presence on GitHub for a while.
At the earliest opportunity, I will implement the changes you require, according to the provided guide link.
I remain eager to hear your and the respected TRON community’s feedback.
waynercheung commentedon Apr 20, 2026
@alichatme Thanks for the update, and no worries about the delay — totally understandable.
Looking forward to seeing the revised proposal once you have time to align it with the TIP template and guidelines. Once the draft is in the standard format, it will be much easier for the community to review the design details (e.g., the inheritance key mechanism, activation timing, and account state transitions) and provide concrete feedback.
Feel free to ping here when the updated draft is ready — happy to take another look.
alichatme commentedon Apr 28, 2026
Dear @halibobo1205 and @waynercheung
Thank you very much for your attention and the time you dedicated to reviewing my proposal. Following your valuable suggestion and carefully reviewing the provided guidelines, I realized that the "Rationale" section was missing in the initial version of the proposal.
This section has now been added, and for easier access for the esteemed TRON community, the complete proposal is included below in the Issue page.
The purpose of adding this section is, as per your constructive feedback, to clarify the technical details of the proposal more thoroughly and to provide a proper platform for receiving more accurate and constructive feedback from the knowledgeable members and community of TRON.
Once again, I appreciate your review, attention, and the support from the TRON community, and I look forward to your feedback, suggestions, and any questions you might have.
Best regards
waynercheung commentedon May 21, 2026
@alichatme Thanks for updating the issue with the full draft and adding the Rationale section. This makes the proposal much easier to review.
After reading the latest version, I think the main remaining concern is implementation determinism. For a Core TIP, several parts still need to be specified more precisely:
last_owner_activity_timestampThe draft says it is updated by Owner-signed state-changing transactions, but this is still too broad. It would be better to provide an explicit transaction-type matrix showing which TRON contract types update the timestamp and which do not.
Please clarify whether execution failures with a valid Owner signature update the timestamp, for example contract revert, insufficient balance, OUT_OF_ENERGY, or other execution failures. These should be distinguished from validation failures such as invalid signatures.
The
Disabled / Configured / Activestates are useful, but the transitions need to be explicit. For example, if the Inheritance Key is already active and the Owner Key signs a valid transaction, does the timer reset and does the state return toConfigured? If Owner and Inheritance transactions appear in the same block, is normal transaction ordering the only rule?The "without additional gas or fee requirements" wording may need clarification. Activation may not require an extra transaction, but transactions submitted by the Inheritance Key should still consume normal bandwidth/energy/fees.
Overall, the rationale is clearer now. I think the next step is to make the specification deterministic enough for node implementation and consensus review.
alichatme commentedon May 22, 2026
Dear @wayne.zhang,
Thank you sincerely for your detailed and highly technical review.
Your questions are extremely valuable because they help move this proposal from conceptual rationale toward deterministic protocol specification.
Please allow me to address each point more precisely.
A transaction updates last_owner_activity_timestamp only if all of the following conditions are satisfied:
· The transaction is signed using the Owner Key,
· Signature validation succeeds,
· The transaction is accepted by protocol validation,
· And the transaction results in a successful on-chain state transition.
This definition intentionally excludes:
· Invalid signatures,
· Rejected transactions,
· Reverted execution,
· Or transactions that fail before state transition.
The purpose is to ensure that the timestamp reflects actual successful Owner activity recognized by consensus.
Therefore, the TIP document will include a deterministic matrix or set of examples of transaction types specifying which TRON contract types are eligible to update the timestamp.
Examples of eligible successful Owner activity include (but are not limited to):
· TRX transfers,
· TRC10 transfers,
· Voting operations,
· Freeze/unfreeze,
· Staking operations,
· Reward withdrawals,
· Permission updates,
· Smart contract calls that complete successfully and produce state changes.
Execution failures — even with a valid Owner signature — do NOT update last_owner_activity_timestamp.
This includes cases such as:
· Contract revert,
· OUT_OF_ENERGY,
· Insufficient balance,
· Failed VM execution,
· Or any execution path that does not commit a state transition.
These cases are intentionally distinguished from validation failures such as:
· Invalid signatures,
· Malformed transactions,
· Or protocol-level rejection.
Only successfully executed Owner-authorized transactions that produce committed state changes qualify as Owner activity.
The state model is intended to remain deterministic and minimal.
The Owner Key always remains the supreme authority of the account.
The Inheritance Key never disables, overrides, or restricts the Owner Key under any condition.
The proposed states are conceptually:
· Disabled
· Configured
· Active
Where:
Disabled = no inheritance configuration exists
Configured = inheritance configuration exists but the delay period has not expired
Active = the delay period has expired and the Inheritance Key is usable
If the Owner Key signs a valid successful transaction while the account is in the Configured state:
· The timestamp resets,
· And the account remains in Configured.
If the Inheritance Key has already become Active, subsequent valid Owner activity does NOT change or affect the timestamp, nor does it update the time, because the activation of the Inheritance Key occurs after the time delay has expired. Therefore, in the above scenario, the time delay has ended and the Inheritance Key is active. However, it should be noted that after the Inheritance Key is activated, the Owner Key being active or its activity does NOT deactivate the Inheritance Key.
However, the Owner, using the Owner Key, can disable or reconfigure the Inheritance Key at any time.
This design intentionally avoids automatic oscillating state behavior and preserves deterministic validation semantics.
If Owner and Inheritance transactions appear in the same block, standard deterministic transaction execution order applies.
The first transaction processed determines the final account state for subsequent transactions in that block.
No additional consensus rules beyond normal transaction execution ordering are required.
You are absolutely correct.
The proposal does NOT mean that transactions executed using the Inheritance Key are free.
Transactions submitted through the Inheritance Key continue to consume normal:
· Bandwidth,
· Energy,
· And transaction fees,
Exactly like standard Active Permission transactions.
The intended meaning is narrower:
Enabling,
Configuring,
Activating,
Disabling,
Or validating inheritance behavior
Does NOT require:
· Smart contracts,
· External services,
· Additional protocol transactions,
· Or any special gas or fee mechanisms.
The Inheritance Key behaves as a native protocol-level permission primitive, rather than a contract-based system.
Overall, I sincerely appreciate your review and technical rigor.
Your feedback is significantly helping to make the specification deterministic enough for node implementation and consensus-level evaluation.
Best regards,
Redchar1992 commentedon Jun 5, 2026
The use case is understandable, but this still feels like a proposal where determinism and safety need to be nailed down before the mechanism.
In particular, the draft should precisely define which owner actions reset inactivity, how native permissions/multi-sig interact with inheritance, how the inheritance key can be rotated or cancelled, and what happens if the owner is active through contracts rather than simple transfers. I would also consider whether this can be modeled as an extension of TRON's existing account permission system instead of a separate account-control path, since permissions already carry weights, thresholds, and operation scopes.
alichatme commentedon Jun 5, 2026
@Redchar1992
Thank you for these very precise and technical questions. This is exactly the kind of review that helps move this proposal from a concept toward an implementable specification.
Please find my responses to each of your points below.
Owner activity that resets the timer includes only successful, state-changing transactions signed exclusively by the Owner Key that cause a verifiable on-chain state change.
These explicitly include (but are not limited to):
· TRX, TRC10, and TRC20 transfers
· Voting and governance participation
· Freeze/unfreeze operations
· Stake/unstake and reward withdrawals
· Permission updates
· Smart contract calls that execute successfully and change state
Failed transactions (even with a valid Owner signature) and read‑only transactions do not reset the timer.
The Inheritance Key is designed as a time‑conditioned Active Permission. Therefore:
· If an account has multi‑signature enabled, multisig rules still apply to normal transactions. However, activation of the Inheritance Key is independent of multisig – the owner inactivity condition is checked regardless of multisig settings.
· The Inheritance Key can be considered an additional signer within a multisig configuration, but by default it is an Active key and can be placed in a multisig group.
· Owner Permissions always remain supreme. The Owner Key can disable, reconfigure, or replace the Inheritance Key at any time – even after it has become active.
The Inheritance Key can only be managed by the Owner Key.
In the TRON network, every account has by default one Inheritance Key in a disabled state. An owner cannot configure two Inheritance Keys for a single account – only one Inheritance Key exists per account (whether disabled, configured, or active).
This does not restrict the owner in any way:
· Rotation: At any time (whether the Inheritance Key is in the Configured or Active state), the owner can change its configuration, disable it, or replace it with a completely new key.
· Cancellation: The owner can simply disable the Inheritance Key (without setting a new key), even if it has already become active. In this case, no Inheritance Key exists for that account until the owner configures it again.
All these operations are performed via Owner Key signature, without additional gas or fees. No other key – whether Active or multi‑signature – can modify Inheritance Key settings except the Owner Key.
A smart contract by itself cannot update the timer unless:
A smart contract call that is signed by the Owner Key and results in an on‑chain state change does count as Owner activity and resets the timer – whether the call transfers tokens, modifies contract storage, or performs any other operation that changes the on‑chain state. However, this applies only if the transaction is signed by the Owner Key.
The only exceptions are read‑only calls (e.g., view/pure functions in Solidity) or transactions that fail with a VM exception – these do not reset the timer.
Yes, exactly. This proposal does not introduce a separate control path.
· Structurally, the Inheritance Key is a standard Active Permission / Active Key, which already exists and is supported by TRON accounts today.
· The difference lies in the protocol validation layer: a time condition is added to determine whether this Active Permission is currently valid.
· Weights, thresholds, and operation scopes from the existing permission system are fully applicable. You can configure the Inheritance Key with the same weight and operation scope as a regular Active Key.
Thus, instead of creating a new path, this proposal adds time‑condition capability to the existing permission system.
Conclusion
This proposal adds a native, minimal‑cost, time‑conditioned mechanism to TRON’s existing permission system – preserving security and determinism while enabling account recovery in cases of long owner inactivity.
Thank you again for your technical rigor. I look forward to your further questions and comments.
alichatme commentedon Jun 18, 2026
Thank you to everyone who participated in the discussion and provided technical feedback.
Based on the comments and review questions received so far, the proposal has undergone a substantial revision and clarification pass.
The updated draft now includes:
• A more deterministic definition of Owner activity and inactivity
• Explicit handling of failed, reverted, and validation-rejected transactions
• Clarified state transitions for the Inheritance Key lifecycle
• Clear integration with TRON's existing permission architecture
• Detailed specification of activation, reconfiguration, replacement, and deactivation behavior
• Clarified fee/resource semantics
• Expanded security analysis and threat modeling
Many of the questions raised in this discussion have now been incorporated directly into the specification to improve determinism, implementation clarity, and consensus safety.
Additional review and technical feedback are highly appreciated.
waynercheung commentedon Sep 8, 2026
I have been following this thread for a while, and I spent some time this week trying to map the draft onto java-tron's actual code paths, mostly to get a feel for what implementing it would involve. I want to share what I ran into, because it changed my own view of the proposal. Code references below are against
developat57b7b04.Up front: I think the underlying problem is real. Permanent asset loss from key loss, incapacity, or death is a genuine gap, and nothing below is meant to dismiss that. But when I tried to turn the draft into something I could implement, I got stuck in several places.
Identifying the inheritance permission.
AccountCapsule.updatePermissionsclears the active permission list and reassigns ids purely by list position (
setId(i + 2)), so everyAccountPermissionUpdaterenumbers them. I could not work out how an inheritance permission designated by id keeps a stable identity across a normal permission update. Related,AccountPermissionUpdateActuatorrejects
activesCount > 8, so I also do not know what is supposed to happen for an account already using all eight slots. A dedicated inheritance slot cannot rest on documentation convention alone; it needs normative state fields, a delay unit and range, an activation predicate, and an upgrade gate.What counts as Owner activity. The draft consistently says "Owner Key", but what exists at the protocol level is Owner Permission (
permission_id = 0), which may be a threshold multisig rather than one physical key. I could not tell which of the two the activation predicate is meant to read, and the answer changes the security model substantially.The timestamp predicate. Two answers in this thread contradict each other: the 2026-01-04 reply says execution failures with a valid Owner signature do update the timestamp; the 2026-05-22 reply says they do not. The current text follows the second.
I also do not think the stated justification is precise enough for implementation. At minimum, a REVERT or OUT_OF_ENERGY smart-contract transaction can still consume bandwidth and energy and, where applicable, charge TRX:
TransactionTrace.finalization()callspay()unconditionally, and bandwidth is consumed before execution. So "does not produce a committed state change" is not a sufficiently precise protocol predicate. I think Owner activity needs to be defined directly by contract type and final execution outcome, with consensus test vectors, plus an explicit boundary rule (>=) and timestamp source.Which state authorizes the inheritance permission. This is the part I found hardest to pin down. The draft says same-block transaction ordering resolves an Owner/inheritance race. In java-tron, signature verification is cached in
isVerified, incoming blocks are pre-validated in parallel against pre-block state before any transaction executes, and the existing selective invalidation mechanism is keyed onAccountPermissionUpdateContract(populated here for transactions thatisMultiSignTransactionmatches, which is onlyAccountPermissionUpdateContract; consumed here), alongside a wholesale clear on fork switch whose comment notes that a cached verification result is not trustworthy across a state change.This does not by itself establish a producer/peer split: incoming blocks are also normally pre-validated against pre-block state. The issue is instead that the TIP must explicitly define which state is normative for this authorization check. If inheritance eligibility is intended to follow sequential transaction execution, a cached signature result cannot be the sole enforcement point. The implementation would need to separate cached cryptographic verification from context-dependent authorization, and specify when the latter is recomputed for pending transactions, locally produced blocks, received blocks, and forks.
Relatedly, the post-activation security model still needs to be stated. A returning Owner and a holder of the inheritance key can race to submit transactions; deterministic ordering does not by itself prevent asset loss. Either specify a claim/challenge/revocation model, or analyze and accept that risk explicitly.
Seed independence. The Rationale treats independence of the two seed phrases as a security property, but the network can only validate public keys and permissions. It cannot prove two keys came from independent seeds. I think that belongs in wallet guidance rather than in the protocol guarantees, and the draft would be stronger for drawing that line and specifying the wallet/API/SDK behavior and migration requirements separately.
On the protocol-layer question. I understand the argument that a contract cannot observe Owner-key activity, and as stated that is true. But it seems load-bearing only because the design requires the liveness signal to be implicit. An explicit owner heartbeat makes the predicate observable to a contract, at a cost of roughly one transaction per delay period. I also do not think the "a contract cannot hold staked or voting positions" objection still applies: java-tron implements
FREEZEBALANCEV2,UNFREEZEBALANCEV2,WITHDRAWEXPIREUNFREEZE,VOTEWITNESSandWITHDRAWREWARD, gated by the corresponding VM proposals (VMConfig::allowTvmFreezeV2,VMConfig::allowTvmVoteinOperationRegistry), so a vault contract can stake, vote, and claim rewards where those are enabled. A contract approach also handles multiple heirs and split shares, which this draft cannot.I do not want to overstate this: the contract route has real costs too, since it moves assets into contract custody and puts a recurring obligation on the owner. But weighing that against a permanent consensus primitive, I personally cannot justify the trade on the current evidence. What would move me is a linked java-tron PoC with an executable state machine and a consensus test plan, rather than more specification prose.
One process note: I checked the diff of the latest commit on #811 hoping for new normative content, but the 2026-08-30 change converts bullet characters to markdown list syntax without altering the specification. The last substantive revision looks like 2026-06-18.
@alichatme, I am happy to review a revised draft or a PoC PR if you want to keep going, and I would genuinely like to be corrected on the code reading above if I have it wrong.
@halibobo1205 @317787106, you both asked earlier for this to follow the TIP template and to be structured for discussion in the issue. My own read is that the open questions are now design questions rather than formatting ones, and that the thread has gone about as far as it can without a revision. If others following this agree, I think it would be reasonable to close #810 and #811 as an incomplete Draft, with the discussion preserved so it can be resubmitted with a full consensus specification and a tested PoC or reference implementation.
alichatme commentedon Sep 12, 2026
I sincerely appreciate the time you took and the depth of your technical review of the java-tron code. This kind of feedback is exactly what helps a proposal mature, and we genuinely appreciate it.
I would like to clarify one important point:
Our proposal has undergone a comprehensive revision. The questions and answers you see in this thread served as the basis for that revision. Based on the feedback and criticisms received from the community and respected contributors, we revised the proposal and addressed the issues raised. In fact, your feedback has also been incorporated into this revision, and we welcome it. This revision is now complete.
Therefore, the current and authoritative reference is the proposal text itself — not the temporary and older responses in the Q&A thread. Those responses were provided at various stages of the discussion based on the understanding of the design at that moment, and may differ from the final version.
We need these Q&A exchanges as a record of the proposal's evolution and the transparency of its design process, and we take pride in them — because they show how our proposal was shaped and improved through constructive community feedback.
Please refer to the proposal text and use it as the basis for your review. The current text is the result of all revisions and corrections made.
Regarding your suggestion to close Issue #810 and PR #811:
This proposal has completed its revision process, and the current version is available. I would suggest keeping the discussion open so that the final version can be reviewed within the same thread.
I sincerely appreciate your collaboration and technical rigor.
waynercheung commentedon Sep 13, 2026
Thanks for the reply. I am happy to treat the proposal text at the current PR head as the authoritative reference, so let me be precise about which text and what it says.
Which text. The current
tip-XXXX.mdhead is637c1ad, dated 2026-08-30, before my 2026-09-08 review; the in-issue copy shows its last edit on the same day. I cannot identify a later substantive revision; the diff from the June 18 revision is formatting-only. If an authoritative revision exists elsewhere, please link the exact commit or comment and I will re-read against that.What the current text says on each point. My review was of that text, not of the earlier Q&A. Mapping each item to the current wording:
Inheritance slot identity: the text says "a dedicated Inheritance Key slot" and that it "reuses the existing Active Permission structure. No new PermissionType is introduced." It does not define a persistent state field, stable identity, configuration contract, migration rule, interaction with
AccountPermissionUpdaterenumbering, or the existing eight-Active-Permission limit.Owner activity: the text uses both "Owner Key" and "Owner Permission". It does not resolve whether activity means authorization through Owner Permission (
permission_id = 0, threshold met) or a transaction involving a particular physical key.Timestamp predicate: Rationale 11 defines activity as a transaction that "results in a committed on-chain state change" and excludes reverts on the basis that they produce none. That phrase still does not uniquely identify a consensus outcome on TRON: failed contract execution can still commit resource and fee accounting. There is no contract-type/result-code matrix, boundary rule, timestamp source, or test vectors.
Authorizing state and post-activation race: the text says that standard transaction ordering applies and that the first transaction determines subsequent account state. It does not specify whether authorization uses pre-block or sequential execution state, nor when context-dependent authorization is re-evaluated for pending transactions, locally produced blocks, received blocks, and forks. Deterministic ordering also does not by itself protect a returning Owner from an already-active Inheritance Key spending assets first.
Seed independence: the text presents independent seed material as a protocol security property. The network can validate public keys and permissions, but cannot validate how keys were derived; this belongs in wallet guidance rather than consensus guarantees.
The current draft also lacks protobuf/state definitions, a normative transition table, an upgrade/migration rule, a PoC, and a consensus test plan.
If any of these is already addressed in the current text, a link to the exact paragraph would let me correct my reading quickly. Otherwise, the useful next step is a substantive revision with an executable state machine and test vectors, ideally accompanied by a java-tron PoC. Note that the TIP template makes test cases mandatory for TIPs affecting consensus, independent of status.
On keeping the issue open. If a revision along those lines is planned, I have no objection to keeping this open while that work happens. You have also described the current text as complete and final; if that means no further revision is planned, then I would regard it as an incomplete Draft, notably because it lacks the consensus test cases that the template makes mandatory for consensus-affecting TIPs. I would leave it to the broader thread whether it should be closed with the discussion preserved for a future resubmission. Either way, it would help to say which of the two it is.
I will avoid repeating this review unless a revised draft or PoC lands, at which point I would be happy to review it.