Stories by TRON Core Devs on Medium

Mainnet Pyrrho Announcement

TRON Core Devs — Thu, 16 Jul 2026 09:58:16 GMT

1. Summary

GreatVoyage-v4.8.2 (Pyrrho) introduces several important optimizations and updates, centered on the theme of “protocol hardening, EVM compatibility, and improved API and operational experience”:

More robust core protocol: historical block hashes are provided from state via TIP-2935 (EIP-2935), improving friendliness toward stateless clients and L2.
TVM continues to align with Ethereum Osaka: adds the secp256r1 signature verification precompile (TIP-7951), the CLZ leading-zero count instruction (TIP-7939), sets an input upper bound for the MODEXP precompile (TIP-7823) and reprices it (TIP-7883), and standardizes the inputs of signature-verification precompiles (TIP-854).
More efficient, secure, and controllable APIs: rate limiting can optionally be non-blocking, HTTP and JSON-RPC parameter validation is enhanced, and API output is optimized.
Improved networking and operational experience: seed/active/passive and others support configuring domain names, InfluxDB is removed in favor of unifying on Prometheus, a configuration auto-binding mechanism is added, Toolkit subcommands are enriched, and more.

Upgrade type: Mandatory upgrade

2. Adapt to Ethereum Upgrade

GreatVoyage-v4.8.2 introduces at the TVM layer a set of execution capabilities aligned with Ethereum Osaka and Pectra. The related changes are all controlled by on-chain governance parameters; upgrading the node software itself does not automatically activate the new TVM semantics.

1. Osaka

1. TIP-7939: Add the CLZ (Count Leading Zeros) instruction

TVM adds the CLZ instruction (opcode 0x1e), which pops a 256-bit integer from the stack and returns the number of its leading zero bits; when the input is 0 it returns 256. The instruction has a fixed cost of 5 energy, in the same tier as MUL.

Compared with a simulated implementation in Solidity that costs roughly 184 gas and 110–160 bytes of bytecode, the native CLZ requires only a 1-byte instruction, reducing computation and ZK proof costs in scenarios such as fixed-point math, bitmap scanning, calldata compression, and post-quantum signatures. CTZ can be computed by first isolating the least significant bit via x & -x and then applying CLZ.

Ethereum EIP: EIP-7939: Count leading zeros (CLZ) opcode

TIP: TIP-7939: Count leading zeros (CLZ) opcode · Issue #838 · tronprotocol/tips

Source Code: https://github.com/tronprotocol/java-tron/pull/6656

2. TIP-7823: Set an input upper bound for the MODEXP precompile

The MODEXP precompile (address 0x…05) previously allowed its three length fields to take arbitrary values; unbounded inputs enlarged the test space of consensus implementations and have historically been a source of multiple consensus bugs. After Osaka activation, length_of_BASE, length_of_EXPONENT, and length_of_MODULUS must not exceed 8192 bit, i.e. 1024 bytes. If any length exceeds the limit, the precompile immediately returns an execution failure and consumes all energy allocated to the current precompile call frame; the caller receives a failure status, which the outer contract can continue to handle. This upper bound still covers RSA 8192-bit keys and elliptic-curve use cases that are typically smaller than 384 bits. Historical call analyses of both TRON and Ethereum show that no successful call had any single length field exceeding 513 bytes.

Ethereum EIP: https://eips.ethereum.org/EIPS/eip-7823

TIP: https://github.com/tronprotocol/tips/issues/826

Source Code: https://github.com/tronprotocol/java-tron/pull/6611

3. TIP-7883: Increase the gas cost of the MODEXP precompile

Before Osaka, TVM followed the legacy pricing path based on EIP-198: it used a piecewise multiplication complexity and divided by GQUAD_DIVISOR = 20; this implementation was not EIP-2565 pricing and had no fixed minimum energy floor.

After Osaka activation, MODEXP switches to the TIP/EIP-7883 formula:

Minimum energy: 500.
Multiplication complexity: let maxLen = max(baseLen, modLen). When maxLen ≤ 32, multiplication_complexity = 16; otherwise, multiplication_complexity = 2 × ceil(maxLen / 8)².
Iteration count: when the exponent length exceeds 32 bytes, the multiplier is changed from 8 to 16.
Final pricing: energy = max(500, multiplication_complexity × iteration_count).

TIP-7883 directly replaces TVM’s legacy pricing formula, so the change relative to the old implementation depends on the specific input, and not all calls increase in price monotonically; for example, some test vectors drop from 665 to 512, while the energy of high-load edge inputs rises significantly. The input interface and modular exponentiation algorithm of MODEXP remain unchanged.

Ethereum EIP: https://eips.ethereum.org/EIPS/eip-7883

TIP: https://github.com/tronprotocol/tips/issues/837

Source Code: https://github.com/tronprotocol/java-tron/pull/6654

4. TIP-7951: Add the secp256r1 (P-256) curve signature verification precompile

To be compatible with EIP-7951 and to support modern secure hardware such as Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn, this release adds a secp256r1 signature verification precompile to the TVM, enabling scenarios such as account abstraction and device-native signing. According to TIP-7951’s estimate for a Solidity implementation, signature verification cost can be reduced by roughly 50–73×.

On failure it does not revert and consumes the same energy as on success. It remains interface-compatible with the RIP-7212 deployment on L2 (same address, same input/output format).

Ethereum EIP: https://eips.ethereum.org/EIPS/eip-7951

TIP: https://github.com/tronprotocol/tips/issues/785

Source Code: https://github.com/tronprotocol/java-tron/pull/6720

2. Pectra

1. TIP-2935: Provide historical block hashes from state

Previously, TVM’s BLOCKHASH could only serve the most recent 256 blocks and implicitly assumed that the client held recent block hashes, which was not friendly enough for stateless clients / Rollups.

This release deploys the block hash history contract at HISTORY_STORAGE_ADDRESS (0x0000F90827F1C53a10cb7A02335B175320002935, consistent with Ethereum) and uses a ring buffer with a capacity of 8191 to store parent block hashes. The parent hash of block N is written to slot (N-1) % 8191, and querying block K reads K % 8191. The query parameter must be 32 bytes, and K must lie within [block.number-8191, block.number-1]; querying a future block or a block outside the window causes the call to revert. The BLOCKHASH instruction still retains its original semantics and cost for the most recent 256 blocks.

This feature is activated by Proposal 95 ALLOW_TVM_PRAGUE and requires ALLOW_TVM_SHANGHAI to be enabled, because the history contract bytecode uses PUSH0. The contract is deployed by directly writing to CodeStore, ContractStore, and AccountStore, and by directly writing to StorageRowStore at the protocol layer, without executing a system call or consuming block energy; when users query via STATICCALL, they are still billed as an ordinary TVM call.

Activation does not backfill the previous 8191 blocks of hashes; the buffer takes about 8191 blocks (roughly 7 hours on TRON) to fill completely. During startup, slots that are still within the valid range but not yet written return bytes32(0). Because TRON’s proposal activation occurs during the maintenance processing phase, the parent hash of the activation block is not written, leaving a one-block coverage gap.

Ethereum EIP: https://eips.ethereum.org/EIPS/eip-2935

Ethereum Pectra Meta EIP: https://eips.ethereum.org/EIPS/eip-7600

TIP: https://github.com/tronprotocol/tips/issues/719

Source Code:

3. Core

1. TIP-833: Hardening resource window calculation logic to eliminate potential overflow risks at the code level

In previous versions, ResourceProcessor completed part of the intermediate results in its resource window calculation logic — such as increase, increaseV2, unDelegateIncreaseV2, getNewWindowSize, and getUsage — using consecutive multiplication with the long type.

Based on the actual range of on-chain parameters, these calculations will not overflow during normal network operation, and there is no realistically triggerable resource calculation risk. However, from a code implementation perspective, the safety of these calculations relies on the implicit boundary constraints of on-chain parameters, making the logic less explicit and robust in its expression.

This optimization unifies the handling of intermediate products in resource window calculations by using BigInteger, and applies strict validation via longValueExact() when writing the final result back as a long. If a future combination of parameters exceeds the range representable by long, an ArithmeticException will be thrown directly, avoiding silent overflow or implicit truncation.

NOTE: This feature is enabled through the on-chain governance proposal parameter 97.

TIP: https://github.com/tronprotocol/tips/issues/833

PR: https://github.com/tronprotocol/java-tron/pull/6721

4. TVM

1. Optimizing the energy calculation for the VOTEWITNESS opcode

Previously, the VOTEWITNESS opcode used DataWord to calculate the memory bounds required for a dynamic array. DataWord arithmetic operates modulo 256 bits, and extreme combinations of length and offset could wrap around, thereby underestimating the memory expansion cost. This update adds getVoteWitnessCost3, which changes the calculation of array length, offset, and memory bounds to BigInteger, avoiding 256-bit modular wraparound, and adds tests for extreme inputs. The new path takes effect after proposal 96 ALLOW_TVM_OSAKA is activated; this PR uses the existing Osaka gate and does not add a separate governance proposal.

Source Code: https://github.com/tronprotocol/java-tron/pull/6613

2. TIP-854: Tightening the total calldata length shape for signature verification precompiles

The two signature verification precompiles (batchValidateSign at address 0x…09, validateMultiSign at address 0x…0a) assume in their billing that the input is a “fixed-length header + an integer number of equal-length elements,” but execute did not enforce the same shape before decoding. This meant the set of acceptable byte strings exceeded the shape covered by pricing (non-word-aligned trailing bytes were silently discarded, overly short inputs were zero-padded, and so on), which was unfavorable for auditing and formalization.

This update adds a total length check at the execution entry point of both precompiles. Let the word length be W=32: validateMultiSign uses H=5, I=5; batchValidateSign uses H=5, I=6. Only inputs satisfying data.length = H×W + N×I×W with N ≥ 1 pass. When data == null, length % W != 0, length ≤ H×W, or (length-H×W) % (I×W) != 0, the precompile returns execution failure and empty output; the current call frame consumes its pre-allocated energy, the call stack receives 0, and the outer transaction can still continue. The billing formula itself is unchanged.

NOTE: This check only regulates the total length shape of the calldata and does not verify dynamic offset, array length, element offset, or the full Solidity ABI canonical encoding. The functionality is controlled by proposal 96 ALLOW_TVM_OSAKA.

TIP: https://github.com/tronprotocol/tips/issues/854

Source Code: https://github.com/tronprotocol/java-tron/pull/6715

3. TIP-871: Normalizing MODEXP zero-modulus output

Previously, the MODEXP precompile returned an empty byte string (length 0) when the modulus was 0. To align with EIP semantics and ensure a predictable output length, this update normalizes the zero-modulus return value under Osaka to “an all-zero string of the same length as the modulus”: when the modulus length is modLen, it returns modLen zero bytes. This change only affects inputs where modLen > 0 and the modulus bytes are all 0; when modLen == 0, both the old and new outputs are empty. Neither energy pricing nor the non-zero-modulus path is affected.

NOTE: Compatible with Osaka; gated by allowTvmOsaka, proposal 96 ALLOW_TVM_OSAKA.

TIP: https://github.com/tronprotocol/tips/issues/871

Source Code: https://github.com/tronprotocol/java-tron/pull/6780

4. Adding a node-level configuration to control the TVM execution time limit for constant calls

Constant calls such as /wallet/triggerconstantcontract/eth_call are subject to the TVM execution time limit (mainnet default of 80ms), and complex contracts will hit out_of_time; meanwhile, using –debug to remove the timeout also affects block processing, causing OUT_OF_TIME divergence and sync stalls, which is unsafe in production. This update adds a node-level configuration vm.constantCallTimeoutMs that only applies to the constant call path (default 0, meaning it is disabled and the original constant call time limit is used; setting a positive millisecond value overrides that limit), without affecting the block processing/broadcast path. When the configuration is loaded, only the validity of the value is checked (non-negative and ≤ Long.MAX_VALUE/1000, to ensure it can be safely converted to a microsecond deadline).

Usage tip: Use vm.constantCallTimeoutMs to extend the constant call time limit instead of –debug; public nodes are advised to combine it with rate limiting.

Source Code: https://github.com/tronprotocol/java-tron/pull/6719 (issue #6681)

5. Net

1. Node configuration supports domain name resolution

The configuration items seed.node.ip.list, node.active, node.passive, node.fastForward, and node.backup.members are now allowed to be configured with domain names in addition to IP addresses. When the node starts, domain names are resolved into IP addresses; for node.backup.members, if the IP address returned by DNS changes, the system automatically refreshes the backup node’s IP every 60 seconds.

Source Code: https://github.com/tronprotocol/java-tron/pull/6727

2. Optimizing the random disconnection strategy

Previously, when connections were full, java-tron would randomly evict a peer to free up a connection slot, but the candidate range was too broad, potentially disconnecting a peer that was normally relaying blocks; meanwhile, an attacker could use stale block inventory to refresh the active time and evade eviction.

This optimization includes three points:

Adding blockRcvTime, which records the time a peer most recently delivered a valid block.
Correcting the lastInteractiveTime update logic, so that only block inventory higher than the current head block is considered valid activity.
Adjusting the random eviction strategy to select only from the half of peers with the oldest blockRcvTime, reducing the probability of mistakenly killing peers that have recently relayed valid blocks.

Source Code: https://github.com/tronprotocol/java-tron/pull/6704

3. Tightening P2P inbound inventory rate limiting (fixing the TRX counting vulnerability, adding BLOCK rate limiting)

Previously, java-tron’s rate limiting for inbound inventory had two vulnerabilities: the TRX inventory check only compared “the existing 10s window count” against the limit (count > maxCountIn10s), without counting the number of hashes carried by the current InventoryMessage. An attacker could stuff tens of thousands of hashes into a single message, and as long as the window count had not yet reached the cap, the entire message would pass through, effectively bypassing rate limiting via batch packing; meanwhile, BLOCK inventory had no rate limiting at all, and a malicious peer could flood block-inv hashes without restraint, each requiring the receiver to perform a lookup, wastefully consuming I/O and CPU. This update tightens things along the rate-limiting theme: (1) the TRX check is changed to count + currentSize > maxCountIn10s, comparing the projected window size rather than the current window against the limit, blocking the batch bypass; (2) adding per-peer BLOCK inv rate limiting, where the hash count limit within 10s is controlled by the new configuration node.maxBlockInvPerSecond (default 10, minimum 1); (3) on the same inbound path, completing type validation as well: the three entry points checkInvRateLimit, InventoryMsgHandler.check, and FetchInvDataMsgHandler.check apply a whitelist to inventory types, and any unknown type other than TRX/BLOCK is rejected with P2pException(BAD_MESSAGE) and disconnected, preventing unknown types from being used for cache writes or constructing outbound fetches outside of rate limiting.

Source Code:

https://github.com/tronprotocol/java-tron/pull/6731, https://github.com/tronprotocol/java-tron/pull/6851 (issue #6659)

4. Enhancing P2P inbound message validation

Previously, java-tron lacked duplicate-data and length validation for some P2P inbound messages, and a malicious node could construct messages containing a large number of duplicate hashes, duplicate transactions, or overly long block lists to amplify the node’s processing overhead and affect network stability. This update adds duplicate-data and length validation for messages such as Inventory, FetchInvData, Transactions, and SyncBlockChain, uniformly deeming messages that contain duplicate data or exceed limits as illegal and disconnecting, effectively reducing the resource consumption caused by malicious messages and improving the security and robustness of the P2P network.

Source Code: https://github.com/tronprotocol/java-tron/pull/6712 (issue #6667)

5. Reducing memory usage during block synchronization by deferring block deserialization and limiting the number of in-flight blocks.

Previously, during catch-up synchronization, java-tron would immediately deserialize received blocks and cache them for a long time, which in multi-peer concurrent synchronization scenarios could easily cause continuous heap memory growth and increase GC pressure. This optimization introduces the lightweight UnparsedBlock, which only caches the block ID and raw data, deferring deserialization to the actual processing stage; it also adds a global in-flight block count limit node.maxPendingBlockSize (default value 500) to uniformly control the synchronization cache size, preventing memory from spiraling out of control due to concurrent block pulling. After the optimization, memory usage during synchronization is predictable, significantly reducing memory pressure and OOM risk in large-scale synchronization scenarios.

Source Code: https://github.com/tronprotocol/java-tron/pull/6717 (issue #6685)

6. Optimizing the transaction cache backpressure mechanism

Previously, when java-tron judged whether a node was busy, it only counted part of the transaction queue and did not include the overall caches of pushTransactionQueue, pendingTransactions, and rePushTransactions in the calculation, which meant that new transaction Inventory continued to be received even when transactions were backlogged, easily causing the transaction cache to keep growing and increasing memory pressure. In addition, the busy threshold was hardcoded and could not be flexibly adjusted. This update uniformly counts the transaction cache size and refines the backpressure judgment logic, promptly stopping the reception of new transaction Inventory when the transaction pipeline is overall busy; it also adds a configurable item node.maxTrxCacheSize to replace the hardcoded threshold, making the transaction cache capacity more controllable and effectively reducing memory pressure in high-load scenarios.

Usage tip: The transaction cache capacity and the backpressure trigger threshold can be adjusted via node.maxTrxCacheSize.

Source Code: https://github.com/tronprotocol/java-tron/pull/6714（issue #6684)

7. Limiting the signature byte length of transactions and HelloMessage

Previously, some network/broadcast entry points only detected abnormal signature lengths during subsequent signature recovery or consensus validation, and inbound transactions, batch TransactionsMessage, and fast-forward HelloMessage could all carry overly short or overly long signatures into deeper processing paths, bringing invalid computation and log noise.

