TRON is moving ahead with a significant upgrade to its Tron Virtual Machine (TVM) as the network begins voting on Committee Proposal No. 107. The proposal would activate two network parameters that bring features from Ethereum’s Prague and Osaka upgrades to TRON. If approved, the changes are expected to take effect on August 28, 2026, at 14:00 SGT. The move represents another step toward reducing technical differences between TRON and the broader Ethereum development environment.
The proposal activates parameters 95 and 96, known as ALLOW_TVM_PRAGUE and ALLOW_TVM_OSAKA. These features were introduced through GreatVoyage-v4.8.2, also known as Pyrrho, but have remained gated by TRON’s on-chain governance system. Their activation would add new functionality around historical block hashes, cryptographic verification, execution costs and Ethereum-compatible opcodes.
One of the most notable changes is support for native secp256r1, also known as P-256, signature verification. This cryptographic curve is widely used by passkeys and hardware-backed security systems, including technologies associated with Apple Secure Enclave and Android Keystore. By providing native verification inside TVM, TRON can substantially reduce the computational burden compared with implementing the same verification entirely through smart contracts. That could make passkey-based wallets and smart-account designs more practical for developers building on the network.
The upgrade also introduces the Count Leading Zeros, or CLZ, opcode and changes the handling of the MODEXP precompile. These modifications are designed to improve execution efficiency and bring TVM behavior closer to newer Ethereum standards. For developers, that matters because fewer differences between TVM and EVM environments can reduce the amount of chain-specific engineering required when deploying applications across multiple networks.
Why the Prague and Osaka Upgrade Matters for TRON Developers
The historical block-hash functionality is another important component of the proposal. Under the new system, TRON would maintain an 8,191-slot history buffer, allowing smart contracts to access block hashes beyond the traditional recent-history limitations. The buffer will not be populated instantly, however. Developers will need to account for a bootstrap period of roughly 6.8 hours after activation, during which some unwritten historical slots can return bytes32(0) rather than a valid hash.
That detail is particularly relevant for applications that depend on historical blockchain data for verification or execution logic. TRON developers have been advised to distinguish an unavailable zero value from a legitimate block hash and to continue using the existing BLOCKHASH opcode for the most recent 256 blocks. Applications requiring a completely populated history window can wait until approximately 8,191 blocks have passed after activation or use an off-chain fallback.
The proposal could also improve the experience for developers using familiar Ethereum tooling. TRON’s newer Solidity compiler versions are being aligned with modern EVM targets, including Prague and Osaka. Once the corresponding TVM parameters are activated, developers should face fewer compatibility issues when working with newer Solidity releases, compilers and development environments designed around Ethereum’s evolving execution standards.
Related: TRON Prepares for Major TVM Upgrade With Ethereum-Compatible Features
This is particularly important as multichain development becomes more common. Developers building the same application across Ethereum-compatible networks often have to account for differences in supported opcodes, precompiles and compiler targets. Bringing TVM closer to current Ethereum behavior could reduce those differences and make contract migration, testing and tooling integration more straightforward.
The P-256 support could ultimately have implications beyond simple compatibility. Passkeys offer users a way to authenticate without managing traditional private keys in the same manner as conventional crypto wallets. TRON’s proposal does not make P-256 a native transaction-signature type, but it creates a lower-level primitive that developers can use to build passkey-enabled smart wallets and related account-abstraction systems.
The distinction is important. TRON developers have indicated that passkeys are expected to remain primarily a contract-layer capability in the near term rather than becoming part of the network’s native permission model. A future move toward native P-256 signatures or an algorithm-agnostic permission framework would require much broader changes involving key representation, transaction validation, wallets, SDKs and consensus rules.
The upgrade has already gone through substantial technical discussion, including testing considerations for the Nile testnet and preparations by Super Representatives. Nodes participating in block production need to run the required GreatVoyage-v4.8.2 software before the new TVM semantics take effect. This preparation is important because nodes that have not upgraded could face synchronization or block-production problems once the protocol changes become active.
Related: Cardano’s Charles Hoskinson Calls Justin Sun “One Direction—Up” in TRON Remarks
For the TRON community, the August 25 voting request is therefore more than another routine governance proposal. It signals an effort to keep the network’s execution environment aligned with major developments in the Ethereum ecosystem while preserving TRON-specific architecture. If approved, the August 28 activation would give developers access to more modern cryptographic, execution and compatibility features.
The immediate impact on TRX’s price is less certain. Protocol upgrades do not automatically translate into higher token demand, and market conditions will remain the dominant factor for short-term price movements. However, stronger developer compatibility, cheaper cryptographic operations and more practical wallet infrastructure could improve the network’s long-term utility. For TRON, the significance of Proposal No. 107 may ultimately be measured not by the upgrade itself, but by what developers build with the new capabilities.
About The Author
