AMPL problem on Aave v2 Ethereum

@ChaosLabs @Naguib @bgdlabs - First of all, we are really grateful that you are all looking into this and trying to help the users who are affected in this situation. This goes to further strengthen our belief in Aave and Ampleforth.

I have an idea that I wanted to run by: There are roughly 2 million AMPL tokens at the moment across all depositors that are stuck in the Aave market. The current total supply of AMPL is 218M (as of this writing) so, roughly 1% of of total current AMPL supply is stuck on Aave. Now, I have not read the technical implementation of AMPL smart contract but I am wondering if it’s possible for the Ampleforth team to mint 2M new AMPL token, airdrop to current depositors as per their current AMPL balance to the wallet on record in Aave and then burn the tokens currently stuck in Aave market with help from the Aave team. Now, to control the supply and re-basing challenges, the token airdrop and burn can be done in the same time window. This may have short term impact on the pricing as some of the depositors may immediately sell the token. However, the 1% supply sale (worst case, everyone sells) may not have catastrophic impact on the prices but this act of making users whole on their current AMPL balance would turn 812 AMPL users/ investors (>0 AMPL in the wallet address per the list published above) into life long champions.

3 Likes

I’d firstly like to repeat my request for the technical details about the bug itself.

Secondly, could you provide the datasets you’ve been using for your analysis thus far?
(utilisation rate over time, aAMPL balances over time, rebases over time, etc)

You say that utilisation has been at 100% for the last 5 months. The interest rates were reduced around start of Feb (went to vote 1st Feb) as far as I can tell. Eyeballing it, your graph should do something like this instead:
image

You also mention that the market cap of AMPL is x10 what it was back in October, but fail to consider that this debt is denominated in AMPL, not USD, and that the supply at these two times has a different ratio.

Referring to [AMPL] Ampleforth Rebase History - Coin Tools we see that:

Oct 23rd 2023 AMPL supply: 25,923,134.56
2024-03-23 AMPL supply: 217,590,611.43

That’s a x8.3 difference. And yes, that remains quite high, but had AAVE DAO been even one month more proactive at resolving this issue we’d have:

2024-02-23 AMPL supply: 89,177,529.58

Which is a x3.5 difference.

5 Likes

First, the smart contract was faulty from start, and AMPL and AAVE are responsible for this.
In order to make an absolutely correct calculation, it is necessary to perform a huge and unrealistic number of calculations, taking into account absolutely all input-output transactions, based on an erroneous contract. Also, at what speed in each second the % increase was received for investors. Take into account the rebasing every day, and how the error in the smart contract affected this during negative-positive rebasings. All these calculations can only be made approximately and not absolutely accurately; now it will simply not be possible.
Therefore, the calculations that are offered to us are approximate by default, and do not take into account all the input data that is necessary for an accurate calculation. Please also note, not understanding how the AMPL protocol works, that AAVE unilaterally has significantly reduced the already low % that AMPL depositors receive here -

and later once again here - [ARFC] AMPL Interest Rate Updates on V2 Ethereum

3 Likes

Considering that it is impossible to make accurate calculations, I currently see only 2 options for a peaceful resolution of this issue, taking into account respect for investors and the reputation of both projects. Perhaps AMPL and AAVE will offer some more.

  1. People will get their AMPL back in the amount that they once contributed to the balance of this smart contract, taking into account all withdrawls and rebases. In this case, it is much easier to calculate what should be paid. The quantity of AMPL and the date of deposit are taken, and all rebases are calculated. You also need to take into account that part of the AMPL could have been withdrawn, again take the date and quantity. This way, people will receive a fair number of amps, which they should have had now if they had not participated in this initially broken smart contract. I personally support the first option, because in my opinion it is the most fair.

  2. Second option, mint as much AMPL, as there are now aAmpls, and deposit it so people can withdraw it. This option is the simplest, because… no additional calculations need to be done. But then AMPL and AAVE must agree among themselves exactly how this will happen.