This update adds SignUtils.isValidLength, and the entry layer only accepts signatures of 65–68 bytes: broadcastTransaction returns SIGERROR before entering the pool; TransactionsMsgHandler rejects with BAD_TRX during the batch transaction check stage; RelayService.checkHelloMessage rejects abnormal lengths before signature verification. The consensus path TransactionCapsule.checkWeight still retains the historical compatibility rule of “size < 65,” not pushing the entry rate-limiting rule down into block replay, avoiding impact on historical on-chain transactions.

Source Code: https://github.com/tronprotocol/java-tron/pull/6782

6. API

1. API rate limiting now supports a non-blocking mode with a configurable switch (resolving HTTP latency caused by rate limiting)

Previously, when an API triggered rate limiting, java-tron used Guava’s RateLimiter.acquire() to block and queue the calling thread. Under high concurrency, request latency grew without bound and could even exhaust the Netty/Jetty worker thread pool, leaving normal traffic unable to be served as well. This release adds support for non-blocking rate limiting: the core path now uses the non-blocking tryAcquire(), which rejects immediately and informs the client that it has been rate limited when no tokens are available; and the rate.limiter.apiNonBlocking switch toggles between blocking and non-blocking modes (off by default = blocking, backward compatible; on = non-blocking peak shaving), letting nodes choose as needed. Two related issues were also fixed: the rate limiting check now evaluates the endpoint first and then the global limit, avoiding a situation where an already-limited endpoint still consumes global quota; and a leak was fixed where per-endpoint semaphores were not released on the global-rejection / exception paths (otherwise, once the accumulated count reached zero, gRPC calls would block permanently).

Usage tip: After enabling non-blocking mode, clients should expect to be rejected immediately rather than receiving a delayed response, and must implement retry / backoff; the default blocking mode behaves the same as before.

Affected interfaces: All HTTP/gRPC/PBFT API entry points with the API rate limiter enabled; the exact coverage is determined by the rate.limiter configuration. This change primarily alters the return timing when rate limiting is hit (blocking wait vs. immediate rejection), and does not add or remove any specific business interfaces.

Source Code:

https://github.com/tronprotocol/java-tron/pull/6733

https://github.com/tronprotocol/java-tron/pull/6761

