Proposal: Enable TIP-6780 SELFDESTRUCT only in same transaction

[yanghang8612]

Simple Summary

This proposal aims to activate TIP-6780 on TRON mainnet.

TIP-6780 has already been implemented in GreatVoyage-v4.8.1(Democritus). Once this proposal is approved and takes effect, the updated SELFDESTRUCT instruction will be enabled at the protocol level.

Motivation

SELFDESTRUCT has already been deprecated in TRON through TIP-652, which formally signaled that its semantics could be further restricted in future TVM upgrades. TIP-6780 is the next step in that direction.

Ethereum introduced EIP-6780 in the Cancun upgrade, changing the behavior of the SELFDESTRUCT opcode. As an EVM-compatible public chain, TRON should activate the corresponding behavior in TVM to maintain compatibility with Ethereum and reduce semantic divergence across ecosystems.

TIP-6780 has already been included in GreatVoyage-v4.8.1(Democritus). This proposal is intended to complete the governance process required to enable this feature on-chain.

Activating this TIP will provide a more consistent execution model for developers, improve compatibility for contracts and tooling migrating across ecosystems, and encourage the ecosystem to move away from patterns that depend on full contract deletion.

How to Initialize the Voting Request

This is the command of initiating the voting request:

• createProposal 94 1

The proposal number refers to:

• Proposal 94: Activate TIP-6780: SELFDESTRUCT only in same transaction

Timeline

The estimated timeline:

• Creation time of the voting request: 7th April 2026
• The effective time of voting request: 10th April 2026

Rationale

This proposal aligns TRON with the direction already taken by Ethereum and with TRON’s own previous deprecation path for SELFDESTRUCT. The main rationale is to preserve common fund-withdrawal and same-transaction initialization patterns, while removing the long-term dependency on full account deletion semantics.

According to TRON’s published on-chain analysis, ecosystem impact is expected to be limited:

• The number of contracts containing the SELFDESTRUCT opcode is very low, and the number of such contracts holding assets is even lower.
• None of those contracts were observed to have executed an actual SELFDESTRUCT transaction for the analyzed set.
• In 2025 data (up to October 17), there were 957,324 internal transactions involving SELFDESTRUCT, and 957,316 of them (99.999%) followed the pattern where the contract was created and self-destructed within the same transaction.
• The remaining 8 transactions were also self-destructed on the same day they were created, and those addresses were never reactivated or reused afterwards.

These observations suggest that the dominant existing usage pattern will remain unaffected after activation, while legacy patterns that rely on delayed destruction or address reuse are already rare in practice.

Technical Specs

After Proposal 94 takes effect, the behavior of SELFDESTRUCT will be updated as follows.

1. Contracts not created in the same transaction

If SELFDESTRUCT is executed in a transaction that is not the same transaction in which the contract was created:

• The current execution frame halts immediately.
• SELFDESTRUCT does not delete contract code, storage, or the account itself.
• The entire account assets (TRX, Staked TRX, TRC10) are transferred to the target address.
• If the target address is the contract itself, the assets are not burned and there is no net balance change.

2. Contracts created in the same transaction

If SELFDESTRUCT is executed in the same transaction in which the contract was created:

• SELFDESTRUCT continues to behave as before.
• The current execution frame halts immediately.
• All account data is deleted.
• The entire account assets are transferred to the target address.
• The account balance of the contract calling SELFDESTRUCT is set to 0.
• If the target address is the contract itself, the assets are burned.

As defined in the TIP, a contract is considered created at the beginning of a create transaction or when a CREATE-series operation begins execution (including CREATE, CREATE2, and future deployment operations). If a balance already exists at the new address, it is still considered a contract creation.

Note (TRON vs Ethereum): Ethereum often uses the presence of balance as a practical signal that an address already exists in state. TRON’s account model differs: accounts can be activated via multiple mechanisms and may exist with zero balance. This clause is kept to mirror EIP-6780 wording and does not change TRON’s account-activation rules; contract creation is determined by whether the contract is successfully created via CREATE/CREATE2 (or equivalent) in the same transaction.

3. Energy Cost Adjustment

• The fixed Energy cost of the SELFDESTRUCT opcode is adjusted from 0 to 5000. This increases execution cost and further discourages misuse.

4. Impact on Existing Contracts

• Contracts that rely on re-deploying to the same address through CREATE2 after SELFDESTRUCT will no longer work as before, unless the destruction happens in the same transaction as creation.
• Patterns that rely on SELFDESTRUCT to destroy an account for security or lifecycle management are no longer reliable.
• Applications that rely on burning assets by calling SELFDESTRUCT with the contract itself as beneficiary will no longer behave the same way, except in the same-transaction creation case.