This is just a proposal for a basic architecture for resolving this situation; it is clear that in order to implement this, calculations and agreements between AMPL and AAVE projects will be needed. The main thing now for both projects is not to shift responsibility for their mistakes onto investors, thereby making them victims. Otherwise, the reputation of the projects will suffer in the long term, at a minimum. And in the worst case, we will have to involve regulators and go to court, and no one needs this. Therefore, let us please find a peaceful solution to this situation.

3 Likes

I second the Option#2 in this. Mint new AMPL (approximately 2 million) and distribute to all the wallets who have locked in aAMPL/AMPL on Aave market in line with their current balance. And then burn the aAMPL/AMPL currently locked in on Aave. As mentioned in multiple comments above - it’s practically impossible to calculate the most accurate view of the token ownership by wallet for equitable distribution, minting and distributing new AMPL tokens and burning what’s stuck in current Aave market sounds the most rightful solution for the depositors.

Only other thing I would add - this is only for Ampleforth team: your hard work over the years is starting to come to fruition, the seed you planted years ago is blooming now. There is renewed excitement about the AMPL protocol, there is lots of energy about SPOT as the future cornerstone of decentralized money. While we are in a situation like that, just please don’t alienate 800+ users of AMPL, many of that group truly believed in the AMPL vision, by putting them at significant loss with their hard earned money due to technical errors in implementation. The proposal above offering to pay 20% of current USD balance of AMPL stuck on Aave is very painful and unfair to 800+ users. Sincerely request for your intervention.

2 Likes

Hi all. When can we withdraw our assets?

@Ampler have you been able to make the withdrawal?

Nice work QuantumEvolver.

Dear @bgdlabs @Naguib,

As a dedicated member of both the AMPL and AAVE communities, I find myself deeply affected by the ongoing issue resulting from the interactions of our smart contracts. This situation has placed undue stress on numerous investors, including myself, and now threatens the integrity and reputation of both projects.

The solutions being discussed by QuantumEvolver —particularly the two leading proposals—represent a consensus on what many of us see as the only viable paths forward. These proposals appear to be born from a deep understanding of the situation and a commitment to finding a fair resolution for all involved.

Option 1: Recalculation and Redistribution
This option, which proposes recalculating and redistributing AMPL based on initial contributions, adjusted for rebases and withdrawals, is seen as the fairest method. It accounts for the dynamic nature of AMPL’s rebasing mechanism and aims to restore investors to their rightful position. This solution, though COMPLEX, represents a meticulous and equitable approach, acknowledging the specific characteristics that define AMPL.

Option 2: Direct Minting and Withdrawal
The second option offers a straightforward solution: minting new AMPL to match current aAMPL holdings, allowing for direct withdrawals. This method, while simpler, sends a powerful message about both projects’ commitment to rectifying the issue without burdening the community with the complexities of the situation.

I prefer to go with OPTION-2 as it appears simple and straightforward. As someone directly impacted by this issue, I strongly urge both teams to consider these options not just as potential solutions but as necessary steps toward maintaining the trust and support of your communities. The decisions made in response to this crisis will undoubtedly shape the future of both Ampleforth and Aave, for better or worse.

The Need for Immediate Action:
Every day that passes without a clear resolution further erodes the confidence of your investors and users. It is crucial that we see decisive action that reflects a commitment to fairness, transparency, and respect for the individuals who have supported and believed in your projects.

We await your swift response and decisive action. Let this moment not be a stain on the legacy of our projects but a testament to our ability to come together and solve complex issues for the betterment of all involved.

5 Likes

No. We’re all in the same boat. I finished reading all the messages today and what Naguib proposed with WAMPL or what QuantumEvolver proposed are the most sensible and objective solutions. I agree that, given all the circumstances, it is simply impossible to make accurate calculations now. Therefore, the option proposed by ChaosLabs is untenable and does not reflect the full picture

