Guarantee data coherence for key DAOs treasuries

[lajarre]

Dumping this here, let's update with problems and solutions.

primedao: "0x567d220B0169836cBF351DF70A9c517096ec9De7"
bankless: "0xf26d1bb347a59f6c283c53156519cc1b1abaca51"
gitcoin:
    timelock: "0x57a8865cfB1eCEf7253c27da6B4BC3dAEE5Be518"
    multisig: "0xde21F729137C5Af1b01d73aF1dC21eFfa2B8a0d6"
    treasuryvester: "0x44aa9c5a034c1499ec27906e2d427b704b567ffe"
radicle: "0x8da8f82d2bbdd896822de723f55d6edf416130ba"
ens:
    registrar: "0x283Af0B28c62C092C9727F1Ee09c02CA627EB7F5"
    proxy: "0xCF60916b6CB4753f58533808fA610FcbD4098Ec0"
    timelock: "0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7"
    tokenlock: "0xd7A029Db2585553978190dB5E85eC724Aa4dF23f"
nouns: "0x0BC3807Ec262cB779b38D65b38158acC3bfedE10"
bitdao: "0x78605Df79524164911C144801f41e9811B7DB73D"
uniswap:
    unitimelock: "0x1a9c8182c09f50c8318d769245bea52c32be35bc"
    treasuryvester1: "0x4750c43867ef5f89869132eccf19b9b6c4286e1a"
    treasuryvester2: "0xe3953d9d317b834592ab58ab2c7a6ad22b54075d"
    treasuryvester3: "0x4b4e140d1f131fdad6fb59c13af796fd194e4135"
    treasuryvester4: "0x3d30b1ab88d487b0f3061f40de76845bec3f1e94"
gnosis:
    1: "0x458cD345B4C05e8DF39d0A07220feb4Ec19F5e6f"
    2: "0x10E4597fF93cbee194F4879f8f1d54a370DB6969"
    gnosissafeproxy: "0x4971DD016127F390a3EF6b956Ff944d0E2e1e462"
    gnosisdaosafe: "0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe"
    instaaccountv2: "0xfa5dcf356a2d80cf0c89d64a18a742edaf8d30e8"
    activetreasurymanagement: "0x849D52316331967b6fF1198e5E32A0eB168D039d"
    proxy: "0xbc79855178842fdba0c353494895deef509e26bb"
    vesting: "0xec83f750adfe0e52a8b0dba6eeb6be5ba0bee535"
balancer:
    multisig: "0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f"
    protocolfeescollector: "0xce88686553686DA562CE7Cea497CE749DA109f9F"

[vaughnmck]

Great. Added to the Product Backlog.

[lajarre]

Problem faced: in a lot of cases, tokens are missing in the Balances series because of the lone-transaction filter.
Solution: ongoing in #78

[lajarre]

Problem faced 2: token transfer histories are starting with negative values (negative delta in the first transfer listed in the Covalent transfers_v2 api, see https://www.covalenthq.com/docs/api/#/0/Get%20ERC20%20token%20transfers%20for%20address/USD/1 ).
Solution: it seems it's due to pagination of transfers which we are not taking into account. I'm going to propose a solution based on proper usage of pagination but also on retro-filling the balances from present to past (which will allow not going back to the first transfer, to save resources).

cc @acemasterjb

[lajarre]

First part of the fix ready to merge in #82

[lajarre]

Historical transfers were not all properly taken into account, fixed in #87

Now, we still have (at least) the following issues with the PrimeDAO wallet:

• the USD balance looks different based on different data sources, for example:
  • in our version: https://review-to-pr-fix-pagina-kiajbf.herokuapp.com/?address=0x567d220B0169836cBF351DF70A9c517096ec9De7
  • in Dune: https://dune.com/queries/1051483
• the Spread balance is totally off.

For the USD balance discrepancy, I'm not sure for now what is the reason. It seems probable that the D2D token had a very volatile price and thus different data sources didn't record the same past values (day high? close? etc.) and which data source / method should be considered best.

• Agree on a reason for the USD balance discrepancy, and fix it if needed.
• Fix the Spread issue, see Spread graph with buggy offset (PrimeDAO) #92