TRON has activated Committee Proposal No. 107, switching on a group of TRON Virtual Machine features designed to bring smart-contract execution closer to functionality introduced through Ethereum’s Prague and Osaka upgrades. The governance change moved previously deployed TVM capabilities into active mainnet use, rather than introducing a new software release. Proposal 107 took effect on August 28 after receiving support from 25 of TRON’s 27 Super Representatives.
According to the TRONLive report on the proposal’s activation, the vote enabled network parameters 95 and 96, which had been gating functionality already included in GreatVoyage-v4.8.2, or Pyrrho. The activated changes expand TVM compatibility through historical block-hash access, a CLZ opcode, native secp256r1 verification and revised MODEXP behavior. TRON’s official developer proposal likewise describes the objective as reducing compatibility differences for contracts, tooling and cross-chain applications.
Proposal 107 Changes TVM Execution Behavior
The Prague-related portion enables TIP-2935, which provides access to historical block hashes through a state-backed mechanism while leaving the existing BLOCKHASH opcode’s 256-block window unchanged. Contracts can now access a substantially deeper history without altering the original opcode semantics, with the additional mechanism maintaining up to 8,191 parent block hashes after its post-activation buffer fills. That capability can be relevant to applications such as bridges, oracles and verification systems that depend on past block data.
The Osaka-related parameter activates several execution changes, including the CLZ instruction and a native precompiled contract for secp256r1, also known as P-256. Native P-256 verification gives developers a more efficient route for building applications around passkeys and hardware-backed credentials, including systems compatible with technologies such as WebAuthn, Apple Secure Enclave and Android Keystore. GreatVoyage-v4.8.2 had already shipped the necessary implementation before governance switched it on.
MODEXP also received new constraints and pricing rules, but that change should not be interpreted simply as lower energy consumption. Proposal 107 hardens modular exponentiation by limiting oversized inputs and changing its energy-cost calculation, while the TRONLive analysis indicates that many historically observed MODEXP calls would actually become more expensive under the revised formula. The broader efficiency improvement comes instead from specialized cryptographic functionality such as the P-256 precompile.
Compatibility Does Not Yet Mean Developer Migration
The activation extends a broader effort to keep TVM behavior aligned with parts of Ethereum’s evolving execution environment. Greater opcode and precompile compatibility can reduce technical friction for developers working across EVM-style ecosystems, particularly where applications depend on newer cryptographic primitives or execution behavior. Still, the presence of compatible infrastructure does not by itself demonstrate that developers, applications or liquidity will migrate to TRON as a result.
That distinction matters because Proposal 107 confirms what the network can now execute, not how extensively those capabilities will be used. The next measurable milestone will be whether wallets and applications begin integrating the newly activated primitives, particularly P-256 passkey verification and extended historical block-hash access. Future governance decisions around Pyrrho functionality that remains separately gated will provide another indication of how far TRON intends to continue aligning TVM execution with Ethereum’s newer specifications.