4 Likes

The resolution of the situation that Naguib voiced out 9 March about WAMPL is also an acceptable scenario, and the most realistic if we are talking about the speed of solving this problem.
Most likely they are currently engaged in negotiations, but I am still surprised by the degree of opacity of what is happening. And so far no one has expressed an apology to us for the situation investors find themselves in. I am a very big fan of Ampl and Aave, and am very disappointed in the way and how long it takes to address this issue. Let’s hope for the best…

Given our involvement collaborating with @ChaosLabs on the analysis, we would like to clarify some aspects to the community, for full transparency:

  • On the Aave side (us BGD and Chaos Labs), significant resources have been allocated last 2 weeks; in our role as service providers on the technical area, we really take the matter as serious as it should.

  • Why not before? Before 2 weeks ago, both us and Chaos Labs were involved, by providing technical feedback of general mechanics of Aave (from our side) and data analysis (Chaos Labs side) to the Ampleforth team. Additionally, we were continuously following up on progress and insisting on getting updates in the forum. Due to the lack of them, we tried our best to update the community ourselves when the Ampleforth team was not responsive.
    We were not leading the effort for what we mentioned before on the thread:

    • We didn’t implement the integration of AMPL on Aave (aAMPL and vAMPL), the Ampleforth team did.
    • We didn’t decide about high-level design of that integration.
    • We didn’t propose the listing of AMPL on Aave, in July 2021.
    • BGD Labs was not engaged as service provider of Aave until May 2022, and Chaos Labs later during the year.
    • We have verified that the Aave contracts have been acted as they do with any other asset, with the only difference being the customization from the aAMPL/vAMPL contracts. It is possible that mechanics of Aave were not properly taken into account during the implementation of the custom aAMPL/vAMPL, but we simply don’t see any reason for the problem to be on components outside those.

    It is important to understand that as service providers for the DAO we are not using the previous as any excuse to be involved proposing technical solutions, and now we are leading with Chaos the effort. We just thought the most reasonable path was for the team fully understanding the intricacies of a system (Ampleforth in this case) to lead an effort like this, as we lack that expertise, especially in a case like this, where massive issuance and deflation of the underlying is also controlled on the Ampleforth side.

  • As mentioned in this thread it is far from simple to even analyse what is “fair” from a completely neutral point of view. On our work with Chaos last weeks the principles have been:

    • The solution must allow for users to get their funds as soon as possible.
    • The priority have been understanding the “intention” behind the design of AMPL on Aave, in order to be able to do an historic reproduction of holdings following clear rules.
    • The design of AMPL on Aave was the following:
      • Borrowing of AMPL was not submitted to rebases, only to interest rates on Aave.
      • Supply AMPL was partially submitted to rebases: only aAMPL supply proportional to the available liquidity (non-borrowed) was rebasing. That means that on 0% utilisation, AMPL rebasing was reflecting directly on aAMPL balances; on 100%, no rebase was reflecting; on 50%, only 50% of the rebase was.
      • Interest rates were properly configured in the Aave protocol. It is debatable if they were correct values given the underlying AMPL dynamics, but they were transparent on-chain, changed via governance proposals and without any bug.
      • Historically, negative rebases of AMPL affected depositors of AMPL almost the same as holding AMPL on negative rebases. On the other hand, positive rebases affected less than pure AMPL positive rebases, because borrowing rates on Aave were not directly proportional to the external rebases, they were proportionally lower. This is what Chaos Labs has presented on previous posts.
        Again, we are not stating this is correct or wrong design-wise, but it was like that transparently on-chain, without any bug.
      • At certain point of time, we detected a problem in terms of debt supply vs aToken supply. From this moment, interest rate dynamics can be determined as broken, because aAMPL supply was simply not correlated with AMPL debt.
        As commented later, this doesn’t mean that it should be ignored that interest rates should have been different after that point, but that the ones on-chain were not representative is a fact.
  • All options in terms of historic analysis of the compensation are on the table, but the previous proposal on THIS POST was just consequence of analysing how to do a neutral solution, considering the previous described design principles. Again, we didn’t implement the AMPL on Aave system neither we designed it, that is why we and Chaos Labs appreciate the previous feedback and we are working on alternative calculations for the distribution.

    We would like to be fully transparent about these alternative solutions though:
    - We (BGD and Chaos Labs) can and will propose solutions for the situation, but we don’t have any power of decision on the final outcome, only the Aave governance and Ampleforth itself (as issuer of the asset) have.
    Because of that, we compromise to propose a range of reasonable options to vote on, and support on the technicalities of moving them forward.

    • Providing AMPL for withdrawals is extremely complicated for the Aave DAO. All systems are decentralised via on-chain governance proposals, including swaps and deposits into the Aave pool. The consequences of rebases on the Aave pool with the current state are uncertain, with high risk of creating further problems which will hurt both users, Aave and Ampleforth. That was the rationale of suggesting USDC or other stablecoin.
    • If the community wants to propose alternative analysis and distributions, we welcome them, as Aave is a decentralized protocol, and we are only contributors to it like everybody else. We simply have a professional responsibility with the Aave DAO to provide our own.
    • Something very important: obviously the time with funds locked since end of 2023 until final resolution (no matter if in 1 day or in 2 weeks), must be considered.
      The implication on this is that even if there has been some delay, a proper time based compensation should be proposed.