Issue: (issue #6363)

2. JSON-RPC call parameters now support input as the calldata field

TRON JSON-RPC previously only declared the data field in the call parameter object. Ethereum’s execution-apis use input to represent calldata; go-ethereum’s ethclient and gethclient, since #28078 (https://github.com/ethereum/go-ethereum/pull/28078), also send input rather than data when calldata is non-empty. Because java-tron did not previously declare input, jsonrpc4j/Jackson treated it as an unknown field during parameter deserialization, causing the request to be rejected before the method executed. This release adds input to CallArguments and BuildArguments, and uses it uniformly for calldata parsing in eth_call, eth_estimateGas, and the java-tron extension interface buildTransaction. In eth_call and eth_estimateGas, input takes precedence over data; in buildTransaction, if both are present and their decoded bytes differ, a -32602 Invalid params error is returned.

Usage tip: Legacy clients that continue to use data are unaffected; new integrations are advised to use input. A non-empty input must carry the 0x prefix and contain an even number of hexadecimal characters; for empty calldata, using 0x is recommended. Submitting both input and data at the same time should be avoided, and all submitted fields must be valid hexadecimal.

Affected interfaces: eth_call, eth_estimateGas, buildTransaction.

Source Code: https://github.com/tronprotocol/java-tron/pull/6722

3. Normalize the nonce returned in JSON-RPC transaction objects

TRON JSON-RPC’s TransactionResult.nonce is a compatibility placeholder field fixed at 0. Previously this field returned 0x0000000000000000, a fixed 8-byte DATA-style encoding that does not conform to the QUANTITY constraint ^0x(0|[1–9a-f][0–9a-f]*)$ that Ethereum’s execution-apis impose on the transaction nonce. This release normalizes it to 0x0. This change affects eth_getTransactionByHash, eth_getTransactionByBlockHashAndIndex, eth_getTransactionByBlockNumberAndIndex, as well as the transaction nonce included when eth_getBlockByHash and eth_getBlockByNumber return full transaction objects with the second parameter set to true. The block object’s own BlockResult.nonce is unaffected and still returns 0x0000000000000000 per the Ethereum bytes8 type. This change only corrects the JSON-RPC encoding of the transaction nonce; it does not change its numeric value, nor does it introduce Ethereum-style nonce semantics for TRON transactions.

Compatibility tip: Clients that parse it as a QUANTITY numeric value are generally unaffected; clients that compare against string literals or fixed lengths need to adapt.

Affected interfaces: eth_getTransactionByHash, eth_getTransactionByBlockHashAndIndex, eth_getTransactionByBlockNumberAndIndex, eth_getBlockByHash , eth_getBlockByNumber.

Source Code: https://github.com/tronprotocol/java-tron/pull/6709

4. Deprecate the HTTP REST mappings in the gRPC proto

The gRPC proto still carried google.api.http REST mappings (such as post:/wallet/getaccount) that existed for the deprecated grpc-gateway, while these endpoints have long had independent HTTP implementations in FullNodeHttpApiService, making the mappings redundant. This release removes the google.api.http option blocks from 56 gRPC interface definitions and deletes 8 empty proto files under protocol/src/main/protos/core/tron.

Usage tip: Access via the default HTTP endpoints (such as IP:8090/wallet/xxxx) or directly via gRPC (Trident SDK), without relying on grpc-gateway REST translation.

Affected interfaces: The Wallet/ WalletSolidity / WalletExtension / Monitor gRPC methods in api.proto that were originally annotated with google.api.http (56 mapping blocks in total); java-tron’s own HTTP Servlet paths are unaffected and still use /wallet*/*.

Source Code: https://github.com/tronprotocol/java-tron/pull/6726 (issue #6548)

https://github.com/tronprotocol/java-tron/pull/6874

5. Unify the HTTP request body size limit

Previously the HTTP layer had no unified “before-entry” request body size limit; validation was performed after reading the full request body, posing a memory amplification risk, and the validation logic was scattered. This release inserts a Jetty SizeLimitHandler at the top of the processing chain for streaming validation; it introduces node.http.maxMessageSize and node.jsonrpc.maxMessageSize (node.rpc.maxMessageSize is still used only for gRPC), defaulting to roughly 4MB. Exceeding Content-Length returns HTTP 413; exceeding it in chunked mode returns 200 + an error JSON, or 200 + an empty body (jsonrpc).

Usage tip: Adjust node.http.maxMessageSize / node.jsonrpc.maxMessageSize as needed; over-limit requests need to be split.

Affected interfaces: HTTP REST /wallet*/* use node.http.maxMessageSize; JSON-RPC /jsonrpc uses node.jsonrpc.maxMessageSize; gRPC is unaffected by this item and is still controlled by node.rpc.macMessageSize.

Source Code:

6. Optimize JSON serialization for block interfaces

Previously the block-related HTTP interfaces took a redundant path — first fully serializing to a JSON string, then deserializing back to an object, then overwriting fields — causing repeated “protobuf→JSON→object” conversions, extra CPU usage, and elevated GC pressure. This release changes the approach to build the JSON field by field on demand in Util.java: printBlockList directly populates the block array, while printBlockToJSON serializes only the block_header and manually populates blockID and transactions. The returned fields are unchanged and fully backward compatible; the goal is to reduce CPU/GC.

Usage tip: Affects GetBlockByLimitNext, GetBlockByLatestNum, GetBlock, GetNowBlock, GetBlockByNum, GetBlockById; callers need no changes.

Affected interfaces: /wallet/getblockbylimitnext, /wallet/getblockbylatestnum, /wallet/getblock, /wallet/getnowblock, /wallet/getblockbynum, /wallet/getblockbyid, and the corresponding /wallet*/* block query paths.

Source Code: https://github.com/tronprotocol/java-tron/pull/6693

7. Add a blockTimestamp field to JSON-RPC log objects

Previously the JSON-RPC log object did not include the block timestamp, so for sorting/indexing clients had to make an additional eth_getBlockByHash/eth_getBlockByNumber call for each log, which was also inconsistent with Ethereum’s execution-apis. This release adds blockTimestamp (a hexadecimal string) to the log object, in the same format as the JSON-RPC block timestamp: a 0x-prefixed Unix second value (not TRON’s internal milliseconds). It is purely additive and non-breaking.

Usage tip: Affects eth_getLogs, eth_getFilterLogs, eth_getFilterChanges (log/event filters only), eth_getTransactionReceipt, eth_getBlockReceipts; clients read blockTimestamp directly, eliminating the second block query.

Affected interfaces: eth_getLogs, eth_getFilterLogs, eth_getFilterChanges (log/event filters), eth_getTransactionReceipt, eth_getBlockReceipts.

Source Code: https://github.com/tronprotocol/java-tron/pull/6671

8. Introduce resource limits for JSON-RPC (batch request count / response body / address count / request body size)

Previously JSON-RPC had no limits on batch array size, response body size, or the number of address filters, posing OOM and resource-exhaustion risks in public/high-concurrency scenarios. This release adds: node.jsonrpc.maxBatchSize (default 100), node.jsonrpc.maxAddressSize (default 1000, validated before eth_getLogs queries), and node.jsonrpc.maxResponseSize (default 25MB, counted incrementally during serialization). Error codes: address over limit −32602, batch over limit −32005, response too large −32003.

Affected interfaces: node.jsonrpc.maxBatchSize, node.jsonrpc.maxResponseSize apply to all /jsonrpc requests; node.jsonrpc.maxAddressSize applies to the address array of eth_getLogs, eth_newFilter; node.jsonrpc.macLogFilterNum applies to the number of log filters in eth_newFilter; the existing node.jsonrpc.maxSubTopics applies to a single topic OR array of eth_getLogs, eth_newFilter.

Source Code:

9. Add an optional parameter: serialize 64-bit integers in HTTP GET responses as JSON strings

Previously, protobuf 64-bit integer fields in the TRON HTTP API were typically output as JSON numbers. After JavaScript clients parse them with JSON.parse, these values are converted to Number; when an integer exceeds Number’s safe integer range [-(2⁵³-1), 2⁵³-1], silent precision loss can occur.

This release adds the optional parameter int64_as_string. When int64_as_string=true is set in the URL query of an HTTP GET request, the signed and unsigned 64-bit integer protobuf fields serialized via TRON’s JsonFormat are returned as JSON strings, including the relevant fields in nested objects and maps. Additionally, the four hand-written JSON fields burnTrxAmount, pendingSize, reward, and count have been individually adapted.

When the parameter is not set or is set to false, the response format remains unchanged. This capability applies to HTTP GET paths in FullNode, Solidity, and PBFT that ultimately generate responses via JsonFormat, or via Util methods that internally call JsonFormat. Interfaces using other serialization approaches are outside the scope of this change. JSON-RPC, gRPC, and all POST requests are unaffected.

Usage example: GET /wallet/getnowblock?int64_as_string=true

Usage tip: This parameter is only accepted in the GET URL query. For POST requests, setting it in either the URL query or the body has no effect. Once enabled, the JSON type of the relevant fields changes from number to string, and clients should handle them as strings, BigInt, or a big-integer library.

Typical interfaces include:

/wallet/getnowblock and the corresponding /wallet*/getnowblock
/wallet/getblock, /wallet/getblockbynum, /wallet/getblockbyid, /wallet/getblockbylimitnext, /wallet/getblockbylatestnum and the registered Solidity counterpart paths
/wallet/getburntrx, /wallet/getReward, /wallet/gettransactioncountbyblocknum and the corresponding /Solidity paths
/wallet/getpendingsize, provided only by FullNode

Source Code: https://github.com/tronprotocol/java-tron/pull/6699

10. Uniformly harden input validation on the JSON-RPC / HTTP API parameter-parsing paths

The JSON-RPC / HTTP API parameter-parsing paths previously lacked validation of input length and format, posing two kinds of risk — first, algorithmic-complexity DoS (Base58.decode/BigInteger parsing, where overly long inputs can saturate threads with a very small request body); and second, various malformed/out-of-bounds inputs that would break through directly to unexpected exceptions (NPE, DecoderException, StackOverflowError, etc.), caught by jsonrpc4j as a fallback returning a default error message. This release adds unified up-front length and format validation across a series of parameter entry points — addresses (Base58/hex length caps), block number/hash/storage key/transaction index/log topic and address/ABI depth/gas-value overflow, and more — converging these exceptional cases into a well-formed -32602 invalid params error response.

Affected interfaces: JSON-RPC methods that parse addresses, hashes, topics, block selectors, transaction indexes, gas/value, and ABI/revert data (typically including eth_getBalance, eth_getStorageAt, eth_getCode, eth_call, eth_estimateGas, buildTransaction, eth_getTransactionByHash, eth_getTransactionReceipt, eth_getBlockByHash, eth_getBlockByNumber, eth_getLogs, eth_newFilter, eth_getFilterLogs); HTTP REST paths that parse address/contract parameters (typically including /wallet/getaccount, /wallet/triggerconstantcontract, /wallet/triggersmartcontract, /wallet/deploycontract, /wallet/getcontract, /wallet/estimateenergy).

Source Code: https://github.com/tronprotocol/java-tron/pull/6828

11. Refactor the parsing logic for the JSON-RPC block selector (block tag / block number)

The parsing logic for the JSON-RPC block selector (latest/earliest/pending/safe/hexadecimal block number) was scattered and duplicated across three places — Wallet, JsonRpcApiUtil, and TronJsonRpcImpl — each with slightly different responsibilities and control flow, resulting in duplicated and inconsistent parsing logic that was costly to maintain. This change consolidates the relevant logic into JsonRpcApiUtil, giving the code a more reasonable structure and clearer logic, and lowering maintenance cost.

Affected interfaces: All interfaces that accept a JSON-RPC block tag / block number parameter, typically including eth_getBalance, eth_getStorageAt, eth_getCode, eth_call, eth_getTransactionCount, eth_getBlockByNumber, eth_getBlockReceipts, eth_getBlockTransactionCountByNumber, eth_getTransactionByBlockNumberAndIndex, eth_getUncleByBlockNumberAndIndex, eth_getUncleCountByBlockNumber, eth_getLogs, eth_newFilter.

Source Code: https://github.com/tronprotocol/java-tron/pull/6668

Source Code: https://github.com/tronprotocol/java-tron/pull/6711

12. Add signature count and length protections to transaction signature query APIs

Tightened the multi-signature query logic to prevent overly long signatures from amplifying responses or bypassing validation. Changes:

Both query entry points now first limit the signature count according to the on-chain totalSignNum, returning too many signatures immediately when the limit is exceeded.
Signatures longer than 65 bytes are uniformly truncated to the standard 65 bytes before participating in weight and approvedList calculations, and the transaction in the response also uses the truncated signatures.
getApprovedList now reuses TransactionCapsule.checkWeight and adds validation of permissionId, permission type, and operation.
getApprovedList behaves more strictly: cases such as too many signatures, signatures not belonging to the current permission, and duplicate signers all fail as a whole, and it no longer returns a partial approvedList.
Early-exit errors return only result, and the HTTP JSON may not contain a transaction field.
The weight == 0 error message no longer echoes the overly long signature hex, but instead uses the fixed-length tx hash, avoiding amplification of the error response.

Compatibility tip: Wallets, multi-signature services, and SDKs should no longer treat getApprovedList as an “arbitrary signature recovery” or “partial authorization probe” interface. Before calling, they should limit the signature count, filter out irrelevant signatures and duplicate signers themselves, judge failure by result.code / result.message, and also handle the case where the response is missing the transaction field.

Affected interfaces: HTTP /wallet/getsignweight, /wallet/getapprovedlist; gRPC Wallet.GetTransactionSignWeight, Wallet.GetTransactionApprovedList.

Source Code: https://github.com/tronprotocol/java-tron/pull/6820

7. Dependencies

1. Unifying the JSON technology stack on Jackson and reducing security risks from legacy dependencies

Previously, java-tron internally used two different JSON processing libraries at the same time: modules such as JSON-RPC, the event plugin, keystore, and TVM trace mainly used jackson, while the HTTP API layer relied on fastjson.

To reduce the impact of this change on business code, we did not directly rewrite every call site to the native Jackson API. Instead, we added lightweight compatibility wrappers such as org.tron.json.JSON, JSONObject, and JSONArray, implemented on top of Jackson. This allows most scenarios to be migrated simply by “replacing the import,” reducing the cost of large-scale refactoring and keeping the JSON parsing and output behavior of the existing HTTP API layer as stable as possible.

From an external compatibility standpoint, this change is an internal dependency replacement and security hardening. It does not involve any changes to API paths, request parameters, response structures, configuration items, or protocol formats. External callers that normally use the HTTP API, JSON-RPC, and gRPC, as well as those consuming event data, generally do not need to adapt. Callers that conform to the interface contract and use standard JSON requests are largely compatible; callers that rely on fastjson’s lenient syntax, field ordering, or special null behavior should take note, and scenarios where downstream code directly depends on com.alibaba.fastjson.* types also require special attention.

Therefore, the core goal of this change is: to unify the JSON technology stack, remove legacy security burdens, and reduce subsequent maintenance and audit costs, while keeping external behavior as unchanged as possible.

Source Code:

2. Dependency upgrades

Bump libp2p from 2.2.7 to 2.2.8
Bump bcprov-jdk18on from 1.79 to 1.84 to address CVE-2026–5598
Bump jetty from 9.4.57 to 9.4.58 to address CVE-2025–5115
Bump pf4j from 3.10.0 to 3.14.1 to address CVE-2025–70952
Bump grpc-java from 1.75 to 1.81 to address CVE-2026–33871

Source Code:

8. Configuration

1. Automatic binding mechanism for new configuration items

This round of refactoring upgraded the java-tron configuration system from “hand-written parsing” to “typed automatic binding.” In the past, a large number of configuration items were centralized in Args and read one by one via hasPath/getXxx, with default values scattered across code, comments, and configuration samples. Adding a new parameter required modifying multiple places at once, which easily led to default-value drift and compatibility issues. The new approach is based on Typesafe Config’s ConfigBeanFactory, splitting configuration such as node, storage, vm, committee, event, and rate.limiter into domain Beans, with reference.conf uniformly carrying default values and parameter descriptions.

Subsequent optimizations focused on three areas: first, calibrating behavioral differences after automatic binding, preserving compatibility with old configuration keys, default-value semantics, and boundary validation; second, cleaning up unused or misleading configuration items to reduce the historical baggage of CommonParameter and the configuration files; and third, establishing normalization or manual-parsing strategies for scenarios such as non-standard naming, optional lists, and nested structures, to avoid strict binding breaking existing configurations. Ultimately, reference.conf became the authoritative configuration reference, config.conf was streamlined into a user-override sample, and documentation on configuration usage and development conventions was added. Overall, this improved the type safety, maintainability, and auditability of the configuration system, and laid the groundwork for later removing the CommonParameter intermediate layer.

Source Code:

2. Fixed 13 CLI parameters being silently overridden by the configuration file

The standard priority should be CLI > configuration file > default value. Previously this was implemented correctly for 9 parameters, but Args.setParam(Config) unconditionally overrode the CLI values of another 13 parameters with configuration-file values, causing these CLI flags to be silently ignored. This refactoring introduces a Default → Config → CLI three-layer override model; the affected flags include –rpc-thread, –solidity-thread, –validate-sign-thread, –max-connect-number, –lru-cache-size, –long-running-time, –max-energy-limit-for-constant, –min-time-ratio, –max-time-ratio, –support-constant, –save-internaltx, –save-featured-internaltx, and –history-balance-lookup, and it also corrects the –seed-nodes flag.

Usage tip: For example, java -jar FullNode.jar –rpc-thread 16 will now correctly override config.conf; please check your startup scripts before upgrading.

Source Code: https://github.com/tronprotocol/java-tron/pull/6569

3. Extracting ConfigKey constants and deprecating the net.type configuration item

This change extracts about 232 HOCON configuration key constants (such as “node.rpc.port”) from Constant.java into the newly created ConfigKey.java, leaving only about 32 business constants in Constant.java. It also removes the outdated testnet configuration and the 0xa0 address format, unifying on the mainnet address format (T- Base58 / 41 hexadecimal). In addition, a unit test for rocksdb was added for the x86 environment.

Source Code:

4. Removing the actuator.whitelist configuration to prevent forks

actuator.whitelist (an early testing feature) allowed a node to register only the actuator types in the whitelist; on the public chain, if a block contained a non-whitelisted transaction type, getActuator() would return null, causing execution to diverge from the rest of the network and leading to state forks and node isolation. This change fully removes the configuration and its related logic; all nodes unconditionally register/execute all valid actuators, and the enabling of transaction types is entirely governed by on-chain proposals.

NOTE: Breaking change. Please remove actuator.whitelist from your configuration before upgrading.

Source Code: https://github.com/tronprotocol/java-tron/pull/6723

9. Database

1. Removing periodic RocksDB database backups

storage.backup periodically copies the database (every frequency blocks), originally intended to guard against disk failures, power outages, or kill-9 corruption. However, the mainnet state database is now about 3TB, and a single copy may take hours and block block synchronization during that window, which is a fatal stability risk; testing also confirmed that kill -9 does not corrupt the database. This change removes the entire storage.backup configuration block and the copy logic in pushBlock(), and recommends switching to a primary-standby dual-FullNode solution using node.backup { port, priority, members } or RAID instead.

NOTE: Breaking change, incompatible with 4.8.1 and earlier; before upgrading, remove storage.backup and migrate to a dual-node disaster-recovery setup or RAID.

Source Code: https://github.com/tronprotocol/java-tron/pull/6724 (issue #6595）

10. Metrics

1. New Prometheus metrics for empty blocks and SR set changes

Prometheus metrics lacked visibility into the number of transactions per block (and whether an empty block was produced) and into changes to the super representative (SR) set during the maintenance period.

This change adds statistics for SR set changes and for the number of transactions within a block.

SR set changes are tracked with a counter, tron:sr_set_change_total (add/remove); the number of transactions within a block is recorded with a histogram, tron:block_transaction_count, with the custom transaction-count buckets {0, 20, 50, 80, 100, 120, 140, 160, 180, 200, 230, 260, 300, 500, 2000, 5000, 10000}, so as to derive the approximate distribution of transaction counts per block. Empty blocks are captured by the le=“0” bucket, and the ratio is computed in Grafana using PromQL.

Usage tip: After Prometheus scraping, compute the empty-block ratio using the le=“0” bucket or PromQL.

Source Code:

Issue: https://github.com/tronprotocol/java-tron/issues/6590

2. Removal of InfluxDB metrics storage support

Up to and including v4.8.1, two monitoring stacks coexisted: Prometheus (/metrics) and the legacy dropwizard MetricsUtil + InfluxDB (monitor/getstatsinfo), which led to fragmented metrics and unmaintained dependencies. This change removes the InfluxDB reporter from MetricsUtil and deletes its configuration block (storageEnable, influxdb { ip=xx, port=8086, database=xx, metricsReportInterval=10 }), consolidating everything on Prometheus.

NOTE: Breaking change; before upgrading, please remove the influxdb configuration and migrate to Prometheus + Grafana (tron-docker).

Source Code: https://github.com/tronprotocol/java-tron/pull/6725（issue #6665）

11. Logging

1. Logging improvements: unify gRPC log ingestion, reduce startup noise, and enhance exception diagnostics

Previously, some of java-tron’s runtime logs had shortcomings in observability and operational troubleshooting: for example, the gRPC layer used the JUL logging framework, and some diagnostic information could bypass Logback and be written directly to stderr; during the node startup phase, DB statistics were output at INFO level in large volumes, easily drowning out key initialization logs; during abnormal shutdown, some logs might not be fully flushed in time; in addition, issues such as long signature-verification times, LevelDB open stalls (on long-running nodes), and invalid log configurations lacked sufficiently clear log prompts.

This change enhances the logging system with a focus on operations, mainly including the following aspects:

Unified ingestion of gRPC logs into Logback
Introduced org.slf4j:jul-to-slf4j:1.7.36 and installed SLF4JBridgeHandler early during node startup, bridging logs that grpc-java originally emitted through JUL into Logback in a unified manner. After the upgrade, io.grpc logs are managed at INFO level by default and output to a dedicated ./logs/grpc/grpc.log. This means that gRPC diagnostic information such as TLS handshake failures, abnormal connection resets, and NettyServerTransport’s “Transport failed” will go into managed log files rather than being scattered across stderr.
Reduced DB statistics log noise during startup
The log level of DbStat.statProperty() was changed from INFO to DEBUG, avoiding a flood of DB statistics being emitted during node startup. This makes important logs such as key initialization, configuration loading, and network startup clearer, reducing interference during startup troubleshooting.
Improved shutdown log completeness
TronLogShutdownHook was refactored, with related constants named more clearly, and the maximum wait time was increased from 60 seconds to 180 seconds, reserving more time for the node executor thread pool to be released, tasks to wrap up, and logs to be flushed to disk, reducing the likelihood of log loss during abnormal exit or normal shutdown.
Slow signature verification made observable
Added slow signature-verification logging. When a single signature verification takes more than 50 ms, TransactionCapsule.logSlowSigVerify(…) outputs an INFO log, making it easier for operators to identify abnormally slow signature verification, increased CPU pressure, or performance bottlenecks triggered by specific transactions.
LevelDB open stalls no longer silent
LevelDbDataSourceImpl adds a watchdog mechanism for factory.open(…), which may block at the JNI layer. If opening LevelDB takes more than 60 seconds, a WARN log is output with troubleshooting and remediation hints, pointing to related tools such as Toolkit.jar db archive, making it easier for operators to handle overly long LevelDB open times.
Invalid –log-config configuration fails fast
If the log configuration file specified via –log-config is not readable, LogService.load(…) will directly throw TronError(ErrCode.LOG_LOAD), and the node fails fast instead of continuing to start with the default log configuration. This exposes deployment configuration problems earlier, avoiding the situation where a missing expected log output is only discovered after the node is running.

After the upgrade, log output will be clearer and more controllable:

gRPC-related diagnostic information will go into ./logs/grpc/grpc.log;
the main log tron.log will no longer be flooded by DB statistics INFO logs during startup;
operations-relevant events such as slow signature verification and LevelDB open stalls will be retained in the main log;
in CI scenarios, the test root logger was changed from DEBUG to INFO to reduce the volume of test logs.

Usage tip: To adjust the verbosity of gRPC logs, you can configure the io.grpc logger in logback.xml.

This change only involves the logging system and operational observability, and does not involve changes to the API, RPC, network protocol, consensus logic, or database format. Normal business calls require no adaptation, but node operators can use this to update log collection paths, alerting rules, and troubleshooting runbooks.

Source Code: https://github.com/tronprotocol/java-tron/pull/6700

Issue: #6583

12. Event Service

1. Event Plugin must be upgraded to version 3.0.0 or above

This upgrade adds a minimum version check for the Event Plugin: when a node enables event subscription and loads an external Event Plugin, the plugin version must be no lower than 3.0.0; otherwise, the node will fail outright during the startup phase.

This change is primarily intended to align with the adjustment of java-tron’s internal JSON technology stack. v4.8.2 has removed the fastjson dependency and switched uniformly to Jackson, whereas the old Event Plugin still relies on fastjson. Continuing to use the old plugin may cause issues such as missing classes, plugin loading exceptions, or event processing failures in the new version of java-tron. Compared with allowing a node to silently drop events during operation after startup, this change adopts a fail-fast approach during the startup phase, which exposes plugin compatibility issues earlier and prevents the event subscription service from being left in an unreliable state.

The nodes affected are those that have enabled an external Event Plugin, for example deployment scenarios that use the Kafka or MongoDB event plugin. A node will be affected only if it meets all of the following conditions:

Uses the –es command-line option or event.subscribe.enable = true
Uses an external Event Plugin rather than the native queue
event.subscribe.path points to an old-version plugin package
The Plugin-Version in the plugin package is lower than 3.0.0, or the version information is missing

If a node has not enabled event subscription, or uses the native queue, it is not affected by this version check.

When upgrading, node operators need to rebuild or replace the Kafka / MongoDB Event Plugin package, and point event.subscribe.path to the new plugin zip, for example plugin-kafka-3.0.0.zip or plugin-mongodb-3.0.0.zip. It is also recommended to check the Plugin-Version in the plugin package’s META-INF/MANIFEST.MF to ensure the version number is no lower than 3.0.0.

This change is an operations-side compatibility requirement and does not affect on-chain consensus, the API protocol, or the event data model itself. However, for data services, indexing services, and Kafka/MongoDB consumption pipelines that depend on event subscription, the Event Plugin must be upgraded in sync before upgrading java-tron; otherwise the node may be unable to start the event subscription normally.

For detailed upgrade instructions and plugin package information, please refer to the Event Plugin v3.0.0 Release Notes: https://github.com/tronprotocol/event-plugin/releases/tag/v3.0.0

Source Code: https://github.com/tronprotocol/java-tron/pull/6760

2.Add chain reorganization rollback (removed) semantics for block and transaction events

Previously, java-tron only provided chain reorganization rollback (removed) semantics for contract events. Block and transaction events did not notify subscribers to roll back when a chain reorganization occurred, which meant subscribers might retain events that had become invalid, and might miss the corresponding block and transaction events when reapplying the new fork branch. This update adds a removed flag to BlockLogTrigger and TransactionLogTrigger, sending rollback events to subscribers during a chain reorganization and resending the corresponding events when the new fork branch is reapplied, ensuring that the event stream can fully reflect chain state changes.

Compatibility tip: After the upgrade, BlockLogTrigger and TransactionLogTrigger will add a removed field and send a removed=true rollback event during a chain reorganization. Event subscribers need to correctly handle the chain reorganization scenario based on this field, undoing the local state corresponding to rolled-back blocks or transactions. In addition, since the event JSON structure adds a field, clients that use strict JSON Schema validation or that disallow unknown fields need to update their parsing logic accordingly to avoid compatibility issues.

Source Code:

3. Fix the issue where the eth_getFilterChanges interface could not obtain new main-chain blocks/logs after a chain reorganization

This fixes a long-standing issue: when a chain reorg occurs, switchFork() was only responsible for withdrawing the logs of the discarded branch (reOrgLogsFilter, marked removed=true), but returned directly after switching to the new main chain. This resulted in “only withdrawing the old, never resending the new,” violating the semantics that a reorg should follow — “first withdraw the old branch, then resend the new branch” — causing dApps polling with eth_newFilter to completely lose the logs of all blocks on the new main chain after the reorg.

Source Code: https://github.com/tronprotocol/java-tron/pull/6819

13. Tooling & Others

1. Optimize the actuator registration process of TransactionRegister

Previously, TransactionRegister would scan and register actuators via reflection during the startup phase. Because the scanned package scope was large, the startup process incurred some additional overhead; at the same time, if an exception occurred during actuator registration, there was no fast-fail, which could increase the cost of problem diagnosis.

This update optimizes the actuator registration process, mainly in three aspects:

Add a registration status check
Uses a registration status check to avoid duplicate initialization, preventing the same batch of actuators from being scanned and registered repeatedly, reducing unnecessary overhead.
Adopt fail-fast error handling
If an exception occurs during registration, it will fail fast via TronError, preventing the node from continuing to start when actuator registration is incomplete or the state is uncertain. This allows deployment or code issues to be exposed as early as possible during the startup phase, making it easier for operations and development personnel to quickly locate them.
Narrow the reflection scanning scope
Narrows the actuator scanning scope from the larger org.tron package to org.tron.core.actuator, reducing the scanning of irrelevant classes and lowering the cost of reflection initialization. According to test results, the first registration time was reduced from about 375 ms to about 188 ms, and the repeat registration scenario from about 165 ms to about 24 ms.

Overall, this optimization does not change transaction execution logic, API behavior, or external protocols; it mainly improves the registration efficiency and error observability during the node startup phase. Ordinary node users do not need additional adaptation; if a custom actuator exists, you need to confirm that its class is located under the org.tron.core.actuator package path, otherwise it may not be scanned and registered.

Source Code: https://github.com/tronprotocol/java-tron/pull/6447

2. Migrate keystore-factory to a Toolkit subcommand

KeystoreFactory (previously invoked via FullNode.jar –keystore-factory) was located in the framework module, with unclear module boundaries. This update migrates it to plugins as a Toolkit subcommand (java -jar Toolkit.jar keystore) and switches to picocli; for compatibility, –keystore-factory is retained for a deprecation period (with a deprecation notice).

Usage tip: The new invocation method is java -jar Toolkit.jar keystore; the old method remains available during the deprecation period.

Source Code: https://github.com/tronprotocol/java-tron/pull/6637

3. Solidity Node supports conditional shutdown

SolidityNode (which syncs about 30%+ faster than FullNode and does not verify signatures) previously lacked conditional automatic shutdown, which is useful when verifying the global state of a target height across architectures (x86 vs ARM). This update introduces the existing node.shutdown automatic stop conditions into SolidityNode: BlockTime (cron), BlockHeight, BlockCount (only one may be set, otherwise fail-fast).

Source Code:

4. CI / Workflow optimization

Improve the 4.8.2 release quality assurance system.

On the CI side, added multi-platform builds, Checkstyle, and single-node/multi-node integration tests, and placed the build after the PR lint to reduce wasted resource consumption;
The coverage process was adjusted from the Codecov approach to a base vs PR comparison based on JaCoCo and diff-cover, focusing on verifying the coverage of changed lines and any regression in overall coverage.
In terms of configuration governance, added key naming, hierarchy depth, port uniqueness, and comment coverage checks for reference.conf, reducing the risk of configuration items that cannot be bound or lack descriptions.
At the protocol layer, added protoLint, enforcing the use of the UNKNOWN_ prefix for enum 0 values, ensuring API evolution compatibility.
Also introduced CODEOWNERS / automatic reviewer assignment and fixed the fork PR permission issue, upgraded actions/cache to v5, and improved GitHub Actions compatibility and stability.

Source Code:

Mainnet Pyrrho Announcement was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

Inside the java-tron v4.8.2 Configuration System

TRON Core Devs — Thu, 16 Jul 2026 08:42:30 GMT

1. Overview

In v4.8.2, the configuration loading process was optimized with reference to the config file formats of other mature projects in the industry; java-tron now uses HOCON with automatic parameter binding. The java-tron configuration system is composed of three layered sources, with priority from high to low:

Command-line arguments (CLI)
↓ override
config.conf (a user-specified config file, or the built-in one)
↓ fallback
reference.conf (built-in default values in the jar)

All values eventually converge into the CommonParameter.PARAMETER singleton, which the node reads from throughout its runtime. Args.setParam() coordinates the entire loading process; once it completes, CommonParameter.PARAMETER is the single source of configuration at runtime.

2. Loading the configuration files

HOCON (Human-Optimized Config Object Notation) is the configuration format defined by the Typesafe Config library, and it is a superset of JSON. It supports comments (# / //), unquoted strings, multi-line strings, variable substitution (${var}), and include statements. java-tron’s .conf files use exactly this HOCON format. reference.conf is the built-in default file name by Typesafe Config convention; when loading, the library automatically finds it on the classpath and uses it as the fallback.

2.1 Locating the config file

Configuration.java locates the config file in the following order of priority:

getByFileName(configFilePath)
1. Look it up as a filesystem path (new File(configFilePath))
   ├─ Found → ConfigFactory.parseFile(file).withFallback(ConfigFactory.defaultReference())
   └─ Not found → load it from the classpath (ConfigFactory.load(name))

configFilePath takes the path specified by the CLI flag -c / --config first; if none is specified, it defaults to “config.conf”.

How the HOCON merge works:

ConfigFactory.parseFile(confFile) parses the user’s config.conf.
.withFallback(ConfigFactory.defaultReference()) uses reference.conf from the classpath to fill in, as defaults, every key not explicitly set.
Any key present in the user’s file completely overrides the same key in reference.conf; keys not present take their default values from reference.conf.

2.2 The role of config.conf

Up to and including v4.8.1, config.conf contained almost every configuration item, along with detailed comments.

From v4.8.2 onward, it is a minimal set of commonly used configuration items recommended for users, with very few comments, reducing users’ cognitive load.

2.3 The role of reference.conf

The core role of reference.conf is to provide a complete default value for every configuration key, ensuring that the node can start in a reasonable state even when the user has not specified any parameters. It serves two purposes:

Baseline: the user’s custom config.conf only needs to contain the keys to override; all other keys are filled in from reference.conf. Typesafe Config’s withFallback mechanism guarantees that the merged config object is always complete, so ConfigBeanFactory binding never throws ValidationFailed due to a missing key.
Contract: reference.conf is the configuration contract between the code and node operators — all tunable parameters, their default values, and their valid ranges are declared here. By reading this one file, operators can understand the node’s complete configuration space without reading Java code.

Before v4.8.2, default values were scattered across ternary expressions throughout Args.java (config.hasPath(X) ? config.getInt(X) : 30), entirely opaque to operators. v4.8.2 introduced reference.conf precisely to make these implicit defaults explicit and centralized.

2.4 Priority in three conflict scenarios

2.4.1 Starting a FullNode without specifying a config file via -c

① Finding the built-in config.conf

When a FullNode starts, the string "config.conf" is passed in by default:

Args.setParam(args, "config.conf")

Configuration.getByFileName() searches in this order:

1. Look for config.conf in the current working directory as a filesystem path
   └─ Found → parseFile() + withFallback(reference.conf)
2. Load a file of the same name from the classpath (ConfigFactory.load("config.conf"))
   └─ Found → loaded (the framework jar contains an example config.conf, so this branch is matched)

Note: the framework/src/main/resources/config.conf packaged inside the jar is only an example and may not match a production node’s configuration. For production deployments, specify a complete external config file via -c.

② If the built-in config.conf and reference.conf have different values

config.conf takes precedence. The semantics of withFallback are: keys already present in the primary config (config.conf) are never overwritten by the fallback; only keys missing from the primary config are filled in from reference.conf.

2.4.2 A config file specified via -c has values different from reference.conf

In this case the built-in config.conf is ignored, and the user’s takes precedence. For any key absent from , the value from reference.conf is used.

2.4.3 reference.conf has values different from a Config Bean field’s initial value in code

reference.conf takes precedence. When ConfigBeanFactory.create() binds via reflection, it writes the values from the config object into the bean fields — and at that point the config object already contains every key from reference.conf, so the Java field initial values are always overwritten.

A bean field’s initial value is therefore never actually used; its role is to indicate the field’s default value to developers.

2.5 Handling keys missing from reference.conf

If a field exists in a Config Bean but the corresponding key is missing from reference.conf, the outcome depends on how that field is bound (source: ConfigBeanImpl.java, Typesafe Config 1.3.2):

Case 1: the bean field has a setter but reference.conf lacks the key → startup throws an exception.

ConfigBeanFactory.create() performs a full validation before binding: it iterates over all setters, and if a setter’s key does not exist in the config object, it adds that key to a problems list, then throws a single ConfigException.ValidationFailed — the node fails to start.

No field in this project’s Config Beans uses the @com.typesafe.config.Optional annotation, so whenever a field has a setter and its key is missing, startup will always fail.

Case 2: the bean field has no setter and reference.conf also lacks the key → it can be bound manually with a hasPath() check:

// Safe: falls into the else branch when the key is missing, using a hard-coded default
mc.foo = config.hasPath("some.key") ? config.getLong("some.key") : defaultValue;

When the key is missing, the code silently falls back to the hard-coded default in code, and startup is unaffected. The cost is that this default value is invisible to operators — it cannot be found in reference.conf.

2.6 Location and contents of reference.conf (different from config.conf)

common/src/main/resources/reference.conf — located in the common module and packaged into the jar.

3. Parsing command-line arguments

3.1 Parsing approach

Command-line parsing uses the JCommander library; the fields of the CLIParameter class carry @Parameter annotations.

CLIParameter cmd = new CLIParameter();
JCommander jc = JCommander.newBuilder().addObject(cmd).build();
jc.parse(args);

Code: framework/src/main/java/org/tron/core/config/args/CLIParameter.java and framework/src/main/java/org/tron/core/config/args/Args.java

CLIParameter fields have no default values; the default values are defined in CommonParameter. JCommander tracks which parameters were explicitly passed via ParameterDescription.isAssigned(), so parameters that were not passed do not override values from the config file.

3.2 Common CLI parameters

The available CLI parameters can be viewed with --help: java -jar FullNode.jar --help .

3.3 Deprecated CLI parameters and their config-key mappings

Some legacy parameters are deprecated but still usable: using one prints a warning, and the value is mapped to the corresponding config key (the DEPRECATED_CLI_TO_CONFIG map in Args.java, lines 80–103). Deprecated parameters may be removed in future releases.

Storage

Virtual machine

Node & network

Events

In addition, passing seed node IPs as positional arguments is deprecated; at runtime the node prompts to use seed.node.ip.list in the config file instead.

4. The full execution order of Args.setParam()

The complete resolution order is:

Args.setParam(args, defaultConfigFile)
├─ 1. JCommander parses the CLI flags → CLIParameter cmd
├─ 2. Determine the config file path: if cmd.shellConfFileName is non-empty, use it; otherwise use defaultConfigFile ("config.conf")
├─ 3. Configuration.getByFileName() loads the HOCON config: config.conf ← withFallback ← reference.conf
├─ 4. applyConfigParams(config): runs fromConfig() → apply*Config() for VmConfig, NodeConfig, StorageConfig, GenesisConfig, BlockConfig, MiscConfig, CommitteeConfig, RateLimiterConfig, MetricsConfig, and NodeBackupConfig in turn
├─ 5. applyCLIParams(cmd, jc): only flags with isAssigned() == true override values in PARAMETER
├─ 6. applyEventConfig(eventConfig): the event config is applied after the CLI step so that --es takes effect
├─ 7. applyPlatformConstraints(): on ARM64, RocksDB is enforced (any dbEngine value in the config file is ignored)
└─ 8. initLocalWitnesses(config, cmd): SR private-key initialization (see Section 6)

5. The Config Bean binding mechanism

Each configuration section maps to a Config Bean class under common/src/main/java/org/tron/core/config/args/:

Keys covered by MiscConfig (scattered fields spanning multiple top-level sections, for which dedicated beans are not practical):

Binding approach

Standard fields are bound with Typesafe Config’s ConfigBeanFactory.create(section, BeanClass.class), which uses JavaBean naming conventions and reflection.

Manual binding is needed in these cases:

The HOCON key collides with a Java reserved word (e.g. native, see EventConfig).
Non-standard camelCase names (e.g. pBFTExpireNum — the JavaBean rules would expect PBFTExpireNum; see CommitteeConfig). These are handled by renaming.
Keys whose value may be null in the config file, which the binder does not support — e.g. node.discovery.external.ip.

All apply*Config() methods ultimately write the bean fields into CommonParameter.PARAMETER, the single source of configuration at runtime.

6. Loading the Super Representative private key (special handling)

Private-key sources, from highest to lowest priority:

1. The CLI --private-key flag (plaintext private key)
2. The localwitness list in config.conf (a list of private keys)
3. The keystore file path(s) in localwitnesskeystore in config.conf, plus the CLI --password

If the node is started in SR mode with -w but no private-key source is provided, the node fails to start and throws a TronError.

After Spring starts, any bean can obtain the configuration in either of the following ways:

// Option 1: inject Args (which extends CommonParameter)
@Autowired private Args args;
// Option 2: access the singleton statically
CommonParameter.getInstance()

The two are equivalent — Args.getInstance() returns the same PARAMETER object.

7. Configuration changes from v4.8.1 to v4.8.2

7.1 New configuration parameters (13)

Event subscription (event.subscribe)

Virtual machine (vm)

Node (node)

HTTP service (node.http)

JSON-RPC service (node.jsonrpc)

API rate limiting (rate.limiter)

On-chain governance (committee)

7.2 Deprecated parameters (old names still accepted as aliases, 4)

The following keys have been renamed. The old keys are still read in v4.8.2 for backward compatibility (with a deprecation warning), but reference.conf only lists the new names:

7.3 Removed parameters (23)

The following parameters are completely removed in v4.8.2. Writing them in a config file does not cause an error, but they no longer take effect.

Actuator whitelist (actuator.whitelist)

Database hot backup (storage.backup, entire group)

node.backup (the primary/standby high-availability switchover for nodes) is a separate feature and is unaffected.

Low-level networking (node.*)

InfluxDB metrics (node.metrics.influxdb, entire group)

v4.8.2 removes support for writing metrics to InfluxDB; the entire group of keys below no longer takes effect:

Prometheus metrics (node.metrics.prometheus) are unaffected and continue to work.

Network typeNetwork type (net.type)

LevelDB storage settings (storage.properties[].*)

Database index settings (storage.index.*)

8. Configuration file migration process

The latest configuration template lives at common/src/main/resources/reference.conf.

You can migrate an old configuration to the new format in two ways. To standardize on the latest template, rebuild your configuration with the new reference.conf as the baseline. To preserve a large fleet of production nodes that each carry different environment settings or deployment-specific customizations, start from your existing configuration instead. Either way, finish with a complete diff against the latest reference.conf and confirm that every remaining difference is intentional.

8.1 Option 1: rebuild using the new reference.conf as the baseline

Suitable for scenarios where the goal is a unified configuration structure and standardized config files, or a first upgrade to the new configuration format.

Migration steps:

Copy the new reference.conf as the base of the new configuration.

2. Extract the deployment-specific settings you need to keep from the old configuration.

3. Migrate these settings into the corresponding places in the new template.

4. Migrate only settings confirmed to still be needed; avoid copying entire sections of the old configuration.

5. Map renamed keys to the new version, for example:

node.maxActiveNodes → node.maxConnections
node.maxActiveNodesWithSameIp → node.maxConnectionsWithSameIp

6. For newly added keys, use the template defaults directly, adjusting them to your deployment’s needs.

7. Review the following configuration modules with particular care: storage, node, node.metrics, event.subscribe, rate.limiter.

8. Finally, diff against the latest reference.conf and confirm that all remaining differences are intentional and deployment-specific configurations.

8.2 Option 2: modify based on the old configuration

Suitable for scenarios where a large number of production node configurations already exist, with considerable environment differences or deployment-specific customizations between nodes, and the migration should preserve the existing configurations as much as possible.

Migration steps:

Keep the old configuration file as the base.

2. Referring to the new documentation and the latest reference.conf, remove deprecated configuration items. Any configuration item not present in reference.conf has no effect — for example:

All factor keys are no longer in effect and should be removed.

3. Replace renamed keys, for example:

node.maxActiveNodes → node.maxConnections
node.maxActiveNodesWithSameIp → node.maxConnectionsWithSameIp

4. Add the newly introduced keys, for example:

node.minConnections = 8
node.minActiveConnections = 3

5. Correct configuration structure and data types, for example:

Move node.metricsEnable inside the node {} block.
Change node.metrics.prometheus.port = “9527” to port = 9527.

6. Remove empty settings, invalid comments, and leftover legacy formatting.

7. Normalize the indentation, blank lines, and ordering of configuration items.

8. Finally, diff against the latest reference.conf and confirm that all remaining differences are intentional and deployment-specific configurations.

Inside the java-tron v4.8.2 Configuration System was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

Technical Guide to the GreatVoyage v4.8.2(Pyrrho) API Upgrade: JSON, HTTP API, and JSON-RPC

TRON Core Devs — Wed, 15 Jul 2026 09:46:26 GMT

1. HTTP JSON Technology Stack Upgrade: fastjson → Jackson

Why Replace fastjson?

Historically, java-tron maintained two JSON technology stacks simultaneously: fastjson and Jackson. The HTTP API primarily used fastjson, while modules like JSON-RPC and the Event Plugin relied more on Jackson. This dual-stack approach not only increased dependency maintenance costs but also easily led to inconsistencies in JSON serialization and parsing behaviors across different interfaces.

Therefore, GreatVoyage v4.8.2 unifies the underlying JSON framework of the HTTP API to Jackson. Rather than rewriting all HTTP Servlets at once, a compatibility layer has been added to org.tron.json.JSON, JSONObject, and JSONArray. The underlying implementation now uniformly uses Jackson, preserving the vast majority of existing call methods while avoiding massive modifications to business code.

This upgrade covers all /wallet*/* interfaces, as well as certain /net/* and /monitor/* interfaces that utilize the HTTP JSON parsing path. If third-party plugins rely on the fastjson provided by the java-tron runtime (such as older versions of the Event Plugin < v3.0.0), they must also be updated accordingly.

Impacts on the API

This upgrade primarily replaces the JSON Parser, not the HTTP API protocol itself.

For the vast majority of HTTP interfaces, requests continue to follow a two-stage processing flow: Parser → JsonFormat.merge() → Protobuf

Therefore, for standard JSON that conforms to the interface definition, the request processing logic remains unchanged. For invalid inputs such as repeated commas, illegal numbers, or type mismatches, many scenarios would naturally fail during the second parsing stage anyway. After upgrading to Jackson, such requests might return errors earlier, and the exception types or error messages may change, but the ultimate success or failure outcome of the interface generally remains consistent.

4.8.1: Original Body → fastjson Pre-parsing → Same Original Body → TRON JsonFormat.merge → Protobuf
4.8.2: Original Body → Jackson  Pre-parsing → Same Original Body → TRON JsonFormat.merge → Protobuf

For POST APIs on FullNode that utilize the Jackson-only path, requests bypass JsonFormat.merge() and are parsed entirely by the Jackson Parser, java-tron’s custom TypeUtils (which retains some historical fastjson conversion behaviors), and business validation logic. Post-upgrade, the handling of invalid JSON on these interfaces will align with the first category of interfaces, standardizing JSON validation standards and providing developers with a more consistent integration experience.

Affected Jackson-only APIs include:

Transactions, Accounts, and Proposals: /wallet/broadcasthex, /wallet/getaccountresource, /wallet/validateaddress, /wallet/gettransactionlistfrompending, /wallet/getproposalbyid
Rewards and Brokerage: /wallet/getReward, /wallet/getBrokerage

Compatibility Notes

For standard JSON requests that comply with interface definitions, this upgrade does not alter the protocol behavior of the HTTP API. The serialization of Protobuf and JSON remains controlled by java-tron’s self-maintained JsonFormat rather than defaulting directly to Jackson’s output. Thus, standard requests and responses remain compatible. Please note that the order of fields in JSON objects may change; however, field order is not part of the JSON protocol itself. Clients must parse based on field names and should never rely on fixed ordering or perform full-string comparisons of responses.

While java-tron currently retains some of fastjson’s loose parsing behaviors (such as single quotes, unquoted field names, and trailing commas) to lower migration costs, these behaviors are solely for backward compatibility and are not part of the API contract. We strongly advise callers to strictly adhere to the RFC 8259 standard when constructing JSON requests, and do not rely on the loose parsing behaviors from either Jackson or fastjson, including single quotes, unquoted field names, trailing commas, leading plus signs, and leading zeros.

We also highly recommend the following:

Parse JSON by field names; do not rely on the order of returned fields.
Do not rely on specific exception types or error texts.
Third-party plugins must explicitly declare their own JSON dependencies and no longer assume java-tron provides com.alibaba.fastjson.*.

2. JSON-RPC: Closer Alignment with Ethereum Client Conventions

To further improve compatibility with Ethereum ecosystem tools and clients, GreatVoyage v4.8.2 optimizes several JSON-RPC interfaces, bringing their behaviors closer to the Ethereum JSON-RPC specifications while reducing adaptation costs for cross-chain tools.

2.1 input as a Calldata Alias for data

Previously, some Ethereum clients (such as go-ethereum) only sent the input field, which older versions of java-tron treated as an unknown field and subsequently rejected the request. GreatVoyage v4.8.2 (Issue #6517, PR #6722) adds support for the input field, making it a calldata alias for data.

Affected Interfaces:

eth_call
eth_estimateGas
buildTransaction

Post-Upgrade Behavior:

We recommend that new clients uniformly use

"input": "0x…"

and ensure the use of the 0x prefix with an even byte length. Although empty strings will also be parsed as empty bytes, using 0x to represent empty calldata is highly recommended to maintain cross-client compatibility.

2.2 Transaction Object nonce Standardized to Ethereum QUANTITY Format

To further align with Ethereum JSON-RPC, PR #6709 adjusts the return format of the nonce in transaction objects.

Previous Return Value:

“nonce”: “0x0000000000000000”

Adjusted Return Value:

“nonce”: “0x0”

Affected Interfaces:

eth_getTransactionByHash
eth_getTransactionByBlockHashAndIndex
eth_getTransactionByBlockNumberAndIndex
eth_getBlockByHash
eth_getBlockByNumber (when fullTransactions=true)

Please note that this adjustment only applies to the nonce encoding format within transaction objects; the numerical semantics remain unchanged. The nonce within block objects remains in bytes8 format (e.g., 0x0000000000000000) and is unaffected by this upgrade. Therefore, if clients rely on string snapshots, fixed-length validations, or literal value comparisons, they must adapt their code accordingly.

2.3 blockTimestamp Added to Log Objects

To lower the cost of fetching block timestamps for indexers, a blockTimestamp field has been added to Log objects. Callers no longer need to query the block separately to determine the time of the block containing the log.

Affected Interfaces:

eth_getLogs
eth_getFilterLogs
eth_getFilterChanges (Log Filters)
eth_getTransactionReceipt (logs[])
eth_getBlockReceipts (logs[] of each Receipt)

The new field uses a Unix timestamp (in seconds) prefixed with 0x, rather than the internal millisecond timestamp used by TRON. The top-level Receipt does not include a field of the same name.

Recommendations for Callers:

Allow the new field when performing strict Schema validation.
Ensure compatibility during rolling upgrades when older nodes may not yet return this field.

JavaScript Example:

JavaScript

const timestampMs = Number(BigInt(log.blockTimestamp) * 1000n);

3. Proto Definitions

To clean up legacy configurations, GreatVoyage v4.8.2 reorganizes the Proto files in the protocol repository, removing the deprecated google.api.http annotations. Specifically, Issue #6548 (PR #6726, PR #6874) removed the google.api.http mappings from api.proto, and subsequently, PR #6762 removed the residual google/api/annotations.proto dependency. As of v4.8.2, all related HTTP annotations have been completely removed.

These adjustments will not affect the HTTP API provided by the node, but they will impact developers who rely on automatically generated code based on Protos.

HTTP Annotation Removal: This affects methods previously annotated with google.api.http across four services: Wallet, WalletSolidity, WalletExtension, and Monitor. If your project relies on Proto annotations to automatically generate grpc-gateway REST routing, you will need to maintain the corresponding mappings yourself or continue retaining older versions of the Proto files.

4. Event Plugin Upgrade Requirements

Alongside the fastjson → Jackson upgrade, the Event Plugin must also be adapted synchronously. This version introduces the following primary changes:

New Plugin-Version Validation Mechanism: For nodes that enable Event Subscribe and load external Event Plugins (including the official Kafka/MongoDB plugins and custom PF4J plugins), the Plugin-Version will be checked upon startup.

Plugin-Version >= 3.0.0: Allowed to load.
Version < 3.0.0 (or missing/unparseable): The plugin will fail to start, ultimately terminating node startup with EVENT_SUBSCRIBE_INIT.

(Note: When event.subscribe.native.useNativeQueue=true, the Native Queue is used, and external plugins are not loaded; thus, this check is not triggered.)

It is important to note that the Plugin-Version validation merely verifies the plugin version; it does not guarantee that Jackson adaptation is complete. For custom plugins, simply updating the version number to 3.0.0 or higher is insufficient. Developers must actively remove dependencies on the node runtime’s fastjson and implement the necessary code adaptations.

Important Note for Developers: Due to the JSON stack upgrade, the parameter types for ContractEventParserJson.parseTopics and parseEventData have been changed from com.alibaba.fastjson.JSONObject to org.tron.json.JSONObject. If a custom plugin calls these interfaces directly, you must update the imports and parameter types, and recompile the plugin against v4.8.2. Failing to do so may still trigger a NoSuchMethodError due to method signature changes.

The Event Plugin v3.0.0 has been officially released and is available here:

https://github.com/tronprotocol/event-plugin/releases/tag/v3.0.0

This version is backward compatible with GreatVoyage v4.8.2 and earlier versions. We highly recommend that developers using the Event Plugin complete their upgrades as soon as possible. After upgrading nodes to GreatVoyage v4.8.2, please pay special attention to verifying that the Plugin Manifest, node startup logs, and event message flows are operating normally.

Technical Guide to the GreatVoyage v4.8.2(Pyrrho) API Upgrade: JSON, HTTP API, and JSON-RPC was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

TVM Osaka Upgrade: Passkeys, Single-Instruction, and Rebuilt ModExp

TRON Core Devs — Mon, 13 Jul 2026 09:36:38 GMT

A Preview of Network Parameter ALLOW_TVM_OSAKA — Releasing with GreatVoyage-v4.8.2(Pyrrho)

To bridge TRON with hardware-grade security standards and significantly reduce on-chain costs for complex cryptography, a new round of TRON Virtual Machine upgrades has been introduced in the release_v4.8.2 branch. It is controlled by an on-chain governance switch — network parameter AllOW_TVM_OSAKA, parameter number 96.

This upgrade introduces a new set of enhancements to the TRON Virtual Machine (TVM). This article highlights three key improvements that directly expand smart contract capabilities: native verification of signatures generated by secure hardware, a new opcode for more efficient bitwise operations, and an enhanced modular exponentiation precompiled contract with improved gas accounting and boundary handling.

Below is a breakdown of what they do, how much energy they consume, and what you should check in your contracts before the vote.

Activation Mechanism

First, let’s clarify a term, as it directly affects how you read this proposal on-chain: 96 is the chain parameter number, not the proposal ID. A TRON proposal carries a map mapping of “parameter → value” and has its own independent, incrementing proposal_id. The feature is activated through a governance proposal. Super Representatives vote on a proposal containing this parameter change, and once the proposal is approved, the feature becomes effective.

This switch has two prerequisites and is irreversible:

The entire network must be upgraded to the VERSION_4_8_2 (block version 36).
Before it takes effect, none of the following behaviors exist: opcode 0x1e is unregistered, ModExp billing remains exactly as it is today, and there is no precompiled contract at 0x100.
The parameter can only be set to 1. There is no path to revert it to 0, and duplicate proposals for an already active parameter will be rejected.

Upgrading a node to 4.8.2 does not activate any of these features. However, if you are a block-producing node, the upgrade will bring a visible change: the block headers you sign will include block version 36 — this is exactly the signaling mechanism for the hard fork itself, and it is how the network satisfies the VERSION_4_8_2 prerequisite. As for VM semantics, they will switch for everyone simultaneously at the maintenance block when the parameter takes effect.

1. P256VERIFY: The Curve Your Phone Has Been Using All Along

TVM has supported verifying secp256k1 signatures since day one. That is the curve chosen by Bitcoin and Ethereum. But it is not the curve chosen by the rest of the computing world.

Apple’s Secure Enclave, Android’s Keystore, WebAuthn, Passkeys, TPMs, smart cards, and almost all hardware security modules on the market speak secp256r1 — also known as NIST P-256 or prime256v1. Previously, if a TRON contract wanted to verify such signatures, it had to run full curve operations in Solidity, at a cost that deterred the vast majority of applications.

Osaka introduces P256VERIFY as a native precompiled contract.

Specifications

Note this address. TRON’s own precompiled contracts are located in an independent numbering range, but P256VERIFY deliberately reuses 0x100 — the exact same slot specified by Ethereum’s EIP-7951. Contracts and auditing tools already written for 0x100 can work on TRON without any modifications.

For reference, here is how the new precompile compares to the existing signature verification standard:

(Note: Both of these numbers are strictly the fees for the precompiled contracts themselves; the outer CALL or STATICCALL will also incur the basic opcode overhead and memory expansion costs.)

Checks Performed During Execution

Before any curve operations, the precompiled contract checks that 0

Three Behaviors You Must Internalize

It does not revert. As long as the forwarded energy is sufficient for its execution, all failure paths — invalid lengths, scalar out-of-bounds, points not on the curve, signature verification failures — return “success + empty data.” Your contract must check the return data, not the CALL status. This is exactly in line with EIP-7951. (If the forwarded energy is less than 6900, you will get a standard out-of-energy result: 0 pushed to the stack, and the precompiled contract is not executed at all.)
No low-s malleability check. Following the specification, s is only range-checked to [1,n-1]. Both s and n — s will simultaneously pass verification for the same message and the same public key. If your design treats the signature as a unique identifier, nonce, or replay protection, it is vulnerable. Please hash the message body and track that hash instead. This is the easiest trap to fall into with this precompile, and it’s not a TRON implementation flaw — that’s just how the standard is written.
Feature detection must check return data. Before the parameter takes effect, 0x100 is not a registered precompiled contract — it’s just a regular address with no code. Therefore, calling it will succeed and return empty data, rather than pushing a 0 to the stack. Contracts probing for the availability of P256VERIFY must distinguish between “returned a 32-byte 1” and “returned nothing.” You must never treat a successful CALL as proof that the precompiled contract exists.

What It Unlocks, and What It Doesn’t

This precompiled contract is the missing cryptographic primitive for scenarios like Passkey accounts, hardware-endorsed authorization, and enterprise HSM signatures. But it is not a WebAuthn implementation in itself.

P256VERIFY accepts an already-calculated 32-byte digest, plus the bare (r,s,qx,qy). It does not parse DER or COSE encoded public keys, does not hash WebAuthn’s clientDataJSON/authenticatorDatapayloads for you, and does not verify the challenge, origin, RP ID, authenticator flags, signature counters, or attestations. It also cannot tell you whether the private key behind the signature is truly secured by hardware or if it’s non-exportable. A production-grade Passkey wallet still needs to write these verification logics into the contract on top of the precompile. What changes is that the most expensive part — the curve operation — is no longer a bottleneck.

2. CLZ: Counting Leading Zeros in a Single Instruction

Opcode 0x1e, mnemonic CLZ. One in, one out. Five energy — the LOW tier, on par with MUL.

It pops a 32-byte word, reads it in big-endian format, and pushes back the number of its leading zero bits, ranging from [0,256].

CLZ(0x0000…0000) = 256
CLZ(0x0000…0001) = 255
CLZ(0x4000…0000) = 1
CLZ(0x8000…0000) = 0
CLZ(0xFFFF…FFFF) = 0

The zero-value line is worth emphasizing separately: CLZ(0) returns 256 — neither 0 nor an error.

This is a small change, but it has a disproportionately large impact on a specific class of code. log2, integer square roots, fixed-point number normalization, Bancor and constant-product price curves, bitmap scanning, large integer libraries — currently, they all rely on hand-written binary search (typically seven to eight rounds of SHR plus comparisons) to locate the most significant bit. That loop now becomes a single opcode.

Before the parameter takes effect, 0x1e is not a registered opcode. Bytecode can contain it, but any execution path that actually hits it will trigger an invalid opcode exception halt, burning all remaining energy in the current call frame. This is different from REVERT — REVERT refunds unused energy to the caller. So: either add runtime switch protection or wait until the vote passes before deploying bytecode containing CLZ.

3. ModExp: Constrained Inputs and Pricing Matched to True Overhead

The modular exponentiation precompiled contract located at 0x05 is the workhorse behind RSA signature verification, VDFs, and various Zero-Knowledge constructions. Its pricing has not been re-evaluated for a long time. Osaka addresses this from three directions.

Input Upper Bounds (EIP-7823)

The upper limits for baseLen, expLen, and modLen are now individually capped at 1024 bytes.

Exceeding the limit will not revert the entire transaction. The precompile returns a failure, CALL pushes 0 to the stack, RETURNDATASIZE is 0, and execution continues — this matches the behavior of geth and besu: only the subcall fails.

One detail is worth stating precisely: this boundary is checked during the execution phase, not within the billing function. The VM first calculates the cost, checks it against the energy you forwarded, executes the precompile, and then refunds no energy when it reports a failure. Therefore, an out-of-bounds call will cost you the entire energy budget forwarded to that subcall. Out-of-bounds inputs will be rejected, but the rejection is not free.

Repricing (TIP-7883)

Before getting to the formulas, here are two definitions. Let m = max(baseLen, modLen). Let highestBit be the zero-based index of the highest significant set bit in the first min(expLen, 32) bytes of the exponent; if these bytes are all zero, it evaluates to 0. All divisions below are integer truncating divisions.

Simply put: Imagine writing the exponent in binary. highestBit is just counting how many bits are to the right of the leftmost 1. For example, 0x02 is 0000 0010 in binary. The leftmost 1 is at index 1 (counting from 0 from the right), so highestBit = 1. Likewise, 0x01001 yields 16.

Current TVM Billing:

multComplexity(m):
    m ≤ 64     →  m²
    m ≤ 1024   →  m²/4 + 96m − 3072
    otherwise  →  m²/16 + 480m − 199680

adjExpLen:
    expLen ≤ 32  →  highestBit
    otherwise    →  8 × (expLen − 32) + highestBit

energy = multComplexity × max(adjExpLen, 1) / 20

After Osaka:

multComplexity(m):
    m ≤ 32     →  16
    otherwise  →  2 × ceil(m / 8)²

iterCount:
    expLen ≤ 32  →  highestBit
    otherwise    →  16 × (expLen − 32) + highestBit
    (minimum 1)

energy = max(multComplexity × iterCount, 500)

Four changes: the complexity curve is replaced by a much flatter one; the multiplier for long exponents is doubled from 8 to 16; the /20 divisor is removed; and a floor of 500 is introduced.

This is not an across-the-board price hike, and describing it as such is incorrect. Removing the /20 divisor, viewed in isolation, pushes prices up. However, the new complexity curve drastically lowers the cost of medium-sized operands, and under certain shapes, it will win out.

Key Takeaway: The Net Result is Cheaper for Medium Operands.

Please stare at the 128-byte row and walk through the math, because the intuition here is backward. The original complexity drops from 13,312 to 512 (a 26x reduction); losing the /20divisor pulls the price back up by 20x. The net result is a cost reduction: 665 → 512.

The floor raises the price of trivial calls, the doubled long exponent multiplier raises the price of genuinely expensive calls, and the middle ground could swing in either direction. If you have been budgeting under the assumption that “Osaka will uniformly make ModExp more expensive,” please re-measure using your actual operand sizes.

Zero Modulus Normalization (TIP-871)

For a successful, non-out-of-bounds call where modLen > 0, when the modulus is numerically zero, ModExp previously returned an empty byte array. After Osaka, it returns an all-zero buffer with a length equal to modLen.

Mathematically, x mod 0 is undefined, so this return value has always been a convention rather than a computed result. The new convention is the more useful one: the caller can determine the size of the return buffer solely from the declared modLen, eliminating the need to write special-case branches for a zero modulus. Pay attention to those qualifiers — out-of-bounds calls still fail with empty return data, and calls where modLen ==0 return zero bytes both before and after the change.

What to Do Before the Vote

Contract Developers: If you call ModExp, please recalculate your costs with your actual operand sizes; do not assume the direction of the price change. If you rely on a zero modulus returning empty data, that behavior has changed. If you plan to adopt P256VERIFY, read the section on malleability twice — check the return data, never check the CALL status, and never treat signatures as unique identifiers. The same rule applies to feature detection: 0x100 will successfully respond today, it’s just that there’s nothing inside.
Toolchain and Compiler Authors: CLZ at 0x1e requires disassembler and analyzer support. Emitting this instruction before the parameter takes effect will generate bytecode where, if the execution path actually reaches it, it will cause an exception halt and burn all remaining energy in that frame.
Super Representatives: ALLOW_TVM_OSAKA (parameter 96) requires that the VERSION_4_8_2 hard fork has passed, only accepts a value of 1, and is irreversible. It can be voted on individually or bundled with other parameters into a single proposal.
Node Operators: Upgrading to 4.8.2 itself does not activate anything. If you produce blocks, note that your block headers will carry block version 36 — this is the fork signal, which is exactly the intended effect.
Test It Yourself: Developers are strongly encouraged to deploy and test these changes on the Nile testnet using the latest toolchains to audit their ModExp budgets and P256VERIFY integrations before the parameter officially takes effect on Mainnet.

Bonus: A Sneak Peek at Another VM Upgrade in 4.8.2

Osaka is not the only VM-facing parameter in this release. ALLOW_TVM_PRAGUE (parameter number 95) introduces TIP-2935: serving historical block hashes from state using a sliding window of 8191 blocks. The system contract that hosts it has a 20-byte VM address and 83 bytes of runtime code that are completely identical to Ethereum’s EIP-2935 contract. (When the parameter takes effect, TRON writes this code directly into state, rather than replaying Ethereum’s pre-signed, keyless deployment transaction; the address is stored in the 21-byte TRON format prefixed with 0x41.)

It has its own prerequisites: it requires ALLOW_TVM_SHANGHAI to already be active, because the deployed runtime code contains PUSH0. Also, it does not backfill: the ring buffer writes one parent hash per block starting from the moment it takes effect. Therefore, slots corresponding to earlier blocks within the window will return bytes32(0) until it fills up roughly 8191 blocks later. It is an independent parameter that Super Representatives can vote on individually or bundle with Osaka. It deserves its own article, and that one is coming soon.

GreatVoyage-v4.8.2 is located in the release_v4.8.2 branch of tronprotocol/java-tron. The aforementioned features land in PRs #6720 (P256VERIFY), #6656 (CLZ), #6654 (TIP-7883), #6611 (EIP-7823), and #6780 (TIP-871), respectively. TIP-2935 lands in #6686.

TVM Osaka Upgrade: Passkeys, Single-Instruction, and Rebuilt ModExp was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

Trying TRON Post-Quantum (PQ) Signatures on the Testnet

TRON Core Devs — Thu, 02 Jul 2026 15:23:39 GMT

Target Audience: ordinary users, developers, and blockchain enthusiasts who want to try out post-quantum signatures on the Nile testnet.

You don’t need to understand cryptography — being comfortable with the command line and copy-paste is enough.

⚠️ Everything here happens on the testnet with test coins; no real assets are involved.

What this is, and why it’s worth trying

Future quantum computers may be able to break the elliptic-curve signatures (ECDSA) in wide use today. To prepare ahead of time, TRON has added post-quantum (PQ) signatures at the protocol level, and is opening them up for early hands-on testing on the Nile testnet first.

You can create a post-quantum wallet and use it to send transactions. Each transaction is signed by a post-quantum algorithm, making it harder to forge even if quantum computers arrive.

TRON currently supports two NIST-standardized schemes for both system transactions and smart contracts, gated by two proposals:

Tip: both PQ signatures are more than 10x larger than a regular ECDSA signature, so PQ transactions consume more bandwidth — that’s the inherent cost of post-quantum signatures.

A quick size comparison of public keys and signatures:

Before you start

Java 8 (JDK 8) — required to run wallet-cli (and to build your own Nile node).
wallet-cli (post-quantum branch) — TRON’s official command-line wallet; PQ support lives on the feature/post-quantum branch:

— Repo: https://github.com/tronprotocol/wallet-cli
— Branch: feature/post-quantum

3. A Nile node that supports PQ — used to broadcast your transactions. Pick one of:

— Connect to a public Nile endpoint directly (configured in Step 1, easiest);
— Or run your own Nile full node per the official docs: https://nileex.io/run/getRunPage

4. Test TRX — claim it for free from the Nile faucet: https://nileex.io/join/getJoinPage

5. Block explorer — look up transactions / addresses / proposal status: https://nile.tronscan.org

⚠️ Key prerequisite: the PQ proposals must already be active on-chain. A PQ transaction is only accepted after the ALLOW_FN_DSA_512 (Falcon) / ALLOW_ML_DSA_44 (Dilithium) proposals have passed and taken effect; otherwise it is rejected even if the signature is perfectly valid. These proposals are turned on by Super Representative vote, and the activation time is not fixed — keep an eye on the progress (official announcements + the explorer’s Proposals page).

To check whether a scheme is enabled, use the command below to query the status of the two PQ parameters:

curl -s https://nile.trongrid.io/wallet/getchainparameters \
 | grep -oE '"getAllow(FnDsa512|MlDsa44)"[^}]*'

How to read the result: an entry containing value:1 means activated; if you only see the key with no value field, it is not yet activated. https://nile.trongrid.io can be replaced with any Nile HTTP node (including your own node, e.g. http://127.0.0.1:8090). You can also run GetChainParameters in wallet-cli’s interactive mode to see the same values.

Download the wallet-cli source

git clone -b feature/post-quantum https://github.com/tronprotocol/wallet-cli.git
cd wallet-cli

Step 1: Point the config at Nile, then build

wallet-cli connects to mainnet by default. Edit src/main/resources/config.conf (or whatever config file you use), change config item fullnode.ip.list to below:

fullnode = {
  ip.list = [
   "grpc.nile.trongrid.io:50051"
  ]
}

Use the latest endpoints published by TronGrid/Nile; if you run your own PQ full node, replace fullnode with your own address (e.g. 127.0.0.1:50051).

Build only after editing the config, to produce the runnable JAR:

./gradlew clean build

After the build, the JAR is at build/libs/wallet-cli.jar — you’ll use it to start the wallet in the next step.

Step 2: Create a PQ wallet

Start the interactive wallet:

java -jar build/libs/wallet-cli.jar

Use RegisterWalletPQ to create a post-quantum wallet, with an optional scheme argument (defaults to Falcon-512 if omitted):

wallet> RegisterWalletPQ                # default FN_DSA_512 
# or 
wallet> RegisterWalletPQ ML_DSA_44      # choose ML_DSA_44

Follow the prompts to enter your password twice. On success it writes an encrypted keystore under Wallet/ and prints your address:

Please input password.
Please input password again.
RegisterWalletPQ successful, keystore file: 
./Wallet/TXxxx...xxx.json

🔑 Note down this TXxxx… address, which you will find it in the next step.

A PQ wallet is password-encrypted just like a regular wallet. The keystore has a scheme field that records which PQ scheme it uses.

(Optional) Just want to see what a key looks like?

GeneratePQKey[scheme] generates a keypair and prints it but does not save it — handy for a first look, after which you can import it with ImportWalletPQ.

Step 3: Fund your PQ address with test coins

A post-quantum address looks exactly the same as a regular T-address, so the faucet works as usual:

Open the Nile faucet: https://nileex.io/join/getJoinPage
Enter the TXxxx… address from the previous step and claim test TRX.
Search for your address on https://nile.tronscan.org to confirm it arrived.

Step 4: Send a post-quantum transaction

Back in wallet-cli, log in with the address and password from before:

wallet> Login
# select/enter your PQ wallet, then type the password

Then transfer as usual — for example, send 1 TRX to some address (1 TRX = 1_000_000 sun):

wallet> SendCoin  1000000

The wallet signs automatically using your wallet’s PQ scheme; you do not need to perform any extra steps. A successful broadcast means Nile has accepted this post-quantum transaction 🎉.

Other commands (TransferAsset, TriggerContract, etc.) also sign with PQ automatically.

Step 5: Verify it in the block explorer

Look up your transaction on the https://nile.tronscan.org explorer to ensure it reaches finality and is recorded on-chain. If valid, you should see a PQ tag indicating the specific quantum-resistant algorithm used.

The difference from a regular transaction is that the signature sits in the pq_auth_sig field (parallel with the previous signature field). Further, you can find all transaction details through API https://nile.trongrid.io/wallet/gettransactionbyid.

Backup and security (please read)

This feature is currently for testnet experimentation and feedback.

When creating a wallet, securely save the persisted private key. Back up the keystore file + password as well.

Do not reuse testnet keys in any mainnet / real-asset context.

PQ private keys are very long and store them in a file kept offline.

Limitations in the current version

This section lists features that PQ wallets currently cannot use, or that have known limitations, on the wallet-cli feature/post-quantum branch — so testers know in advance and avoid confusion.

Gas-free transfer (GasFreeTransfer): relies on an off-chain EIP-712 permit signature (ECDSA secp256k1); since that protocol does not yet define a PQ scheme, it cannot be supported. Workaround: use a regular ECDSA wallet for GasFree scenarios.
Mnemonic-related operations: PQ wallets do not generate BIP-39 mnemonics and cannot be exported or recovered through one. Backup alternative: use BackupWallet to export the private-key hex and ExportWalletKeystore to back up the JSON file.
Ledger hardware wallet: Ledger firmware only supports ECDSA signatures and currently can’t handle post-quantum algorithms; the two are incompatible.

These limitations will be lifted gradually as the surrounding toolchain gains native pq_auth_sig support; they are all temporary technical constraints for now.

FAQ

Q1: My transaction was rejected by the node?

The most common cause is that the target network hasn’t activated the corresponding proposal yet. A PQ transaction is only accepted after the ALLOW_FN_DSA_512 (Falcon) / ALLOW_ML_DSA_44 (Dilithium) proposal is active. Follow To check whether a scheme is enabled in Section 2 and use getchainparameters to confirm the switch’s value is 1; if it is 0 or the field is absent, it isn’t active yet and you must wait for the proposal to pass before retrying.

Q2: My PQ address looks identical to a regular address — is that normal?

Yes. PQ addresses are derived with the same formula as regular addresses and are indistinguishable before signing. To confirm a wallet’s type, check the scheme field in the keystore JSON.

Q3: Can a single multisig transaction mix PQ wallets and regular wallets?

Yes. In a multisig, each participant signs with the algorithm of their own keystore (PQ signs with PQ, regular signs with ECDSA/SM2) — they don’t interfere with each other.

Feedback

Hit a problem or have suggestions? Feedback is welcome in the TRON community / on GitHub:

java-tron: https://github.com/tronprotocol/java-tron
PQ TIP: https://github.com/tronprotocol/tips/issues/899
wallet-cli: https://github.com/tronprotocol/wallet-cli

Have fun, and let’s get the blockchain ready for the post-quantum era together 🚀

— — End of guide — —

Trying TRON Post-Quantum (PQ) Signatures on the Testnet was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

TRON Post-Quantum Signature Design

TRON Core Devs — Wed, 01 Jul 2026 04:05:22 GMT

Summary

Introduce post-quantum (PQ) digital signature support at the TRON protocol layer. The first activation enables two post-quantum signature algorithms — Falcon-512 (FN_DSA_512) and Dilithium2 (ML_DSA_44) — covering all consensus-flow signatures. Falcon-512 remains the primary choice for its compact size; ML-DSA-44 is implemented in parallel as a NIST-finalized (FIPS 204) hedge against the still-draft FN-DSA standard. Each is independently gated by its own on-chain governance proposal. The design principle is to leave the Account structure unchanged — the address field carries both ECDSA- and PQ-derived addresses in an “algorithm-agnostic” way. New PQAuthSig fields are added to Transaction, BlockHeader, and HelloMessage payloads, and verification is routed to the matching path based on which signature field is set.

Target timeline: launch the testnet in Q2 2026, completing the deployment ~3 years ahead of the industry-projected quantum-threat threshold (~2029) and positioning TRON as the first major public blockchain to complete a full PQ migration.

Problem

Motivation

All major blockchains today (TRON, Bitcoin, Ethereum, BNB Smart Chain, etc.) use elliptic-curve cryptography (ECDSA) for consensus-flow signatures. The security of ECDSA rests on the discrete-logarithm problem, which would take billions of years for a classical computer to solve but only minutes for a quantum computer running Shor’s algorithm. The industry widely projects the quantum-threat threshold to arrive around 2029; on Bitcoin alone, over 6.9M BTC (~1/3 of supply) sit at addresses whose public keys are already exposed.

Cryptographic migration itself is highly complex: protocol changes, third-party security audits, and adoption across wallets, exchanges, and contract ecosystems typically take a long time. Waiting until the quantum threat actually arrives is too late; the work must start now.

Current State

All TRON transaction and block signatures currently use secp256kl ECDSA, with addresses derived as 0x41 || Keccak-256(ecdsa_pk[1:])[12..32]. The protocol layer carries no post-quantum-signature fields.
The TVM precompiles ValidateMultiSign, BatchValidateSign, and ECRecover all depend on ECDSA and cannot be directly reused for PQ signatures, which require an explicit public key as an input parameter.

Post-Quantum Algorithm Challenges

PQ algorithms, the same as ECDSA, are based on public-key / private-key pairs, but porting them to the protocol layer raises several core challenges.

Explicit public-key transmission — the core problem to solve in this cycle

ECDSA has the Swiss-army-knife ecrecover: given a 65-byte secp256kl signature, the node can recover the public key (65 bytes) and derive the account address (21 bytes). This lets the TRON transaction carry no public key at all; all upper-layer protocols rest on this implicit convention.

Falcon, ML-DSA, SLH-DSA, and other PQ algorithms have no equivalent recover primitive:

Falcon key recovery is still at the academic-research stage; BouncyCastle 1.84 has not yet exposed any related API.
ML-DSA / SLH-DSA do not, by design, support recovering the public key from a signature.

In other words, to verify a PQ signature, a node must first obtain the full public key. This is the first problem this round of protocol changes must solve. The concrete design choice boils down to where to store the public key. We weighed two paths:

Option A — store the PQ public key on chain; transactions only reference it. The simple transfer TRX transaction body would still grow ≥ 5× because the Falcon signature alone is ~11× the size of an ECDSA signature. Additional costs: passively activated accounts have no public key on file, account state inflates significantly, wallets cannot sign without reading real-time on-chain data, and the protocol layer itself requires substantial new design — on-chain key-storage layout, the reference mechanism used from transactions, key-rotation semantics, etc. — none of which has a validated, mature precedent in any major chain today, translating into notable stability risk.
Option B — carry the PQ public key inside each transaction. Benefits: minimal protocol intrusion (account state fields are unchanged), zero friction for passively activated accounts, and stateless signing from wallets / SDKs. The only downside compared with Option A is that the transaction body grows >= 10× (a cost that could be optimized over time).

Weighing the three dimensions of “minimal intrusion into the existing protocol, lowest first-release implementation cost, smallest ecosystem-side change”, we choose Option B, which can be iteratively optimized as the scheme matures and more community feedback is incorporated, whereas Option A’s architectural problems (passive activation, Account-structure breakage) would be virtually irreversible once shipped. Implementation details are covered below in Proposed Design.

Per-signature size inflation — known cost, optimizable in stages

As mentioned above a side effect of carrying the public key is the jump in signature footprint: a Falcon-512 public key + signature is ~25× the ECDSA size. The table below compares ECDSA against three PQ candidates:

Falcon-512 has the most compact size profile and is the primary algorithm; ML-DSA-44 is also supported, with a larger per-transaction footprint (~2.3× Falcon) accepted as the cost of having a FIPS-finalized fallback already wired into the protocol. SLH-DSA remains out of scope this cycle due to its signature size.

This constitutes a material protocol-layer overhead and is treated as an explicit trade-off rather than a minimized concern. As the initial launch design — with PQ adoption expected to stay low in the early phase — the size growth is acceptable and not a launch blocker. Future optimization paths include Falcon key-recovery mode, which can reduce per-transaction wire size, and a possible BLOCK_SIZE increase. The BLOCK_SIZE change must be proposed through a separate dedicated TIP under the standard governance process and should not be bundled with this PQ rollout.

Design

Core design principles: the Accountprotocol structure is completely unchanged. The account address is derived from the signing public key via Keccak-256, and the derivation is decoupled from the signing algorithm — ECDSA, Falcon, and ML-DSA public keys share the same slicing rule and produce addresses in the standard 21-byte T-prefixed form (e.g. TTW663tQYJTTCtHh6DWKAfexRhPMf2DxQ1).

Transactions and blocks add a PQAuthSig field to carry the full PQ signature along with its public key. This field coexists with the original signature field; it is neither a replacement nor mutually exclusive, except for block signatures, where only one of the two may be set. Nodes dispatch verification based on which field is present.

After obtaining the public key, both paths converge on the same permission-check flow: derive address → match against Permission.keys[] → accumulate weight → compare against threshold. A single transaction may carry a mix of ECDSA, Falcon, and ML-DSA signers, with their weights pooled into one sum.

1. New PQ signature structure

message PQAuthSig {
  PQScheme scheme = 1; // Mandatory; UNKNOWN_PQ_SCHEME (proto3 default) is rejected at validation time.
  bytes public_key = 2;
  bytes signature = 3;
}
enum PQScheme {
  UNKNOWN_PQ_SCHEME = 0; // proto3 default; never registered, rejected at validation
  FN_DSA_512 = 1; // Falcon-512 (FIPS 206 draft)
  ML_DSA_44 = 2; // ML-DSA-44 (FIPS 204, finalized)
}
// Example: the transaction body gains a PQAuthSig field
message Transaction {
  …
  repeated bytes signature = 2;
  …
  repeated PQAuthSig pq_auth_sig = 6; // newly added field
}

2. Four PQ signature channels and field additions

3. Address derivation (identical form to ECDSA derivation)

Address derivation (identical form to ECDSA derivation):

pq_address = 0x41 ‖ Keccak-256(pq_public_key)[12..32]

The address stays 21 bytes with the T prefix, fully compatible with the existing ECDSA address format; only the hash input differs. Collision probability is algorithm-independent and remains at $1/2^{160}$ .

4. Signature target (unchanged)

Transaction signature target: txid = SHA-256(Transaction.raw)
Block signature target: blockHash = SHA-256(BlockHeader.raw)
Relay-identity signature target: SHA-256(BigEndian(timestamp)) (inherits the existing ECDSA digest construction)

5. TVM precompiles

We do not reuse 0x09 / 0x0A because the PQ verification interface verify(pk,msg,sig)→ bool provides no way to recover the public key — the caller must supply the full public key explicitly.

Falcon precompiles gate on ALLOW_FN_DSA_512; ML-DSA precompiles gate on ALLOW_ML_DSA_44; 0x1a is available when either is active.

6. Governance activation

The algorithm-agnostic multi-sign precompile 0x0200001a ValidateMultiPQSig is enabled when either proposal is active.

7. Performance

Single-operation cost (500-run average, measured by SignatureSchemeBenchmarkTest):

Both PQ schemes improve signature-verification CPU on the consensus hot path; the binding constraint is transaction size, not verify cost. TPS ceiling scales with the blended average transaction size against a roughly constant block-byte throughput:

In the early transition phase, PQ adoption will be limited, keeping the size increase manageable. Falcon-512 serves as the default size-efficient choice, while ML-DSA-44 provides a FIPS-finalized fallback for specialized multi-sig use cases. The PQ functionality will soon live on the Nile testnet, where we are actively monitoring feature stability and gathering performance data to inform future enhancements. Moving forward, optimization work will focus on Falcon key-recovery for footprint reduction and, if needed, a possible BLOCK_SIZE increase proposed through a separate dedicated TIP under the standard governance process.

Account Migration

Regular account Migration

Regular accounts can choose either of the two paths below:

Path 1: in-place permission replacement (zero asset movement) — an AccountPermissionUpdateContractthat simultaneously adds a PQ-derived Key and rebalances the Permission so that no ECDSA-only signature set can meet the threshold.

⚠️ The rebalancing step is mandatory for quantum safety. Simply adding a PQ key while leaving the existing ECDSA key with enough weight to meet the threshold alone provides no actual PQ protection — a quantum attacker who breaks the ECDSA key still controls the account. The PQ key in that case adds only key-management overhead, not security.

Any configuration that requires at least one PQ signature in every passing signature set is acceptable. Examples:

Operators choose the strictness based on tolerance for ECDSA continuity during the transition. Once the rebalancing is in effect, the old account address, assets, contract bindings, cross-chain whitelists, and DApp integrations are all preserved. Costs: the one-shot permission-update fee plus the standard MultiSignFee for any subsequent multi-sig transaction.

Path 2: asset migration, deprecating the old account. Operators must generate a brand-new PQ account, transfer all TRX / TRC10 / TRC20 / staked / delegated assets to the new account (staked / frozen resources must first be released via UnfreezeBalance / UnDelegateResource, then wait out the unlock window), and finally deprecate the old account. This fully cuts off the quantum attack surface, at the cost of transfer fees, the unlock waiting period, and address-change adaptation across external systems (exchanges, DApps, cross-chain bridges, contract whitelists).

SR Account Configuration

SR accounts — after PQ is enabled on mainnet, complete the Witness Permission switch and configure the pre-derived keypair through the localPqWitness section in config.conf. Each entry in localPqWitness.keys is a JSON key-file path. The key file itself specifies the scheme.

Ecosystem Integration

Wallets / SDKs / exchanges / block explorers — need to extend key management, address derivation, signature construction, node-capability detection, and pq_auth_sig field parsing. PQ keypairs can be generated with TRON’s Toolkit via the pq-key new command:

java -jar build/libs/Toolkit.jar pq-key new --scheme=ML_DSA_44

The command also supports seed-based generation through--seed.

Open Questions / Discussion Points

Given the early-stage nature of this proposal, multiple architectural elements are being actively refined beyond the previously discussed transaction size optimizations. Key areas currently under development include the economic framework and user-cost model, which encompasses PQ-specific transaction pricing, energy calibration for precompiles, and potential incentive structures like fee waivers. Additionally, work is focused on ensuring comprehensive ecosystem integration across SDKs and wallets, addressing hardware-wallet compatibility, key-derivation standards, and finalized API requirements. These efforts are being monitored through an open governance TIP and will reach finalization before the mainnet launch.

References

TRON Post-Quantum Signature Design was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mainnet Democritus Announcement

TRON Core Devs — Fri, 06 Feb 2026 07:58:06 GMT

The TRON network has released the GreatVoyage-v4.8.1(Democritus) version (hereafter referred to as “Democritus”). This is a mandatory upgrade that introduces support for the ARM64 architecture, alongside several key updates and governance proposals. Please find the details below.

Core

1. Expand compatibility for ARM64 architecture and JDK 17

To further enrich the java-tron technical ecosystem, the Democritus version introduces support for the arm64 architecture. In arm64 environments, the system currently supports JDK 17 and the RocksDB database.

ARM64 architecture

Mandatory JDK 17: JDK 17 is the required Java runtime environment to ensure the operational stability of the node in the arm64 environments (based on JEP 237, 388, 391).
Mandatory RocksDB: The database only supports RocksDB (v9.7.4). LevelDB JNI does not support arm64 architecture and lacks maintenance, so the community-active RocksDB was chosen.
Floating point computation adaptation: Floating-point calculations have been switched to use StrictMath via a proposal to ensure consistent results across different platforms. Before the proposal took effect, differences in floating-point implementations between arm64 and x86_64 architectures could lead to inconsistent results. Therefore, on arm64 architectures, results are kept consistent with x86_64 mainnet data via hardcoding. Warning: Private networks on x86_64 platforms using floating-point computation (specifically Bancor transactions involving pow) may face synchronization issues from genesis on arm64. In such cases, please use a database snapshot from an existing height to start arm64 nodes.
Toolkit limitations: LevelDB-related commands (db archive and db convert) are not supported in arm64 environments.

Changes under x86_64 architecture

Mandatory JDK 8: Since versions higher than JDK 8 have removed Java EE modules (per JEP 320), annotations such as @PostConstruct will fail, leading to NullPointerExceptions and block synchronization failures. Democritus introduces mandatory JDK 8 validation on x86_64 to ensure environment stability.
RocksDB/LevelDB compatibility restrictions: Due to version discrepancies (x86_64 uses RocksDB v5.15.10 which supports LevelDB, while arm64 uses v9.7.4 which does not), forcing RocksDB to open LevelDB in an arm64 environment triggers “Database Corruption” errors. To ensure consistent cross-platform behavior and data migration, Democritus uniformly prohibits RocksDB from accessing LevelDB databases (Existing databases successfully opened via compatibility mode remain unaffected). Error prompts for LevelDB attempting to open RocksDB have also been optimized, and interfaces/exception logic have been standardized.
Toolkit update: Previously, db convert defaulted to a “compatibility mode” that only updated the value of engine.properties to RocksDB while keeping the underlying data in LevelDB format. To align with arm64’s strict RocksDB requirements, the db convert command has been refactored to perform a non-compatibility conversion (previously the -safe flag logic). Consequently, the -safe parameter and “compatibility mode” have been removed to ensure seamless data migration across architectures.

Other changes

JDK 17 Compatibility

Null pointer compatibility: Optimized null pointer prompt information to facilitate problem positioning (based on JEP 358).
Number conversion exception compatibility: Optimized number conversion exception prompts and added conversion radix error prompts (based on JDK-8176425).
JDK version parsing compatibility: Adapted to JDK 10+ version number format changes (based on JEP 223).
var inference keyword: Supports var type inference mechanism (based on JEP 286).

RocksDB Resource Optimization

Increase max handle setting parameter: Added the parameter dbSettings.maxOpenFiles, default is 5000 (previously mandatory and unconfigurable), developers can adjust according to server load.
Resource release optimization: Set a reasonable lifecycle for RocksDB resources to release used resources in time, avoiding potential memory leak problems.

To support JDK 17 and arm64 architecture, the following dependency changes were made:

Issue: https://github.com/tronprotocol/java-tron/issues/5954

Source Code: https://github.com/tronprotocol/java-tron/pull/6327 https://github.com/tronprotocol/java-tron/pull/6421 https://github.com/tronprotocol/java-tron/pull/6440 https://github.com/tronprotocol/java-tron/pull/6455 https://github.com/tronprotocol/java-tron/pull/6457 https://github.com/tronprotocol/java-tron/pull/6459 https://github.com/tronprotocol/java-tron/pull/6472 https://github.com/tronprotocol/java-tron/pull/6502

TVM

1. Modify the behavior of SELFDESTRUCT

Following the proposal to deprecate the SELFDESTRUCT instruction via TIP-652 in GreatVoyage-4.8.0 (Kant), the Democritus release formally introduces behavioral adjustments to SELFDESTRUCT. This change ensures deep compatibility with Ethereum’s EIP-6780, aligning the TVM (TRON Virtual Machine) with EVM standards. Detailed specifications can be found in TIP-6780.

In versions prior to Democritus, SELFDESTRUCT allowed a contract to terminate itself, transfer its funds to a designated address, and delete all associated account data (code, storage, and the account itself). Starting with the Democritus release, the behavior of the SELFDESTRUCT instruction is modified as follows:

Restricted Execution Scenarios

Account data deletion (including code, storage, and the account itself) is now only permitted if SELFDESTRUCT is invoked within the same transaction in which the contract was created.

Scenario 1: invoke SELFDESTRUCT in a Subsequent Transaction (Standard Case)

The contract account is not destroyed.
Execution of the current contract stops immediately.
No data is deleted, including storage keys, code, or the account itself. However, all assets (TRX, staked TRX, and TRC10 tokens) are transferred to the target address.
If the target address is the contract itself, the assets are not burned.

Scenario 2: invoke SELFDESTRUCT in the Same Transaction (Creation & Destruction)

Execution stops immediately.
All account data is purged.
All assets are transferred to the target address.
If the target address is the contract itself, the balance is reset to zero and the assets are burned.

Energy Cost Adjustment

To increase the threshold for usage and further mitigate abuse, the Energy cost for the SELFDESTRUCT opcode has been increased from 0 to 5,000.

NOTE: This feature is governed by TRON network parameter #94. It is disabled by default (value: 0) and can be enabled through a governance proposal vote. Once enabled, it cannot be disabled.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-6780.md

Source Code: https://github.com/tronprotocol/java-tron/pull/6383 https://github.com/tronprotocol/java-tron/pull/6448

Net

1. Fix “gt lastNum” and “gt highNoFork” error during block synchronizing

The synchronization service previously outputted full exception stack traces during specific edge-case scenarios involving gt highNoFork and gt lastNum errors. To better align with standard error-level logging practices, this behavior has been adjusted. The service now logs only the specific exception message, suppressing the full stack trace to reduce log noise and improve readability.

Source Code: https://github.com/tronprotocol/java-tron/pull/6381

2. Fix the light node incorrectly reporting a FORKED disconnection

In versions prior to Democritus, light nodes often misidentified connection issues as FORKED during handshakes with Full Nodes of lower block heights. This occurred specifically when a Full Node’s highest solidified block was not present on the light node’s local main chain.

The Democritus release refines this logic by introducing a specific height threshold: a FORKED status is now only triggered if the light node’s lowest block height is lower than the Full Node’s highest solidified block height. In all other cases of chain mismatch, the error is correctly categorized as LIGHT_NODE_SYNC_FAIL.

Source Code: https://github.com/tronprotocol/java-tron/pull/6375

3. Optimize P2P disconnection reason codes

Prior to the Democritus release, certain P2P_DISCONNECT messages utilized vague reason codes, hindering accurate network troubleshooting. This update refines the error reporting logic for three specific scenarios to provide clearer diagnostic data:

Scenario 1: If a connection is terminated because a received block fails signature verification, the reason code is updated from UNKNOWN to BAD_BLOCK.
Scenario 2: Previously, failures during the HelloMessage validation incorrectly triggered an UNEXPECTED_IDENTITY error, even when no identity-specific checks were performed. This has been corrected to INCOMPATIBLE_PROTOCOL to accurately reflect the validation failure.
Scenario 3: When a P2P_HELLO message contains a block ID with a length other than 32 bytes, the disconnection reason is now reported as INCOMPATIBLE_PROTOCOL instead of UNKNOWN.

Source Code: https://github.com/tronprotocol/java-tron/pull/6394

4. Implement P2P message rate limit

Prior to the Democritus release, P2P message processing was not rate-limited, leaving nodes vulnerable to resource exhaustion (bandwidth, CPU, and RAM) when handling high message volumes. To address this, Democritus introduces a per-peer rate limiting mechanism. If the frequency of specific messages from a single peer exceeds defined thresholds, the node will drop the messages and proactively disconnect from that peer. The following limits are applied based on message type and node state:

SyncBlockChainMessage: Restricted to 3 QPS during the synchronization phase (defined as ChainInventory.remainNum > 0).
FetchInvDataMessage: Restricted to 3 QPS during the block synchronization stage.
P2P_DISCONNECT: Processing is limited to 1 QPS.

Source Code: https://github.com/tronprotocol/java-tron/pull/6393

5. Optimize concurrent access to fields of PeerConnection

The Democritus release optimizes concurrent access to PeerConnection by applying the volatile keyword to shared fields and refining the sequence of variable assignments. These changes ensure thread-safe visibility and prevent race conditions, significantly reducing exceptions caused by state inconsistencies during network synchronization.

Source Code: https://github.com/tronprotocol/java-tron/pull/6360

Other Changes

Configuration & Dependencies

1. Optimize the configuration switch for zkSNARK

Added configuration item node.allowShieldedTransactionApi to replace node.fullNodeAllowShieldedTransaction.

Source Code: https://github.com/tronprotocol/java-tron/pull/6371 https://github.com/tronprotocol/java-tron/pull/6427

2. Upgrade gradle to support jitpack publish

Gradle version has been upgraded to 7.6.4, using the maven-publish plugin to support jitpack publishing.

Source Code: https://github.com/tronprotocol/java-tron/pull/6367

3. Optimize local witness initialization logic

The Democritus release refines the local witness initialization process. Private key and address initialization logic is now executed exclusively by witness nodes. If an invalid witness address is configured, the program will throw an exception and terminate. Additionally, the cryptography library has been upgraded from org.bouncycastle:bcprov-jdk15on:1.69 to org.bouncycastle:bcprov-jdk18on:1.79.

Source Code: https://github.com/tronprotocol/java-tron/pull/6368 https://github.com/tronprotocol/java-tron/pull/6452

4. Optimize log prompts for missing Blackhole configuration

The Democritus release improves the error logging for missing Blackhole account configurations. The updated logs provide more actionable guidance, explicitly notifying users to configure the Blackhole account address within the config.conf file.

Source Code: https://github.com/tronprotocol/java-tron/pull/6356

5. Enrich FullNode command-line options

Starting with the Democritus release, the standalone SolidityNode.jar and KeystoreFactory.jar have been merged into FullNode. Users can start the SolidityNode service using the command-line parameter—-solidity, or start the KeystoreFactory service using --keystore-factory. This unification reduces storage overhead and simplifies build and deployment workflows.

Source Code: https://github.com/tronprotocol/java-tron/pull/6397 https://github.com/tronprotocol/java-tron/pull/6450 https://github.com/tronprotocol/java-tron/pull/6446

6. Synchronize config.conf with tron-deployment

The Democritus version introduces full synchronization of configuration items between config.conf and the tron-deployment repository, and updates the seed node list in seed.node.ip.list.

Source Code: https://github.com/tronprotocol/java-tron/pull/6332

7. Standardize full configuration and annotation guidelines

The Democritus version introduces a standardized configuration file containing all supported parameters. Any configuration item not included in this file is considered invalid or deprecated. Additionally, this release defines specific annotation and commenting standards within the configuration files:

Whole-line comments Must begin with the # prefix.
Comments appended to the end of a configuration line may use either # or //.
Configuration items without default values must be prefixed with # to serve as a commented-out template.

Source Code: https://github.com/tronprotocol/java-tron/pull/6430

8. Update dependencies

Upgraded dependencies such as grpc-java, spring, jackson, and jetty:

Deleted dependencies:

Additionally, the Democritus version upgrades the underlying network library libp2p, from 2.2.6 to 2.2.7. This version not only adds compilation support for JDK 17 but also introduces numerous optimizations and improvements:

Added formal compilation support for JDK 17 (#113).
Upgraded grpc-netty and protobuf libraries (#110).
Optimized connection pool (connPool) and general resource allocation logic (#116).
Implemented a concurrent external IP acquisition mechanism with built-in validation (#120, #121).
Refined network detection logic (#122).

Source Code: https://github.com/tronprotocol/java-tron/pull/6400 https://github.com/tronprotocol/java-tron/pull/6429 https://github.com/tronprotocol/java-tron/pull/6431 https://github.com/tronprotocol/java-tron/pull/6481

9. Update code version to 4.8.1

The version number has been formally defined as 4.8.1 to reflect the Democritus release.

Source Code: https://github.com/tronprotocol/java-tron/pull/6445

Event Service

1. Optimize transaction info retrieval logic for Event Services

The Democritus release addresses compatibility issues encountered during the retrieval of transaction info. To ensure data availability, if the event service fails to retrieve data from the transactionRetStore database, it will automatically perform a compatibility fallback to retrieve data from the transactionHistoryStore database.

Source Code: https://github.com/tronprotocol/java-tron/pull/6443 https://github.com/tronprotocol/java-tron/pull/6453

2. Remove bloom filter write toggle

The section-bloom database is used to store bloom filters for contract logs and their corresponding block indexes. When processing eth_getLogs requests, the node queries this database to quickly locate matching blocks. This is a critical step for efficient event retrieval.

Prior to the Democritus Release, writing to this database was controlled by the node.jsonrpc.httpFullNodeEnable configuration. If this setting was disabled, the node would not record block bloom filter data to the section-bloom database. Because these index data points cannot be retrospectively backfilled automatically, users were unable to query historical transaction events that occurred while the toggle was off — even if they enabled the configuration later.

Starting with the Democritus version, dependency on this configuration toggle has been removed. The node now persistently writes data to the section-bloom database by default. This change ensures the continuity and integrity of the bloom filter index, completely resolving the issue where eth_getLogs failed to retrieve historical data due to specific configuration states.

Source Code: https://github.com/tronprotocol/java-tron/pull/6372

3. Optimize event service shutdown logic

The Democritus version introduces an optimized shutdown logic for the HistoryEventService thread. By implementing a global state variable, isClosed, the system now ensures that resource deallocation occurs exactly once, even if the close function is invoked multiple times. This optimization effectively prevents redundant resource disposal and associated exceptions, significantly enhancing system stability during termination.

Source Code: https://github.com/tronprotocol/java-tron/pull/6463

Test Case

1. Optimize resource management for test cases

The Democritus version introduces a systematic optimization of resource management for unit testing. These enhancements significantly improve execution efficiency while further ensuring the cleanliness and stability of the testing environment.

Standardized Cleanup Mechanism: Implemented a more rigorous file cleanup protocol to ensure that all temporary data generated during testing is thoroughly removed post-execution.
Improved Execution Performance: By optimizing high-latency test cases, the total duration of the unit testing suite has been reduced by up to 30%.
Robust Resource Release: Addressed known resource leak issues and standardized the resource release logic.
Enhanced Runtime Stability: Resolved specific NullPointerExceptions.

Source Code: https://github.com/tronprotocol/java-tron/pull/6437 https://github.com/tronprotocol/java-tron/pull/6483 https://github.com/tronprotocol/java-tron/pull/6486

2. Implement gRPC timeout mechanism

When executing test cases repeatedly (e.g., over 100 times) on arm64, certain gRPC test cases would hang. To solve this, the Democritus version introduces a gRPC timeout mechanism. A 5-second execution timeout was added for individual gRPC test case, and a 30-second timeout for the entire test execution; if it times out, it breaks and continues executing subsequent logic.

Source Code: https://github.com/tronprotocol/java-tron/pull/6441 https://github.com/tronprotocol/java-tron/pull/6460

3. Ensure automated termination of unit test

The Democritus version introduces optimizations to the termination logic of the ConditionalStopTest unit test. Specifically, within SR scenarios, the logic has been refined to accurately identify stop conditions even when the block production sequence undergoes changes. This ensures that the unit test terminates correctly and automatically as expected.

Source Code: https://github.com/tronprotocol/java-tron/pull/6469

4. Enhance log context isolation mechanism

The Democritus version addresses the issue of global logger configuration pollution previously triggered by the TronErrorTest unit test. By strengthening the output of error and warning messages during the LogService configuration loading phase and explicitly restoring the logger context within unit tests, the system now ensures complete log environment isolation between different test cases. This improvement eliminates interference in logging behavior across test suites and provides clearer diagnostic data for rapidly locating Logback configuration loading anomalies.

Source Code: https://github.com/tronprotocol/java-tron/pull/6476

5. Resolve CheckStyle violations in test cases

Added a line break to a comment statement in the test case file to fix checkStyle issues in test cases.

Source Code: https://github.com/tronprotocol/java-tron/pull/6392

Documents

1. Update readme for FullNode startup JVM parameters

Adjusted the JVM startup parameters for java-tron on x86_64 and arm64 platforms, aiming to ensure that FullNode nodes can meet basic disaster recovery requirements under minimum hardware configurations; meanwhile, modified hardware requirements to recommend more stable machine configurations.

Source Code: https://github.com/tronprotocol/java-tron/pull/6478

2. Fix README badge display errors

The Democritus version fixed the issue where the GitHub badge at the top of the README document displayed as “unknown”, and modified the badge image link.

Source Code: https://github.com/tronprotocol/java-tron/pull/6340

3. Update telegram info and doc link in README

The Democritus version udpated the README document to add Telegram contact information for the official TRON development discussion group.

Source Code: https://github.com/tronprotocol/java-tron/pull/6364

Others

1. TIP-767: Transitioning voting window configuration to chain governance

To ensure high uniformity of governance parameters across the entire network and enhance protocol consistency, the Democritus version introduces TRON №.92 network parameter (PROPOSAL_EXPIRE_TIME), transitioning the configuration of proposal expiration time to on-chain governance.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-767.md

Source Code: https://github.com/tronprotocol/java-tron/pull/6399 https://github.com/tronprotocol/java-tron/pull/6454

2. Fix protocol buffer syntax compatibility issue

Fixed the hexadecimal casing error in the ReasonCode struct, resolving compilation compatibility issues in JavaScript environments.

Source Code: https://github.com/tronprotocol/java-tron/pull/6426

API

1. Introduce the eth_getBlockReceipts API

The Democritus version introduces the eth_getBlockReceipts interface, used to query all transaction receipts in a specified block. For genesis blocks, blocks already pruned by light nodes, and unproduced blocks, it returns null.

Parameters: Block identifier (required). Supports three types: a block number represented as a hexadecimal string, a block hash (with or without the 0x prefix), or a block tag ("latest", "earliest", "finalized").
Returns: An array of objects. Each object is a receipt for a transaction within that block, and follows the same structure as the response returned by eth_getTransactionReceipt.

Source Code: https://github.com/tronprotocol/java-tron/pull/6379 https://github.com/tronprotocol/java-tron/pull/6433

2. Introduce a new API to query the real-time vote count of witness

The Democritus version introduces the getPaginatedNowWitnessList interface. This endpoint is designed to query real-time voting data for the current epoch and return a paginated list of witnesses sorted in descending order of their vote counts.

Parameters

offset: long, start index, requires >= 0.
limit: long, number of items to return, requires > 0, upper limit is 1000.
visible: boolean, optional; controls whether the returned address is in base58check or hex format.

Returns

Success: witnesses array, each item is a Witness (containing address, vote count, URL, etc.), sorted descending by “real-time votes”.
Failure: No result. When invalid parameters (e.g., limit <= 0, offset < 0, or offset >= total Witness count) returns {}, http code = 200.

API-specific errors: When in a maintenance period and requesting non-solidified data, throws a maintenance period unavailable exception, http code = 200.

Source Code: https://github.com/tronprotocol/java-tron/pull/6373 https://github.com/tronprotocol/java-tron/pull/6451

3. Optimize the return data of eth_call

In versions prior to Democritus, the eth_call interface provided limited feedback upon contract execution failure. It typically returned a generic error message (e.g., “REVERT opcode executed”) while leaving the data field empty. This lack of detailed execution context made it difficult for developers to diagnose and trace specific issues within the smart contract.

The Democritus version introduced JsonRpcException as the base class for all JsonRpc exceptions, and a JsonRpcErrorResolver class for data field generation logic.

Using the demo contract as an example, the following information was returned when calling the testInsufficientBalance method prior to the change:

{
 "jsonrpc": "2.0",
 "id": 1,
 "error": {
    "code": -32000,
    "message": "REVERT opcode executed",
    "data": "{}"
  }
}

After modification: The data field returns error information (e.g., encoded revert reason), allowing developers to obtain the specific error reason via ABI parsing. (Consistent with Ethereum node strategy, returns unparsed data for everything except default Error(string)).

{
 "jsonrpc": "2.0",
 "id": 1,
 "error": {
    "code": -32000,
    "message": "REVERT opcode executed",
    "data": "0xcf47918100000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000064"
  }
}

Source Code: https://github.com/tronprotocol/java-tron/pull/6369

4. Performance optimization for eth_getLogs, eth_getFilterLogs

Event query interfaces like eth_getLogs rely on a partialMatch function to query the bloom database. The query conditions are derived from 3 bitIndexes generated for each topic or address. Since the bloom filter has a bit limit (2048 bits), when the number of topics reaches 683, the total number of indexes (683 * 3 > 2048) exceeds the filter capacity. This inevitably leads to bit collisions and redundant bitIndexes, resulting in duplicate database queries. To address this, the proposed optimization implements de-duplication of bitIndexes prior to execution, significantly reducing the frequency of database lookups.

The table below contrasts the duplication rate of bitIndex and execution time of partialMatch under different numbers of topics and addresses. It shows that as the number of topics increases, the higher the bitIndex duplication, the more significant the performance improvement after optimization.

Source Code: https://github.com/tronprotocol/java-tron/pull/6370

To a wise and good man the whole earth is his fatherland. — — Democritus

Mainnet Democritus Announcement was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is TIP-6780?

TRON Core Devs — Tue, 18 Nov 2025 09:11:57 GMT

1. Background

TIP-652 proposed the deprecation of the SELFDESTRUCT opcode. This change discouraged its use in newly deployed contracts and suggested its functionality may be further limited in future TVM upgrades.

As an EVM-compatible public chain, TRON has introduced TIP-6780 to align with Ethereum’s EIP-6780 and maintain behavioral consistency with the EVM.

2. Changes

Previously, the SELFDESTRUCT opcode allowed a contract to destroy itself, transfer its entire balance to a specified address, and subsequently delete all associated data of the contract account (i.e., code, storage, and the account itself).

2.1 Core Change: Restriction on SELFDESTRUCT Usage Scenarios

Account data (i.e., code, storage, and the account itself) is only deleted if SELFDESTRUCT is executed within the contract’s creation transaction.

Scenario 1: SELFDESTRUCT Called in a Different Transaction (Default Case)

The account is not actually destroyed.
The current contract’s execution halts immediately.
No data is deleted, including storage keys, code, or the account itself.
However, all assets held by the contract (TRX, staked TRX, TRC-10 tokens) are transferred to the target address.
If the target address is the contract itself, the assets are not burned.

Scenario 2: SELFDESTRUCT Called in the Same Transaction (Immediate Self-Destruction after Creation)

In this scenario, the opcode’s legacy behavior is retained:

The current contract’s execution halts immediately.
All account data is deleted.
All assets are transferred to the target address.
If the target address is the contract itself, its balance is set to 0, and the assets are burned.

2.2 Energy Cost Adjustment

The fixed Energy cost of the SELFDESTRUCT opcode is adjusted from 0 to 5,000. This raises the execution cost to further deter misuse.

3. Impact

3.1. Impact on Developers and Smart Contracts

Hard Fork Requirement: This TIP is a consensus layer change that must be implemented via a hard fork.

TRX Burning Behavior: Previously, with SELFDESTRUCT, a contract could burn its TRX by specifying itself as the target address. Now, this action is restricted:

If the contract was not created in the current transaction, its TRX will not be burned, and no transfer occurs.
TRX can only be burned if the contract is created and SELFDESTRUCT is called within the same transaction.

Invalidated Design Patterns: Some solutions that rely on SELFDESTRUCT to implement security mechanisms or proxy upgrades are no longer secure or effective. For example:

The pattern of using CREATE2 + SELFDESTRUCT to implement “upgradeable contracts” is broken.
The practice of relying on SELFDESTRUCT to destroy an account to protect sensitive data is no longer viable.

3.2. Impact on the TRON Ecosystem

Enhanced Ethereum Compatibility: This change improves alignment with the EVM, simplifying the migration and integration of cross-chain infrastructure, developer tools, and decentralized applications (DApps).
Improved Contract Security: This change encourages developers to adopt more robust and predictable contract design patterns, moving away from opcodes that are considered unstable or are planned for future deprecation.

3. TRON On-Chain Data Analysis

3.1 Analysis of Contracts Containing the SELFDESTRUCT Opcode

Table 1: Contracts containing SELFDESTRUCT on TRON, by Asset Value.

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.

3.2 Analysis of SELFDESTRUCT Transactions

Figure 1: Example of the “create-then-destroy” pattern shown in TRON’s internal 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.

4. Conclusion

This proposal restricts the functionality of the SELFDESTRUCT opcode to enhance compatibility with Ethereum. Developers are strongly advised to avoid using SELFDESTRUCT in new smart contracts and instead adopt safer, more maintainable patterns for contract lifecycle management.

The change to the SELFDESTRUCT opcode will be included in an upcoming version release. Once released, it must be activated via network governance voting to take effect. Please stay tuned for the latest updates on the proposal via TRONSCAN.

What is TIP-6780? was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

Committee Proposal 103

TRON Core Devs — Thu, 26 Jun 2025 06:18:47 GMT

Committee Proposal №103 is a voting request aimed at enabling chain parameters №83, №88, and №89 on the TRON network. These changes align the TRON Virtual Machine (TVM) with the Ethereum Cancun upgrade and introduce optimizations to the consensus layer’s verification mechanism. Please refer to here for the origin discussion. The № 103 committee proposal is already in effect, please refer to here for the voting details.

The proposal has officially taken effect as of 2025–06–26 14:00 (SGT). And this post provides a detailed breakdown of the proposal’s content and significance.

What does this proposal include?

Proposal 103 activates parameters defined in the following four TIPs:

TIP-650: Transient Storage Opcodes

Two new EVM-compatible opcodes are enabled:

TLOAD (0x5c) — Load from transient storage
TSTORE (0x5d) — Store to transient storage

Transient storage offers an energy-efficient alternative to memory for storing temporary data across internal calls within the same transaction, without persisting data beyond the transaction.

TIP-651: Memory Copy Instruction

One new opcode is enabled:

MCOPY (0x5e) — Copy memory efficiently from one location to another

This instruction provides energy optimization for contracts that need to manipulate memory regions directly.

TIP-745: BLOB Opcodes for Cancun Compatibility

Two new opcodes are enabled in placeholder form:

BLOBHASH (0x49)
BLOBBASEFEE (0x4a)

While these opcodes return default values (0) for now, they ensure forward compatibility with Ethereum Cancun bytecode.

TIP-694: Consensus Layer Verification Enhancements

This proposal strengthens validation logic in the consensus layer:

Enforces a maximum size for account creation transactions to prevent bandwidth abuse
Validates total transaction sizes more strictly to avoid exceeding block limits
Ensures that the number of transaction results matches the number of invoked contracts
Applies stricter filtering for near-expiry transactions to preserve network bandwidth

What’s the benefit brought by this proposal?

For Virtual Machine (TVM) Compatibility:

Ensures alignment with Ethereum Cancun specs
Maintains bytecode-level compatibility with the EVM
Simplifies smart contract migration from Ethereum to TRON
Provides developers with the same energy-saving improvements

For Consensus Layer Security and Efficiency:

Strengthens block verification during sensitive periods (e.g., maintenance windows)
Prevents malicious blocks with non-standard timestamps
Refines Super Representative (SR) ranking algorithm for rare edge cases
Mitigates risk from oversized or malformed transactions

Additionally, this proposal sets the groundwork for enhanced cross-platform compatibility in the future by signaling a transition from java.lang.Math to deterministic math libraries in Java-Tron. This ensures consistent behavior across environments and JDK versions.

Summary

Committee Proposal 103 enables TRON’s compatibility with the Ethereum Cancun upgrade and significantly enhances consensus layer verification. With the activation of new opcodes and stricter validation rules, the TRON network further improves its performance, security, and developer-friendliness.

The TRON Virtual Machine is now Cancun-compatible — enabling seamless DApp migration, cross-chain development, and more efficient contract execution.

Committee Proposal 103 was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.

Committee Proposal 102

TRON Core Devs — Fri, 13 Jun 2025 06:23:29 GMT

Committee proposal 102 is a voting request for modifying the № 5 and № 31 chain parameters on TRON network, adjusting the block reward from 16 TRX to 8 TRX, and the voting reward from 160 TRX to 128 TRX. Please refer to here for the origin discussion. The № 102 committee proposal is already in effect, please refer to here for the voting details, this post is dedicated to provide more details.

Why does the TRON network need this proposal at this time?

The implementation of a series of proposals within TRON’s tokenomics model has significantly impacted the TRX supply, resulting in a transition from inflation to deflation, but with a potential rebound trend showing recently. Especially after increasing the total energy limit from August to October 2024, the net increase of TRX supply shows a gradual increasing trend in recent months, indicating a potential resurgence of inflation.

Fig. 1 — The TRX supply shows a deflationary trend since 2022

Fig. 2 — The net increase of TRX supply shows a positive number some days in recent months

The feasibility and reasonability of this proposal

The community has widely and deeply discussed this proposal on Github and during multiple core devs community calls, and finally made consensus on enabling this proposal.

The previous TRX block rewards effectively stimulated network staking and transaction volume growth in the early stages. However, as the TRON network develops, the relatively high production rates of TRX may dilute the token’s value over time and reduce the incentive for long-term staking.

By reducing the TRX reward from 176 TRX to 136 TRX in total, the expected annual deflation rate will become about 1.29%, which better adapts the transaction volume and activities on the TRON network.

Diving into other mainstream public chains, most have designed mechanism to control the inflation rate:

BTC is well-known for halving every 4 years to cut the supply.
ETH implemented EIP-1599 introducing base fee to accelerate burning in 2021, and significantly reduced ETH supply rate after the merge in 2022, bringing the inflation rate drop from about 4% to 0.3% at the moment, reduced by about 90%.
SOL supply rate is pre-set, currently about 5.1%, and is designed to decrease by about 15% each year.

The current supply rate of TRX has remained for more than 5 years, as the total energy limitation has been enlarged a lot and many chain parameters have been adjusted, it’s time to consider the proper TRX supply rate.

The biggest question during the discussion is that reducing TRX reward will decrease the benefit of staking holders. However, taking the advantage of energy renting into consideration, the expected comprehensive APR will change from about 9.15% to 7.08%, which is still attractive and competitive.

What’s the benefit brought by this proposal?

Enabling this calculation performance optimization brings several benefits:

Enhance Deflation: Lowering the TRX block rewards will enhance the network’s deflation rate, potentially increasing its value.
Incentivize Staking: Leveraging the advantage of TRON’s staking model, the increase in TRX value can encourage more users to stake TRX to obtain the resources for transactions.
Strengthen Network Security: Increased staking participation strengthens the network’s security by locking up more TRX.
Improve Economic Incentives: Align token distribution with the maturity of the network, ensuring that incentives remain robust and meaningful for both new participants and long-term holders.

Summary

After the proposal of reducing TRX reward takes effect, the annualized deflation rate of TRX is expected to increase from the previous 0.85% to 1.29%, which will further accelerate the deflation process of TRX, optimize TRON’s economic model, and enhance the long-term sustainability of the network.

Committee Proposal 102 was originally published in TRON on Medium, where people are continuing the conversation by highlighting and responding to this story.