RFP (Request for Proposals): Sushi Forum v2 [DRAFT]

1. Introduction

This Request for Proposals (RFP) is issued to provide the selection process for development services. Proposals will be accepted from:

  • (subject to revision) SUSHI community members or groups holding 100 SUSHI or more during submission and throughout selection

Proposers submitting a response to the RFP will be asked at a minimum, to state their qualifications, understanding/experience relating tot he project and offer their methodology for meeting the design criteria. The finalists from the RFP phase will proceed to the interview phase and be requested to participate in video interviews.

Selection Schedule (to be determined)

2. Description of Services

The objective of this RFP is to develop and enhance the Sushi Forum with a Discourse plugin that utilizes web3 to determine the amount of Sushi from a user’s wallet and the duration of such holdings in order to enable or disable forum features such as polling, comments, discussions, posting.

Please note this RFP is still labeled as [DRAFT], however discussion is welcome.


Firstly, it’s great to see the idea of competitive tenders and RFPs make their way into DeFi. As someone who has worked on hundreds of tenders, developed procurement strategies and prepard countless RFP documents and responses (both as buyer and supplier), I think the form of RFP presented here is a good sketch and would form a great basis for engaging dev firms once it’s built out. Doing this will give Sushi the flexibility and sound legal framework required for a competitive procurement process.

The types of issues I’d typically ask a client to consider in any RFP include the following:

  • Decide what type of engagement you are seeking before going to market. Is this a tactical, one-off tender or the basis for a longer, strategic relationship?

  • What type of suppliers you want to supply? Are you engaging PwC/IBM or college grads forming their first business?

  • Include unambiguous tender procedures and timelines with deadlines for submission and explanation of the rules regarding late submission (these are typically rejected).

  • Include “Rules of the Game”, i.e. provide an explanation of the policies relating to procedural fairness and conflicts of interest. Gaming of the process or price collusion should result in immediate disqualification. Communication directly with the evaluation team should also be prohibited. Failing to maintain tender hygience will skew your results and undermine competition.

  • Decide on the evaluation team early and give them full authority to make the recommendation. Having outsiders jump in to influence tenders usually results in a mess that the evaluation team has to clean up.

  • I recommend the evaluation team introduce probity principles to apply during the tender i.e. rules that apply to the evaluation team and their engagement/communication with suppliers.

  • Include a detailed requirements document. This is essential as it will allow for proper assessment of proposals on an “apples for apples” basis. It’s actually a very difficult task but one of the most important onces as this is often an area of conflict. High level or vague requirements allow suppliers to offer a lot of puffery and raise expectations pre-tender only to fail on delivery because the requirements were too vague. This requirements document, if done well, can save time at the contracting phase becuase it usually ends up becoming the basis for the Statement of Work and can minimise opening of new issues or scope-creep.

  • Are you expecting service levels, acceptance criteria and project plans for this work? That is considered standard in the industry.

  • The RRP should include the full legal terms that will apply to the engagement so Sushi isn’t subject to “bait and switch” proposals that suddenly become more expensive once the contract terms are shared with the tendering suppliers. These legal terms represent one element of the risk profile for suppliers and can definitely affect price.

  • Speaking of price, proposals should be fixed for a period of time (typically 90 days).

  • The tender process should allow for Sushi to back out of a tender in an orderly fashion without committing to any one tenderer or any tenderer at all. In some jurisdictions, issuing a tender may result in legal obligations on Sushi to follow through unless the tender provides clear back-out provisions.

  • Tenderers should be asked to sign NDAs before partipating in a tender to ensure communications between Sushi and a supplier are not shared elsewhere.

  • Tenders can be costly, time-consuming exercises for suppliers - there’s a lot of paperwork involved. Please take this into account when putting the RFP together. As a general rule of thumb, you want suppliers to want to bid again on the next RFP if they miss out this time. Without that, you’ll lose competitive tension between suppliers and find products becoming more expensive over time. This might not be critical yet but will it be once Sushi builds out its supplier relationships.

  • Negotiate, negotiate, negotiate. You will need someone on the evaluation team who has negotiation experience (it helps if they enjoy it), understands the principles of negotiation and can handle complex negotiations with multiple parties.

  • The selection criteria should be explicit and avoid selection criteria based solely on the lowest price. In many tenders, the phrase “value for money” is used as a cornerstone principle because this gives maximum flexibility to pick the best solution for the money.

  • On the topic of flexibility, make sure that Sushi has maximum flexibility to change direction if required. You probably want to avoid changing direction at all costs as this can mess up a tender but legally, it is prudent to build that flexibility into the RFP itself.