Taken the previous into account, and knowing it is not an easy situation, we request some additional patience for the work to be performed. Updates on this forum will be continuous.

We keep adding resources on this topic, and a final proposal to be voted next week still seems realistic.

5 Likes

@bgdlabs, @ChaosLabs – just want to express my gratitude for all your efforts, it’s not lost on me (and fair to say “us”) that you’re out there helping these 800+ users on Aave to have a fair outcome.

I am bit surprised to hear the lack of responsiveness of the Ampleforth team, I thought, they are in this for long haul and trust/ credibility with 800+ users of AMPL would matter to the Ampleforth…

2 Likes

Let’s be clear here: bgdlabs and chaoslabs do this because it’s their job. They are paid by the Aave DAO to act in its interests, which is also why they’re presenting “compromises” that benefit the Aave DAO at the expense of aAMPL holders.

Which brings me to:

Considering the eagerness with which the proposed solution tries to reduce the cost burden to the Aave DAO, is it not fair to say that bglabs and chaoslabs should have been considering some aspects of this problem more seriously three months prior?

Aspects of the proposed resolution include paying aAMPL holders a below market rate amount of USDC instead of actual AMPL. Reasons cited are the currently abnormally high price and low market liquidity of AMPL, and whilst it’s clear that yes this would make this more costly for the DAO to purchase that AMPL, it remains the case that it’s AMPL denominated debt that the DAO owes affected lenders. Repaying them in USDC just transfers the burden of price impact to them if they wish to then rebuy AMPL with it, and denies them the ability to sell the asset they should have for its current elevated price if they don’t.

What’s more, the argument that the Aave DAO should not be burdened with buying the asset during a time where it’s less favourable is undermined by the Aave DAO’s previous decision to sell its AMPL reserves, despite still having borrowed AMPL at the time. Put bluntly: the DAO seems happy to sell low but not to buy high, and argues that lenders should bear the brunt of that.

The other detail proposed that beggared my belief was that Ampleforth contributes 40% of funds for resolving this. It’s unclear whether they’re proposing this comes from the FORTH DAO treasury, or the Ampleforth team’s private funds, but as a holder of FORTH and AMPL I have a vested interest in seeing neither cover for Aave’s mistakes. I had previously stated that since I do not have any aAMPL at this time I am interested in this issue only as an onlooker, but I cannot say that any longer.

