In reply to posts asking about Ampleforth’s position on this matter, the Ampleforth development team (Fragments) will continue offering the necessary support for investigation and for BGDLabs in reaching a proposal that satisfies the community. We also support the arrangement of deferring to BGDLabs to take the lead to a resolution as we believe they are best positioned to perform this work.
For transparency and to help the community understand the situation, here is the timeline of events that led to the current state:
-
The discrepancy issue on AMPL Aave V2 market was initially noticed for the first time at a much smaller scale in May 2022.
It was discussed with BGDLabs and was investigated and monitored by Ampleforth. At the time, the discrepancy was small, well below the AMPL reserve balance. -
The conclusion between the two groups at the time was that the accumulation of small errors in interest that are typically negligible for other AAVE markets became relevant for the AMPL market due to the pool APY reaching up to 186210.38% at 100% utilization.
It was decided in Oct 2022, after discussion between BGDLabs and Ampleforth, that in the transition to AAVE V3, the aAMPL V2 pool will be frozen and kept frozen. If it happened that the pool becomes insolvent before all deposits are withdrawn, BGDLabs would propose using the AMPL reserve to inject more funds in the pool for withdrawal. -
After this proposal Tally | Aave Proposal was executed, Ampleforth team assumed the issue was concluded from our side.
-
In Dec 2023 - more than a year after the proposal above was executed - we were contacted by BGDLabs about a discrepancy between aAMPL total supply and the AMPL liquidity in the pool.
-
After revisiting this, we learned about two events that had happened in the interim. First, after the AMPL market was frozen, aAMPL deposits were re-enabled in Tally | Aave Proposal (Risk Parameter Updates for Aave v2 Ethereum Liquidity Pool). Second, the AMPL reserve needed for the contingency was liquidated in Tally | Aave Proposal (Ethereum v2 Collector Contract Consolidation)
-
Our initial proposal to BGDLabs for resolution of this larger shortfall was to pick a date before the discrepancy started growing exponentially, and assume lenders were holding AMPL since that point. The aim was to have a simple and non-controversial resolution to avoid having to simulate AAVE platform behavior off-chain.
At that point the total liability was around 450k USD (~52,000 WAMPL at ~$8.5) which could have been mostly covered by the AMPL reserves and potentially the Ampleforth Foundation if it became necessary. -
BGDLabs did not support making this proposal to the community and instead advised that we needed a simulation of balances, based on the specific transactions of the holders, compared to if the bug never existed. Because the exact source of the issue had still not been identified, that task would involve simulating AAVE’s lending/borrowing logic, which would require significant development and testing effort.
-
We continued the effort to pinpoint the root source of the discrepancy, but despite significant technical investment, we have been unable to isolate any issue in the aAMPL implementation. However, it was determined that even with the discrepancy, adjusting the liquidity index of the pool with the same ratio for all balances can be used to get balances at a particular point of time, and that can be used to calculate the balances on the pool freezing date. Based on that, we posted this on March 9 AMPL problem on Aave v2 Ethereum - #45 by Naguib