RFP for Maintenance and Development of Encrypted Mempool and/or Shutter API

Shutter DAO DAO Proposals
1

Motivation

Prop 60 started a great discussion with more 36 million votes voted which is probably the most voted proposal ever existed

Even though it did not pass but it has a close split vote for For and Against if you exclude the vote from one of the subjects being reviewed - Brainbot themselves (Given the vote comes from early contributor allocation which mostly consist of Brainbot employee).

It is contentious but to certain extend kick off a productive discussion.

While It is a good governance practice that brainbot start this temp check TEMP CHECK: Cancel Current Grant & Replace with Reduced Grant but it does not look reduce the cost as asked by many DAO members and/or reaches a high degree of consensus among members yet

For the most significant spending contract and also for better DAO process with transparency and accountability in mind, I propose we start a RFP process this budget. Hopefully this way we can find a way forward with consensus among different members.

The content of RFP posted below:

Maintenance and Development of Encrypted Mempool and/or Shutter API

Tentative Proposal Submission Deadline: April 18, 2025 (subject to DAO vote)

Introduction

The Shutter 0x36 DAO is seeking proposals from skilled teams or individuals to maintain and enhance two critical components of the Shutter Network: the Encrypted Mempool and/or the Shutter API.

The Shutter Network leverages threshold cryptography to safeguard Ethereum transactions from front-running and malicious Miner Extractable Value (MEV), fostering a secure and equitable ecosystem. The Encrypted Mempool (and Shutter API to certain extend) are vital to this mission, and their ongoing maintenance and development are crucial for network growth and adoption.

Proposers may submit bids for Option 1 (Encrypted Mempool), Option 2 (Shutter API), or both, with each option evaluated independently.

This Request for Proposal stems from a DAO discussion (see Temp Check), where concerns were raised about the current development proposal’s high costs, lack of transparency, and unclear success metrics, etc and 41% voted against and many vote do not vote For. The DAO intends to address these issues by inviting new, detailed, measurable, and cost-effective proposals.

Notice: All dates, timelines in this RFP are tentative and subject to the DAO’s governance process. Final confirmation of the RFP’s approval, timeline, and related decisions will occur only after the DAO’s vote.

Scope of Work

Proposals may target one or both of the following components. Each option outlines specific objectives, requirements, and deliverables to guide proposers.

Option 1: Encrypted Mempool

  • Objective: Maintain and enhance the Encrypted Mempool, which encrypts transaction data before it enters the public mempool, preventing front-running and MEV exploitation. It must remain secure, reliable, and compatible with partners like Snapshot and Gnosis.

  • Requirements:

    • Ensure the current implementation remains secure and operational.
    • Address bugs and performance issues reported by users or integration partners.
    • Update the codebase to ensure seamless integration with stakeholder systems (e.g., Snapshot for voting, Gnosis for safe transactions).
    • Maintain and potentially improve the threshold cryptography system (e.g., Distributed Key Generation protocol).
    • Implement performance enhancements based on real-world feedback.

  • Deliverables:

    • Updated Encrypted Mempool codebase reflecting all changes and enhancements.
    • Comprehensive documentation detailing modifications, stakeholder integration, and new features.
    • Test suite validating compatibility, security, and performance under typical conditions.

Option 2: Shutter API

  • Objective: Maintain and expand the Shutter API, a developer interface that enables dApps and services to leverage Shutter’s encryption features, driving ecosystem adoption.
  • Requirements:
    • Ensure the API remains stable, secure, and accessible, resolving any downtime or issues.
    • Add features to support new use cases, such as dApp integrations or Keyper interactions.
    • Update the API based on user feedback, potentially incorporating rate-limiting or authentication.
  • Deliverables:
    • Enhanced Shutter API with improved stability and new features.
    • Updated technical documentation (e.g., OpenAPI/Swagger) detailing endpoints and examples.
    • Guides or tutorials demonstrating at least two new use cases (e.g., DeFi integration, Keyper coordination).

Proposal Requirements

Proposals must address the selected option(s) and include the following sections with sufficient detail.

