I will repeat for the third time, the error was in the smart contract from the very beginning, and over time it was reflected more and more. From time to time I carried out manual calculation of my aAmpl, and when, for example, there was a negative rebase, with 50% of the borrowed liquidity, aAmpl holders should have received only 50% of the rebase. BUT, this value was greater, and as I said, over time, the difference between what it should have been with the right contract, and how it was actually, changed and degraded to the point where we are now. This error started a long time ago, not in the Autumn of 23 as you said. And when devs from Ampleforth will find the cause of the bug in the smart contract, everyone will be able to see it.
Its a reason, why I wrote in my previous messages, it will be mostly impossible to do absolutely accurate calculations now. Because you will need to take into account every deposit-withdrawal of aAmpl, its quantity, exact time, you should find smart contract bug, and understand how it was influencing everything. Also aAmpl APY % was influencing deposited balance ~ every second, so unless someone have quantum processor, I really dont understand how you can simulate all this situation accurately.
With a financial asset like AMPL, even minor deviations in the past will, in a butterfly effect, accumulate and be reflected in an avalanche-like manner, what we all see now.
From the discussion so far in the thread, it seems only fair solution is that Ampleforth DAO should mint new AMPLs, airdrop them to the wallets affected on Aave (based on snapshot balance) and concurrently burn the AMPL/aAMPL locked in on Aave, with the help from the Aave team. This saves an enormous amount of time for everyone involved in analyzing the entire history and helps 800+ AMPL investors/ users on Aave have the most reasonable outcome. cc @bgdlabs @ChaosLabs @Naguib @evankuo
I dont think minting brand new Ampl is an option, since the team doesnāt have the admin keys anymore to do something like that.
The Ampl would have to come from the Forth DAO treasury
I would sincerely request Ampleforth team to explore options here.
The Forth DAO treasury market value is currently at $57M, as of this writing. Now, roughly 2 million AMPL tokens would need to be airdropped looking at the current supply of AMPL that is stuck on AAVE and at current market price, it would be roughly $2.7M (as of this writing) so that comes down to about little less than 5%. So, the 800+ AMPL long-term investors/ users can be rescued by the <5% of the current treasury balance. This will help alleviate the pain for all these 800+ AMPL users immediately. Now, Forth DAO/ Ampleforth team can work with Aave team to fix the technical errors in Aave implementation to recover as much AMPL stuck on Aave as possible.
Curious to hear everyoneās thoughts, specially of Ampleforth and Aave teams.
Why would Forth DAO pay out it if there are issues on AAVEās smart contract?
That has been my concern as well thanks for that question
So may be there is some misunderstanding. Are you saying that all the AMPL investors are stuck on Aave solely due to Aaveās smart contract issue? Nothing to do with how AMPL team implemented AMPL on Aave? My apologies if I misread. If 800+ users are stuck due to issues in Aave smart contract then I agree Aave should compensate these users. But compensating at the 20% of current USD balance is not fair, it should be based on the current balance (either AMPL tokens or USD balance) - please note we have stuck around in the worst times in the market so when the market is in good conditions, we should not be penalized for a technical error in a system where we staked our tokens. @bgdlabs @ChaosLabs please confirm. Also ccāing @stani
Because the AMPL developers made a mistake in the smart contract from start, and they still cannot determine what exactly the mistake was. And AAVE is also responsible since they should have audited the smart contract before integrating it into the AAVE platform to make sure it would work fine. Thus, both parties are responsible. I just manually checked all the balances of aAmpl holders, there are 751 wallets with 5 aAmpl or more, so many people are affected by this issue.
We also donāt know if the ~500k$ that is still in the old geyser is included in the calculation of the total number of aAmpl that is displayed at the etherscan aAmpl address. I have early read question about this case from ubAMPL holder, but nobody replied to himā¦
This is accounted for in the per address distribution sheet shared by ChaosLabs, the specific address is 0xf03387d8d0ff326ab586a58e0ab4121d106147df.
Ah, so from this address token exchange takes place, aAmpl for ubAmpl. Well, good it is like that, so all ubAmpls are already calculated then as aAmpls
If both teams are responsible so how about Aave team airdrops the 50% of current AMPL balance and Ampleforth team does the remaining 50% of the AMPL balance to the wallets affected on the Aave. And then both Ampleforth and Aave teams can work together to figure out what to do with the AMPL supply stuck on Aave.
So letās say if at present I have 1000 AMPL tokens stuck on Aave due to the smart contract errors, then Ampleforth airdrops 500 AMPL tokens and Aave airdrops another 500 AMPL tokens to my wallet. I am okay if I donāt have access to my 1000 AMPL tokens stuck on Aave.
This way, a resolution can be provided to all the 800 users quickly and then both Aave and Ampleforth teams can work on their leisure to figure out how to deal with the AMPL stuck on Aave.
We need to wait for AMPL to finally start a dialogue with us publicly. So far they are chatting with AAVE in private chats, and we donāt even know what or how they are talking about. Actually because of lack of transparency from AMPL team we are in confused state right now
I agree. All I am trying to say is that there are 800 users affected by technical issues in two very prestigious protocols (and in fact, one very very prestigious, almost the cornerstone of DeFi - Aave) and I also understand that addressing those issues is complex and may take long time to fully resolve. So in the interest of doing the right thing for their users, if the two teams can step in to help users withdraw the current AMPL balance, that would go a long way in strengthening our belief in the protocols and community. cc @evankuo @stani @bgdlabs @ChaosLabs
Actually going back to this briefly, there is something Iām confused about that perhaps you or @ChaosLabs can provide clarity on.
I was reading [ARFC] - Chaos Labs RF and IR Updates - Aave V2 Ethereum - 2023.11.24 again after it was linked again recently and noticed that it states AMPL has total supply and borrows of ~$40,000, presumably at the time of posting in Nov 2023.
Looking around, these figures were presumably sourced from ChaosLabsā analytics site, where we can find an summary of the AMPL market here: Chaos Labs
Reading it today, we see:
That 64K AMPL is very different to the aAMPL total supply etherscan displays here: Aave interest bearing AMPL (aAMPL) Token Tracker | Etherscan
Am I fundamentally misunderstanding what these total supply and borrow values represent?
Or are there issues with how ChaosLabs is tracking the AMPL market?
(The rebasing nature of the token wouldnāt make it a surprise to me that it requires custom work to behave correctly, afterall)
I just realized yesterday that because over 300k aAMPL are attributed to the ubaAMPL address, this issue could affect way more than 800 users. That figure could represent hundreds or more additional people who staked their aAMPL on geyser and have yet to pull them out.
Hello
any update on AMPL. still i can not withdraw my asset. i am supplier. i never borrow any asset. why my asset is freeze. what is future of AAVE? is AAve protocole is reliable>
Most possibly it is scam, dont add anyone on telegram. Moderator, delete this message if it is possible
No one reply with steps.
Summary
Understanding the priority and urgency to provide clarity to AMPL users, we propose an interim solution enabling partial but quicker funds withdrawals upon Aave governance approval, while allowing service providers more time to prepare for a final additional distribution.
During the last days since the last update, our efforts and Chaos Labsā have been on the following directions:
Discover the core root of the problem
As we have not received any update from the Ampleforth team, we have made really significant progress on this, and currently have detected already some logic related with aAMPL total supply (and balance) causing imprecision. This is definitely the cause of the massive and wrong growing of aAMPL supply when it was not supposed to, including at the current moment, where by definition on 100% utilisation the supply simply should not grow.
As there can be different/additional problems, we keep working on this direction, and will unveil the details once we have full confidence on the results. On the side, Chaos Labs is working extracting data to better model consequences of the findings in the code.
Withdrawal of funds
Given that all scenarios are pretty complex, we have a different interim proposal to present to the community. At this stage, we know the following for certain:
- In terms of absolute values, aToken supply is totally virtual, not real, and consequently balances. Answering the question asked frequently on this thread: the ~2ā494ā000 aAMPL supply that can be seen at the moment on Etherscan, does not represent real claims under any scenario; it is consequence of a problem in the aAMPL logic.
- However, balances of aToken as a proportion of aToken supply are actually representative of the share each user has on the AMPL pool. There could be some deviation even in terms of proportions, but minor.
To be more precise, that means that if the real supply is X, the sum of all the balances should be almost exactly X. - In any model of compensation, we certainly believe the amount will be more than 300ā000 USD. It is still difficult to say how much exactly, but that number as lower threshold is safe.
Consequently, we think it is reasonable to propose the following:
-
Withdrawals from aAMPL will be completely halted. This is to create a factual āsnapshotā of balances, that will not change any proportion over total supply.
This is a pure technical measure, has no effect on any current of future claim.
-
In parallel, prepare a Merkle distribution contract with the aforementioned 300ā000 in USDC/USDT. This amount will be distributed in terms proportional to the balance of each user, relative to the total supply of aAMPL. That means that if the aAMPL supply would be 300ā000 units, a balance of 300 units will give a claim of 300 USDC.
Non-AMPL stablecoins is chosen for the reason we commented before: reduce as much as possible complexity in this initial distribution. -
In parallel, continue with the analysis, to afterwards create at least another distribution for the value not included in the first of 300ā000. If the complexity would be reasonable, using WAMPL could be explored, but we are not really confident considering the Aave DAO rails, and would mainly depend on the Ampleforth team/treasury.
-
As we donāt have any type of news from the Ampleforth team, we will propose for the Aave DAO to solely cover this initial 300ā000 USDC/USDT distribution, as the priority are the users. We expect communication in this forum from Ampleforth if there is any interest on contributing, as technically will be perfectly doable.
The advantage of this approach is that it will be possible for users to withdraw some funds in a very short time period, without any major blocker, once the Aave governance approves. At the same time, will give more time for service providers to continue the work in preparation for a final additional distribution.
We still define the amount in conservative terms, because while it is possible to add more in the second distribution, is not possible to remove once claims have been done. Again, there will be another distribution it the Aave governance approves, this first one is to at least provide some withdrawal liquidity.
As a final note, unless we have explicit confirmation of smart contracts maintainers (e.g. ubAAMPL) that the claim can be executed somehow by its smart contract, those will be left out of this initial distribution. If we get said confirmation, will be included. Please reach us in DM in this forum.