Please support tracking erc20 token approvals amounts.

[ytrezq]

Tokens became more important than Ether with the rise of DeFi. This is currently something very hard which requires full storage trace scanning for all transactions outside the node software as some contracts have calls which modify allowances in a way that fire a custom event.

More exactly, I would like to be able to find who approved a given address for token spending.

There s should be 3 optional parameters

• Token. An array of Token contract s address, which if given allows to filter the tokens concerned. If not present, all existing erc20 tokens concerned by the approval call search are to be returned.
• Amount. Which would allow to filter based on a specific approval amount. Please note some tokens are unable to use UINT256_MAX for infinite amount as they for example limit themselves to UINT96_MAX, so it should be made optional to be able to return all amounts even if interested into infinite approvals.
• Block. If a block number, returns the result for the given block number. If latestblock, returns for the latest mined block. If PendingBlock, return the would be result after all transactions in the mempool would be mined in a Parity/Openethereum fashion. Default would be latestblock.

[tjayrush]

Hi @ytrezq

Thanks for your suggestion.

I completely understand exactly what you're asking for here, and while I agree that It's a much-needed capability of the node, I'm not sure it's Erigon specific. This is more of an issue at the RPC level which would extend across all nodes, not just Erigon.

Having said that, I work on a project called TrueBlocks (we're one of Erigon's ecosystem partners -- you can find our channel in their discord).

Your first paragraph gets at exactly why the problem is hard. A single address may own hundreds of different tokens and, in order to get a completely accurate list of that address's token holdings (or in your case allowances), one would have to either know about each token beforehand or scan the entire chain (including into the traces) to find all occurrences.

TrueBlocks builds an index of every appearance of an address (including the "hidden-in-the-traces" appearances) for exactly this purpose making your query pretty straight-forward.

chifra export <address>

Note that, unlike the RPC, this query is against the receiving address of the token, not the token address and it finds every appearance anywhere on the chain, not just events.

The following query returns every appearance of the address in an event with a given topic.

chifra export --logs <address> <topic> [block-list]

and the next

chifra export --logs --emitter <token_address...> <address...> <topic> [block-list]

find events with a given topic emitted by a given list of token addresses for one or more holders at one or more blocks.

We're hoping to incorporate some of the indexing ideas we have about building this index into Erigon2. That conversation is just getting started, and you're welcome to join in on the discord.

I think this issue can probably be closed or brought to the broader RPC discussion at the EIP level.

[ytrezq]

@tjayrush hi, correct, this isn t Enrigon specific, but as it might requires a database change, this might be the only node willing to implement the feature as other nodes focus on database stability.

Also, as I said, I want to know who gave approvals to whom, not getting the list of approvals given by a specific address. I m meaning something like https://contract-library.com/contracts/Ethereum/0xDef1C0ded9bec7F1a1670819833240f027b25EfF/approvals which don t work on large datasets.

@tjayrush so chiffra can t be used for what I want, since receiving an approvals by an allowers doesn t means using it so the address who receive an approval might have never called the token address.

[ytrezq]

@tjayrush also doing in the node, provide the possibility to filter the result beforehand through plain geth s GraphQl capabilities.

[tjayrush]

...this isn't Enrigon specific, but as it might require a database change, this might be the only node willing to implement the feature as other nodes focus on database stability.

I'm not speaking for the team, but to me, this sentence, in itself, contains three arguments why not to implement this change: (1) it actually would be Erigon specific -- by that I mean it is not at the RPC level, (2) it requires a database change, and (3) it might cause database instability.

As I say, I'm not speaking for the team, so I'll wish you luck and bow out of this conversation.

[ytrezq]

Coing from Openethereum/Parity, i m a bit a acustomed to get things working without using a standard.

For me, attempts to standardize the rpc will fails because geth/Openethereum will comply it would require to modify the database. On the other end, Erigon focus on database agility and is not afraid to break compatibility for speedup. Though I saw this project implement rpc endpoints which requires custom database changes in other node but not in Erigon. Technically speaking I m unsure how this should be implemented.

Although it came from other nodes, Erigon implemented non standard rpc.

[antonio-fr]

I'm not sure sure this thing needs to be addressed by the node. Anyway, for now, you can use DappsProtect.com. Given an address, it provides all the tokens approvals, including NFTs. It covers Ethereum, Polygon, BSC and Fantom.

[ytrezq]

@antonio-fr no I can t, as again, I want to search for allowers given an address, not spenders.

I think scanning all transaction s storage traces should be only the job of the node and that if it needs to be done outside, it s because an api/rpc is missing.

[antonio-fr]

Oh OK, you want all the allowed users given a contract address. DappsProtect is user centric (wallet) indeed, and it doesn't provide that. For curiosity, what is the use case of knowing all the users allowing a dapp contract?

[ytrezq]

@antonio-fr I want to perform it for various/past dapp analysing success like UniswapV1. I m meaning counting allowers regardless of the token amounts. Though there s might be a more generic way to implement this in a way that both ends can be queried.

Even for UniswapV1, the number is sometimes still large enough that contract-library.com doesn t returns any results (api timeout).

I don t have an Erigon full archival node, and I feel unconfortable building a database during months a second time using existing tools.

Sauf si Marine Le pen, opposante notoire au chiffromonaies s étant prononcée pour l interdiction de toute activité lié au chiffromonaies (ce qui peut être fait par décret en utilisant les lois anti blanchiment) gagne les élections. Je n ai pas de Master ou de diplôme d école d ingénieur publique pour m expatrier.

[antonio-fr]

Try Dune Analytics, it offers pretty much what you are seeking.

[ytrezq]

Try Dune Analytics, it offers pretty much what you are seeking.

@antonio-fr no, I want allowers count as standalone anyway. A specific metric.

[github-actions[bot]]

This issue is stale because it has been open for 40 days with no activity. Remove stale label or comment, or this will be closed in 7 days.

[ytrezq]

Problem still actual with a whitehat attempt that failed because of incomplete list building.

[github-actions[bot]]

This issue is stale because it has been open for 40 days with no activity. Remove stale label or comment, or this will be closed in 7 days.

[github-actions[bot]]

This issue is stale because it has been open for 40 days with no activity. Remove stale label or comment, or this will be closed in 7 days.

[ytrezq]

Problem still actual with a whitehat attempt that failed because of incomplete list building.

[github-actions[bot]]

This issue is stale because it has been open for 40 days with no activity. Remove stale label or comment, or this will be closed in 7 days.

[ytrezq]

Problem still actual with a whitehat attempt that failed because of incomplete list building.