The UI of the reserve overview for AMPL shows some misleading things. This ARC collates such misleading things.
Misleading information can cause borrowers and lenders to make mistakes.
Here is one such misleading thing. In the top right corner, the utilization rate graph shows 32%. However, in the middle, the utilization rate pie chart shows 49%.
Checking a second source for the utilization rate (the number of tokens here as compared to the number of tokens here) confirms that the utilization rate is 49%. This suggests that the utilization rate graph is misleading.
it is only updated a few times a day, or so it seems
Fair enough, this explains why the graph does not show the 100% borrow rates we have during rebase.
However, it does not explain this: for more than 2 days now, the graphed utilization rate still shows ~32%, yet the actual utilization rate has been sitting at 49%.
In fact, since I first posted, the graphed utilization rate is now down to 30.5%, yet the actual rate is still 49%.
I think the primary issue is the incorrect interest rates sometimes quoted to depositors and borrowers.
As described here, the quoted and actual rates diverge exponentially as it gets above 10%. This exists on every market so it’s not AMPL specific, but AMPL is uniquely exposed because the interest rate is very high at the top end of utilization.
Right now, users need to look up the utilization rate in this table, curve #1, to know the applied rate.
I don’t know if this is directly within the scope of Aave governance since it can only be addressed in the frontend. However, it should be looked at as soon as possible by the maintainers.
Hello, i just checked the code and i think the issue is very specific to AMPL (although agree that it could be more obvious that the chart renders 6h avg).
It updates every 5 minutes and the 6h is just a resolution setting to limit the dots to be rendered - it could be lowered to 1h, but i think the 6h setting was chosen to reduce noise in the chart.
There are multiple issues with the utilization though:
the data is based on thegraph an apparently for AMPL (at least)the utilization data is completely broken. Currently utilization is ~85%, and the graph shows sth around ~ 56% https://thegraph.com/hosted-service/subgraph/aave/protocol-v2?selected=playground
There are even data-points where the utilization for AMPL is negative.
// in case you want to check yourself
{
reserves{
symbol
utilizationRate
}
}
while deposit/ variable apy are based on accrued index calculation and therefore should be pretty accurate, the utilization on the other hand is just a snapshot taken every 5min (ignoring what happens in between) - didn’t do the math, but can’t imagine this has a huge impact aave-api/RatesHistory.ts at master · aave/aave-api · GitHub
edit: just digged a little and supply is also wrong and therefore apy probably as well. will create a pr to disable the charts on ampl for now
This screenshot shows an APY of 706.18%, but it should be closer to 127,000%.
This is because the contracts and frontend each calculate APY differently. In AAVEs MathUtils there is an over-approximation in the application of the interest rate for computing compounded interest that is not accounted for in the frontend.
Since the contracts determine ultimate behavior, the frontend is quoting incorrect rates. This is not specific to AMPL, as it would be the same for any market with an APY over 50% or so.
With Ampl being at max util for almost 2 days in a row, this issue is becoming very urgent.
As others have mentioned, borrowers and depositors are seeing one APY on the front end, while there is a completely different APY calculated on the backend.
This can lead to borrowers paying excessive fees on their loans due to misinfornation. Also, there aren’t any disclaimers or any additional information for borrowers on what the real rate is.
Not saying this will happen, but some individuals may resort to legal action because of this.
Each day that passes with borrowing at a max utility, the situation exponentially becomes worse. I think this should be a high priority fix. I’m disappointed and shocked to see this has been an issue for so long, and known openly but hasn’t been addressed yet without at least a disclaimer on the site in the interim.
Hi @neptune
It is good the main issue here has been fixed but do you think the chart should say on it somewhere that the data is lagged and the user should look at the raw numbers for the latest and most up to date information. I expect not everyone will realize they should be doing this already