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.

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.

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

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

We want to clarify once again that this process does not replace the existing one but instead introduces an additional procedure. Therefore, it is incorrect that it reroutes the problem-identification process from service providers to delegates. If an SP identifies a problem, they could still present it in the forum and offer a solution, just as they can today. We are simply adding a new option, which we believe is more transparent and competitive, without eliminating the current system.

---

---

Wouldn't you agree that this possibility—perhaps even in a more severe form—already exists today? If the scenario you describe occurs, where the budget is inflated, it will exceed the previously budgeted amount, allowing another competitor to offer a better price. As a result, the malicious actor would not be contracted. In contrast, under the current system, an inflated budget is simply put to a yes-or-no vote by the DAO, without any reference price or competition.

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.

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.

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.

We want to clarify once again that this process does not replace the existing one but instead introduces an additional procedure. Therefore, it is incorrect that it reroutes the problem-identification process from service providers to delegates. If an SP identifies a problem, they could still present it in the forum and offer a solution, just as they can today. We are simply adding a new option, which we believe is more transparent and competitive, without eliminating the current system.

---

---

Wouldn't you agree that this possibility—perhaps even in a more severe form—already exists today? If the scenario you describe occurs, where the budget is inflated, it will exceed the previously budgeted amount, allowing another competitor to offer a better price. As a result, the malicious actor would not be contracted. In contrast, under the current system, an inflated budget is simply put to a yes-or-no vote by the DAO, without any reference price or competition.

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.

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.

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.

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.

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.

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

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.

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

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.

---

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.

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

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.

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.

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

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.

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

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.

---

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.

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