There’s a lot of detail under each of these points but I’d be happy to participate in a call if that would help.


Questions regarding the RFP’s technical goals:

  1. Discourse has built in Trust Level requirements that forum admins can control. Is it the RFP’s intent to modify the existing Trust Levels with the new requirements listed in the RFP (a certain number of Sushi / xSushi & a certain duration of holdings)? As an example each default Trust Level would have a new requirement “tl1 requires X Sushi”, “tl2 requires Y Sushi”, “tl3 requires Z Sushi”, etc. where X, Y, & Z are certain amounts of Sushi in the user’s wallet.

  2. Discourse already has default Trust Level controls for:
    A. min trust to create topic
    B. min trust to edit wiki post
    C. min trust to edit post
    D. min trust to allow self wiki
    E. min trust to send messages
    F. min trust to send email messages
    G. min trust to flag posts
    H. min trust to post links
    I. min trust to post embedded media
    J. min trust level to allow profile background
    K. min trust level to allow user card background
    L. min trust level to allow invite
    M. min trust level to allow ignore
    This RFP also requests controls for “polling, comments, discussions, posting”.
    Is the RFP’s intent to add controls for each of the following items?:

    N. min trust level to allow polling
    O. min trust level to allow comments
    P. min trust level to allow discussions (need a definition of ‘discussions’)
    Q. min trust level to allow posting


Thinking about this more, there are some interesting privacy issues that come up as presumably a user’s status is linked to wallet holdings which may not be ideal if users prefer to keep this data private (which would probably be most people).

That feeds into a threshold question about voter engagement which is a challenge that lots of governance token platforms face - how can Sushi drive maximum “voter turnout” when running a poll and ensuring votes reflect the wishes of the community? I won’t open the can of worms on quadratic voting but, yeah - a meaty topic in of itself.


I’ve been thinking about this recently, too. I think at the root we have a reputation issue in DeFi. There are many participants (which is good), but because there are so many participants it is hard to filter through to the most productive input.

I think everyone would agree that more voter engagement is better, but we also need to find a good way to elevate the productive dialogue around a given topic so that the most productive input doesn’t get lost. A reputation system could solve that.

One way to solve that reputation issue is to tie it to bag-holding (100 sushi, etc.).

For privacy purposes is it realistic to live in multiple wallets? Some tied to your eth name? Some anonymous?

I don’t think requiring a minimum amount of SUSHI to participate in forum discussions is going to be a big problem and the proposal by @OmakaseBar is sound as long if it can be done on a ZK basis where wallet details are validated without having to be tied to a user’s identity. That will depend largely on the solution architecture chosen through this RFP process.

For sophisticated users like you and I, perhaps not (although this year I’ve realised that my growing list of wallets is really getting out of hand). For less sophisticated crypto users (i.e. the other 99.999% of the world) I fear that centralised solutions (supported by their wealthy backers and armies of developers, designers and sales folk) will come along and massively improve UX by centralising functions and creating walled gardens. It’ll be a crypto back-end and centralised front-end/database. That is where regulations are already taking the industry.

This isn’t a critique of the OP proposal at all. It makes sense and seems to be a no-brainer as long as it can mitigate the privacy complications.