So to reiterate, it seems clear to me that bgdlabs and chaoslabs have failed in their duties to mitigate risk for the Aave DAO by delegating this issue to a third party that has different priorities and obligations. Whilst it’s reasonable to rely on the Ampleforth team to assist with analysing the bug and trying to map out intended balances, the Aave DAO should have been immediately taking action to ensure it can meet its financial obligations to lenders at the same time.

My expectations are not that the DAO would have back in January purchased enough AMPL to match aAMPL 1:1, but that they now argue for repaying in USDC makes it painfully clear that they should have purchased enough AMPL to at least cover its most conservative estimates of what lenders were owed.

It is clear there was early recognition by these entities that there was cause for concern about this matter too, as we can see from their proposal and ratification of freezing interest on AMPL during this time.

  • The Aave DAO voted in favour of the design, integration and listing of AMPL
  • The Aave protocol advertises its Safety Module as a means to ensure any lender can withdraw their deposits in full, selling and even minting AAVE as necessary to repurchase the shortfall assets

Whilst I accept that there are grounds for reimbursing aAMPL below 1:1, I strongly object to it being paid as USDC, and sourced in part from Ampleforth (team or DAO). In terms of what the true aAMPL to AMPL exchange rate is/should be, I want to reiterate my previous requests for the raw data that is being used for this analysis and technical details of the bug itself (which continues to remain a mystery to everyone involved…?)

7 Likes

Dear Aave and Ampleforth Communities,

In light of the recent AMPL challenges on Aave v2, a balanced and fair resolution is necessary to address both the immediate issues and the broader implications for trust and fairness within the ecosystem. This proposal suggests a structured approach to compensation, which includes considerations for initial investments, trust, and notably, missed interests.

Structured Compensation Approach

  1. Reimbursement of Initial Investments: It’s proposed that compensation equal to the dollar value of each investor’s original AMPL investment at the time of entry on Aave be provided. This step is to ensure no financial loss is incurred due to the situation.

  2. Additional Compensation for Engagement: Further compensation is advisable to acknowledge the continued engagement and trust by the AMPL investors on Aave. This should proportionally reflect the amount and duration of the investment, rewarding those who have shown long-term support.

  3. Missed Interest Reimbursement: Acknowledging and compensating for the interest that investors missed out on is crucial. Given AMPL’s unique properties and its integration with Aave, investors had expectations for certain yields that were unmet due to the ongoing issues. Fairly assessing and compensating for this missed interest is key to a comprehensive resolution.

Advocating for Fairness and Transparency

This proposal is aligned with the core values of decentralization: ensuring transparency, fairness, and respect. By comprehensively addressing the impact on investors, including the lost opportunity for interest accrual, the proposal aims to reinforce the integrity of the ecosystem.

Invitation for Collaborative Resolution

The proposal acknowledges the complexities involved but emphasizes the importance of community cohesion and trust. Feedback, dialogue, and collaboration from all community members are welcomed to refine and implement a solution that is considerate of every stakeholder’s contributions and expectations.

Thank you for your attention to this matter. Engaging with and understanding this comprehensive approach will be crucial as efforts are made to amend the current situation and enhance safeguards for the future.

3 Likes

To be very clear, both us and Chaos Labs are analysing the situation as neutrally as possible, because it is our job with the Aave DAO and as proxy with its users to do it that way. That is the reason why the previous post of Chaos Labs is quite data driven, showing the rationale behind the previously proposed distribution.

We can definitely ask them to publish the data sample, but we don’t really find reasonable to doubt that the data is not accurate, being taken directly from on-chain.



The reason is not the abnormally high price, it is that if the system have been working, the utilisation would have not allowed withdrawal of AMPL, following the historic dynamics.
Once again, we will request Chaos Labs to provide more clear data about this fact about utilisation, but the cause of it is as we described on the previous post: the interest rate was always configured on 100% below the rebase percentage of the underlying AMPL. That caused everything to be always fully borrowed at high utilisation. The proposals
That previous implies that whatever entity (e.g. Aave DAO) is acquiring AMPL and making it available for withdrawals will artificially burden the current price, going completely against the historic value of holdings.
To be clear, aAMPL at 100% utilisation price is not 1:1 with AMPL, it is 1-discount, with discount being higher as the price of AMPL becomes higher.



