[Temp Check] Implementation of an RFP Framework for Service Provider Engagements

Governance General
1

Author: @benhoneill
Date: August 25, 2023

Summary

This proposal aims to propose a more structured vendor selection process for the Aave DAO to determine the needs of the protocol prior to engaging with external service providers. The goal of this is to ensure that major budget items are put forth to a competitive process with multiple parties bidding on the work so that the DAO receives the best service at a competitive price from capable partners with a history of success.

Motivation

To date, when there is a need for work to be done by the DAO, it is usually determined by an outside service provider who proposes their specific solution to fill that need. They post in the forum a proposal that highlights the issue, but primarily focuses on how they can solve it. Because the original post pertains not to a specific problem, but a specific vendor solution, competing providers are disincentivized from participating and proposing their own solutions. This process leads to “vendor-specific” solutions that may not be the best solution for Aave specifically.

This proposal was outlined in response to the thread regarding the cancellation of the Llama service provider stream (link) and was born out of the learnings of their engagement process. While this is not a reaction to their engagement, the DAO can take this opportunity to change how vendors are onboarded to minimize the probability of future offboardings due to vague or outsized scopes while more intentionally onboarding future partners.

The framework outlined below is intended to keep bureaucracy to a minimum and purely provide structure to analyze, discuss, and compare future third-party expenditures.

What proposals does this include

Right now, there are two process flows for potential vendor engagements related to working on behalf of the protocol:

  1. <$100k in total cost: funded and voted on by AGD without the need for a broader community discussion or snapshot/AIP
  2. $100k+ in total cost: full proposal posted to the forum for community debate before needing both Snapshot and AIP votes before being validated

As a part of this process, I propose adding a third bucket to add a more rigorous analysis to larger, more complex engagements. This would create a distinction between “vendor-specific engagements” and “core protocol contributors”:

  1. Vendor-specific engagements (VSE): engagements with a narrow scope and a treasury ask between $100k-250k (ex. Flipside, ACI, Sigma Prime extension)
  2. Core protocol contributor (CPC)*: Any proposal asking for >$250k in funds over the duration of the engagement where the community believes there is a competitive market of vendors to be reviewed beyond the proposing entity.

For any proposal falling under the classification of a VSE, the current process of an isolated proposal + vote to the community is sufficient because:

  1. The budget expenditure is not sufficient to warrant an extended process (at this time)
  2. The discussion in the community is traditionally around the specific benefits of this specific vendor/partner helping solve a specific problem

For proposals falling under CPC, the community should be taking an extra leg of diligence to understand:

  1. The functional problem of the protocol that needs to be solved
  2. What the ideal solution looks like
  3. What the right market cost should be
  4. What different service providers exist and how they compare

*Note: The community can elect to raise the VSE limit to $500k or reduce the CPC to $250k, but for the purposes of this proposal, we leave that gray area to the community to decide whether a full RFP process is required for a given proposal.

Process

To enhance the diligence capabilities of the community for designated CPC engagements, we aim to enhance the information to be shared in the initial proposal beyond just the service provider aiming to win business. This includes additional color on the market, the competition, and similar engagements for reference. If the RFP receives favorable responses, service providers can begin to “bid” on the work to be done with their own proposals. (At this time I do not believe that a Snapshot “ratifying” the RFP is a necessary step as it would simply add governance overhead, but may need to be added in the future).

Vendors can post the initial “RFP” proposal as well as an initial “bid” to it to provide work to be done. In an ideal world, the RFPs would be sponsored or posted by a recognized delegate for independence, but this is not mandatory.

CPC Proposal Process

  1. RFP is posted to the forum for feedback (framework provided below)
  2. Community discussion and alignment on:
    1. Need for a service provider to be engaged for work
    2. Budget range for bidders to aim for
    3. Additional questions to be answered in the “bids”
    4. Deadline to submit bids and go to a vote
  3. Bidders are sourced from the community or publicly posted by reputable service providers
    1. Bidders post separate threads with their respective proposals for specific Q&A
    2. Bidders schedule live Q&A sessions with the community for presentation and discussion
    3. RFP threads are used for bidder comparison and discussion
  4. Ranked choice Snapshot vote of proposed Bidders, narrowing the field to the top 2-3 choices
  5. Binary AIP vote selecting which Bidder’s contract to initiate or reject all Bidders and proceed with the status quo

To provide sufficient time for bidders to draft submissions and receive community feedback, a proposed template timeline would look something like the below:

Time Step
T + 0 RFP is posted for feedback
T + 7 RFP has received positive feedback and is finalized for bidder submissions
T + 21 Final day for bidder submissions
T + 28 Snapshot vote
T + 35 AIP vote

To remove the potential partiality of any specific individuals during this process, this structure proposes an independent third party to manage the process to keep timelines and ensure the market is aware of the opportunity. There are three members who are already funded by the DAO who could take this added responsibility, the Grants Lead (cc: @0xbill), Flipside, and ACI. This lead would be responsible for ensuring RFP/Bidder post formats and scheduling of Q&A/demo sessions.

RFP Proposal Format

Each proposal must include the following sections:

A header:

  1. Title: A concise and descriptive title for the proposal, including the proposal type [RFP] in a [TAG] format.
  2. Author: The name of the author and/or entity creating the proposal.
  3. Date: The date the proposal is being made, in the YYYY-MM-DD format.

A proposal body:

  1. Summary: A succinct summary of the proposal.

  2. Problem area: A detailed presentation of the existing problem this engagement will address and how it is currently impacting the protocol.

  3. Proposed solution: Outlining the proposed engagement structure and how a third party will integrate with the DAO. This section should include specific details around:

    • What exact (and minimum) deliverables should be expected from a service provider
    • What qualifications are needed from a proposed Bidder
    • What further information will be needed during the bidding process (i.e. specific questions to be answered)
    • A list of potential service providers who should be engaged to submit bids to the DAO for review

  4. Budget: A compensation target range for the community to discuss which includes:

    • Commentary on how this number was chosen
    • Links to any relevant comparable engagements with other DAOs

  5. Disclaimer: Any necessary disclaimers, such as conflicts of interest or third-party involvement.

    • If posted by a delegate or community member: clarity on any potential parties who might submit a proposal that either
      1. Was involved in the RFP drafting process
      2. Has any conflicts with the posting member (prior dealings, investments, financial incentives for approval, etc.)
    • If posted by a Bidder: disclaimer that they are a vendor and will also be submitting a bid in due time

  6. Next Steps: The proposed timeline for receiving and finalizing bids as well as proposed Snapshot and AIP dates.

  7. Copyright: A statement defining proposal copyright. While Open-Source is mandatory, the choice of a specific license is left to the author.

Bidder Proposal Format

Each bidder proposal must be posted in its own thread and include the following sections:

A header:

  1. Title: A concise and descriptive title for the proposal, including the proposal type (RFP-BID) in a [TAG] format.
  2. Author: The name of the author and/or entity creating the proposal.
  3. Date: The date the proposal is being made, in the YYYY-MM-DD format.

A proposal body:

  1. Summary: A succinct summary of the proposal including a link to the RFP it is in response to.
  2. Problem area: A detailed presentation of the existing problem beyond what is scoped out in the RFP. This may include new insights and implications of not solving this problem or solving it incorrectly.
  3. Proposed solution: Outlining the bidder’s proposed engagement structure while providing specific information requested in the RFP:
  • What exact deliverables and commitments are being made
  • Bidder’s qualifications and past experience, specifically highlighting:
    1. Other work done specifically for Aave
    2. Other engagements with similar or relevant DAOs
    3. Other work that is relevant to the RFP
  • Answers to any specific questions
  • Team background and further information
  1. Budget: Specific breakdown of the expected cost and incentive structure (i.e. is it a flat fee or is a portion contingent on successful completion of work or KPIs hit)
  2. Disclaimer: Any necessary disclaimers around work with others in the Aave community or other DAOs that may impact the impartiality of their work.
  3. Next Steps: Acknowledgement and acceptance of the timeline proposed in the original RFP and any live presentations or Q&A sessions scheduled.
  4. Copyright: A statement defining proposal copyright. While Open-Source is mandatory, the choice of a specific license is left to the author.

Miscellaneous

We propose adding a new tag in Discourse for “RFP” proposals to ensure they do not overrun the “Governance” section.

Specific questions for discussion

  1. Do the cost thresholds make sense, should they be higher or lower? Are there any other factors that should be considered?
    • Should we remove the VSE & CPC differentiations and anything above $100k goes through an RFP?
  2. Is there any further information necessary for an RFP to be thorough?
  3. Is there any specific information needed from a Bidder to appropriately diligence them?
  4. Who should be specifically empowered to facilitate the management of this process?

Disclaimer

I am not presenting this ARFC on behalf of any third party. Research, diligence, and time invested were funded by AGD.

Next Steps

If consensus is reached on this TEMP CHECK via forum responses, escalate this proposal to the Snapshot stage.

If the Snapshot outcome is YAE, this proposal will be considered canon, and the guidelines will be adopted.

Copyright

Copyright and related rights waived via CC0.

17 Likes
2

I am extremely supportive of this proposal.

I believe a more formalised RFP process for onboarding service providers will enable the DAO to reach a new stage of maturity. Accepting new providers would hopefully be less bias, and we would also see a greater variety of choice + ultimately the competition will = lower cost. We would aslo avoid a situation where we keep getting proposed one size fits all broad services for which the DAO has to try to negotiate specific points in a challenging forum - imo, on the DAO side, this process would ensure we get exactly what’s needed and at a lower cost.

Also, on the prospective service provider side, currently, groups looking to become new providers to the DAO have to go through a relatively opaque process and what the DAO wants/needs is not always clear. This RFP process would clear up issues with information sharing and make it clear what is needed (and wanted) by the DAO and how providers can fit that mould.

Personally, I would like to see current proposals up for new service providers waiting to see the outcome of this RFP proposal before going further in the governance process.

Cool to see AGD funding proposals like this to help clear up governance!

2 Likes
3

We support this initiative, which we see as an obvious evolutionary step towards an effectively managed DAO.

As @benhoneill pointed out, passively waiting for Service Provider proposals to dictate what’s in the DAO’s best interest doesn’t seem the most efficient way for conducting community-wide strategic planning, let alone fostering market-driven price/SLA discovery mechanisms.

In our opinion, it should be the other way around: the community should decide on the most compelling topics/areas of focus to invest in based on the available budget and optimise for short-term ROI.

Today, the DAO is currently allocating its Service Provider budget to the following areas:

  • Technical Development: maintenance, improvement, and support of the multiple components that comprise the Aave ecosystem’s architecture (e.g. Aave v2/v3; Governance v2/v3; Safety Module; GHO; GSM; UIs; etc.), including the launch of these on new chains (BGD; Aave Companies);
  • Grants: community-led grants program, focused on growing an ecosystem of contributors within Aave through funding ideas, projects, and events that benefit the ecosystem (Aave Grants DAO);
  • Security: smart contract auditing, as well as specification development for the Aave protocol (Certora; Sigma Prime);
  • Risk Management: risk assessment and risk parameter recommendations to optimise capital efficiency Vs insolvency risk and liquidations (Gauntlet; Chaos Labs);
  • Governance: Coordination of Aave governance discussions, development and submission of Snapshot votes & AIPs, and collaboration with Delegates and Stakeholders (ACI);
  • Protocol and Ecosystem Development: Support the onboarding of strategic assets to the Aave ecosystem, push for product innovation and improvement (e.g. GHO; Safety Module), and foster the expansion of the protocol to new chain ecosystems (ACI);

The end of Llama’s Service Provider Agreement will leave a void that will need replacement (even if not necessarily for the entire scope). This is the perfect opportunity to execute differently and potentially avoid the pitfalls that led to the unexpected reduced stream for Llama’s last two months: an undesired outcome both for the DAO and for the Service Provider.

We’d be keen to know the opinion of more experienced Delegates, especially the ones involved in this domain e.g. @MarcZeller; @fig; @Kene_StableLab.

9 Likes
4

We’re supportive of this Temp Check and believe that the DAO is in need of such framework!

4 Likes
5

Having an RFP Process would be a great step towards improving the quality of Service Providers here at Aave.
By evaluating multiple options, the Aave DAO can ensure that it gets the best value for its money.

When it comes to service provider selection through governance votes, from the perspective of a delegate, it is easier to say No to a service provider, when a better alternative stands side by side, the RFP Framework will be a great step towards ensuring that DAO Service Providers are no longer evaluated in isolation.

4 Likes
6

We are supportive of this initiative for the pertinent reasons that have already been mentioned. The step change this framework could make for improving governance of the DAO should deem it a priority.

4 Likes
8

We support this initiative and we feel it’s urgently needed. Especially now that there are ongoing proposal of potential SPs like Flipside and TokenLogic. It is crucial that the DAO verbalize what is needed from the SPs and not vice-versa.

2 Likes
9

After receiving questions from several community members, we would like to clarify that Ben O’Neill has not been associated with Chaos Labs for over four months. Additionally, we were not informed of the existence of this proposal.

Aave stands as a prime example of a well-functioning DAO within the ecosystem, with robust participation from the community, delegates, and service providers. Although the proposed framework has theoretical merit, it potentially introduces massive governance overhead relative to the actual advantages it offers.

Currently, the DAO’s requirements are relatively clear, especially with regard to the existing service providers, as articulated by @karpatkey in their comment.

If the DAO deems any service provider’s performance or scope unsatisfactory, it retains the prerogative to either discontinue their engagement or modify the terms, as demonstrated in the recent proposal concerning Llama.

We advocate for competition within the ecosystem and believe that a diverse range of service providers enhances the DAO’s functionality. This belief is rooted in our firsthand experiences. However, we have reservations regarding the efficacy of the proposed framework in serving the DAO’s best interests, as it could inadvertently lead to a “beauty contest” among potential bidders. To maintain Aave’s competitive advantage and leadership in the space, service providers should possess substantial expertise and preferably prior experience working on the protocol to prove their competency. Opening the bidding process to any party can introduce undesirable political dynamics and, even worse, undermine the professionalism of the DAO.

We propose an alternative approach, where aspiring service providers gain protocol-specific experience through smaller engagements before assuming full-time contributions. This way, the community can more objectively evaluate and compare the alternatives, leading to a more professional bidding process. Regardless, it remains possible for any service provider to extend their offerings, with the community having the mandate to onboard them even without such prior experience.

2 Likes
10

Hello @benhoneill,

Thank you for your detailed proposal. I’d like to share some thoughts and concerns on behalf of ACI.

1. Aave DAO’s Reputation:
The Aave DAO’s quality and reputation are recognized across the entire DeFi ecosystem. We’ve built this reputation through consistent innovation, transparency, and a commitment to our users. Our DAO is often cited as an example of efficiency and quality.

2. Minimum Viable Bureaucracy:
The doctrine of the Aave DAO is “Minimum Viable Bureaucracy”. This is the spirit and intent behind every framework crafted by the ACI. We aim to maintain agility and efficiency, avoiding the pitfalls of excessive bureaucracy. We do not wish to emulate the complexities of protocols like MakerDAO, as increased complexity often leads to gatekeeping.

3. Disclaimer Concerns:
Your disclaimer section seems a bit light, after a brief review of social media & public information. It would be beneficial to provide more clarity and transparency in this section.

4. AGD’s Isolation:
This proposal underscores our recent concerns about the AGD sometimes operating as an isolated entity instead of one part of the Aave DAO ecosystem of service providers. We firmly believe that the AGD, especially on operational matters, should collaborate closely with relevant service providers. The AGD should not be an island.

5. Timing of the RFP System:
While we are in strong agreement with the idea of an RFP system, however, we believe the timing is off. Implementing this during the V2 to V3 transition, post the CRV V2 crisis, and at the beginning of the GHO journey would be counterproductive. Our current service providers should be entirely focused on their core tasks, not navigating bureaucratic processes. Six months from now, our stance might be different.

6. Budgeting and @karpatkey’s Comment:
We concur with @karpatkey’s suggestion as a precursor to a potential RFP system. The DAO should first establish a clear operational budget for the upcoming 6 to 12 months., there’s undeniable value in defining and voting on a global and section-specific budget for the DAO. The ACI has been working on this and will present its findings to the DAO soon.

7. Complexity of Aave Protocol:
Aave is a billion-dollar protocol with over 500 risk parameters. It’s a highly intricate system where a single misstep can have dire consequences for our users. Only a handful of teams globally possess the expertise to work for the Aave DAO. Many of the best are already with us, while those who didn’t meet our standards have been recently let go. While an RFP system has its merits, we believe the protocol needs further optimization first. Initiatives like the Aave robot, Risk & Gho stewards, and discussions on dynamic risk parameters are steps in the right direction. Once we achieve a more streamlined state, we’ll be open to further optimizing DAO expenses. However, at this juncture, we don’t see enough value in the proposed system.
it should be clearly stated that the Aave DAO spending budget is already in a clear downtrend if we compare 2023 to 2022 due to several governance decisions

Closing Thoughts:
We appreciate the effort and thought put into this proposal. However, considering the points mentioned above, we cannot support it in both its current form and in current timeline.

NAY
NAY2949Ă—2780 1020 KB

3 Likes
11

Similar to other initiatives appearing on DAOs, a Request For Projects procedure is something that sounds rational but has its caveats. I will approach to the feedback from slightly different high-level direction.


A DAO’s vision/strategy/way forward is (and will be) more chaotic than a non-decentralized organization: It is fundamentally impossible to have a perfectly optimized strategic side while being really decentralized.

Counter-examples to this idea try to be “sold” continuously out there, but one way or another, they fall into DAOs being less operational optimal, or DAOs being more centralized:

  • In some cases, grant programs led by foundations or community members try to appear as filling the strategic side. This is a recipe for disaster (and I’m starting to see symptoms of this here), because almost always, the components of said grant programs don’t really have the proper sense of direction.
    Yes, it is relatively easy to qualify a project as giving some value to the community, but there are countless items that give value out there, but make absolutely no sense strategy-wise.
    Usually, these cases boil down to completely un-optimal operations and over-spending: instead of improving in decentralization, chaos takes control of the DAO. In other cases, given the opacity of interests within grants programs, it can be even more dangerous and create big centralization, bad dynamics of evaluation, and with it, loss of big reputation.
  • In other cases, behemoth multi-year “vision plans” are presented to communities, generally by early contributors or some type of leaders. This is definitely way better than the grants route in my opinion, but if really big in scope, when/if accepted, the outcomes are probably one of the following:
    • If the plan is successful, then highly likely that the DAO itself was a sham because big visions require big alignment.
    • The plan is a failure, and factually ends with the ecosystem/project, one way or another.

So, what do I think is the solution to this? Generally, I think goes through a general set of principles: optimistic acceptance of critical aspects, pessimistic control mechanisms, and step-by-step goals derived from activity.


Optimistic acceptance on criticals

I think there is a common consensus in the DAO on let’s say the following items (just an excerpt):

  • Development of the different projects is required, both on maintenance, innovation, and security.
  • Professional risk control on protocols requiring it.

If we look in perspective at previous contributions in those fields (and please, really welcome everybody to contradict me on the development side, given my involvement in it), most probably there is nobody that would qualify the outcome at this point as bad. Yes, it is perfectly possible to be in the range of acceptable, good, and excellent, but Aave is a blockchain leader in all measurable senses, and at this point, self-sustainable budget-wise. This, while really putting a big effort into decentralization, with incredibly big self-imposed obstacles on operations.
So in my opinion, the approach of the DAO in those fields should be optimistic: when entities in these sections with certain track records (or even without much) propose collaborations with crystal clear indications that give value, the DAO should be a little bit optimistic about them.

Important, this doesn’t mean the DAO should ignore operational overhead or economic aspects, but generally, it is pretty straightforward to perceive those on proposals.


Pessimistic control mechanisms

This one is pretty simple: when somebody engaged with the DAO doesn’t perform, the reaction should be fast and firm.
Something really important on this part is that public (negative) criticism on this forum should be normalized, as sometimes silence to not create conflict can be really damaging for the DAO in the long term.


Step-by-step goals

When looking with perspective, Aave has never had an explicit years-long “plan”. This could look negative, but we should not forget how early stage still is the blockchain infrastructure surrounding Aave, which makes it the opposite, positive.

An imprecise step-by-step retrospective could look like this:

  1. First, Aave v1 showed success on Ethereum.
  2. Decentralization is important → Aave Governance v1.
  3. Aave v2 as a more mature system than v1.
  4. AAVE token dynamics can be improved → Aave Governance v2, Safety Module.
  5. Other networks seem to be in a functional state and cross-chain communication, doable → Aave v2 multi-chain.
  6. Risk control mechanisms should be better, and Aave v2 has room for improvement → Aave v3.
  7. Governance v2 is a problem for scale of participation → Governance v3 development.
  8. The stablecoins market seems more and more facilitator-oriented, fitting with the multi-faced nature of Aave → GHO.
    Etc.

It is true that this supports the granularity of scopes, potentially involving one way or another RFP, but each one of those points involved a myriad of components.
“Evaluating” RPC for them is basically impossible without deep expertise, as it boils down to trust in competency, together with trust in criteria if changes are needed down the road.



After all this dissertation, what exactly is my point? I think the key is (agree with @MarcZeller on this) to not bureaucratize the DAO, but align principles:

  • If you propose something, alternatives appearing should be expected in some cases, and respected.
  • Nobody should have control or be a gatekeeper of anything, apart from the substance presented first, and the DAO governance decisions after.
  • If somebody shows historic results, the community should be optimistic (but reasonable).
  • Negative criticism in public forums should be fully accepted and perceived as healthy. Especially important to never demonize the messenger, as that only creates a culture of silence.
  • And more.

The main idea is to not try to implement a complex system of rules, but a minimal “environment” which puts pressure on certain dynamics.



About RFP

Something like the proposed framework is in my opinion too predetermined bureaucracy at this stage, which will degenerate (really fast) into an operational nightmare and centralization (e.g. 100% sure somebody will need to step up and create RFP from the community, which should not happen).

My stand is that I support experimentation with RFP on isolated cases, but not in the main contribution streams of the DAO.

7 Likes
12

I appreciate the feedback and conversation from the community around this proposed framework and the earnestness of conversation around DAO construction and coordination, especially as it relates to Aave. I hope to answer some of the above questions and pose counterarguments to some of the pushback below.

Enhanced disclaimer

I am a former employee and current shareholder of both Messari and Chaos Labs. Messari is a prior “service provider” to the DAO (mainly through AGD, I believe) and has an open proposal from earlier this year for more permanent work. Chaos is a current service provider in good standing and continues to execute on the deliverables outlined in its engagement.

Neither entity nor their respective teams had a prior heads-up about this proposal nor input on its structure. I do not believe this framework specifically benefits or harms either concerning current or future opportunities with the DAO other than the fact that Messari may submit a proposal for work alongside various other vendors. I have had conversations with the majority of the vendors mentioned above and believe the DAO would benefit from working with any of them. I have no intention of influencing this process to benefit or harm any single provider outside of guiding a smooth process.

I hope this clears up any confusion and minimizes further distraction to conversation around the framework at large. If there are any other questions, I am happy to answer them 1:1.

Overarching DAO “strategy/vision”

On this topic, I agree with @eboado, that truly decentralized organizations are unlikely to have a multi-year or cohesive plan for the future, but many diverse visions are executed and prioritized in concert by the community. This is a feature, not a bug.

The optimistic potential of this framework is to force those same community members, delegates, and service providers to initiate discussions from the point of “protocol need” first, then review solutions. These can be as focused as selecting a smart contract auditor or as vague as an overarching DAO treasury strategy. It doesn’t need to be an all-inclusive OKR planning session, but starting at first principles when determining when and how to spend money to onboard new partners.

On “Bureaucracy”

Bureaucracy is a dirty word in DAOs and start-ups because it is associated with slow decision-making and a blocker to innovation. That is an unfortunate way to define this proposal and one I wish to avoid. I agree that MakerDAO has been bogged down by bureaucracy and process, one that no one at Aave is hoping to replicate, but that doesn’t mean that all process frameworks are inherently bad.

Process definition, without additional overhead or complexity, should allow for more structured conversations and efficiency within the DAO to make decisions. Instead of reviewing proposals in isolation, it can review them against a standard rubric to best measure solutions on an apples-to-apples basis. Measure twice, cut once, and move on.

This proposal should add negligible overhead or complexity to the operations of the DAO. The majority of governance is not onboarding new vendors (nor should it be), but ongoing maintenance, improvements, and modifications to the existing protocol. These votes, 90%+ of the DAOs decision-making, execution, and development would not be impacted by this process. Existing service providers would not have to go through a retroactive RFP process assuming they are in good standing and the DAO wishes to renew without entertaining new providers (again, a common action in traditional procurement).

To @MarcZeller point on timing: if I believed the implementation of this framework were to negatively impact the ability of existing service providers from executing their priorities, then I would agree that we should wait. This, however, should only impact new service provider funding proposals.

With the offboarding of Llama’s expansive scope, Aave is in a position to examine and engage a diverse group of new service providers under the relieved budget. It is because of this that the timing is more appropriate than ever to consider this framework and competitively onboard new service providers to fill that gap.

Unfortunately, recent history has not shown an explicit eagerness by either delegates or vendors to engage in an unclear proposal process for competing services. More often than not, the processes operate in isolation and the DAO only gets to review one proposal before voting. Drafting and refining a proposal takes time (and usually a healthy amount of conversation with existing delegates and service providers) behind the scenes, and allowing for a proactive process vs. a reactionary response will greatly increase the rate of alternatives appearing.

In a healthy environment, I believe these RFPs should come from one of two personas:

  1. Delegates: They spend their time obsessing over the protocol and guiding it to their respective vision of success. We’ve already seen this with @Kene_StableLab proposal for AGD and should not shy away from further empowering (and expecting) delegates to take more active involvement in proposals vs. passive “governing”

  2. Service providers: If a new service provider wishes to be contracted by the DAO, let them first make the case of why the DAO needs to invest in this specific domain. This is not uncommon for outbound sales motions at more traditional B2B companies and would allow a period for discussion to center around the DAO’s needs before diverging on budget and vendor-specific concerns

Conclusion

I believe that this proposal is not adding undue bureaucracy but streamlining conversations around Aave spend and future vendor diligence. Its implementation should not be a blocker for any ongoing work, nor should it be a distraction for any existing service provider to continue to execute on their core tasks.

Aave is a leader in the industry on many fronts and I hope to continue that with measured processes and enhancements to push forward the efficiency quality discussion and decision-making.

Proposed next step

Instead of voting on this framework in its totality, we can test it on an isolated basis: an RFP for treasury management.

Right now the DAO has three separate proposals related to treasury management (Centrifuge, TokenLogic, and Hashnote) alongside interest from other third parties such as @Karpatkey and @Avantgarde.

These can be reviewed in isolation or we can challenge each of these providers to present a holistic solution to the DAO to manage the treasury across key verticals such as:

  • Yield/risk-adjusted return on treasury assets
  • RWA access and construction
  • Protocol owned liquidity
  • Treasury allocation vs. expenses (ability to pay)
  • Cost structure
  • and more

This way we can both better analyze both the existing proposals as well as this process before moving forward with either. I would be happy to work with relevant parties in drafting this RFP to test its efficacy in streamlining the conversation.

Side note: I appreciated this point from @eboado and hope to see such discussion continue. Aave has traditionally been a professional community with rigorous debate anchored in what respective community members believe to be in the best interest of the DAO.

6 Likes
13

@benhoneill I can appreciate the amount of effort that has gone into this. Based on the current discord there is a lot to digest. While we (Hashnote) are relatively new participants in this community we would come under this proposal as there is, as you mentioned, a pretty exciting situation forming around RWA / treasury mgmt.

From my perspective, this approach could work for things with a healthy level of competition amongst providers. In situations where there are only a couple of firms performing a particular service and that activity is pretty nascent then this framework may not work well.

Returning to the RWA topic, this is a great real-life topic that (in my opinion) should get an RFP. While the high-level concept of buying short-dated US treasury bills seems easy enough to understand there are a lot of nuances that 99.99% of the world population doesn’t know exist nor can appreciate without spending a healthy amount of time researching. I outlined some of those nuances here. It’s completely reasonable for most people to come across the Centrifuge proposal and not understand what types of questions to ask (this is not intended to be read as a criticism of the original poster). When there are such variations in implementation amongst vendors, it requires a level of community education to get everyone on the same page. An RFP can serve as that vehicle and we hope to assist in that process.

You laid it out well, if these proposals are viewed in isolation, then the outcome, most likely, won’t be cohesive. Identifying the attributes that are important to the DAO and then comparing each product/service provider to them is the best way to identify the right partner or partners, it doesn’t need to be a winner-take-all model. In that same vein, I posted this a few days ago to help align us on what some next steps could be.

I am a big fan of learning and improving through experience. As such, we fully support running an RFP process for treasury mgmt in order to progress the strategy and learn from the process.

4 Likes
14

Hi can I ask why issn’t there a RFP for competitive bidding here while Centrifuge went ahead for an allocation here> Snapshot

We need a fairer and more transparent decision framework before we start allocating to any service provider

1 Like
15

Couldn’t agree more. I don’t understand why the rest of the SPs are not pushing for this type of initiative.