Thanks for the information around the team and congrats on the growth!
We were not present or aware of the mentioned CRV AIP that had an impact of ~$1m and we’re not fully aware of the context around it.
Additionally, this is really a bad look if indeed @Llamaxyz was receiving payments for asset listings.
We’re leaning towards supporting this proposal but still quite undecided. Happy to be proven wrong based on new comments left.
If Llama is to be cancelled as a service provider we do believe that there is space for a new team or teams ideally to take the responsibility of the huge scope that Llama had. Maybe that was one of the contributing factors of under-perfomance and revenue contributed to the DAO?
We would like to put out the idea of multiple teams taking upon a specific vertical that they are solely focused on and if necessary collaborate with the other entities that pick up Llama’s scope.
After writing this, @fig just commented and we’re aligned with his thoughts.
We first wanted to address two points that were brought up: CRV proposal and payment for asset listings.
To reiterate what we noted above, the proposal was of high complexity and not something that Aave had done in the past; significant research and development went into the proposal. We’d encourage you to read our post on the timeline of the AIP development to learn more about all of the obstacles and complexities that needed to be addressed in order to ensure that the payload would function safely and as intended. Our goal is to move as efficiently as possible without compromising on security. Price movements are not in our or anyone’s control.
payments for asset listings
During our Aave contract, we never received payments from external parties for asset listings. Before our contract, we helped Lido and Stader with the engineering work required for asset listing proposals and we were paid a small amount. This was encouraged by Aave Companies and others because asset listings require protocol expertise.
We appreciate Llamas’s involvement thus far in Aave, and while there were some hiccups we do think some of the initiatives driven by Llama were important for Aave’s growth (as they should’ve been under the approval of their service provider agreement).
Looking at the remainder of Llama’s work, we believe the expected benefit of these changes would be notably less than the remaining balance of their payment stream. This is further emphasised if ACI/TokenLogic are willing to finish the remaining work for no extra cost to the DAO.
At the end of the day, the Aave DAO has to look after their bottom line.
We will be supporting this proposal and thank Llama for their contributions to Aave.
Without commenting on the original contract or value remaining in the Llama service provider stream, I do think there are two points that are import to flag for a more meta discussion.
1. Service provider contract structure
In the Llama service provider proposals approved by the DAO in 2022, the community negotiated a 6-month cancellation option. This gave the community the flexibility to bow out if the initial proposal was not fulfilled, but left an amount of ambiguity on what those options would be.
When Llama provided their 6-month update there was no push-back and no discussion of a cancellation. Seeing as service provider proposals do not include the many pages of standard legalese of traditional B2B contract, there is no concept of termination for cause or for convenience defined and it is left open to interpretation.
AIPs as contracts a nascent legal field without sufficient case law, but this should be used as a case study to enhance the explicitness of expectations from service providers and provider contractual rights of cancellation periodically if they are not upheld. We should take this as an opportunity to formalize a DAO service provider ToS that is included in all funded AIPs which clarifies expectations and rights of each party to minimize ambiguity.
2. DAO issued RFPs vs. Service Provider Proposals
As is expected with large contracts at traditional institutions, the DAO should build competitive markets around its needs so that it gets the best service at the best price. As @fig mentioned, we should break down the existing llama contract to understand:
What the DAO needs new partners to continue providing
How much it should pay for those services
What teams it should approached to “competitively bid” on that work
Some different work streams that the DAO could benefit from a diversity of providers are FP&A/Accounting, treasury management, protocol partnerships and TVL growth, among others.
For example, the community should hear pitches from teams like Llama, TokenLogic, Messari, Steakhouse, Gallifrey Labs, and others to handle the FP&A/Accounting aspects of the proposal.
TokenLogic has shown that they are a dedicated and beneficial service provider, and one that likely has a long-term place within the DAO, but we should not discount the benefits of a competitive bidding process to:
Better understand the DAO’s needs (must haves, nice to haves, etc.)
Compare different providers on an equal platform and ensure it is receiving the best proposal (not just cost, but quantity, too)
Define expectations of the specific provider more clearly
Bring in a diverse set of contributors and participants to continue decentralizing work done on behalf of the protocol
I would be happy (and eager) to work with @fig and other delegates to propose a more formal process for this for community review and approval.
Separately, there is an additional $500k of “KPI-based bonuses” that needs to be reviewed for payment in accordance with the AIP.
Alongside the conversation to terminate the engagement, the DAO should determine what amount of this bonus scheme should be paid, if any, with a detailed accounting of deliverables. @llamaxyz, can you provide a breakdown on where these stand?
I understand the sentiment behind this proposal, and if passed it would certainly constitute an effective cost cutting method.
I would say though, if the Aave DAO does decide to cancel this service provider agreement it could disincentivise other potential service providers from engaging with the DAO (especially extremely professional ones imo). It could be hard for a growing team, that would be using the funding from a DAO to sustain their efforts and provide professional services, to pick Aave as their DAO of choice if they believe their contract may be cancelled with little notice after one of their employees leaves.
A more mediated step could be to renegotiate the cost of these final months so Llama can soft offboard from the DAO and isn’t handicapped too much (if Llama is open to it).
The conversation is moving in a few different directions, so we wanted to address the point about our deliverables. Below are the deliverables we committed to in our initial proposal as @benhoneill suggested. We highlighted what is already completed (most work) and what will be finished in the next 8 weeks. We believe it is valuable to complete several items that we have spent months working on, including (but not limited to) the StrategicAssetManager and Curator contracts.
If the issue is that the amount streamed for the next two months is high, we could request a lower amount for the next two months as @Hazbobo suggested but we think it is vital to complete the work originally planned.
It is a strange precedent to set for a DAO that if the work is completed ahead of time, the contract can be cancelled earlier. Teams will be incentivized to wait till their last payment to complete outstanding work.
Treasury Management and Analytics
Work with other communities to determine if they are a good match for the Aave community and Aave’s vision/future intentions. Coordinate and deploy all on-chain proposals across necessary platforms.
Deploy a portion of the DAO’s funds across diversified strategies of varying risk profiles to earn yield across many networks while maintaining sufficient stablecoin runway and optimizing risk exposure.
Develop a live, customized, and transparent financial reporting backend solution for Aave.
Developed a data warehouse that combines and transforms on-chain data from numerous networks with off-chain data sources to provide a comprehensive base layer of Aave blockchain data that can be used to build real-time analytics dashboards.
Considering the tremendous effort that has been and is being done to set Aave as an example of a decentralized DAO, but still optimal, for me it is simply unacceptable to have a situation like the aforementioned. We can’t have an entity engaged for treasury management and accounting reporting, and be in a scenario in which service providers (even Llama itself) can’t claim the vested payments on their engagements.
This is not a matter of having now a payload prepared to solve the problem, or even a matter of really negative consequences (as contributors hopefully will accept the situation): the issue is that having a pretty clear vision of outflows for like 1 year, nothing has been done until a service provider noticed the inability to claim.
I don’t even think budget is the main consideration here: the situation is simply ridiculous and not up to expected standards. Most probably, in non-decentralized entities, this would be equivalent to gross negligence and immediate closure of engagement.
So I think a vote on the matter for the community to express itself is acceptable.
Now, the points raised by @fig are actually the root of the problem here, even if I differ slightly on the view.
In my opinion, there should be way more separation of concerns in terms of entities contributing. At least clearly delimited by expertise, and not trying to touch development, risk, treasury, growth, marketing, etc.
To be clear, I don’t think this is a problem exclusive to Llama and its scope (even if it was, and I was really vocal about it back in the days). But I’m really aware due to my involvement providing services with BGD that the approach of having a lot of parties trying to tackle multiple “fields” (and budgeting them) is 1) not optimal operationally 2) creates huge darkness and lack of transparency to the community
If an entity does development → design and develop systems to Aave, and support non-technical entities
If an entity provides security procedures → support development and risk on security considerations.
If an entity does risk advising → analyze liquidity conditions and Aave pools and propose improvements to be applied (or implemented by development).
If an entity does treasury-related tasks → do proper tracking of finances, propose investment strategies, and be sure that the DAO is in a good treasury position.
If an entity does support external parties → support
…and so on.
I also think the DAO should be “optimistic” enough to not over bureaucratize itself. Just segmenting the fields of contributions will be definitely healthy.
For example, going back to treasury management, the needs to Aave are actually pretty simple:
Keep funds available for due payments, pro-actively.
Invest in strategies not creating big overhead for the DAO, even if producing less yield.
Everything else is either 1) superfluous or 2) to be done ad-hoc.
This really deserves a clarification, because it is really misleading and factually incorrect.
First, BGD is/was not involved at all in “asking” for anything to potential contributors, including Llama. The relation BGD has with listings is that as part of our scope, we support any team seeking it on the technical parts, like writing the proposal payload or explaining how is the procedure of submitting a governance proposal. Over time, we have also supported contributors Llama and others on precisely these technical aspects, even when they were done on behalf of other teams because we are just neutral and try to help everybody.
Now, for full transparency, Shreyas (founder of Llama) asked me personally for feedback back in the days on the proposal for engagement with Aave, which I gladly gave as a community member.
Something I commented (basically more or less same as publicly HERE) is that as an option, the cost of supporting listings could not be bear by the Aave DAO (meaning not including it at all on the scope of Aave <> Llama), with Llama budgeting it to external teams contacting if really ad-hoc support. Again, as an option on a feedback request and in this forum; it is not up to me to decide what Llama proposes or not.
Obviously, I never suggested that BOTH the Aave DAO and third parties should cover services cost. And even more, once the listing cost was finally included in the Aave <> Llama budget, and knowing some extra cost was still being derived to third parties, I gave strong feedback to Llama to do something about it, as I believe it hurts the Aave DAO relation with partners.
Re. USDC on mainnet: we have a payload that can go live once it is reviewed by BGD. We informed Certora, Gauntlet, and Chaos of the payload two weeks ago and they were appreciative of the heads up.
Re. service providers in the future taking on more limited scope and tasks: we are supportive of that for any future DAO contributors.
Re. receiving payments for asset listings: we agree with you here! Aave DAO did not bear any cost of proposal payloads; we only included risk assessments in the scope as noted. During our Aave contract, we never received payments from external parties for asset listings. Before our contract, we helped Lido and Stader with the engineering work required for asset listing proposals and we were paid a small amount. This was encouraged by Aave Companies and others because asset listings require protocol expertise.
In the past, I’ve been critical of Llama, their scope, and the questionable grants they received. There is some merit in the concerns raised by community members, and I believe that these issues have been extensively discussed. My feedback is that while Llama might not deserve the full final amount, they should receive a portion (25%-50%) of the final amount for the work they have performed or are planning to do. After all, some employees rely on their salaries from such work (although this point might be disagreed with).
My biggest concern is how @MarcZeller with ACI has handled this issue by openly calling to cancel the contract without first initiating a discussion or open forum on the matter. Such behaviour is unacceptable within the DAO and creates an unwelcome and hostile culture for current and future contributors. It appears to me that there might have been collusion behind the scenes with TokenLogic and ACI to ensure that TokenLogic gets paid.
I don’t question the work that ACI has done for the DAO, as it speaks for itself. However, I’m calling out the aggressive nature demonstrated by ACI when dealing with disagreements from other community members.
ACI is quickly becoming, if not already, the strongest force in the DAO, and the attitude being demonstrated raises concerns.
I’m not discrediting the work ACI has contributed, but I urge them to review their approach to addressing topics like this and strive for a more balanced and constructive approach when raising such issues.
Thank you for your comments, @G-Blockchain. As your post indicates, our only request to the community is to be able to complete the work we have in progress, especially since there is just 8 weeks left in our contract and we do not plan to renew.
Post our contract, we encourage many other service providers and contributors to take on some of our previous scope. All our contracts, swap tooling, and Aave data warehouse are open source and we are happy to answer any questions to help onboard future contributors to Aave.
First step (NOW): Initiation of the discussion on the open forum
(5 days at least before the second step)
Second step: Create the Snapshot (This can really work like a temp check)
Third step: AIP publication
I feel that temp checks are kind of redundant on topics that don’t require a lot of technical implementations so I agree with the decision of going directly to an ARFC. We can have our discussion here, then vote on Snapshot and see how it works out. From my POV you need a TEMP check if you need to spend a lot of time building something and you want to validate the idea before actually starting it to not waste your time.
To elaborate on the above, Llama has helped AGD put up this renewal payload along with others. As a general comment, Llama has been responsive and supportive of requests when AGD has reached out.
On ending Llama’s stream early, I would echo @Hazbobo’s post and caution against increasing uncertainty for service providers - while there should be expectations of high quality work and engagement, there should be clear and agreed on processes to follow.
I agree on your point, however we can also make this a precedent that if the DAO does not agree on how you operate we can terminate the engagement. It’s not this case but I don’t want the DAO to be a slave on the future because of an engagement that they did some months ago because it could create uncertainty for service providers.
I am open to listen a counter proposal from the @Llamaxyz team. I am also sure that if the majority of the people here agree on some different options it will be also added on the Snapshot. Again this is a proposal on a DAO, the whole point is to hear all the sides of the story and vote on it. I don’t care if it’s ACI, the Aave Companies or BGD, the community will decide voting.
@MatthewGraham, can you please give some clarity/context on your relationship and communication with Llama leading up to this? I get business can be cut throat but this has a very nasty smell to it but perhaps it is just the communication around it rather than the actual actions. So if you could help explain the transition and comms from your Llama commitments to TL that would be helpful I think.
Disclaimer: this is my personal view and not that of my employer etc. etc.
I think what would make the most sense is the DAO producing a generalised framework for service contribution. This could outline cost bands the DAO is willing to spend for certain services, what disclaimers are required from service providers, what criteria they must meet and importantly - under what circumstances an agreement can be cancelled. I’m sure other things could be added too
Would be happy to work on something like this is anyone is keen