1

It turns out that the getSignaturesForAddress RPC method is unreliable as soon the "before" or "until" parameter is being used. An example would be:

POST https://explorer-api.devnet.solana.com/

{"method":"getConfirmedSignaturesForAddress2","jsonrpc":"2.0","params":["4UTjuiHzKaBgZsahAMfB71HgjXbTX7dBLXnRy4Gby5tg",{"until":"5G9xuEkjW2KuGxbuo49jcGihCpTMi5nqFat5W7AirF7qTjmUUcf5kPPEyZs7sRSSyyjjU9YmSRoaWCL2ozGfVKK5","limit":25}],"id":"577357bc-d612-491c-9fe7-02cade99e739"}

As a result, you will receive the following signature: 2CnUUp5QYgTTZMnTuBcBnVFcWbvD2pAYsjCXssjDhUSYDLVoFUFbfWWV1Xz2Dq2fGZhyes4cnYh5b6FbeHqjjRgd It is part of the same block as the 5G9... address

Now, if you start to call the same query, but this time with 2Cn..., you will notice that the address with 5G9... will be part of that result again (kind of looping). Unfortunately, this is not the only issue - when transactions are part of the same block, this becomes completely unreliable. before/until parameters might be adding or missing transactions of the same block against expectation.

I am using solana/web3-js and have been trying the legacy and 2.0.0-experimental.56103b0 version. It does not make a difference - pretty clear, because both are using RPC methods under the hood.

It neither makes a difference to use getSignaturesForAddress or the deprecated getConfirmedSignaturesForAddress2 method.

Currently, I have to retrieve the full history, which might exceed the limit of 1000 easily. But let's assume there would be 2000 transactions inside one block. In such case, I would never be able to visualize the full history as I cannot control, which transactions I receive. I understand this is quite an unlikely scenario, but it would probably much more attractive to process transactions on a specific address by giving it a range of block number. E.g. getSignaturesForAddress("beforeBlock: 500", "untilBlock": 100). Therefore, I could control much better what has already been processed and what not.

I'd be happy to get some input from you guys on this. Maybe someone ran into a similar issue - I don't expect the RPC to update soon in this regard, but I am kind of stuck on this limitation.

Kind regards!

1 Answer 1

1

It seems like I found the answer to my problem. Theoretically, the limit/before RPC call is working, BUT...

Order of transactions explains that there is the concept of sub-blocks/entries, but they don't have a guaranteed order across validators.

So far, I have been using https://api.devnet.solana.com, which seems to be a pool of servers.

From the website: "Solana RPC service running on lon32.nodes.rpcpool.com in region EU on network devnet."

My assumption is, that all my RPC queries are not executed on the same server. This must be where the order inside blocks might differ, depending on the server.

I have started to use a local validator and the original issue immediately had been solved. https://docs.solanalabs.com/cli/examples/test-validator

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.