Detailed Project Plan

  • Task and milestone breakdown with estimated timeframes (e.g., “Week 1-2: Code audit; Week 3-5: Bug fixes”).
  • Technical approach, including tools (e.g.Github, Golang, React), methodologies (e.g., agile), and methods for integration or use case development.
  • Risks (e.g., compatibility issues) and mitigation strategies (e.g., early stakeholder testing).

Success Metrics

  • Measurable indicators, such as “100% integration with Snapshot” (Encrypted Mempool) or “99.9% API uptime” (Shutter API).
  • Testing methodology for compatibility, security, and performance (e.g., unit tests, stress tests).
  • Clear completion criteria per phase (e.g., “all critical bugs resolved”).

Team Qualifications

  • Experience in blockchain, cryptography, and Ethereum projects relevant to Shutter.
  • Examples of past work (e.g., GitHub links) and team roles (e.g., developer, tester).

Cost Estimate

  • Itemized budget (e.g., “$20,000 for code updates”) with justifications.
  • Milestone-based payment schedule (e.g., “30% after onboarding”).

(Optional) Enhancements

  • Suggested improvements (e.g., new API endpoints, better architecture design) with separate costs and timelines.

Hand-Over/Onboarding Phase

  • Onboarding plan (e.g., “Week 1: Code review; Week 4: Independent bug fixes”).
  • Knowledge transfer details and success metrics (e.g., “resolve sample bug”).

Evaluation Criteria

  • Clarity and Detail (25%): Thoroughness of the plan and deliverables.
  • Success Metrics (25%): Quality and measurability of proposed metrics.
  • Cost Efficiency (20%): Budget reasonableness and transparency.
  • Team Expertise (30%): Relevant experience and capability.

Submission Guidelines

  • Format: Markdown or PDF.
  • Length: Maximum 15 pages per component (30 pages for both).
  • Process: Submit to the DAO forum.
  • Tentative Deadline: April 18, 2025, 11:59 PM UTC (subject to DAO vote).
  • Questions: Post to the forum by April 10, 2025 (tentative, subject to DAO vote).

Tentative Timeline (Subject to DAO Vote)

  • RFP Issued: March 28, 2025 (tentative)
  • Q&A Period: March 28 – April 10, 2025 (tentative)
  • Submission Deadline: April 18, 2025 (tentative)
  • Review Period: April 19 – April 30, 2025 (tentative)
  • Decision Announced: May 5, 2025 (tentative)
  • Project Start: May 15, 2025 (tentative)

Note: All timeline dates are tentative and will be finalized only after the DAO’s governance vote.

Budget Guidance

Budgets exceeding $100,000 per component require detailed justification. Payments will be made in USD stablecoins or SHU tokens, tied to milestones.

Additional Notes

  • Code must be open-source (e.g., MIT license).

  • Active community engagement (e.g., forum updates) is encouraged.

  • Inclusivity in Bidding: No entity, including current developer firms, is excluded from bidding on this RFP. All qualified parties are encouraged to submit proposals.

  • Non-Development Work: If the DAO votes to replace the current contributor, areas like communications, marketing, and community management may require attention. These are outside this RFP’s scope and will either continue under current arrangements or be addressed through a separate RFP, depending on the DAO’s vote (tentative).

3 Likes
2

Thank you for a discussion opener.

This proposal is much better than the open-ended grant running for Brainbot, and also offers a way for continuity that the earlier proposals lacked.

If Brainbot lacks founder-like leadership for the project, as they have been recently struggling with scrutiny, whether justified or not, an RFP would be the best way to continue the project and clean the air.

It might be that we get zero proposals or only proposals from Brainbot. Regardless, this way, DAO members have the wanted transparency and correctly exercise the control of the DAO with the requirement for accountability.

2 Likes
3

I completely agree with the points mentioned. Since proposal 60, the additional spending of 300-400K—and the potential to reach 800K—underscores the urgency of re-evaluating our current expenditure. Running the protocol at 150K per month is unsustainable, so addressing the spending issue should indeed be our first priority. We need to thoroughly assess all the points, invite community proposals, and, meanwhile, focus on establishing the minimum viable costs for the protocol. The proposed RFP for the Maintenance and Development of the Encrypted Mempool and/or Shutter API is a crucial step towards ensuring responsible spending and maintaining our product until we can achieve clearer and more sustainable operational guidelines.

