Closed defispartan closed 1 month ago
tagging for awareness @tomfutago i can help look too, but if you end up looking, let me know here!
WIP: We are still researching the issue and will provide example queries
thank you for raising the issue. with this note, we will wait for follow up on examples.
@jeff-dude I updated the description with specific examples, and after analyzing the data and lending.supply
model code, I also outlined what I think is the solution. My SQL skills are pretty rusty though so it would be helpful if someone could help us implement a fix :)
I can take a look at this.
PR #6447 with lending.supply
updated logic is ready for review.
Notes:
lending.borrow
to exclude repay records if flagged as useATokens
, but reversed this change as it doesn't seem to return correct totals - if this change should be considered, plmklending.supply
macro and spells relying on it combine all events affecting supplies, but it doesn't take into account accumulated interest - currently this needs to be calculated separately by looking at Pool_evt_ReserveDataUpdated
(example looking at an individual account). It'd be nice to have a spell showing aggregated balance for each market, but that requires building additional spells - perhaps something similar to ERC20 transfers/balances, which is quite a task..@tomfutago tysm!
lending.borrow
is correct how it's currently handledscaledBalance = supplyBalance / liquidityIndex (at block of transaction)
liquidityIndex
and variableBorrowIndex
, from `Pool_evt_ReserveDataUpdated. Current index multiplied by the cumulative scaledBalance = current cumulative balance including accrued interestIf there's anything we can do test these changes on our side let us know and we can take a look
Just for clarity - I'm not planning to add accumulated interest logic in PR #6447 - just additional flagged repay events.
Re testing - here are 2 queries that might help (but if there's anything else that comes to mind, ofc go for it):
lending.supply
as it currently stands)The output totals are much lower than the original query, which is what I'd expect as it's "raw supplies" without accounting for accumulated interest (can be dealt with by adding this logic to the query).
Description
Certain tokens in Aave V3 markets report total supplied balances in
lending.supply
that exceed onchain values and we believe it's due to this table not factoring in aTokens that are burned throughrepayWithATokens
method.Current behavior
The total supply of certain tokens in
lending.supply
is higher than compared to queryingAToken.totalSupply()
onchain.This dashboard contains cumulative supply queries where we are seeing discrepancies.
The differences vary for each market / token. The tokens with largest differences correlate with most borrowed tokens, and specifically with markets where there were reward programs which incentivized leveraged stablecoin borrowing. Leveraged positions are often closed with the new
repayWithATokens
feature in Aave V3, which is further evidence that this is the potential cause.The biggest discrepency is Avalanche USDC. Onchain the Avalanche aUSDC totalSupply = 88m which is much lower than cumulative amount from lending.supply table = 2.9b.
Expected behavior
Aave V3 values in
lending.supply
match onchain queries ofAToken.totalSupply()
.As an example, Avalanche aUSDC totalSupply should match cumulative amount from lending.supply table.
Impacted model(s)
lending.supply
Possible solution
I think the cause is a function that was introduced in Aave V3,
repayWithATokens
.If user has a supply and borrow position in the same token this function allows them to repay the borrow position by using the supplied tokens directly (burning aTokens). If this function is used it is emitted as a parameter withing the Repay event.
Currently the calculation for the lending.supply model does not factor aTokens burned through this function into the cumulative supply.
I think the solution is to add
Pool_evt_Repay
to the Aave supply sources and subtract the repay amount from total supply if the repayWithATokens flag is set in the repay event.