tvm

A new discussion has been opened in the @trondao developer community about enabling TIP-6780, which updates how the SELFDESTRUCT opcode works in the TRON Virtual Machine (TVM).

This change is designed to align TRON’s behavior with Ethereum’s EIP-6780, improving compatibility between ecosystems and preparing developers for future TVM upgrades.

The feature is already implemented in GreatVoyage-v4.8.1 (Democritus). Once governance approves the proposal, it will become active at the protocol level on TRON mainnet.

👇 Here is what the update introduces

➠• Contract deletion will only be allowed in the same transaction where the contract is created

If a contract calls SELFDESTRUCT in a later transaction, the contract will no longer be deleted. Instead, the execution simply stops and the contract remains on chain.

➠• Assets will still be transferred

When SELFDESTRUCT runs outside the creation transaction, the contract’s assets such as TRX, Staked TRX, or TRC-10 tokens will be transferred to the specified address, but the contract code and storage will remain intact.

➠• Energy cost adjustment

The Energy cost for the opcode will increase to 5000, discouraging unnecessary use and aligning execution economics with modern contract practices.

This change continues the direction already started by TIP-652, where the SELFDESTRUCT opcode was formally deprecated and its functionality began to be restricted.

Data from TRON’s ecosystem analysis shows the impact should be minimal. Most contracts already use SELFDESTRUCT only within the same transaction where they are created.

In fact:

▫️Over 99.999% of SELFDESTRUCT activity already follows this pattern

▫️Contracts relying on delayed destruction or address reuse are extremely rare

▫️No active contracts holding assets were found to rely on the legacy behavior

For developers, this update creates a more consistent environment for smart contract deployment and migration between TRON and Ethereum ecosystems.

Developers who currently use SELFDESTRUCT should review the discussion and evaluate their contracts, especially if they rely on patterns such as delayed contract deletion, address reuse via CREATE2, or lifecycle management through destruction.

Future TVM upgrades may continue limiting this opcode, so developers are encouraged to adopt safer contract lifecycle patterns instead.

Community feedback is important before activation.

Developers and ecosystem participants are encouraged to review the proposal, share feedback, and prepare their contracts if adjustments are needed.

Staying engaged with protocol proposals helps ensure your applications remain compatible as the TRON network evolves.

👉 Join the discussion
github.com/tronprotocol/t…

@Justin Sun孙宇晨 #TVM #TRONDevelopers #TRONEcoStar