tjayrush
commented
1 year ago This transaction https://etherscan.io/tx/0x634799410165000edaf1b1e8e5e8055b39cdd534d3c3dc9738865d39adb5d888 does not reconcile.
Reproduce with:
chifra export 0x65b0d5e1dc0dee0704f53f660aa865c72e986fc7 --accounting --statements --ether --fmt json --first_block 11670418 --last_block 11670420 --asset 0xc713e5e149d5d0715dcd1c156a020976e7e56b88This happens because the smart contract does not generate events for the interest income.
Of course, this is an error by the smart contract.
Because we do not want to do "per-smart-contract" accounting (as this would be completely unsuportable), we will solve this in the following way.
Solution: We will create two new fields in our reconciliation data called impliedMint and impliedBurn. This will account for intra-appearance mis-balances. That is, reconciliation errors that occur internal to a transaction. If the actual ending balance of a transaction is below the expected value, create an impliedMint. If the calculated value is above the actual value, create an impliedBurn. In this case it would be an impliedMint because the interest is missing.
Solution for inter-appearance reconciliation errors: In this case, there is a missing transaction between the previous appearance and the current appearance. Here we will create a correctingMint and/or correctingBurn.
Covered by test case acctExport_failed_statement_2572_2.txt
~This transaction: https://etherscan.io/tx/0x506e7978ba52886681b75797e4403579ba703b5f9df576a34602ada1709085fb~
~Does not reconcile. Reproduce with:~
~chifra export 0x054993ab0f2b1acc0fdc65405ee203b4271bebe6 --accounting --statements --ether --fmt json --first_block 15549161 --last_block 15549163 --asset 0xf5b2c59f6db42ffcdfc1625999c81fdf17953384~
~The reason this happens can be called a 'misleading airdrop.'~
~The smart contract generates events, but there is no change in any of the ERC20 balances.~
~We've been told this is method that people fish for private keys. "Hey, you got an airdrop, visit this website..."~
~This is a less expensive way to do this (they would have to pay for state changes otherwise).~
~We can delete these automatically by doing this:~
~1) Does the reconciliation not balance?~ ~2) Is the transfer a token transfer?~ ~3) Does the transaction contain more than some number (100?) of Transfer events?~ ~4) Does the account balance at the previous block == account balance at end of the block? (no state change)~
~If yes -- ignore the event.~
~Covered by test case
acctExport_failed_statement_2572_1.txt~