1 Like
4

This proposal poses significant risks to the long-term success of Shutter Network. Replacing the current team—who has already delivered a functional product—with a new organization is unnecessary and could be deeply disruptive. The team is making strides on cutting-edge innovations, such as decentralizing the keeper set, a critical and complex task. Changing leadership now could lead to delays, fragmentation, and instability that would hinder the project’s growth and reputation.

Additionally, the influence of private discussions in a Telegram group, which excludes the broader community, raises serious concerns. Governance must be transparent and inclusive. Decisions made in closed circles, without open dialogue, undermine trust and risk creating divisions within the community, weakening the foundation of the project.

Switching teams at this stage introduces unnecessary risks: disruption, delays in development, and potential alienation of the dedicated community. The momentum already built could be lost, and the project’s adoption may face setbacks, especially in a competitive market. More importantly, such a move could confuse token holders, whose confidence is essential for the project’s future.

Instead of a leadership change, the focus should be on continuing development and driving market adoption. The current team has proven they can deliver functional products. It would be a mistake to jeopardize their progress due to short-term pressures or personal interests.

I urge the community to reject this proposal and stand behind the team committed to building long-term value for everyone involved.

2 Likes
5

Thank you for sharing concern.

My personal opinion is this does not have to replace the current team but put the important and significant spending go through an RFP process is important regradless who will be selected. I believe this is the same with most of other DAOs as well.

Additionally, I would suggest you also go through other proposals and discussions ongoing on the forum. The motivation section attempts to summaries the situation but there is much more discussion on the sustainability of current DAO budget which is the main topic of past month.

Regardless you are happy with the current budget or developer or not, an RFP is a more objective process for allocate significant resource

1 Like
6

The proposal looks good, however I fundamentally don’t believe switching from brainbot to another dev house is the right way forward. Ultimately when I invested in shutter it was a bet on both the idea and brainbot as the genesis of that idea and the implementer. Switching to another (competent) dev shop is too big a risk imho. We would lose a lot of the non-development work that brainbot have done such as building relationships with nethermind, gnosis etc, the relationships with the cryptography experts that brainbot have been working with, plus the cost in time of another shop getting up to speed. Whilst I think overall success of the project (has always been) a long shot, I think this would substantially reduce the likelihood of success. As an alternative path forward I would have preferred more effort be put into governance, objectives, roadmaps, collaboration with brainbot - recognising their weaknesses and attempting to help fill them etc.

Tbh, I am considering cutting my losses and just moving on as I think the DAO overall is too divided for success and initiatives like this pose too big a risk for success.

2 Likes
7

I agree with your take. Swapping out the original team now would introduce serious risk. Brainbot has been the driving force behind Shutter’s vision from the beginning, and beyond delivering core infrastructure, they’ve built important relationships and laid the groundwork for long-term success. Replacing them would mean losing technical continuity, trusted partnerships, and momentum at a time when the project is already tackling complex initiatives like decentralizing the keyper set — something that’s both technically demanding and essential to Shutter’s future.

It also seems like the underlying tension here is less about execution and more about short-term price dissatisfaction. That’s understandable in a tough market, but these kinds of proposals feel reactive rather than strategic. If the goal is real adoption, the focus should be on supporting what’s already working and identifying where the community can actually contribute.

For example, Shutter is already integrated into the Gnosis Chain validator set, and as decentralization expands, that integration is only going to deepen. Gnosis itself is gaining traction — the Aave v3 proposal to improve capital efficiency passed overwhelmingly (Aave - Open Source Liquidity Protocol), and CowSwap, where Shutter is expected to integrate further, just processed over $8B in volume last month. These are strong signals — but they need visibility.

Community coordination around spreading the word in the right places, whether through aligned ecosystems or broader crypto forums, could go a long way. It’s time we actually start pushing. A united and positive effort from token holders can help amplify what’s already in motion and support the team in delivering long-term value.

1 Like
8

Thank you for comments and concern but I think there is some misunderstanding. I have quoted related proposal content above

1 Like