After a Transfer() event of an ERC-20 token (and other similar tokens in the future), and/or periodically, fetch the token's totalSupply() from the EVM, and fetch the sender's and receiver's balanceOf() for the token from the EVM.
The goal is to be robust in the face of errors in our dead reckoning. There is a category of balances that we almost expect to get wrong with dead reckoning: When a token contract is first created, it might hardcode some initial balances and never emit events for those.
If the EVM fetch detects a discrepancy with the DB, and the DB hasn't been updated since we started the EVM fetch, log the discrepancy at error level. We'll want to look into these.
This could be a part of the same analyzer that fetches EVM token metadata, or a separate similarly-structured analyzer.
After a
Transfer()
event of an ERC-20 token (and other similar tokens in the future), and/or periodically, fetch the token's totalSupply() from the EVM, and fetch the sender's and receiver's balanceOf() for the token from the EVM.The goal is to be robust in the face of errors in our dead reckoning. There is a category of balances that we almost expect to get wrong with dead reckoning: When a token contract is first created, it might hardcode some initial balances and never emit events for those.
If the EVM fetch detects a discrepancy with the DB, and the DB hasn't been updated since we started the EVM fetch, log the discrepancy at error level. We'll want to look into these.
This could be a part of the same analyzer that fetches EVM token metadata, or a separate similarly-structured analyzer.