[BUG] Discrepencies with Aave total supplied values in `lending.supply`

[defispartan]

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 through repayWithATokens method.

Current behavior

The total supply of certain tokens in lending.supply is higher than compared to querying AToken.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 of AToken.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.

[jeff-dude]

tagging for awareness @tomfutago i can help look too, but if you end up looking, let me know here!

[jeff-dude]

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.

[defispartan]

@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 :)

[tomfutago]

I can take a look at this.

[tomfutago]

PR #6447 with lending.supply updated logic is ready for review.

Notes:

• I also experimentally changed 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, plmk
• lending.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..

[defispartan]

@tomfutago tysm!

• I think the lending.borrow is correct how it's currently handled
• That would be nice to account for accumulated interest as well, for supplies and borrows. To capture this in a table it would need to index 3 things:
  1. Cumulative scaledBalance. The query you shared has the correct steps to do this calculation, scaledBalance = supplyBalance / liquidityIndex (at block of transaction)
  2. Current liquidityIndex and variableBorrowIndex, from `Pool_evt_ReserveDataUpdated. Current index multiplied by the cumulative scaledBalance = current cumulative balance including accrued interest
  3. An additional event would need to be tracked, BalanceTransfer which is emitted on transfer of aTokens and debtTokens. These evens would need to be used to add or subtract from the cumulative scaledBalance

[defispartan]

If there's anything we can do test these changes on our side let us know and we can take a look

[tomfutago]

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):

• aave v3 lending.supply mockup query (just avalanche)
• and forked Supply breakdown Avalanche v3 that uses query above (rather than 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).