The `nonce` returned by `eth_getTransactionByHash` is non-compliant

[leonway336]

It should be 0x0, not 0x0000000000000000.

Match pattern: ^0x(0|[1-9a-f][0-9a-f]*)$

[waynercheung]

Thank you for reporting this issue.

After reviewing our code, I can confirm that java-tron currently returns 0x0000000000000000 for the nonce field:

nonce = ByteArray.toJsonHex(new byte[8]); // no value

This was previously modified to maintain compatibility with Graph Node.

According to the Ethereum JSON-RPC specification at https://ethereum.github.io/execution-apis/api/methods/eth_getTransactionByHash, the nonce field should match the pattern: ^0x(0|[1-9a-f][0-9a-f]*)$

This means the correct format should be 0x0 (without leading zeros), not 0x0000000000000000.

This maybe an non-compliance issue. However, since this interface is already being used in production by existing users, we need to carefully evaluate the compatibility impact before making changes. We will:

1. Assess the potential breaking changes for existing integrations
2. Consider a migration strategy if needed
3. Define a proper fix plan based on the evaluation

I appreciate your patience while we work through this compatibility assessment. I will update this issue once we have a concrete plan for the fix, and we welcome input from other developers during this process.

[lxcmyf]

@leonway336
Both 0x0000000000000000 and 0x0 will be parsed as 0, so this should not actually impact users functionally. However, for better spec compliance and standardization, we can update the return value to 0x0 in a future release.

[0xbigapple]

Hi, @leonway336 Thank you for reporting this issue. I would like to support updating the nonce field from 0x0000000000000000 to 0x0 in the next release.
As @waynercheung mentioned, this change aligns with the Ethereum JSON-RPC specification and ensures consistency with the broader ecosystem, reducing potential formatting discrepancies during cross-client integrations.
As @lxcmyf pointed out, both representations are numerically equivalent, and most downstream libraries parse the value as a number rather than performing strict string comparisons. Therefore, the practical compatibility risk should be minimal.

From a long-term maintenance perspective, retaining non-standard behavior increases technical debt and may require downstream systems to implement special handling logic. Aligning with the specification helps reduce maintenance costs, improve interface consistency, and prevent similar compliance discussions in the future.

[waynercheung]

@0xbigapple @lxcmyf
I think this issue can be included in the v4.8.2 release (ref: #6585).

Development is currently in progress. We will continue to sync updates here as work advances. The fix is tentatively expected to be completed by March 2026.

[leonway336]

Thanks for keeping us updated. Great work. Looking forward to seeing this in the next version.

[waynercheung]

@leonway336 Thanks! The fix is currently in progress. We'll keep this issue updated as development moves forward and share any notable milestones along the way. Stay tuned!

[waynercheung]

A PR has been submitted to address this issue: #6709

Scope of the fix:

• TransactionInfo.nonce corrected from 0x0000000000000000 to 0x0 per the uint (QUANTITY) type defined in execution-apis (^0x(0|[1-9a-f][0-9a-f]*)$).
• Same root cause (byte[N] zero-fill serialised as leading-zero hex) is fixed for v / r / s in the unsigned-signature branch, and the malformed "0x" placeholders for gasPrice / blockHash / blockNumber / transactionIndex in the fallback constructor are corrected to 0x0 / null per spec.
• Block.nonce is intentionally not changed — the Block schema defines nonce as bytes8 (pattern ^0x[0-9a-f]{16}$), so the existing 0x0000000000000000 is already spec-compliant; shortening it to 0x0 would break conformance.

See the PR description for the full field-by-field change list and compatibility analysis.