Aave V3 Fee Issue (potentially large deviations from the real value)

[melotik]

Hey defillama team,

I am over at messari and noticed a bug in how you are calculating the fees for aave v3 (likely other aave protocols and forks).

https://github.com/DefiLlama/dimension-adapters/blob/ce9c198f72023d150dfa5aab915d9c484588a7c5/fees/aave/index.ts#L392

What is "outstanding treasury income"? This is the accruedToTreasury field in the aave subgraph you use. And that coincides with accruedToTreasury in aave smart contracts.

What is accruedToTreasury? "//the current treasury balance, scaled" - per comment in contracts

How does this field behave? This is essentially a counter for reserve accrued interest, and once it is large enough a MintToTreasury event is emitted and the counter is reset to 0, and the value (in aTokens) is minted to the treasury.

Why is this wrong?

1. This is not a strictly increasing field. So it is reset to 0, and when you subtract current value by yesterday's value it is possible to get negative values. Doesn't seem to be handled in the open source code, so I am guessing you do something internally to hide these values.
2. This value is really just lifetimeReserveFactorAccrued or treasuryIncomeUSD (in the adapters). So it is double counting fees generated to the protocol from user interest sent to the treasury.

What are the effects? There are pretty massive $1mm+ spikes, that don't coincide with the actual revenue.

Source: https://defillama.com/protocol/aave-v3

[dtmkeng]

fixed https://github.com/DefiLlama/dimension-adapters/commit/bd3d3b36037ccb0738787965bc2c4a810759cd65

[melotik]

The data looks the same, does this require a backfill?

[dtmkeng]

The data looks the same, does this require a backfill?

which day ?