The Aave DAO didn’t exclusively sold AMPL in the past, but multiple different assets in the same governance proposal. Additionally, price speculation is not a consideration for treasury proposals: funds are swapped strategically when needed, usually to major stablecoins like USDC or major assets like ETH and LSTs.
In any case, whatever the Aave DAO did in the past has no influence in this situation: whatever should be compensated, will be proposed.


As we simply don’t have enough visibility outside the forum, would you mind clarifying exactly your relation with the Ampleforth team?
We are happy to continue the conversation and accept the feedback here in this forum, but the question is to not create any un-transparent scenario and with conflict of interests, because of the following:

  • Representatives of the Ampleforth team told us you and Buttonwood are close collaborators with Ampleforth for a long time.
  • The Ampleforth team representatives with who we have discussed since end of 2023 are supposed to be precisely analysing the bug itself since then. Given the previous point of your close collaboration, it is simply strange to ask specifically the nature of the bug in this forum because 1) we already said that was a task that Ampleforth voluntarily assumed, which is pretty natural given it is their code 2) wouldn’t make more to ask them directly being close collaborators?
    To be very clear, we don’t know at the moment the exact cause of the bug, because for our understanding, Ampleforth has not yet find it.
  • Looking at the smart contract of the protocol you represent/work in (ubAAMPL of Buttonwood), it was deployed by the same address that deployed the AMPL token and the WAMPL token, amongst other smart contracts of the core Ampleforth ecosystem.

If your position is anyhow the one of the Ampleforth team (and contradictory with our internal conversations), it is something the community should be fully aware of.


The proposed split 60% Aave 40% Ampleforth is something we proposed in order to have some reference, and we have no say on the final decision of it, could be even voted separately from the compensation itself.
We simply think 100% compensation by Aave or 100% compensation by Ampleforth make no sense.

1 Like

Well the reason I asked was because their recent graph did not match my expectations based on my understanding of the timeline of events, as I stated above with the ms paint edit. It’s entirely possible I have the timeline wrong, regarding when interest rates were changed etc. So I’d like to see the data to get a sense of it.

The other aspect is that since Aave protocol operates on a block to block basis, I’m curious whether their analysis has been done block to block or abstracting out over day intervals.

Okay, that’s a reasonable point which hadn’t been clearly conveyed before. Is this standard policy for Aave then, stated somewhere? That in a shortfall event when bad debt results in indefinite 100% utilisation of an asset then affected lenders will receive discounted rates for their lost deposits?

Does this also mean that the aAMPL to AMPL redemption rate will be modelled as if the interest rate had not been frozen too, since we’re simulating theoretical non-bugged conditions?

I don’t really think that’s relevant to what I said. The point remains that Aave DAO prematurely sold reserves that would now be useful in reimbursing lenders, whilst arguing that it shouldn’t be obligated to repurchase at current market rates.

Not at all - though I had hoped my arguments would be judged on merit rather than prestige. As you note I work as a developer for Buttonwood, which enjoys close collaboration with the Ampleforth team on some of our products.

From a financial perspective, I have no private investment in Ampleforth, nor do I receive any sort of compensation from the Ampleforth team. I hold FORTH, and thus am a member of the FORTH DAO and hold concerns over how the FORTH DAO treasury is used. I also hold AMPL, and thus would rather see whatever private funds the Ampleforth team has go towards the further development and growth of the project than on covering Aave’s mistakes.

The ubAAMPL contract was deployed by the Ampleforth team, which is why the deployer matches that of the rest of their contracts.

