Forum

Getting address balance and transactions through Blockscout's API

I’m integrating xDAI DAOs to our dashboard at https://deepdao.io and trying to use the Blockscout API for the DAO financial value. It seems like something is not aligned correctly.

Here’s an example, regarding this address, 0xE3a89ed4956C4f7173418E4dEC2A77a5F60807DE

The transactions here show 4 txs, with a flow into the contract totaling 10k xDAI.

When looking at the internal transactions by using the REST API, action=txlistinternal I get a huge number of calls, and the total value going out of the contract is 20k xDAI, which is impossible because it’s larger than the total in.

In addition there are several transactions which I know about and xDAI was transfered out of the contract, but are not recorded by the API.

What am I missing?

@Eyal_Eithcowich

When looking at the internal transactions by using the REST API, action=txlistinternal I get a huge number of calls, and the total value going out of the contract is 20k xDAI, which is impossible because it’s larger than the total in.

Please, post requests here, which you made to txlistinternal API endpoint where you see more total value going out than expected.

In addition there are several transactions which I know about and xDAI was transfered out of the contract, but are not recorded by the API.

Can you elaborate hashes or other details of those transactions?

1 Like

Hi @viktorbaranov thank you for looking into this. The two requests I’m using are

https://blockscout.com/poa/xdai/api?module=account&action=txlist&address=0xe3a89ed4956c4f7173418e4dec2a77a5f60807de

and

https://blockscout.com/poa/xdai/api?module=account&action=txlistinternal&address=0xe3a89ed4956c4f7173418e4dec2a77a5f60807de

The 2nd one is now timing out, but it worked when I first tried it.

Just to make sure I explained clearly what we need: a full list of all transactions in and out of the address for all tokens.

Hi,
Honestly, I didn’t find any problems with those endpoints.

txlist returns all regular in/out transactions
txlistinternal returns all internal in/out transactions

Note here, that it is possible, that regular transaction which internally calls target contract, is made to another contract. That means, that transaction will appear in the list of txlistinternal API and will NOT appear in the list of txlist API for target contract.

For instance, this tx:

This is why you see more txs in txlistinternal endpoint.

Thus, txlistinternal is what you need to track all in/out internal txs for a target address of your contract. But in order to track all regular transactions, where tokens are involved, you need smth another. I suppose, it would be suitable to use tokentx endpoint for that

Get token transfer events by address. Up to a maximum of 10,000 token transfer events. Also available through a GraphQL ‘token_transfers’ query.
?module= account &action= tokentx &address={ addressHash }

1 Like

Thanks @viktorbaranov. Right now I’m not even able to run this call

https://blockscout.com/poa/xdai/api?module=account&action=txlistinternal&address=0xe3a89ed4956c4f7173418e4dec2a77a5f60807de

because it times out. When I was able to run it, the values where as I described above. I’m talking about the total xDAI, not tokens at this point.

Use pagination to mitigate gateway timeout issue

https://blockscout.com/poa/xdai/api?module=account&action=txlistinternal&address=0xe3a89ed4956c4f7173418e4dec2a77a5f60807de&offset=100

and other filters if possible. For instance, firstBlock since you know when contract was created.

1 Like

Hi @viktorbaranov is there a doc for the API filters? For example to use pagination I’d need a start param in addition to offset. Thanks.

Also it’s really not clear why are there so many internal txs for this address, but this could be an issue with the contact.

is there a doc for the API filters?

Yes, each API method has “Try it out” section on https://blockscout.com/poa/xdai/api-docs page with the description of each parameter.

You need to add page number together with offset for pagination.

1 Like

Thanks. I tried several configurations of the offset & page. A few issues:

  1. Offset of 100 returns 200 transactions, and in general the API returns 2x of the offset.

  2. The last transaction still dies on a time out, whether I’m trying with a large, or small offset.

  3. It dies at around 60,000 internal transactions, which is a mystery to me, why so many of them? But I guess this is not related to Blockscout but to the contract itself.

For example try this one:
https://blockscout.com/poa/xdai/api?module=account&action=txlistinternal&address=0xe3a89ed4956c4f7173418e4dec2a77a5f60807de&address=0xe3a89ed4956c4f7173418e4dec2a77a5f60807de&offset=1000&page=10

This returns 2000 transactions, 2x of the offset = 1000.

https://blockscout.com/poa/xdai/api?module=account&action=txlistinternal&address=0xe3a89ed4956c4f7173418e4dec2a77a5f60807de&address=0xe3a89ed4956c4f7173418e4dec2a77a5f60807de&offset=1000&page=50

This times out.

Just reminder to myself, that all this is to get the full list of transactions that involve xDAI going in and out, which when the call wasn’t timing out gave what seemed on my end as an incorrect xDAI balance.

Currently, offset in this API endpoint works for each direction. By direction I mean to/from filters. Thus, 1000 items per page where internal_transactions sent to address and 1000 items per page for internal_transactions sent form address. And 2000 int txs in total.

It dies at around 60,000 internal transactions, which is a mystery to me, why so many of them? But I guess this is not related to Blockscout but to the contract itself.

I suppose it is timing out because there are less internal txs than 60_000. Possibly you request page which doesn’t exist. The suggesion here is to request internal_transactions in the smallest chunks as possible from the first page and see where exactly it became timing out. Likely, that would be the end of the internal transactions list. Anyways, I will try to address performance of the query, when very deep internal transactions are requested.

1 Like

I could work with the to/from of the API, but not sure how to deal with the time out on the last batch. It runs well, then eventually times out regardless of the batch size.