Null receipt status in the "Get decoded transactions by wallet" API

Dear Moralis Support Team,

In a part of our project, we utilize the Moralis transaction API to acquire the transactions of a wallet. However, we’ve encountered an issue while calling the APIs.

When invoking the “Get decoded transactions by wallet” API, we receive all the native transactions of a wallet. To differentiate between the failed or canceled transactions and the regular ones, we check the receipt_status of a transaction. Ideally, this should yield true or false, or ‘0’ or ‘1’ in the API, but sometimes its value in this API appears as None.

The None value presents ambiguity as in reality, it should either be ‘0’ or ‘1’. To ascertain the correct value, we must call the ‘Get decoded transaction by hash’ API. This indicates that Moralis indeed has the correct value, but for some transactions in the initial API, the value is None.

Due to this issue, our project has to call the latter API for those transactions with None receipt_status. This adds a significant load to our project as we must call the Moralis API per transaction.

Would it be possible for you to address this issue in the “Get decoded transactions by wallet” API, to eliminate the need for calling the other API for each transaction?

Best regards,
Shadi

Hi Shadi,

Thank you for your message.

Can you please provide us some examples where you are having receipt_status as null? This will help us to replicate and identify the issue

Thanks

Hi,

Take, for example, this wallet address: 0x996737253bc72D0196f5D4110D679B0566dC3e84. Out of 54 native transfers, 24 have a receipt_status of ‘None’. A sample transaction hashes for these are as follows:

‘0xd7f9186b3ceab519c522d1a368724c0821ad676d84ea7d82bcaa3b17d24a64e9’
‘0xda9c22d536f96e2b0b36c2670937a70ce9898abd375016618fa3c1e17f7c649b’
‘0x76375bb1ee6885bb0752e02311d1523db98c524a2aac6144739d84fb6bde7708’
‘0x2bbb2676afa344cc6286157a67becf71e510431fe519fb25297fc907bb48ebfd’
‘0xad58fd04f8badad28534b679d7f4d47adb765a4ef299e50df7e6e6d094f045d7’
‘0x6c1e426ef49ac59c0cb4de76012c264f38861be03dad0ddb55ba5d57cf6dcf6e’
‘0x16ae369ff89108235f96d6854c17f1999a98ce808abb7a9929876c46aaa2cf07’
‘0xf5eff9692bca0589402ad6256c33df83a9804bd17480dd721fb83466f3a0eae8’
‘0x137094009a3cf8cc03cc491c90bbc51587f212ab251f1aff72f22d2465db98c6’
‘0xe64dae2283a9d5c1213a13221eb4b278583822fc19b18595caefeece075871b0’

However, if these hashes are checked using the “Get decoded transaction by hash” API, the receipt_status for each shows a value of either ‘0’ or ‘1’.

Thanks

Hi @Shadi

Thanks for the details. It seems like these transactions was very old. After doing some research I found that receipt_status will not be present in the older transactions. Receipt status was a feature introduced in Ethereum Byzantium Update.

You can identify these transactions using the receipt_root value. Whenever receipt_status is null, receipt_root value will be present. If both receipt_root and receipt_status values are null then the old transaction can be considered as failed.

I hope this data helps to update your code logic.:smiley:

Feel free to reply if you have any other questions.

Hi,

Thank you for your prompt response. However, I found a counterexample that contradicts this logic.

The transaction hash in question is ‘0x66971ae5ae59b3c3abdfd8811d5a8b75cdf2c46378208c5ae008913b3ed8ea36’, and the wallet address is ‘0x996737253bc72D0196f5D4110D679B0566dC3e84’.

When using the ‘Get decoded transactions by wallet’ API for this transaction, the ‘receipt_status’ is returned as ‘None’, and the ‘receipt_root’ has a value. However, when using the ‘Get decoded transaction by hash’ API, the ‘receipt_status’ is returned as ‘0’, indicating a failed transaction.

Could you kindly provide some clarification on this discrepancy?

Best regards

Hi @Shadi
Thanks for the data. From the etherscan I can see that it was a failed transaction. So maybe my previous consideration about receipt_root being null failed transactions might be wrong.:thinking:

Let me share this with the devs and will get back to you soon.

Hi @Shadi

The issue has been shared with devs. Apparently, we never had a way to identify if a transaction was successful or failed for the older transactions, since receipt_status is a newer feature introduced after 2017.

We will add a fix for this in the near future.

Hi @johnversus

Thank you so much :slight_smile: