[RFC] - Uniswap DAO Tendering Procedure

[SEEDGov]

Summary

This proposal outlines a process for the DAO to allocate resources to strategic projects, issue a public call for bids, and select the most suitable provider. This isn’t a replacement for existing procedures for requesting funds.

Abstract

The ‘Tendering Procedure’ looks towards community-driven problem-solving by enabling delegates to identify needs, share context, and collaboratively develop requirements/specifications for external service solutions through fair competition.

Motivation

In practice, what happens in most DAOs is that a member or organization identifies a problem, proposes a solution, and simultaneously offers their services to resolve it. This means the DAO must vote on the issue, the solution, and the service provider within a single proposal.

Generally, the DAO agrees with the problem—since these tend to be real issues—and the solution might be suitable; however, it is always the only option. As a result, the current process tends to monopolize problem-solving with a single provider, which can lead to unnecessarily high costs, limit more innovative alternatives, and repeatedly rely on the same service providers.

With this in mind, we propose to introduce an open bidding process as an optional system alongside the current one (not as a replacement). This would allow the DAO to resort to a public tender process if it so desires. This process would enable any service provider or candidate to submit proposals not only to address specific problems but also to perform roles within a DAO committee.

This proposal is based on three key principles commonly evaluated in such systems:

1. Competition and cost efficiency: The DAO will have access to a variety of more competitive pricing options.
2. Diversity of solutions: Evaluating proposals from different service providers (SPs) allows the DAO to select the most suitable and efficient solution.
3. Quality and skills: New teams and candidates will be able to compete in both quality and skills, as well as pricing, with top providers and individuals in the ecosystem. This will attract the attention of new participants within the DAO.

This system is neither innovative nor new. Similar RFP and RFT processes are standard in traditional organizations worldwide and have proven effective in fostering transparency, competition, and efficiency in resource allocation.

Specification (step-by-step)

1. Identification of Needs

• Any delegate can identify a need or problem that requires resolution through an external service provider.
• The problem and its potential solution are discussed and debated by the DAO community in the forum through a RFC or “pitch proposal”.
• The requirements/specifications for the solution are defined and finalized through discussion.

2. Cost Estimation by Accountability Committee or other trusted body

• The responsible body estimates a range of the costs associated with the proposed solution.
• The body establishes a preliminary budget cap based on the requirements/specifications.

3. Tender Proposal Submission

• A formal tender proposal is created. This includes:
  • Finalized requirements/specifications.
  • A predefined budget.
• The proposal is presented to the DAO via Snapshot for approval by any delegate.

4. Call for Proposals (Bidding Phase)

• Upon approval and based on the complexity of the requirements, the proposer will define the duration of the call for proposals.
• A 7-14 day call for proposals is announced, inviting external service providers to submit bids.
• Proposals are submitted to a trustworthy body (e.g., Accountability Committee, dedicated Procurement MultiSig, or the Uniswap Foundation).
  • The body acts solely as a secure inbox to ensure that proposals remain private until the submission deadline.
  • Another 7-day extension may be granted if there are less than two bids.

5. Revealing and Voting

• After the submission period ends, all bids are revealed simultaneously.
• A Snapshot proposal is created, listing all valid bids.
• DAO members vote on the proposals (ranked-choice voting or single-choice voting)

6. Awarding the Contract

• The proposal with the highest votes is selected and a voting in Tally is created to ratify the tender’s final result.
• The winning bidder receives the allocated funds to implement the solution through a vesting schedule against pre-defined milestones.

This is what the proposed flow chart would look like. You can see it in good quality at this link.

Other considerations

• Accountability:
  The Accountability Committee, dedicated Procurement MultiSig, Foundation or any other designated trusted body serves as a neutral intermediary, ensuring privacy during submission and fairness during the review.
• Future Optimizations:
  • Automating the bidding process via a DAO-integrated UI if the process becomes attractive and useful.
  • Exploring on-chain mechanisms for bid submission, verification, and ranking.

Other potential use cases

The proposed framework could also be applied to other specific use cases beyond procurement, such as Council/Committee Member Elections: these elections often become popularity contests because compensation is predefined. In this context, the DAO tends to choose the most popular or well-known candidate, as the system does not allow for competition among applicants. If an open system existed that allowed candidates to offer different prices for providing the service the DAO needs, the competition would be fairer and more balanced. This approach could enable the DAO to prioritize candidates who may be less “popular” but offer greater cost-effectiveness.

Community Feedback

This document outlines, at a high level, what we believe to be a fairer process for selecting service providers and committee members. Before developing a more detailed proposal, we are seeking feedback from the DAO to ensure alignment and confirm that this is truly the right path forward.

Finally, we would like to thank @PGov @Tane @AranaDigital @Areta and @WintermuteGovernance for their valuable feedback. And also, we extend our thanks to everyone who shared their ideas during the last community call.

[karpatkey]

This is a very interesting proposal in principle, and we appreciate the effort to introduce structured processes like tendering to the Uniswap DAO. However, we are curious to see how feasible this approach would be in practical terms. Traditional tendering processes often come with significant flaws, such as inefficiencies, bias, or challenges in ensuring transparency and accountability. Ideally, we’d like to see how this system can be designed to address these issues and leverage the strengths of DAOs to improve upon them.

We are generally supportive of running a smaller-scale experiment to test the viability and effectiveness of the proposed approach before committing to a full implementation. A trial could provide valuable insights and help identify any potential bottlenecks or areas for improvement.

[drllau_LexDAO]

1. With wicked problems, often the cost is in trying to discover the root cause … a procurement system places the budget on the response-solution phase without compensating the prior sense-forensic efforts
2. Your use-case could also be extended to the UniSwap foundation grants … basically they’ve already segmented the problems and are asking for proposals, albeit with more vague specs. Certain service solutions are hard to evaluate quality of goods (eg DeFi education fund which is about reducing regulatory risk/blowback)
3. a procurement system essentially centralises certain spending … another approach is to short-list possible vendors including developer delegates as pre-vetted, issue the budget in the form of vouchers or pre-paid discounts, and airdrop to the community. So rather than trying to project manage the service, ask for services to be provided and let the end-user pick (but with the vounchers a guaranteed total spend)

Stepping back, I would ponder on principles for cost-sharing (especially in thin markets) … how to jointly with other AMMs procure similar services. Some principles might be

contestability - competition law notes that gaining a monopoly is not illegal but abuse of market power is … this can be in the form of lockins, tying/bundling of disparate services, and intimidation of new entrants;
composability - avoid integrated platforms but ask for RPC or APIs which allow users to select the subset of services (avoid over-engineering)
conflicts of interest - need clarity to separate out who decides what … delegates having specialist knowledge is good but the accountability board should be vigilant as to tension between commercial-in-confidence and whistle-blowing in the wider DAO interest

For your amusement as to how procurement can be rorted

[drllau_LexDAO]

@karpatkey

We are generally supportive of running a smaller-scale experiment to test the viability and effectiveness of the proposed approach before committing to a full implementation. A trial could provide valuable insights and help identify any potential bottlenecks or areas for improvement.

perhaps the trial can come in the form of asking to procure components of the procurement process within UF open for developer-heavy delegates … successful aspects can be adopted for their other grant initiatives. As a model, you can look to the split between development and deployment in the STTR/SBIR. For example, refactoring traditional procurement to use farcaster style protocol might be a way to track delegate participation in transparent fashion and allow UAB to audit conflicts of interest.

1. STTR phase - ask developer delegates for proof of concept of a composeable probe-sense-analyse-respond cycle
2. SBIR phase - proof of viability - do A/B testing on existing UF programs … eat own dog-fu
3. best of breed gets to the proof of scaling where adopted for commercial procurement, not just UF

The reason for doing many small cautious probes is because some issues are wicked … if hypothetically the treasury becomes insolvent, then you want to find the root cause, not apply a patch and prayer. Paying $$$ for a solution that could be solved by $ elsewhere requires multiple perspectives. xref Recoding America

[jengajojo]

I appreciate @SEEDGov the positive development in opening up the conversation on how to effectively choose the best service provider for any given problem. I agree with the limits of such a process as pointed out by other delegates here. However, I do believe there is merit in collecting data by doing a trial run as suggested earlier. I would encourage the trial to not only test a traditional tendering process as suggested here but also a range of other possible solutions such as one suggested here:

@drllau_LexDAO

a procurement system essentially centralises certain spending … another approach is to short-list possible vendors including developer delegates as pre-vetted, issue the budget in the form of vouchers or pre-paid discounts, and airdrop to the community. So rather than trying to project manage the service, ask for services to be provided and let the end-user pick (but with the vounchers a guaranteed total spend)

In an ideal scenario we’d be able to collect feedback from a variety of processes to identify the best ones, rather than just retesting something we already know the limits for.

[SEEDGov]

@karpatkey

Thanks for your reply!

Traditional tendering processes often come with significant flaws, such as inefficiencies

Could you please elaborate on this? What do you think are the inefficiencies in the tendering process?

@karpatkey

Traditional tendering processes often come with significant flaws, such as… bias

We precisely understand that the current system has a lot of biases, which we aim to minimize through this procedure that instead of having to vote Yes or No on service providers who present themselves in the forum offering services at a single price based on self-created proposals, our suggested procedure enables the DAO to define its own needs. This approach fosters competition and provides opportunities to secure better pricing for equal or superior services, effectively reducing the harmful biases inherent in the current system.

@karpatkey

Traditional tendering processes often come with significant flaws, such as… challenges in ensuring transparency

What do you mean by that? Could you elaborate on the kind of challenges procurement processes face in ensuring transparency?

@karpatkey

Traditional tendering processes often come with significant flaws, such as … challenges in ensuring… accountability

Accountability is not directly affected by this process, which aims to generate competition between potential service providers so that the DAO can contract with the most efficient, economical and best service provider. The accountability process is not related to the contracting process but to the subsequent monitoring and tracking measures. The accountability system will therefore not be changed by this proposal and will remain as it is now, and moreover, in the system we are proposing, it would be expected and healthy for the submission of a tender proposal to include an accountability system for the specific case to which the applicants will have to commit. In conclusion, this process aims to provide an alternative to the DAO’s service provider selection process through a tendering and competition system.

---

@SEEDGov

This isn’t a replacement for existing procedures for requesting funds.

However, we reiterate that this proposal is not intended to replace the current system of requesting funds from potential service providers offering their services, but to provide an alternative, where the DAO deems it necessary, which allows for competition between different potential service providers and for the DAO to benefit from it.

[kfx]

As already said on the community call, I think it’s a great idea. Moreover, I expect that in the longer run most DAOs will converge to something like this.

Specifically in this formulation, I’m not convinced about the need to hold a DAO vote for the individual proposals. It could become a popularity context. As a compromise, how about changing it so that at least for smaller services (up to some $$$ budget cap) the process automatically selects the lowest offer that meets all requirements.

@karpatkey

Traditional tendering processes often come with significant flaws

I’m very surprised to see this as one of the first points of feedback on this RFC. Traditional processes are traditional for a reason — specifically, because they have usually proven to be substantially better than the alternatives. The alternatives in the context of DAOs, to make it brutally clear, has been giving money to the first one who comes along with an identified problem, a proposal to solve it, and a sufficient social clout to get the votes, which has never seemed to be especially efficient to me.

[drllau_LexDAO]

Both are right - because the traditional procurement works when there’s sufficient prior examples that you can go straight to the price-comparison relative to known service quality (flaws or not).

However @kfx is also right (social stature to swing votes) because nobody gets compensated for pointing out the emperor has no clothes. TNSTAAFL so the cost of problem & solution is bundled for voting consideration.However, if the right software can be sourced, delegates can be engaged earlier in the definition phase, and divergent paths considered in the discovery phase.

Separating out the WHAT (needs to be done =sense) to the HOW (it is done = response) makes sense If there is sufficient expertise. So a WHY probe should result in
a) sufficient specs for a tendering process (nominate inside UF)
b) report that might be up to UAC to audit (I did mention surfacing conflicts of interest)
c) tokenomic forensics that (future) treasury to analyse to maintain stability/solvency/etc

The spec is then used to solicit WHO/WHEN/WHERE (budget) beauty contest based on (hopefully objective) criterion for desired deliverables. Up to vendors or whoever participates (decentralised) to figure out the HOW.

So long as stick to basic principles of contestabilty, composibility, and conflict(-abstainations) whether it is the existing RFC/temp-check or enhanced software to allow delegates to nut out the details in the problem definition, it adds to the toolset for Uniswap governance. I doubt if delegates have time to micro-project manage procurement so focusing on measuring/assessing the deliverables would be more proper use of scarce time & cognitive load.

PS if it works well, then other DAOs can also double-down (a la gitcoin style) so the complaint about thin markets for DAO-tooling is not a barrier as raised in the monthly meeting.

[karpatkey]

@SEEDGov

Could you please elaborate on this? What do you think are the inefficiencies in the tendering process?

This question summarizes several related queries on the same topic.

Traditional procurement processes face numerous challenges, including:

• Limited transparency
• Inefficient communication
• Difficulty evaluating large or complex problems/solutions
• Inconsistent evaluation methods
• Increased costs

We believe technology can help mitigate some of these challenges, such as improving transparency. However, other challenges stem from trade-offs made in pursuit of a fairer process, such as increased costs.

While we support the introduction of a tendering procedure that brings numerous benefits, we also acknowledge the risk of replicating inefficiencies inherent in traditional procurement. Let’s take “difficulty evaluating large and complex problems/solutions” as an example.

The proposed tendering process begins with the “identification of needs,” where requirements and specifications for solutions are defined and finalized through discussion. While effective for smaller or simpler projects, this approach often requires specialized expertise and a deep understanding of diverse topics to identify feasible and effective solutions for complex problems. Delegates, understandably, may not always possess the skills needed to define such requirements.

The next step, “cost estimation,” presents similar challenges. Accurately estimating costs requires a comprehensive understanding of all the steps involved. Additionally, this process assumes that all proposals will follow the same execution path. In practice, different providers frequently propose varied solutions, each involving unique costs and execution strategies.

While there are situations in a DAO context where this approach has proven successful—the STEP program in Arbitrum DAO is a notable example—the challenges remain significant. We believe the DAO should carefully consider these challenges while adopting the proposed tendering process.

To clarify, we fully support this initiative. However, given the concerns outlined above, we suggest starting with a small-scale experiment. By applying the tendering procedure to specific, limited-scope initiatives, we can refine and improve the process before scaling it to larger, more complex projects. This approach not only ensures successful execution on smaller initiatives but also allows us to optimize the procedure for broader applications.

[_0xnix]

@drllau_LexDAO

Separating out the WHAT (needs to be done =sense) to the HOW (it is done = response) makes sense If there is sufficient expertise

I agree with this, especially the importance of separating the “what” from the “how.”
However

@drllau_LexDAO

nobody gets compensated for pointing out the emperor has no clothes

delegates already receive compensation, which should account for raising issues—even if they don’t yet have a solution. Still, if defining the “how” is an expectation, some may hesitate to highlight problems without having a clear path forward.

[SEEDGov]

@karpatkey

Traditional procurement processes face numerous challenges, including:

• Limited transparency
• Inefficient communication
• Difficulty evaluating large or complex problems/solutions
• Inconsistent evaluation methods
• Increased costs

We believe that this is not relate to our proposal, which is limited to establishing a selection process for service providers based on tendering and competition. All the issues you mention are additional issues that should undoubtedly be foreseen when the DAO understands that there is a need to be covered (step 1) and, fundamentally, when the tender proposal is created (step 3), so that all the issues you mention are part of the agreement with the applicant that wins the tender.

It is precisely the tendering process that makes it possible to establish stricter requirements in terms of efficiency, transparency criteria, evaluation of performance and accountability, and competition between bidders to improve costs, none of which is currently verified when a third party comes to the DAO offering a service at a fixed cost, sets the price and its own accountability criteria, and the DAO simply votes yes or no. The solution we are proposing will then make it possible to solve the issues you mention, which are in fact experienced with the current contracting system.

@kfx

I’m very surprised to see this as one of the first points of feedback on this RFC. Traditional processes are traditional for a reason — specifically, because they have usually proven to be substantially better than the alternatives. The alternatives in the context of DAOs, to make it brutally clear, has been giving money to the first one who comes along with an identified problem, a proposal to solve it, and a sufficient social clout to get the votes, which has never seemed to be especially efficient to me.

This is exactly our point, thank you for putting it in such clear words. We want to propose an alternative system - we repeat that it does not replace the current one, it creates another alternative - in which the DAO can define what needs it considers necessary to cover or solve, with what characteristics, performance requirements, monitoring, KPIs and transparency, and then there is a competition between bidders to offer the best services at the best price.

[Avantgarde]

Thanks for sharing this proposal @seedgov. Tenders have arguably been severely underused in DAOs, but as you note actually makes a lot of sense in certain cases; not only sourcing solutions from collective problem recognition, but likewise competitive cost-efficiency by preventing winner-takes-all scenarios.

Keen to see more feedback from other delegates on the neutral entity responsible for collecting/presenting applications etc. Giving the responsibility to the Accountability Committee could make sense if we assume these tenders will come relatively infrequently and the workload can be managed. What has the Foundation said about its potential involvement?

[eek637]

Appreciate the effort here - I think we’re taking a swing at solving the issue you’ve identified with Butter. Details are rolling out soon on our first experiment, will update this post when we’re live. (cc @noturhandle).

[SEEDGov]

Hi Erin!

Are you referring to this announcement? https://uniswapfoundation.mirror.xyz/iUps06RQxXqFZ5xVeta1Zd-TL0mtlw3od2uHUh4T8qA

Very interesting! Can you tell us in advance how this will be relates to the issues we identified, the tendering process we are proposing here and, in general, the DAO’s process for contracting service providers?

If that’s the case, what will the process look like and when can we expect this solution to be fully operational and ready to be applied to the DAO’s service providers contracting processes?

[404DAO]

Thank you to @SEEDGov for introducing this RFC.

We believe this proposal has the potential to serve as a valuable framework to enhance inclusivity and accessibility for new service providers who are not yet deeply integrated into the DAO. By reducing barriers to entry, this initiative could attract fresh perspectives, foster innovation, and provide the DAO with a broader range of ideas and solutions.

From our experience, we’ve seen how new service providers often struggle to establish a foothold in Uniswap due to politically driven processes. Implementing a formal tendering process could professionalize business relationships and address a common criticism that DAOs feel overly political.

Ensuring an Open Problem Identification Process

It’s crucial that the problem identification phase remains as open and accessible as possible. Any stakeholder—including delegates, existing service providers, the foundation, or community members—should be able to identify a need requiring resolution through an external service provider.

At the same time, the framework should allow for flexibility when service providers choose to bypass the tendering process and submit a proposal directly to the DAO. In such cases, the DAO should have the option to require the service provider to go through the tendering process.

For example, this could be achieved by adding voting options on Snapshot, such as:

• “Yes, with proposed service provider”

• “Yes, with tendering process”

This approach balances vendor optionality with DAO control and flexibility by permitting existing service providers to bypass the tendering process when appropriate.

Desired Outcomes

To ensure this framework delivers meaningful results, it should aim to:

1. Increase service provider satisfaction by improving accessibility and reducing friction in the proposal process.

2. Foster more innovative ideas by encouraging problem identification to a broader set of stakeholders.

3. Provide vendor optionality by creating a structured process that welcomes competitive bids while maintaining flexibility for exceptional cases.

[eek637]

Yep that’s the one, you beat me to it!

I’m still wrapping my head around your prop but I thought it would be a good exercise to describe how Conditional Funding Markets (CFMs) work in the abstract and then compare to a traditional tendering process.

The general idea of CFMs is that you set an objective (let’s say “increase metric A”), and a budget (let’s say 500,000 UNI).

A set of projects would apply for funding, and in their application describe how, given 500k UNI, they would increase metric A over time period T.

Conditional Funding Markets would be spun up for each team, each of which is asking the market “If this team gets 500k UNI, how much do you think they’ll impact metric A over time period T”

The markets (currently running on a fork of Uniswap v2) would trade freely for a pre-determined amount of time. Market participants (Butter calls them forecasters) would express their views with dollars. More concretely, let’s say Project 1 was trading at 10 (which implies that, given $500k UNI, Project 1 would increase metric A by 10 over time T), but a forecaster believed Project 1 would increase metric A by 20 under those conditions. That forecaster would buy Project 1 tokens at 10 because they believe they’ll be able to redeem them for 20 at time T.

After that predetermined amount of time (it’ll probably be a week after the markets launch in our first live experiment next month), the markets would reach the Decision point. If 5 teams applied and their prices at the decision point were 10, 20, 30, 40, and 50, the market has determined that, given an influx of 500k UNI to do the work, the team whose price is 50 is most likely to produce the best outcome. In our example are granted 500k UNI.

Note that this distribution has to be defined prior to the markets launching, but it could be infinitely expressive - you could give all the UNI to the top performer, or divide the funds out however you wish amongst the teams that applied based on their results. For the sake of our example, I’m using the simplest possible implementation and saying that the winning team gets the whole pot of UNI.

The other four markets would be settled and forecasters and liquidity providers who participated in those markets would be able to redeem.

Team 1 would then take the 500k UNI and use it at their discretion until time T to improve metric A. At time T, the market would resolve. Let’s say Team A increased metric A by 50. Forecasters who bought Team A’s tokens below 50 could redeem their tokens for a profit. Holders of Team A who bought them above 50 would redeem them for a loss.

With that in mind, let’s talk about tenders. A tender process addresses the bias in DAO proposals which bundle a description of the problem with a potential solution. If the person who identifies the problem correctly is given a monopoly on selecting and providing a solution this leads to inferior results. A tender process introduces a competitive process to select the solution once a problem has been identified. However, there are known problems with this process:

1. Bureaucracy: introducing a tender process requires staffing, and staff introduce their own inefficiencies and process
2. Bias: Staffers, if not incentivized on results alone, can use their powers to further their own objectives and award funding to their preferred selection rather than the most qualified, producing the same outcome as the incumbent situation but with more steps (and cost)
3. Misplaced Competition: a tender process introduces competition, but there is a competition to jump through the hoops instantiated by the process, favouring teams who are better at the tender process than delivering the desired result
4. Risk Aversion: tender processes tend to prefer lower risk decisions, to avoid the possibility of the organization being blamed for a bad decision and losing its mandate which produces middling returns
5. Lack of measurement: a tender process for selecting vendors tends to focus on inputs and outputs rather than outcomes

On the other hand, CFMs:

1. require no staffing as decisions are outsourced
2. are expensive to bias as all traders are incentivized to profit from attempts to move the price away from the real outcome
3. direct competition towards selecting the best outcome, not the preferred vendor
4. are tolerant of risky proposals if they provide the best risk-reward
5. are outcome-focused

[Tane]

We agree that there is broad support for experimenting with a tendering process on a small scale before considering wider adoption. We should begin by clarifying which types of projects or needs will benefit most from tendering.

As @drllau_LexDAO noted, an important distinction is whether the problem has already been identified (the “WHAT” or “sense” phase) or if identifying the problem itself is still part of the task. When the problem is clear and sufficiently defined, a tendering mechanism is ideal for discovering the best solution.

@drllau_LexDAO

However @kfx is also right (social stature to swing votes) because nobody gets compensated for pointing out the emperor has no clothes. TNSTAAFL so the cost of problem & solution is bundled for voting consideration.However, if the right software can be sourced, delegates can be engaged earlier in the definition phase, and divergent paths considered in the discovery phase.

On the other hand, we should also define when not to use a tendering process. If the DAO (delegates or core contributors) has yet to recognize a particular problem, we want to preserve incentives for ecosystem participants to identify the problem themselves. Several approaches could work here:

• A dual-track system that either proceeds with a direct proposal vote or a tendering process, depending on whether the DAO already acknowledges the problem.
• A “bug bounty” style mechanism that rewards the act of problem-identification itself.
• A tendering framework in which the vendor who discovered the problem receives additional weighting or “bonus points” in voting.

Regarding Conditional Funding Markets (CFMs), they occupy a similar space of the tendering process as an alternative to RFPs but rely more on prediction markets to determine which proposal will yield the best outcome. This potentially offers strong incentives for accurate forecasting, which could outperform tendering in certain situations. We believe it would be worthwhile to test this approach on a small scale to see if market-based signals can guide resource allocation more effectively.

In summary, we support running a trial phase for both tendering and CFM-style solutions. The main next steps would be to define the scope of which projects or issues each mechanism should address, establish clear criteria for when a tendering process is most appropriate, and consider how to encourage proactive problem discovery while still preserving the option of competitive bidding when solutions need to be compared.

[Gauntlet]

We appreciate the conversation here. Service providers are an inherent part of any DAO’s process since most DAOs struggle to handle the operational aspects of supporting protocol development and growth.

There are also fair questions about whether Delegates are appropriate evaluators of service providers and RFPs. Often, these proposals become either a popularity contest or last-minute votes by stakeholders who may not have expertise around the issues these contractors are expected to solve. Further, Uniswap (to date) has been relatively inactive with regard to service providers. Although this may change with the Unichain launch, to date, compared to an L2s (Optimism, Arbitrum, ZkSync), Uniswap’s mandate has historically been more specific.

@404DAO makes some interesting points here about the tendering process as an option for an SP proposal other than full rejection. Conditional funding markets are also a potentially innovative approach. Still, to date, all futarchy experiments for DAOs have appeared to attract too small a market to demonstrate efficacy (MetaDAO) and raise concerns about the potential for manipulation at such small volumes.

Lastly, we’ve seen firsthand at Arbitrum how these kinds of processes can sound good but also be quite nefarious in their bureaucracy. What could be best serviced by a handful of experts can sometimes get diluted into a long, expensive, and ultimately harmful process.

[SEEDGov]

Hi @eek637 thanks for sharing the details on CFMs — it’s great to see this experiment taking shape. Robin’s work is impressive, and we’ve been following MetaDAO’s proposals on Futarchy with interest. The potential alignment between CFMs and the tendering process we’ve proposed seems like an interesting idea for us to explore.

In the tendering proposal, the process starts with a delegate (or a group of them) identifying a need and defining a clear objective (e.g., “increase metric A”) alongside a budget (e.g., 500k UNI). This creates a structured framework for upfront evaluation. From there, CFMs could naturally step in, spinning up markets for each team to ask, “If this team receives 500k UNI, how much will they impact metric A over time T?”

This integration could allow the tendering process to serve as a starting point, opening the stage to A) workshopping the problem definition, potential solutions and specifications B) allow current and new SPs to propose themselves to the community and C) voters (or forecasters) to make informed decisions based on aggregated information.

When SPs enter the process, the DAO ensures proposals align with delegate preferences, clear specifications, and a reasonable budget. Defining these parameters in advance aids decision-making based on set objectives. A market-driven decision, good or not, should be well-informed. This process reduces information asymmetry between delegates, SPs, and forecasters.

For example, after the tendering process selects a set of projects (e.g., Project 1, 2, 3, 4, 5), CFMs could help refine the decision by letting the market predict which team is most likely to deliver the best results. In this case, the tendering process would provide the foundation, and CFMs could add a competitive, predictive layer to help validate the outcomes

We think this approach doesn’t replace the tendering process but rather complements it. The tendering framework could provides standardization upfront, while CFMs will introduce a flexible, market-driven way to refine decisions and measure success.

Looking forward to seeing how this unfolds and how these mechanisms might coexist in practice.

[BlockworksResearch]

Hi @SeedGov,

We appreciate the proposal, but we have a few concerns. Candidly, we would like to see a trial of this first prior to widespread institution. As others have pointed out, this proposal reroutes the problem discovery phase to delegates instead of service providers. This could lead to poor discovery because the incentive to find problems is partially diminished here. The SP has an active incentive to find the problem because they have a vested business interest. SPs need to make money and better the reputation of their business, making them apt as a party to find issues within a DAO or protocol. Reattributing this to the delegates possibly makes the mistake of assuming that there are enough delegates with enough subject-matter expertise to find any/all possible problems. At the same time, even if we incentivize delegates with payment for this, it’s possible that the payment incentive for the forensic work is not enough. Again, as others have noted, the problem identification cost is often grouped into the cost of the overall service proposal, and thus there might be some misalignment there as well.

Additionally, in step one of the process you’ve outlined, does there exist the possibility of SP-delegate collusion per this logic. If a delegate proposes the problem identification, what’s stopping a delegate from teaming up with an SP, that SP doing the identification, and the delegate charging a cost for their representation. This might lead to some bloat on the price in that regard. Moreover, the cost estimation process by the Accountability Committee should be elaborated with a negotiation process so that the DAO can get and give a competitive market rate for the SP. In certain situations this may need privacy for the competitive landscape as well.