As for why I am asking about the details of the bug here rather than in private corresondence with the Ampleforth team, that is primarily because I thought bgdlabs and/or chaoslabs had been making their own efforts to debug the code and that I would get a nice overview of all three team’s findings rather than just Ampleforth team’s perspective on it. It’s a little bizarre to me that you consider me engaging with this topic publicly to be a problem.

No sense in what regard? Can you point me towards any statements the Ampleforth team made that assumes liability for how aAMPL behaves?

3 Likes

The Aave protocol works on an action-by-action basis in terms of determining rate and utilisation, while on time basis (not block) for calculations with the previously determined rate.


There is no standard policy that we are aware of. This case of AMPL is completely custom, so the analysis should be performed on simply rational terms based on historic dynamics observed.
Freezing was performed before any bug was detected, so the most natural approach is to assume that after the bug was detected, the reserve was behaving normally, with borrowers repaying their positions and depositors withdrawing.


Once again, we have no problem discussing the topic publicly, but conflicts of interest should be properly disclosed for anybody on this forum to evaluate subjective opinions like that the Ampleforth side should not participate at all in the compensation plan. As we commented, we are happy to propose that as an option, but we also don’t think it is reasonable, and we will propose others too.


We are repeating ourselves already, but to again make it transparent:

  • Ampleforth implemented the custom implementation and the design dynamics of AMPL on Aave.
  • Pursued the listing of AMPL of Aave.
  • Proposed different AIPs to change configurations of AMPL on Aave over time (e.g. interest rates).
  • Pointed out about the use case on its own documentation.

Those were good initiatives from the Ampleforth team, we are not saying the opposite. But we just think that saying that Ampleforth has no relation with the problem and that the most rational thing if for Aave to cover 100% is not reasonable.
Once again, if that is the case the Ampleforth team should properly disclose it here publicly, we are just trying to be as transparent as possible from the Aave service providers side, but their communications are not ours.

1 Like

But you would agree that at no point was there any representation to AMPL lenders that in the event of any problems they should expect different to the usual insurance that Aave advertises?

Again, perhaps I have a misunderstanding of the timeline of events but I am under the impression the bug was raised around December last year and the interest rates were frozen around February this year. Happy to be corrected, and if you have the list of proposals handy then maybe a concise timeline recap would be useful for everyone.

I literally did in the post where you first got weird about this:

Right but the point I am making here is that Ampleforth would be offering this as a gesture of goodwill, not because they declared or now assume any liability for this bug. Again, whilst the Ampleforth team produced the integration, it was the Aave DAO that ratified it and the Aave DAO that actually offers insurance on deposits.

I wouldn’t actually be surprised if the FORTH DAO or Ampleforth team were amenable to the suggestion of contributing to the cost either. But any such request should be presented with the recognition that it’s not an obligation, and so far your proposals have been anything but by listing off all the reasons one might think Ampleforth was liable. (To be clear, if Aave didn’t offer insurance I would instead be saying that nobody is liable and that users should be cognisant of risk of bugs when participating.)

4 Likes

I want to clarify and understand, calculations that @bgdlabs and @ChaosLabs done, does they include 87643% APY for depositors, or you done calculations with very unfair APY % from this 2 changes done by you?

First you have cut APY % without any reason, without understanding of AMPL protocol on November-December, and later you done it again even more in January.

If you want to do fair calculations, so please do it with 87643% APY for aAmpl holders.

-5386854382324273595_121

P.S. You can read proposal “[ARFC] - Chaos Labs RF and IR Updates - Aave V2 Ethereum - 2023.11.24]” they have made. They said they are “increasing” APY for borrowers, of all assets on AAVE v2. So like that borrowers would payout borrowed amount asap.
But actually cause they didnt know anything about AMPL, they not increased APY for borrowers, but decreased it enormously! And you can read thread, I told them that from start, they still didnt put it at least back to 186.21k% for borrowers, so what they done is opposite of what they declared they want to do. It would be funny, if not so sad for aAmpl investors now…

3 Likes