5. Guidance for Developers

Although TIP-6780 preserves certain legacy behaviors in limited scenarios, SELFDESTRUCT remains deprecated as specified in TIP-652. Its use in newly deployed contracts is strongly discouraged, and future TVM upgrades may further reduce its functionality. Developers are encouraged to adopt safer and more maintainable patterns for contract lifecycle management.

[laurenceja]

Agree. Essential for long-term state management. It simplifies the node's storage logic and prepares the TRON network for future scalability optimizations.

[lxcmyf]

Any recommended safer alternatives to SELFDESTRUCT under this new rule?

[aiden3885]

Any recommended safer alternatives to SELFDESTRUCT under this new rule?

Since SELFDESTRUCT can no longer be relied upon for cleaning up contracts in most scenarios, here are the recommended safer alternatives and design patterns:

1. Explicit "Disable" or "Pause" Mechanisms (Recommended)

Instead of trying to delete the contract, simply render it unusable.

How it works: Implement a boolean flag (e.g., isPaused or isActive) in your contract storage. Modify all critical functions to check this flag using a modifier (e.g., require(isActive, "Contract disabled")).

Benefit: This effectively "kills" the contract's functionality without needing to alter the blockchain state drastically. It is safer because it doesn't rely on opcodes with changing semantics and allows for potential re-activation if governance requires it.

Code Pattern:

bool public active = true;
address public owner;

modifier onlyWhenActive() {
    require(active, "Contract is disabled");
    _;
}

function disableContract() external onlyOwner {
    active = false;
    // Optional: Transfer remaining funds here
}

function criticalFunction() external onlyWhenActive {
    // Logic here
}

2. Fund Migration and Abandonment

If the goal is to retrieve funds and stop using the contract:

How it works: Create a function that allows the owner to withdraw all remaining trx/tokens to a designated address. Once funds are drained, the contract is left dormant on the chain.

