Repository navigation
NullPointerException when calling triggerconstantcontract with blacklisted address #6523
Description
Issue Description
When calling the triggerconstantcontract endpoint to check if a TRON address is blacklisted using the isBlackListed(address) function, a NullPointerException is thrown when the address is actually blacklisted.
Environment
- TRON Network: Mainnet
- API Endpoint:
https://tron-mainnet.gateway.tatum.io/wallet/triggerconstantcontract - Contract Address:
TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t(USDT TRC-20) - Function:
isBlackListed(address)
Steps to Reproduce
- Call the
triggerconstantcontractendpoint with the following payload:
{
"owner_address": "TKgD8Qnx9Zw3RNjdiU2i5y2Swa2y4QvG6v",
"contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
"function_selector": "isBlackListed(address)",
"parameter": "0000000000000000000000418a8e8b8c8d8e8f9a9b9c9d9e9f0a1b2c3d4e5f6",
"visible": true
}- The address
TKgD8Qnx9Zw3RNjdiU2i5y2Swa2y4QvG6vis confirmed to be blacklisted.
Expected Behavior
The endpoint should return a successful response with the blacklist status in the constant_result field, for example:
{
"result": {
"result": true,
"constant_result": ["0000000000000000000000000000000000000000000000000000000000000001"]
}
}Actual Behavior
The endpoint returns an error:
{
"result": {
"code": "OTHER_ERROR",
"message": "class java.lang.NullPointerException : null"
}
}Error Details
- Error Type:
java.lang.NullPointerException - Error Code:
OTHER_ERROR - Message:
class java.lang.NullPointerException : null
Additional Information
Test Cases
-
Blacklisted Address (Fails with NullPointerException):
- Address:
TKgD8Qnx9Zw3RNjdiU2i5y2Swa2y4QvG6v - Expected: Should return
trueor1in constant_result - Actual: Returns NullPointerException
- Address:
-
Non-blacklisted Address (May work correctly):
- Should be tested to confirm if the issue only occurs with blacklisted addresses
Request Details
- Method: POST
- URL:
/wallet/triggerconstantcontract - Content-Type:
application/json - Parameter Encoding: The address is converted from Base58 to hex format, padded to 64 characters (32 bytes)
Address Conversion
The address TKgD8Qnx9Zw3RNjdiU2i5y2Swa2y4QvG6v is converted as follows:
- Base58 to hex:
418a8e8b8c8d8e8f9a9b9c9d9e9f0a1b2c3d4e5f6 - Ensure
41prefix (TRON address prefix) - Pad to 64 hex characters:
0000000000000000000000418a8e8b8c8d8e8f9a9b9c9d9e9f0a1b2c3d4e5f6
Possible Root Cause
The NullPointerException suggests that when processing a blacklisted address, the TRON node may be encountering a null reference when:
- Accessing the blacklist mapping
- Processing the return value
- Encoding the response
This could indicate a bug in the contract execution or response encoding logic when dealing with blacklisted addresses.
Impact
This issue prevents applications from properly checking blacklist status for addresses that are actually blacklisted, which is critical for compliance and security purposes.
Requested Action
Please investigate and fix the NullPointerException that occurs when calling triggerconstantcontract with isBlackListed(address) for blacklisted addresses. The function should return a proper boolean value instead of throwing an exception.
Related Information
- TRON USDT Contract:
TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t - Function Signature:
isBlackListed(address) - Test Address:
TKgD8Qnx9Zw3RNjdiU2i5y2Swa2y4QvG6v(confirmed blacklisted)
Activity
Benson0224 commentedon Jan 23, 2026
I took a quick look at the request. It appears the address in your query parameters is invalid; the string length is one character short. Please double-check the address and try again.
waynercheung commentedon Jan 23, 2026
@csc-EricWu
As @Benson0224 pointed out,
TKgD8Qnx9Zw3RNjdiU2i5y2Swa2y4QvG6vis not a valid Base58 address. Please verify it.yanghang8612 commentedon Jan 23, 2026
Should we improve the error messages for such interface issues? Currently, these error prompts are extremely unfriendly to users.
yanghang8612 commentedon Jan 23, 2026
Additionally, your data parameter contains 63 hex characters. Please verify this. Otherwise, even if the owner address is valid, the call will result in a revert.
GordonLtron commentedon Jan 23, 2026
Agree. While the root cause here is malformed input (invalid address length and odd-length hex parameter), throwing a raw
NullPointerExceptionis confusing for API users. It implies a node-side failure rather than a client-side request error.csc-EricWu commentedon Jan 23, 2026
Thank you all. Upon confirmation, this is an invalid address.
GrothenDI commentedon Jan 23, 2026
About why
TKgD8Qnx9Zw3RNjdiU2i5y2Swa2y4QvG6vis not a valid Tron address:Although this address is
34characters long and starts withT, which aligns with the characteristics of a TRON address, it is inBase58format but notBase58Check. When converted to hexadecimal format, the address becomes416A7A4AD43541826EDAFD718826F58BADCEB483B819C12F8B. The last four bytes19C12F8Bare not the correct checksum for the actual address416A7A4AD43541826EDAFD718826F58BADCEB483B8. The correct checksum should be054B538Ahalibobo1205 commentedon Mar 17, 2026
The root cause is that the API lacks input validation for the address parameter — when an invalid address is passed, it triggers a bare
NullPointerException, which is very unfriendly to API consumers. We suggest adding upfront validation with a clear and descriptive error message in the next release. I'll confirm the implementation approach at the upcoming Core Devs Community Call 58 before we move forward. cc @yanghang8612 @waynercheunghalibobo1205 commentedon May 12, 2026
Apologies that we did not cover this topic in the Core Devs Community Call 58 as previously planned. The agenda was already full, so this item was not discussed.
I'd like to add this to Core Devs Community Call 62 for discussion.
cc @yanghang8612 @waynercheung
waynercheung commentedon May 15, 2026
@halibobo1205 Hi，after the tronprotocol/pm#207, is there any update for this issue?
halibobo1205 commentedon May 15, 2026
@waynercheung Hi, the Core Devs Community Call 62 hasn't started yet.
halibobo1205 commentedon May 20, 2026
A consolidated plan ahead of Core Devs Community Call 62.
Shared root cause
The NPE in this issue and the CodeQL alert
java/error-message-exposureare the same class of problem: HTTP servlets catchExceptionand write the raw exception class/message straight back to the client.Proposal — split API errors into parameter errors vs. internal errors
"invalid address: base58check failed".logger.warn(..., e)); the response carries only a fixed generic message, noe.getClass()/e.getMessage().Util.writeError(response, code, message)helper.halibobo1205 commentedon May 27, 2026
Status update: this was discussed in Core Devs Community Call 62, and the consolidated plan above was accepted with no objections.
Agreed approach:
"invalid address: base58check failed"— no more rawNullPointerExceptionreaching the client.logger.warn(..., e); the HTTP response carries only a fixed generic message, with noe.getClass()/e.getMessage()leakage.Util.writeError(response, code, message)helper so every servlet goes through the same sanitization point.This also resolves the CodeQL
java/error-message-exposurealerts, since both share the same root cause.Timing: v4.8.2 scope is already locked, so this work will land in a later release. The issue stays open and will be updated once implementation is in flight.
Thanks @yanghang8612, @waynercheung, and everyone who contributed to the discussion.
halibobo1205 commentedon Sep 2, 2026
traced by #6936.