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

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.

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.