Benefit: This ensures no value is locked. The contract code remains on-chain (which is immutable anyway), but since it holds no value and has no active logic (if combined with pattern #1), it is harmless.

3. Proxy Patterns with Upgradability

For complex systems where "destruction" was meant to signify an upgrade or migration:

How it works: Use the Proxy pattern. Instead of destroying the old implementation contract, you simply point the proxy to a new implementation address.

Benefit: The old implementation contract remains on-chain but is no longer called by users interacting with the proxy. This is the standard industry practice for managing contract lifecycles.

[aiden3885]

Analysis of Contracts Containing the SELFDESTRUCT Opcode

Contract Categary	Count
Total Contracts	5709
Contracts With Assets > $10	531
Contracts With Assets > $100	286
Contracts With Assets > $1000	98
Contracts With Assets > $10000	12
Contracts With Assets > $100000	3
Contracts With Assets > $1000000	1

As shown in the table, the number of contracts containing the SELFDESTRUCT opcode is very low, and the number of such contracts holding assets is even lower. Furthermore, none of these contracts have executed an actual SELFDESTRUCT transaction. The opcode is generally included as a mechanism to transfer assets out of the contract, a functionality that will remain unaffected after this proposal is implemented.

[aiden3885]

Analysis of SELFDESTRUCT Transactions

An analysis of data from 2025 (up to October 17) reveals 957,324 internal transactions involving SELFDESTRUCT. The overwhelming majority — 957,316 (99.999%) — followed an identical pattern: the contract was created and self-destructed within the same transaction. This specific use case will not be affected after this proposal is implemented.

The remaining 8 transactions show a similar pattern: the contracts were also self-destructed on the same day they were created, and these addresses were never reactivated or reused after destruction.
A historical analysis of all SELFDESTRUCT transactions confirms that addresses that have self-destructed were never re-created afterwards.

[lily309]

Analysis of Contracts Containing the SELFDESTRUCT Opcode
...

Analysis of SELFDESTRUCT Transactions
...

This is an exceptionally thorough analysis, examining both the bytecode of contracts already deployed on-chain from a static perspective and transactions that historically included suicide instruction execution.

Based on these two analyses, the impact of this proposal's changes on the TRON on-chain ecosystem is negligible. I support proceeding with this proposal.

[lily309]

Additionally, for deployed contracts that rely on the SELFDESTRUCT to implement "Disable" or "Pause" mechanisms, are there any recommended approaches?

[yanghang8612]

Additionally, for deployed contracts that rely on the SELFDESTRUCT to implement "Disable" or "Pause" mechanisms, are there any recommended approaches?

To my knowledge, for contracts that have already been deployed, unless the contract is upgradeable, the ability to “Disable” or “Pause” it will be lost once this proposal takes effect.

[TonyStank911]

Why change the fixed Energy cost from 0 to 5000? That feels like it could surprise someone.

[lily309]

@yanghang8612 That makes sense. For already deployed, non-upgradeable contracts that currently “pause/disable” by calling SELFDESTRUCT (especially as an emergency kill-switch), what’s the recommended operational mitigation after TIP-6780 is active?
Do we have any best-practice guidance like: (1) frontends/indexers should treat the contract as disabled via a registry/denylist, (2) encourage users to revoke approvals / migrate funds before the effective time, or (3) publish a public advisory / checklist for projects that used this pattern?

[yanghang8612]

Why change the fixed Energy cost from 0 to 5000? That feels like it could surprise someone.

@TonyStank911 Two reasons: (1) it nudges people away from relying on SELFDESTRUCT long-term, which TRON already marked as deprecated; (2) it matches the “modern EVM” direction where state deletion isn’t treated as a cheap/normal flow. In practice, contracts that still use it tend to use it rarely, so the cost bump should be pretty contained.

[yanghang8612]

... what’s the recommended operational mitigation after TIP-6780 is active?

@lily309 Good question — once TIP-6780 is active, SELFDESTRUCT won’t reliably “brick” a contract outside the same-tx creation case, so a non-upgradeable kill-switch implemented via SELFDESTRUCT is effectively gone.

For mitigation, the realistic options are mostly off-chain coordination and user-level hygiene: projects can (a) publish an announcement and migration plan before the effective time, (b) update frontends to block new interactions and guide users to withdraw/migrate, (c) recommend users revoke allowances/permissions where relevant, and (d) optionally coordinate with major infra (explorers/indexers/wallet UIs) to display warnings.

On-chain, unless there is an existing access-controlled “pause flag” or upgrade path, there isn’t a generic way to retrofit a hard-disable mechanism into immutable code — the safest approach is to migrate users/funds to a new contract and deprecate the old one operationally.

[halibobo1205]

I'd like to raise a question about the actual motivation for TRON to adopt TIP-6780.

From what I understand, the primary driver behind EIP-6780 on Ethereum was to pave the way for the Verkle Tree migration — a fundamental change to Ethereum's state storage architecture. SELFDESTRUCT's ability to delete arbitrary contract state in a single transaction is fundamentally incompatible with how Verkle Trees handle state updates at the block level.

However, TRON does not appear to have a Verkle Tree migration on its roadmap. If that's the case, the core technical pressure that motivated EIP-6780 simply doesn't apply here.

The stated rationale in this proposal is essentially "Ethereum did it, so we follow" — to reduce semantic divergence and maintain EVM compatibility. That's a legitimate goal, but it comes with real costs:

• Already-deployed, non-upgradeable contracts that use SELFDESTRUCT as a kill-switch will permanently lose that capability with no migration path.
• The Energy cost increase from 0 to 5000 is a breaking change for any contract that budgets Energy around the current cost.
• The on-chain data presented here actually shows that problematic usage of SELFDESTRUCT on TRON is virtually nonexistent — 99.999% of cases are same-transaction destructions, which remain unaffected.

So the question I'd like to put to the authors is:

If TRON doesn't face the same architectural constraints as Ethereum, are we accepting concrete, irreversible breaking changes in exchange for a compatibility benefit that primarily serves cross-chain developers — rather than addressing any real risk within the TRON ecosystem itself?

And a follow-up: the Energy adjustment from 0 to 5000 doesn't appear to be a strict requirement of EIP-6780 compatibility — it seems like an independent policy decision. What is the specific justification for bundling it into this proposal?

[lily309]

... what’s the recommended operational mitigation after TIP-6780 is active?

@lily309 Good question — once TIP-6780 is active, SELFDESTRUCT won’t reliably “brick” a contract outside the same-tx creation case, so a non-upgradeable kill-switch implemented via SELFDESTRUCT is effectively gone.

For mitigation, the realistic options are mostly off-chain coordination and user-level hygiene: projects can (a) publish an announcement and migration plan before the effective time, (b) update frontends to block new interactions and guide users to withdraw/migrate, (c) recommend users revoke allowances/permissions where relevant, and (d) optionally coordinate with major infra (explorers/indexers/wallet UIs) to display warnings.

On-chain, unless there is an existing access-controlled “pause flag” or upgrade path, there isn’t a generic way to retrofit a hard-disable mechanism into immutable code — the safest approach is to migrate users/funds to a new contract and deprecate the old one operationally.

Got it — so for immutable contracts this basically becomes an operational deprecation problem rather than an on-chain “kill switch” problem. Thanks alot. @yanghang8612

[aiden3885]

I'd like to raise a question about the actual motivation for TRON to adopt TIP-6780.

From what I understand, the primary driver behind EIP-6780 on Ethereum was to pave the way for the Verkle Tree migration — a fundamental change to Ethereum's state storage architecture. SELFDESTRUCT's ability to delete arbitrary contract state in a single transaction is fundamentally incompatible with how Verkle Trees handle state updates at the block level.

However, TRON does not appear to have a Verkle Tree migration on its roadmap. If that's the case, the core technical pressure that motivated EIP-6780 simply doesn't apply here.

The stated rationale in this proposal is essentially "Ethereum did it, so we follow" — to reduce semantic divergence and maintain EVM compatibility. That's a legitimate goal, but it comes with real costs:

• Already-deployed, non-upgradeable contracts that use SELFDESTRUCT as a kill-switch will permanently lose that capability with no migration path.
• The Energy cost increase from 0 to 5000 is a breaking change for any contract that budgets Energy around the current cost.
• The on-chain data presented here actually shows that problematic usage of SELFDESTRUCT on TRON is virtually nonexistent — 99.999% of cases are same-transaction destructions, which remain unaffected.

So the question I'd like to put to the authors is:

If TRON doesn't face the same architectural constraints as Ethereum, are we accepting concrete, irreversible breaking changes in exchange for a compatibility benefit that primarily serves cross-chain developers — rather than addressing any real risk within the TRON ecosystem itself?

And a follow-up: the Energy adjustment from 0 to 5000 doesn't appear to be a strict requirement of EIP-6780 compatibility — it seems like an independent policy decision. What is the specific justification for bundling it into this proposal?

Your analysis of the technical situation is highly perceptive. You have correctly identified that the primary architectural driver for Ethereum's EIP-6780 (the Verkle Tree migration) does not apply to TRON. However, the decision to adopt TIP-6780 is driven by a different set of strategic priorities: security, institutional adoption, and developer experience, rather than state storage architecture.
Here is a breakdown of the motivations behind TIP-6780, addressing your specific questions.

Motivation Beyond Verkle Trees: Security and Institutional Appeal

While TRON does not face the Verkle Tree constraint, the change is far from a simple case of "Ethereum did it, so we follow." The primary motivation is to address a well-known security vulnerability.

The SELFDESTRUCT function has historically been one of the most error-prone functions in smart contracts, often acting as a backdoor for malicious closures or accidental logic errors. By limiting its functionality, TRON is making a "security-first" decision to establish a higher security baseline for its network.

This is a strategic move to make the platform more attractive for enterprise-grade applications and high-value dApps. For institutional capital and Real-World Asset (RWA) tokenization to move on-chain, a predictable and secure smart contract environment is a prerequisite. By removing the unpredictable nature of SELFDESTRUCT, TRON is building the "architectural concrete" needed to become a reliable settlement layer for tens of billions of dollars in assets.

Balancing Compatibility with Ecosystem Health

You are right to question the trade-off. The network is accepting a breaking change for a small number of legacy contracts to gain a significant advantage in another area.

The benefit of this compatibility is not just for cross-chain developers; it's about unifying the developer security model. A fragmented security landscape, where a contract behaves differently on TRON than on Ethereum, is a systemic risk for a network that handles a high volume of liquidity. By aligning with Ethereum's standard, TRON reduces this friction, allowing developers to use familiar tools and security assumptions. This accelerates dApp deployment and reduces integration problems, which is crucial for ecosystem growth.

The on-chain data you mentioned, showing that problematic SELFDESTRUCT usage is rare, was a key factor in the decision. It indicates that the upgrade's negative impact on existing contracts and user assets would be minimal, making the security and compatibility benefits a worthwhile trade-off.

Justification for the Energy Cost Increase

The adjustment of the Energy cost from 0 to 5000 is indeed an independent policy decision bundled with the proposal, not a strict requirement of EIP-6780 compatibility.

The justification for this change is to prevent abuse and mitigate potential Denial-of-Service (DoS) attack risks. When an operation has zero cost, it can be exploited to spam the network or execute malicious logic without any economic disincentive. By introducing a fixed cost, the network adds a layer of protection against such abuse, further enhancing the stability and security of the TRON network.