Request for Proposal (RFP): Compound DAO Voting Service Provider (VSP)

[Mel_StableLab]

Request for Proposal (RFP): Compound DAO Voting Service Provider (VSP)

Co-Authors: Compound Governance Working Group (CGWG): StableLab @Doo_StableLab, Arana Digital @AranaDigital, & PGov @PGov

Motivation & Background

Following feedback from the community, Compound Governance Working Group is coordinating for qualified Compound DAO Voting Service Providers (VSPs) to submit proposals to deliver a high-availability governance interface that supports Compound governance in growth, resilience, and efficiency. Although the primary interface that Compound DAO relies on today is Tally, the continuation of their services is contingent on the DAO engaging with them on a formalized contractual basis. It is important for delegates to have the optionality for selecting the most favorable VSP, based on desirable feature sets and financial cost. This RFP acts as a process for evaluating a set of potential options before committing to a singular vendor.

Timeline & Order of Operations

The initial term of this engagement will run through the end of Q2 2026, covering approximately one year of service and funding. Based on the review as well as feedback from the DAO, the DAO may choose to renew the program with the selected VSP or initiate a new selection process.

To ensure transparency and accountability, the CGWG will coordinate a retrospective review of the selected VSP’s performance. This will include an independent CGWG-led analysis based on the KPIs and milestones proposed in the present application, as well as a self-assessment published by the VSP. These evaluations may differ due to methodological or interpretive differences, but both will be made available to the community to help inform future decisions around governance infrastructure and vendor engagement. The vendor must publish their KPI goals prior to the start of each quarter, along with a retrospective of the given quarter’s achievements, in order to ensure that the capital being streamed to the vendor remains active. These details are to be articulated on the Compound forum.

RFP Process: 4 June through 13 June 2025, 11:59pm UTC:
Note: The deadline has been extended to 16 June 2025, 11:59pm UTC

• All vendors are meant to complete the “Required Responses” section of this RFP in the current forum post.
• After a proposal has been submitted by a team, the CGWG will check that all of the required questions have been thoughtfully answered, allowing the proposal to proceed to the OpenZeppelin review.

Snapshot Phase:

• Compound DAO Voting Service Provider Selection will be determined by a Snapshot vote. Delegates will have the opportunity to vote on which vendors they prefer to utilize as well as an option to do nothing and keep the current status quo—the conditions of the “status quo” option will be further detailed after the RFP Process concludes and may require further comments from the existing vendor, Tally.

On-chain Vote & Coordination:

• The Voting Service Provider selected from the Snapshot vote will move to the on-chain vote, which will include the budget request. If voted in, the budget will be streamed to the vendor using WOOF’s streaming solution. The CGWG will act as the oversight body, ensuring that the selected vendor is fulfilling promised deliverables, evaluated on a quarterly basis. The duration of the stream will last a one-year period, with the ability for governance to withdraw remaining stream funds in the event that the vendor does not abide by their agreement to the DAO.

Scope of Proposals

Proposal should cover:

• Technical support for Compound governance
• 12-month budget and also long-term budget if applicable
• KPIs and milestones
• Security assumptions, audits, and risk mitigations
• Operational responsibilities and maintenance commitments

Please follow the order of questions provided in the below section under the three overarching categories: technical questions, economic considerations, and security/risk assessment.

For the sake of standardization, please reply to this forum post using the “Required Responses” template:

• General Overview
  • Background Questions
• Section 1: Platform Functionality
  • 1a)
  • etc.
• Section 2: Technical Integration and Security Assessment
  • 2a)
  • etc.
• Section 3: Commercial Terms and Commitment
  • 3a)
  • etc.

Required Responses

General Overview

Company/Protocol Name and Brief Background:

List Existing History with Compound Protocol/DAO:

Section 1: Platform Functionality

1a) Platform Overview and Feature Set

Please describe your governance platform’s core features and capabilities. Examples can include:

• Proposal creation and management
• Live vote display and execution status
• Delegate dashboards and delegation tools
• Notifications and alerts for voters or delegates
• On-chain/off-chain interoperability (e.g., Snapshot, forum integrations)

1b) Service Tiers and Customization Levels

Based on your response to 1a, do you offer different levels of service (e.g., basic access vs. dedicated support), or are you presenting your platform solely as a tool (without a service component)? Please clearly outline which features are included at each tier. If you offer tiers, what level of responsiveness, customization, or integration support is included? Do you offer specific feature integrations on a request basis as part of a particular tier, or will you require separate grants for new feature requests?

Some examples are listed below—essentially outline what features would require a higher tier, if applicable:

• Basic voting and delegation interface
• Proposal creation interface
• SLA guarantees (e.g., 99.9% uptime, 24-hour response time)
• Access to dedicated support reps
• Custom frontends (Compound-branded pages or ENS-integrated dashboards)
• Feature prioritization for Compound-specific needs
• Vote simulation
• Gasless voting

1c) Existing Partnerships

Please disclose relevant DAOs that currently use your platform. Which of these clients are using your platform in a similar capacity to what is proposed for Compound (i.e., full proposal lifecycle management, delegate dashboards, on-chain voting, etc.)?

Section 2: Technical Integration and Security Assessment

2a) Audit History and Security Reviews

Has your platform or its infrastructure undergone formal audits? Please provide links to audit reports, security reviews, or penetration test summaries. If your platform is unaudited, describe your plan and timeline for completing an audit.

2b) Integration Requirements and Implementation Timeline

What is required to integrate your platform into Compound DAO’s existing governance system? Please include details on:

• Smart Contract Compatibility: Will any smart contracts need to be deployed or modified? Would there need to be any on-chain Compound proposals to modify Compound OpenZeppelin Governor?
• On-chain Proposal Requirements: Would your integration require any governance proposals (e.g., to set new roles, addresses, or contract approvals)?
• Design Assumptions and Limitations: Does your platform assume any contract patterns or interfaces that may not be present in Compound (e.g., ABI encoding, metadata formatting, or proposal construction flows)? Are there proposal formats that your platform struggles to interpret (e.g., call data-only proposals, parameterless calls)?
• Governor Compatibility and Upgrade Constraints: Are there any assumptions in your platform that would limit Compound’s ability to upgrade or modify Governor Bravo in the future? Is your system forward-compatible with potential Governor upgrades or alternative implementations?
• Timeline: What is your estimated timeline from DAO approval to launch?
• Dependencies: Which dependencies are used by your platform? What is your approach for preventing security risks arising from the use of these dependencies?

2c) On-chain/Off-chain Data Alignment and Proposal Verification

How does your platform ensure that what users see in the frontend matches the on-chain state (e.g., proposal content, execution status, vote totals)?

• How do you prevent mismatches between displayed metadata and actual contract state?
• Do you offer verification tools or calldata previews before proposals go live?

2d) Developer Support:

Please provide links to your developer documentation and best practices. Do you provide developer support and, if so, what form does this take—and is it dependent on a particular service tier? Who is the contact person who can answer questions in relation to this proposal?

2e) Threat Modeling:

If your team or an independent firm have conducted formal threat modeling for your platform, please include a link and high-level summary.

Otherwise, please identify the top five attack vectors you’ve considered most relevant to your governance interface or infrastructure. You are not limited, but we’re interested in vectors such as frontend injection, DNS hijacking, API abuse or rate-limiting failure, phishing of delegates or proposal authors, smart contract replay attacks, signature injection, insufficient access control, calldata spoofing, unverified proposal metadata, or integration-side failures (e.g., oracles, third-party APIs, or ENS resolution). For each of the attack vectors you list, please describe: likelihood of occurrence, cost to exploit, impact severity, mitigations currently in place, monitoring and alerting practices, if any.

Section 3: Commercial Terms & Commitment

3a) Budget Request

What is your proposed budget request for the first year of engagement with Compound DAO? Please specify the total 12-month budget (USD equivalent). Are you intending on altering the fee after the first year—or offer a discount for the initial year?

3b) Milestone-Based Payment Structure

Substantiate on the performance indicators (KPIs) or milestones tied to each payment tranche—the CGWG will disburse payments on a quarterly basis based on predefined KPIs that are to be posted on the selected VSP’s forum update thread.

Broad KPIs can be categorized into two categories: Maintenance/Uptime and Usage/Adoption

Platform Maintenance, Reliability, and Uptime KPIs

These KPIs should demonstrate operational excellence, ensure baseline functionality, and mitigate service risk for the DAO. Please include:

• Uptime guarantees (e.g., “Maintain 99.9% frontend and API uptime on a monthly basis”)
• Response time SLAs (e.g., “Respond to critical governance-related support requests within 24 hours”)
• Infrastructure reporting (e.g., “Publish a quarterly uptime and incident report”)
• Change management practices (e.g., “Notify the DAO at least 7 days in advance of any platform upgrades that affect the governance UI or vote interaction”)

Governance Feature Usage, Impact, and Platform Adoption KPIs

These KPIs should measure the platform’s actual impact on Compound DAO’s governance process. Feature Addition KPIs may vary quarter to quarter and can be defined more specifically before the start of each quarter, but examples here would be appreciated. Please include metrics such as:

• Feature delivery (e.g., “Deliver a fully branded Compound governance interface by the end of Q1”)
• Governance activity usage (e.g., “75%+ of on-chain proposals in a quarter are initiated, tracked, or voted on using our platform”)
• Participation metrics (e.g., “Achieve an average of X unique voters per proposal across Q2–Q4”)
• Feature Additions (e.g., “Implement gasless voting by the end of next quarter”)

3c) Offboarding, Data Portability, and Sunset Plans

Transparency around exit conditions is critical to long-term DAO resilience, even if there is no preexisting intention of changing the service provider. In the event that the DAO chooses not to renew your services, how will offboarding be handled?

• Will Compound retain access to historical governance data (e.g., dashboards, delegation records, proposal history)?
• Will a static or open-source interface remain available to reference past activity?
• Are there contractual or technical constraints that would limit Compound’s ability to transition to a new provider?

Final Considerations

Is there anything about your approach that you believe we’ve missed asking about? This can include anything that represents a competitive edge, unique design principle, or deeper alignment with Compound’s mission?

Feel free to post a link to any relevant articles, videos, or demos demonstrating the nature of your product—but do answer all of the above questions in the provided setup and sequence on this forum page. Please keep the final considerations section brief and to the point, if applicable.

[Mel_StableLab]

The deadline to post has been extended to 2025-06-16T11:59:00Z.

[cylon]

While I appreciate the Compound Governance Working Group’s (CGWG) initiative in convening infrastructure discussions, I have concerns about the formal authority underpinning this RFP process and the precedent it sets for DAO-wide vendor selection.

The CGWG renewal proposal does not delegate responsibility for managing RFPs or making binding decisions regarding vendor procurement. While CGWG has played an important role in supporting participation and coordination, establishing a structured, high-stakes RFP process—without first securing governance approval—goes beyond the mandate granted by tokenholders. Even though this process includes snapshot and onchain votes, the fact that CGWG is unilaterally defining the structure, evaluation criteria, and oversight introduces significant influence and responsibility that have not been formally scoped or approved.

This lack of formal delegation raises valid concerns about the legitimacy and enforceability of the RFP’s outcome. We’ve already seen inconsistency in how vendor selection is approached—for example, WOOF’s proposal for core protocol development recently moved forward and passed without an RFP process and received strong support from CGWG members, while the ongoing OEV RFP evaluation was launched by CGWG around the same time. It’s not at all clear to me why one vendor proposal required an RFP and the other did not. These inconsistencies erode confidence in the objectivity and fairness of the process.

It’s also important to acknowledge that Tally is currently the de facto governance interface for Compound and has been funded in the past via the Compound Grants Program (CGP). Tally’s infrastructure is already deeply integrated into the DAO’s workflows. Even if there is merit in evaluating alternative vendors, Tally’s longstanding contributions deserve recognition. We should not pursue an RFP just for the appearance of process—especially when baseline existing needs are already being met.

Given that Tally continues to fulfill the DAO’s core governance requirements, there is no urgent justification for rushing into an RFP process. A more appropriate course of action would be to propose a short-term proposal funding Tally’s existing support and defer the broader vendor evaluation process to the soon-to-be-established Compound Foundation. The Foundation is explicitly tasked with operational leadership and vendor oversight and would be far better positioned to manage a standardized, transparent, and community-sanctioned RFP and vendor selection process.

Pushing this process forward without clear mandate risks creating confusion and undermining accountability. A more deliberate approach—grounded in formal delegation and consistent process—would better serve the DAO in the long run.

[Mel_StableLab]

Hey Michael,
While we’re not opposed to the status quo as an option, we’ve had inbound from a couple of delegates requesting a more robust vendor selection process. The ability to select between various options is something that we’ve received support for from multiple parties and have communicated our intetions during the past few community calls. Disparate votes for the selection of one or more vendor reduces much needed DAO organization. It’s much easier to conduct an apples to apples comparison when vendor selection is publicly facilitated between various parties in a concerted manner. Such a setup allows the DAO to reduce expenditure and elect the best solution. We have aimed to include as many necessary questions in the RFP to best enable delegates to make informed decisions, without bias towards a particular solution. The result of this RFP will also be conducted via an election, and the payment stream will be in the hands of governance. Our goal, upon delegate request, has been to provide effective organization around these processes. We are by no means the final arbiter. Control remains with governance.

[Jorstack]

That’s interesting. I like the idea of having in multiple vendors come in and seeing how each one actually performs. I agree it gives the DAO a better picture of what’s out there instead of just sticking with the default.

I’ve also seen similar suggestions from the OEV conversations and do think this is worth trying out. That said, I also agree that Tally’s deep integration and long-term commitment to the protocol should be recognized and considered in this, especially if the difference between options doesn’t end up being significant.

[cylon]

I appreciate that the GWG is bringing this initiative forward based on interest from some delegates in exploring infrastructure alternatives.

That said, I want to respectfully express concern regarding the process behind this proposal. According to CIP-1—a governance process the community formally adopted via Snapshot—decisions regarding off-chain governance processes or tooling, such as launching an RFP process for evaluating vendors, should be proposed through a Meta Process CIP and approved via Snapshot signal vote.

While it’s true that formal processes like CIP-1 haven’t always been strictly followed in recent months, the Governance Working Group, of all groups, should be setting some kind of standard when it comes to process. Taking on new responsibilities—like unilaterally initiating an RFP and defining its structure—without clear delegation sets a problematic precedent.

Informal delegate conversations and community sentiment are valuable inputs—but they aren’t a substitute for actual votes. If the GWG believes there is a strong case to pursue an RFP program, the appropriate path is clear: draft a proposal and put it to a snapshot vote. Until that happens, this process lacks legitimacy and CGWG can’t solicit vendors on behalf of the Compound protocol.

To be clear, I’m not necessarily opposed to evaluating new infrastructure or providers. I’m opposed to the process proceeding without an established mandate from a formal governance decision.

[PGov]

CIP-1 and many of the items outlined are outdated, and have been outdated for years. Things such as “The Working Group” have not existed for a while.

In this situation, we were presented with multiple vendors that wanted to apply for a specific role, and many delegates and DAO members expressed interest in a RFP to smoothly facilitate the governance process, in line with our governance stewardship mandate. We’ve done this for OEV and Compstaker, which has been on the forums for over a month now, hence, we are confused why this is the first concern that has been brought up as we have also talked about it on every community call the last couple of months. We have communicated to the vendors that we can not force them to wait and not put up a snapshot, however, understanding delegates’ wishes, they have all agreed to move forward with the RFP.

As for the process itself, we think you bring up a great point regarding formalizing the process and having a snapshot vote to check off on it. We will look to gather sentiment around this in the coming weeks to finalize and see the best processes on how an RFP would work.

[1a35e1]

Thanks for putting other this RFP. It’s the first time we have ever seen a formal RFP in this fashion when it comes to governance providers selection.

As some people may know we (https://lighthouse.cx/) offer full voting support for Compounds current voting scheme across both Snapshot and current Governor.

[RFC] Compound x Lighthouse

GM Compound DAO, We’re pleased to announce that Compound governance is now accessible on iOS and Android through Lighthouse Governance. Our platform offers several practical features for governance participants: New proposal notifications Voting on Snapshot proposals with Safe Support for both Snapshot + Governor Sign in with Ethereum over Reown In-context on-chain voter data [compound-preview] As this is our first touch point with the DAO, we welcome feedback and will be monitoring to ans…

Is there a meeting recording were where we can catch up on some of the background to better understand the intentions of this RFP process?

While we are not a major player in driving votes via our interface at the moment. I think we novel in the sense that we offer some of the most sophisticated way to vote natively on mobile.

I don’t think we have the traffic to justify being a sole vendor but we do have a pipeline of work that would definitely bing a brand new set of features to the Compound governance process.

The following article documents how you can use a Safe to vote on Compounds Snapshot space: Native voting with Safe on Snapshot — Lighthouse Labs

[cylon]

As for the process itself, we think you bring up a great point regarding formalizing the process and having a snapshot vote to check off on it. We will look to gather sentiment around this in the coming weeks to finalize and see the best processes on how an RFP would work.

Thank you for the reply. Introducing a Snapshot vote to establish a clear mandate for vendor management would directly address my primary concern.

I hadn’t raised any issues regarding the processes for OEV or COMP Staker because I wasn’t following those threads as closely at the time. I had assumed there was already some prior governance mandate in place. It was only when I realized that no such delegation had occurred that I became concerned. I do make a point to follow Snapshot and governance votes—and that’s where I would have expected to see any change to the GWG’s scope, particularly if it now includes vendor selection and RFP issuance. That expectation aligns not only with CIP-1, but also with standard practices across other major DAOs.

CIP-1 and many of the items outlined are outdated, and have been outdated for years. Things such as “The Working Group” have not existed for a while.

Even if elements of CIP-1 are outdated or have fallen out of use, that makes it all the more important for the Governance Working Group to take the lead in formalizing a new process. That seems well within the scope of your current mandate, as outlined in the GWG renewal proposal. If governance stewards are going to ask vendors to engage in a structured selection process, that process should be grounded in something legitimate—otherwise vendors have no obligation to abide by the results, and the DAO has no clear framework to enforce them.

At the end of the day, what’s needed is a clear mandate to run a vendor RFP process. A Snapshot vote to formalize the framework would be a solid step in that direction.

[GozmanGonzalez]

This RFP is a strong precedent for maturing DAO procurement practices.

The emphasis on performance-based streaming, KPI disclosures, and vendor accountability signals a shift from “trust-based coordination” to contractual clarity within decentralized systems exactly what’s needed for sustainable DAO operations.

Binding quarterly KPIs
Sunset clauses with data portability
Clearly defined service scopes and milestone-linked disbursements
Transparent selection via Snapshot + OpenZeppelin review

These are hallmark principles of good governance hygiene and signal-risk reduction, especially when vendor continuity and platform integrity are at stake.

As we move forward, it would be great to see:

1. Template service agreements built for DAO contexts, including arbitration mechanisms or fallback procedures.
2. A lightweight legal memo outlining what constitutes a “material breach” in this decentralized procurement model.
3. Commitment from vendors to open-sourcing core governance modules at offboarding (or via time-based license).

Big kudos to the CGWG, this is how decentralized governance scales responsibly.

[Avantgarde]

We sincerely thank the CGWG for putting this forward. Since separate service providers have put up competing proposals, it makes sense to formalise the process with some additional structure.

However, given various discussions that have taken place over the last few months about things like optimistic governance (which btw appears as a very valuable addition to the DAO), staking models etc etc, it seems like it would be appropriate for the DAO to first outline which features it actually wishes to implement (in the short- to medium-term) and what sort of capabilities it may want to experiment with later on.

By picking the service provider before deciding what sort of governance we may want to run for the DAO, we risk boxing ourselves in. Perhaps we could organise a couple of workshops to iron this out before we move ahead with voting on service providers? That way we’d have a clearer understanding of what we’re looking for.

[1a35e1]

@Avantgarde

Perhaps we could organise a couple of workshops to iron this out before we move ahead with voting on service providers? That way we’d have a clearer understanding of what we’re looking for.

ENS recently ran their second term of their Service Provider Program where they allocated 4.5M of capital though a public RFP and then Snapshot with Ranked Choice voting and custom scoring using Copelands method.

As an interface vendor we were involved in shaping aspects of the voting mechanism but mostly we spent a large time discussing the nuances of the program. I would recommend a study as it is really interesting from a capital allocation PoV. Aside: we also received a retro grant for our contributions.

Aspirationally I am an advocate for Vendors delivering services that are tightly coupled with the needs of the DAO but as @Avantgarde noted these needs are not always clearly articulated or documented.

This actually cuts to meat of much of the analysis that we had over at ENS. I would recommend reading this thread which covers a lot of the broader-thinking from delegates to serve as input for the next season.

[aurelianoB]

Hey, this is Aureliano from Snapshot Labs. We’ve just seen this RFP and we’d like to submit Snapshot as an alternative to existing bids.

Our plan is to deliver an open-source interface that unifies every stage of Compound’s governance flow, combining Snapshot signalling and Governor onchain voting in a unified organisation view, with room to add any extra features the DAO may need.

Before we submit a full proposal, we’d appreciate guidance on two quick points:

1. Is replying in this thread the correct way to apply, or should we open a separate post like Tally and Aragon? Will there be an internal vote to ratify the RFP first?
2. Would you consider a short extension so we can prepare a more thorough proposal?

Thanks!

[AranaDigital]

Snapshot Labs Response

Hi @aurelianoB, thanks for your comment—

@aurelianoB

• Is replying in this thread the correct way to apply, or should we open a separate post like Tally and Aragon? Will there be an internal vote to ratify the RFP first?

We request that you reply to this RFP in the format outlined above in the initial RFP post to ensure standardization of the process and consolidation of the information in one thread. There will be an off-chain Snapshot vote held soon, where delegates can select the vendor(s) that they are keen on supporting based on the RFP responses.

@aurelianoB

1. Would you consider a short extension so we can prepare a more thorough proposal?

Since we are still awaiting responses from the each of the vendors that have so far demonstrated interest in this application, we are extending the application deadline to June 16, 11:59pm UTC.

RFP Process Update for DAO Members

We will post a proposal shortly pertaining to officially authorizing the CGWG to conduct future RFPs on behalf of the DAO. The current RFPs that we have begun running are a result of popular demand by delegates. We recognize that our initial mandate does not explicitly outline “RFPs” as a line item—however, through interactions with different stakeholders, we’ve been identified as a neutral party that can help facilitate vendor solicitation. The goal of these exercises has been to aid delegates in selecting the best and most cost effective providers for Compound. After outlining a formalized structure for future RFPs based on our learnings, we will bring this authorization vote to a Snapshot vote.

The authorization Snapshot vote is entirely separate from this current VSP and the ongoing OEV RFPs. To maintain continuity for the existing VSP and OEV RFPs, we will continue to facilitate them as initially intended. They also serve as helpful prototypes for future proposals.

—Compound Governance Working Group (CGWG)

[nathanvdh]

Aragon’s Response to Compound DAO’s RFP

Thank you to the Compound Governance Working Group (CGWG) for conducting this RFP. We appreciate the fairness and clarity of the process, and are confident that it will help the Compound DAO make the best decision for its future.

Before responding in detail to the provided questions, we want to provide our perspective on what this RFP means to the direction and future of the Compound DAO.

The current governance model is exclusively reliant on token-based voting. This model is akin to running census-wide referendums for all decisions. We believe the governance mechanism itself has failed to meet the project’s needs. There are persistent issues reaching quorum, high levels of voter apathy, and service providers are paralyzed. Total value locked (TVL) has stagnated, plateauing in the last three years and giving Aave a now tenfold lead, clearly indicating that the Compound DAO urgently requires a structural shift in its decision making.

This RFP itself, as noted by @Avantgarde, focuses on optimizing the existing referendum-based approach. We propose that incremental improvements will not directly address the root causes of Compound’s hampered growth and operational agility. Simply put, token-based referendum voting is insufficient on its own to efficiently manage a mature protocol like Compound.

This proposal advocates for Compound DAO’s adoption of Aragon’s modular governance tooling. The proposal will explain how having different decision-making flows with different stakeholder groups represented as their own governing bodies, optionally in an optimistic or non-optimistic configuration, will address the challenges outlined above. These features also accommodate easy further changes thanks to the plugin-based architecture of OSx, designed to adapt to changing regulatory requirements.

What we propose is highly practical:

• Risk managers like Gauntlet that will gain limited permissions to efficiently adjust protocol parameters without requiring full community votes.
• Security partners like OpenZeppelin that can immediately trigger a pause on critical functions without holding broader administrative rights.
• Delegates can shift their attention from routine votes to strategic and growth-oriented initiatives.
• The upcoming Foundation will access powerful new governance tools to swiftly implement and manage diverse decision flows transparently and replicate their legal setup onchain.

All these improvements are available at a fraction of the cost of other proposals, without vendor lock-in, and through open-source contracts that avoid the need for full-scale upgrades and expensive security audits with each incremental improvement. These savings allow Compound to better use its funds to focus on what it does best - growing the best lending market in DeFi.

---

General Overview

Aragon Background

Founded in 2016, Aragon has established itself as one of the most trusted onchain governance providers. Our frameworks secure tens of billions of dollars in DeFi, including high-profile implementations for Lido (stETH), Curve, and Taiko. We emphasize security and modularity with a long-term orientation, reflected in over seven years with no security incidents. This commitment to security has led us to create OSx, the most modular smart contract governance framework.

Aragon OSx is fully audited by tier-1 security firms. Links to our audits can be found here.

Existing History with Compound

Aragon and Compound were side by side, building governance at the beginning of Ethereum.

While Compound’s Governor product line became a standard for vanilla token-based voting, and this standard has served many DAOs well in recent years, it has become evident that one-size-fits-all governance, where everyone is required to vote on everything, is hindering projects from reaching their potential. Aragon’s modular stack was built directly to address these challenges.

---

Section 1: Platform Functionality

1a) Platform Overview and Feature Set

Proposal Types:

• Emergency Proposals: Governance processes can be added for quickly responding to urgent vulnerabilities or protocol threats. This prevents governance from being paralyzed when time-sensitive action is needed.
• Resource Allocation: Governance processes can be added specifically (e.g., staking contracts, voting gauges) for financial decisions.
• Additional Proposal Types: Aragon DAOs have their own dedicated and flexible ACL, so any number of permissions can be arbitrarily defined with no new code. This allows a DAO to have any number of governance processes, each able to execute actions for specific types of functionality only (based on function selector).

Flexible Governance Processes:

• Staged Proposals: Governance processes can pass through any number of sequential stages, each governed by different bodies. Compound-pioneered timelocks are also available between or after stages.
• Governing Bodies (including Councils): Specialized bodies (e.g., a multisig, another Aragon OSx plugin, an EOA) can be added to any governance stage, ensuring that the right stakeholders are involved in the right proposals at the right time. Multi-body governance can happen serially (in stages) or in parallel, with any number of bodies voting at the same time.
• Legal Structures: Integrates compliance or off-chain legal frameworks directly into onchain governance by using them as governing bodies. This can help mirror real-world legal entity requirements for DAOs that must adhere to regulated environments, or add BORGs as governing bodies.

Optimistic Governance:

• Governance stages can be configured to pass optimistically, so that proposals pass automatically unless vetoed by a governing body, reducing voter fatigue yet still providing them a voice.

Future-proof Governance:

• Governance processes can be added, removed, or modified to iterate as the needs of the DAO evolves. There’s no need to re-audit anything.

Additional features:

• Action Decoding: Onchain actions are automatically decoded and displayed in a user friendly way, with many of the most common actions (i.e. transfers) having a custom UI. Common Compound functions can be given their own custom UIs.
• Notifications & Alerts: Email or telegram notifications for new proposals, impending deadlines, or veto windows, letting delegates or other stakeholders stay informed.

1b) Service Tiers and Customization Levels

Free, Open-Source Tier

Aragon’s no-code open source governance platform is openly available at zero cost. All the features described above are available, but no custom work or dedicated support channel is available. We do not have a proposal fee.

Dedicated Support (Recommended for Compound)

For $5k/month, Compound receives specialized support and advisory, including custom branding and assistance with any governance-specific need. In addition, our team is available to review any proposal for an additional layer of security. Any highly advanced or specialized feature (unique analytics or staking logic) can be scoped under a separate work arrangement if needed.

1c) Existing Partnerships

Lido: Lido uses Aragon contracts both for stETH, securing billions in TVL, and for governance proposals.
Curve: Curve’s governance and ve-system operates on Aragon-based smart contracts.
Polygon: Polygon uses Aragon for its governance, including their Community Treasury.
Taiko: Taiko uses an optimistic governance system on OSx, creating a security council with a tokenholder veto rather than relying on referendum-based governance.

We’ve recently upgraded our UI to fully unlock the capabilities of battle-tested OSx, with no code wizards for creating and managing complex multibody governance structures.

---

Section 2: Technical Integration and Security Assessment

2a) Audit History and Security Reviews

Aragon OSx and previous frameworks have been audited by tier-1 firms. No security incidents or exploits have ever occurred since Aragon’s inception. We welcome any specific tests or external audits upon Compound’s request.

2b) Integration Requirements and Implementation Timeline

Smart Contract Compatibility: No proposals would be necessary to upgrade any of the existing Governor contracts as the permissions would be granted to the Aragon DAO contract. The COMP token, delegations, etc. would not change.

Onchain Proposal Requirements: Integrating with Compound requires a single onchain proposal that moves the relevant permissions to the Aragon DAO contract.

Design Assumptions & Limitations: COMP does not use the latest IVotes ABI so a simple adapter contract or minor code change to the Aragon TokenVoting plugin would ensure compatibility.

Timeline: We can deliver a fully operational interface within one month of DAO approval. Further customization can be layered on gradually, without blocking daily governance.

Dependencies: Aragon has a philosophy of fully onchain binding execution so for the DAO to operate onchain there are no strict dependencies. The Aragon frontend, our recommended UI to use for Compound, uses the Aragon indexer. Alchemy is used for RPC calls and the Etherscan API for smart contract ABIs. API keys and secrets are obfuscated through server-side proxying so that they are not exposed to the frontend.

Frontend dependencies (e.g. WalletConnect) are kept up-to-date every two weeks.

The advantage of putting in this effort now is that any further changes to Compound’s governance system over the years (and especially with regulation coming up shortly) will not require any changing the DAO contract address, due its decoupling from the governance layer–one of the core principles of OSx’s modular plugin-based architecture. In contrast, in other Governor DAOs, new contract versions have required replacing (rather than upgrading) the Governor contract in order to keep up with new features. For example, any future staking contract that the DAO would select can work with Aragon DAO contracts, while the current system would need to use a new Governor contract to be compatible.

2c) onchain/Off-chain Data Alignment and Proposal Verification

The Aragon indexer has automated data integrity checks that call multiple APIs to ensure that the data is internally coherent. These run as part of our GitHub pipeline for all commits, but also on a schedule as part of our monitoring services.

However, to ensure that data is consistent with onchain state, we currently have in development and are soon deploying a parallel subgraph specifically as an aggregate source of truth.

2d) Developer Support

Comprehensive guides are available at docs.aragon.org. In addition, I’d like to invite delegates to message me on Telegram at @nathan_vdh for technical or governance-related questions. If chosen, we will create a specific setup to ensure we’re easily accessible.

2e) Threat Modeling

Aragon maintains the Aragon Scorecard, a self-imposed continuously updated assessment of our commitment to security, open-source code, and threat-mitigation.

We are open to collaborating with Compound’s security experts on further threat modeling or targeted reviews.

---

Section 3: Commercial Terms and Commitment

3a) Budget Request

Budget Request:

• $5,000/month for 12 months, totalling $60,000.

• Payments can be streamed monthly or quarterly.

• Open to receiving COMP, stablecoins, or a combination thereof.

After Year 1: Compound can continue using our products for free, or can decide to continue the 5k/month agreement to benefit from the previously described Dedicated Support fee tier. None of our features are dependent on the continuation of the Dedicated Support fee tier.

3b) Milestone-Based Payment Structure

Milestones & KPIs: Seeing as we propose a large structural shift, the key milestones we will focus on are related to:

• 99.9% frontend availability, 24-hour response time for critical issues, and quarterly incident reporting.
• Fast and orderly migration of permissions.
• Delegate satisfaction with the new UI, and participation in the creation of the new system.

Usage & Adoption: We will measure basic metrics such as governance participation and successful proposal proportion, but as stated earlier our goal is to eventually help Compound transition towards a better system. When this system will be in place, under the oversight of the CWGW, we will put KPIs in place related to the good functioning of said system.

Payments can be paused if expectations are not met, operational uptime is not respected, or if the new system doesn’t improve DAO operations and decision making (under the oversight by the Compound Governance Working Group).

3c) Offboarding, Data Portability, and Sunset Plans

Offboarding & Data Portability:

• All governance data is onchain, so historical records remain accessible even if Aragon is discontinued.
• After the first year, Compound can use Aragon’s infrastructure at no additional cost, or transition to a new provider with no vendor lock-in.

---

Final Considerations

When we started building Aragon OSx, we had exactly DAOs like Compound in mind. DAOs that have grown to the point where one-size-fits-all governance just doesn’t cut it anymore. At this stage, you need tools that let you grow, adapt, and make changes without kicking off costly audits or introducing new security risks every time. DAOs should never get stuck, especially not by quorums they can’t reach, sluggish processes they can’t fix, or outdated contracts that feel too risky to change. Governor has been a true hallmark of both Compound and DeFi as a whole, but nostalgia and path dependency shouldn’t decide what comes next. With fresh momentum, a new foundation in place, and a friendlier regulatory landscape emerging, Compound is on the verge of an incredible opportunity. This is the perfect moment for Compound to equip itself with better governance tools, so it can move fast, adapt smoothly, and reclaim its spot as a leader in DeFi.

Relevant Links & Contact

• Documentation: docs.aragon.org
  
• GitHub: github.com/aragon
  
• Aragon App: app.aragon.org
  
• Contact: nathan@aragon.org to establish a direct line to any of our 25+ governance specialists or smart contract developers.

[coolhorsegirl]

Proposal: Tally as a Dedicated Governance Service Provider to the Compound DAO

General Overview

Company/Protocol Name and Brief Background: Tally is a full-stack governance platform for onchain DAOs. We provide the leading interface for creating proposals, delegating, and voting using Governor-based contracts. In addition to core functionality, Tally supports advanced governance features like staking and multichain governance. Launched in 2020, Tally supports over 500 DAOs and is built specifically around Compound’s own Governor architecture. Over 7,000 proposals have been made on Tally and over $1billion in treasury value has been transferred via proposals that were created, voted, and executed on Tally.

List Existing History with Compound Protocol/DAO:

• Tally has supported Compound governance continuously since December 2020, making it our longest-standing DAO relationship. See Compound DAO homepage here.
• Our platform was built on top of the Governor standard, originally pioneered by Compound.
• Tally is the default governance interface used by Compound DAO contributors to vote, delegate, and create proposals.
• We recently completed the “Tally UX for Compound-specific Proposals” grant, delivering:
  • Added support in Tally’s UI for creating proposals that interact with key Compound contracts, including Governor, Compound v2, and Comet.
  • Enabled creation of cross-chain Compound proposals directly through Tally’s interface.
  • Improved visibility into proposals created outside of Tally by decoding calldata for mainnet Ethereum proposals.
• We have deep familiarity with Compound’s governance architecture, contributor workflows, delegates, and evolving needs.

Section 1: Platform Functionality

1a) Platform Overview and Feature Set

Live since 2020, Tally is the most feature-rich and battle-tested governance platform in the ecosystem, with full support for every stage of the onchain governance lifecycle. Our platform enables proposal creation (including arbitrary executable calls, no-code transfers, and MEV-protected swaps), live vote tracking, and execution status updates. We offer voting, proposal simulations using Tenderly, proposal execution, notifications, DAO analytics, Gnosis Safe management, integrations with Discourse and Snapshot, and DAO analytics (“Tally-litics”). Tally has a full-featured public API that is used by builders across the Ethereum ecosystem to power governance applications.

Outside the scope of this proposal, Tally also offers staking and multichain governance (MultiGov). Tally’s modular, audited staking system is purpose-built for DAOs, designed to align incentives between DAOs and tokenholders. We also offer MultiGov, a production-ready multichain governance framework that anchors proposal creation and voting on Ethereum while supporting secure cross-chain execution. MultiGov preserves delegate reputation, voting history, and governance continuity as token liquidity expands across chains. Each of these features may be turned on by Compound, via proposal, at any time.

1b) Service Tiers and Customization Levels

Tally is proposing an enterprise tier agreement that includes a dedicated feature roadmap, developer support, regular reporting, and SLAs.

Rather than a rigid scope, we propose a flexible engagement model where the Compound Governance Support Working Group (GSWG) sets quarterly priorities and Tally executes these initiatives directly. This model ensures alignment with Foundation and DAO-wide goals while enabling us to adapt as governance evolves. After consultation with the GSWG, we have prioritised the example deliverables within each workstream. We expect to deliver the bolded items within the first quarter of this engagement.

Workstream	Example Deliverables
Compound proposal UX	• Advanced simulations specific to Compound contracts: Deep simulation support tailored to Compound’s architecture, enabling users to preview proposal effects before onchain execution. • Custom proposal actions for Compound contracts and proposal scripts: Support for advanced Compound-specific actions, including scripted proposals and custom calldata. • Decode calldata of cross-chain proposals made off Tally (e.g. via script): Tally will automatically decode calldata for proposals submitted via external scripts or other frontends, including cross-chain messages, so users can easily understand what actions a proposal will take — even if it wasn’t created on Tally. • Automatic proposal execution: The automation of enacting passed proposals without manual intervention – once a proposal is approved onchain, it is queued and executed by a bot, streamlining governance by removing the need for delegates to execute transactions themselves.
Voting UX	• Gasless voting: A relayer-powered voting mechanism that lets token holders vote onchain for free. This will allow Compound DAO to sponsor gas fees for votes, so participants can cast votes without paying gas, lowering the barrier to governance participation. • Custom domain: Compound DAO can host Tally governance portal on a unique, branded domain or subdomain like gov.compound.finance. • Karma integration: Tally will display delegates’ Karma scores within the Tally UI. Karma is a delegate reputation tool that supports Compound. Every delegate’s profile displays a Karma score reflecting their activity and reliability (e.g. voting participation rate onchain and engagement in forums), helping token holders identify and differentiate highly active, “high-quality” delegates from less active ones. • Forum bot: Tally’s forum bot automatically posts updates in the Compound DAO Discourse forum when a proposal moves to the voting stage and when voting concludes, keeping the forum in sync with onchain governance activity. • Improved notifications: Enhanced governance alerts with expanded platform support (e.g. email, Telegram, Discord) and customizable preferences so users can choose which proposal or DAO events they want to be notified about and how. • MarketAdmin proposals: Display transactions made via the alternate governance track for market updates. • Rollback UI integration: Frontend to support Compound’s upcoming Emergency Upgrade Rollback system, providing visibility into rollback-enabled proposals, queued rollback transactions, execution windows, and guardian activity.
Governance resilience	• Tally Zero: A fully decentralized, read-only governance app and backup interface with live data sync, requiring zero reliance on Tally’s servers or backend. Tally Zero is an IPFS-hosted front-end that anyone can run to view proposals and cast votes directly on-chain via any Governor contract, ensuring that governance can continue uninterrupted even if the main Tally app is down.
Transparency & Reporting	• Homepages for Compound Safes: Dedicated Safe pages within Tally that enhance multisig visibility, showing signer addresses, transactions, and token balances. • DAO Analytics dashboard (”Tally-litics”): A dashboard with real-time charts and metrics visualizing DAO activity — including proposal trends, turnout rates, top voters, and execution stats — to give Compound DAO a snapshot of governance health. • Success metrics: On the Compound DAO homepage on Tally, Tally will show key governance performance indicators tracked to measure the health and effectiveness of the DAO’s processes. • Treasury Analytics: A module surfacing real-time insights into DAO treasuries — including token holdings, inflows/outflows, runway projections, and historical changes
Support & Uptime Guarantees	See “SLAs” section below.

Enterprise support includes the following SLAs:

• Tally usage
  • We will continue to track the number of proposals and % of votes per proposal made on Tally and report on those to the DAO.
• Roadmap feature usage
  • As we roll out new features for the Compound DAO, we will track usage of those features and report on them to the DAO.
• Monthly office hours
  • An open feedback session for Compound DAO contributors to suggest new features and contribute to our roadmap
• Uptime and availability
  • System Uptime: 99% monthly uptime, ensuring the system is accessible with minimal disruptions.
  • Scheduled Downtime: Maximum of 2% monthly allowance for scheduled maintenance, communicated in advance.
• Response and resolution time
  • Incident Response Time: Initial response within 4 hours for high-priority incidents (e.g., outages) during working hours in the United States, and 24 hours for incidents outside of working hours and low-priority issues.
  • Resolution Time: Resolution or workaround within 8 hours for high-priority incidents (e.g., outages) during working hours in the United States, and 24 hours for incidents outside of working hours.
• Maintenance and support
  • Bug Resolution: Resolution of non-critical bugs within 5 business days and critical bugs within 1 business day. For bugs that are not possible to resolve in this time frame, a post-mortem analysis to be shared with the DAO following resolution.
  • Regular Maintenance Updates: Regular monthly maintenance updates, including minor upgrades, patches, and performance improvements.
• Public API access
  • Tally provides open access to its governance API, allowing developers to query proposal data, vote records, delegate profiles, and DAO metadata. We ensure 99% monthly uptime for the API and will notify the DAO of any major updates, deprecations, or downtime.
  • Feature requests and support for API integrations can be raised during monthly office hours or through direct support channels.

Compound may instead use Tally’s baseline implementation (“self-serve tier”). Tally’s self-serve governance product includes only our public platform with a proposal fee and does not include any of the additional services described in this proposal including the items listed above.

1c) Existing Partnerships

Over 500 DAOs use Tally for governance, all publicly viewable here. Some of the most prominent include Arbitrum, Wormhole, zkSync, Uniswap, Obol, ENS, EigenLayer—and of course, Compound, which has used Tally continuously for over 4.5 years.

Many of these DAOs use Tally for the full proposal lifecycle, including onchain proposal creation, delegate dashboards, voting, and execution. Uniswap has an enterprise support agreement in place with Tally.

Section 2: Technical Integration and Security Assessment

2a) Audit History and Security Reviews

Tally takes security seriously and values the contributions of security researchers who help keep our platform and users safe. Our security practices are documented here. We have a clear reporting process and reward system in place for valuable reports.

Tally’s architecture is built around OpenZeppelin Governor. OpenZeppelin’s security practices can be reviewed here.

Tally has developed open source staking contracts, which can be viewed on Github and read about on our docs. The public audit reports are listed here.

2b) Integration Requirements and Implementation Timeline

Tally has supported Compound governance since its inception in December 2020 and remains the longest continuously-operating DAO governance provider. No new integration work is required — Compound is already fully supported on Tally, with complete compatibility for Governor and its custom implementations. Our system imposes no constraints on future upgrades, requires no onchain proposals or contract changes, and is ready to continue serving the DAO without delay.

2c) On-chain/Off-chain Data Alignment and Proposal Verification

Tally is a modular application layer for viewing the state of and interacting with on-chain governance contracts. Our product is explicitly designed to match the on-chain state. We offer multiple tools to verify the information on our app matches the on-chain state, including Tenderly Simulations. We will soon display Seatbelt simulations. The calldata of every proposal can be reviewed prior to proposal creation and on the proposal page before voting.

2d) Developer Support:

Tally’s developer documentation is available at https://docs.tally.xyz, including integration guides, best practices, and reference materials for working with our APIs, SDK, and governance infrastructure. We provide hands-on developer support for partners, including dedicated support channels and direct engineering assistance.

Enterprise-level support is available to Compound as part of our enterprise support tier. Our self-serve tier is best-effort and community-supported, offering access to documentation and occasional help via public channels.

For any questions related to this proposal, please reach out to @coolhorsegirl on Telegram.

2e) Threat Modeling:

Many of the attack vectors listed in the prompt are relevant to Tally, including frontend injection, domain spoofing, calldata spoofing, supply chain attacks, and DDoS. More information is available about Tally’s security in our documentation. We are happy to discuss our security posture in more detail if delegates have specific questions.

Section 3: Commercial Terms & Commitment

3a) Budget Request

We are requesting a $150,000 USD budget for a 12-month enterprise engagement with Compound DAO.

This represents a discount from our typical $250,000 annual rate for enterprise support and custom development work, reflecting that we plan to contribute to future proposals in the Compound DAO including for staking and multichain governance. These two areas are out of scope for this service agreement and would be priced separately.

3b) Milestone-Based Payment Structure

Maintenance/Uptime:

• Uptime Guarantee: Maintain 99.9% uptime for frontend and API services on a monthly basis.
• Response Time SLA: Respond to critical support requests (e.g., governance outages or vote failures) within 4 business hours and resolve or escalate within 24 hours.
• Incident & Uptime Reporting: Publish a quarterly incident + uptime report covering response time, resolution details, and mitigation steps.
• Maintenance & Change Management: Notify the DAO at least 7 days in advance of any major platform changes (e.g., UI redesigns, vote transaction flow updates) that may affect governance participation.
  Bug Resolution Timeframes: Fix non-critical bugs within 5 business days; critical bugs resolved or mitigated within 1 business day.
• Monthly Feedback Loop: Host open office hours once per month for Compound contributors to raise issues or feature requests directly.

Usage/Adoption:

• Feature delivery by end of Q1 of this agreement (as shown in table in above section)
  • Advanced simulations specific to Compound contracts
  • Gasless voting
  • Custom domain
  • Karma integration
  • Tally Zero
  • Homepages for Compound Safe

Governance participation metrics are vulnerable to sybil attack. We recommend tying success to a broader set of product delivery and reliability metrics like customer satisfaction and the ones mentioned above in Maintenance/Uptime.

3c) Offboarding, Data Portability, and Sunset Plans

There are no constraints to using a new provider. Tally is a modular application layer built on open standards (Governor) and there is no dependency on Tally at the smart contract level.

For governance resilience, Tally also offers Tally Zero, a fully decentralized, read-only governance app and backup interface with live data sync, requiring zero reliance on Tally’s servers or backend. Tally Zero is an IPFS-hosted front-end that anyone can run to view proposals and cast votes directly on-chain via any Governor contract, ensuring that governance can continue uninterrupted even if the main Tally app is down. We plan to deliver this for Compound in the first quarter of this agreement.

Final Considerations

We believe Compound is best served by a partner who knows its history, is invested in its future, and can deliver on both.

Tally has supported Compound governance since 2020, when we built our platform on top of the Governor system introduced by Compound. We’ve served as Compound’s primary governance interface since then, providing ongoing support, infrastructure, and custom feature development. Formalizing Compound DAO’s relationship with Tally ensures continuity, a proven track record of support, and a product roadmap designed to evolve alongside Compound.

• Site: https://tally.xyz
• Docs: https://docs.tally.xyz
• Compound’s page on Tally: Tally | Compound

[1a35e1]

Given our diverse offering we decided to put our services forward to the DAO for consideration.

Lighthouse Labs as a VSP

General Overview

Company/Protocol Name and Brief Background:

Lighthouse Labs is a mobile-native governance platform designed to boost DAO participation and transparency by reaching users where they are: on mobile. We have been operating for three years as a legal company in the UK.

Our governance work extends beyond offering mobile voting solutions. As an applied research lab, we are committed to researching improvements and innovation in decentralised governance. You can find much of our work documented here

List Existing History with Compound Protocol/DAO:

As of March 2025, Compound governance is accessible on the Lighthouse governance app, including new proposal alerts and support for voting on Compound’s Snapshot space and Governor contract on Ethereum.

The average voter turnout on the last 20 governor proposals is ~45. We currently have 11% of this audience subscribed for Compound notifications on Lighthouse.

Section 1: Platform Functionality

1a) Platform Overview and Feature Set

We offer three key features:

Lighthouse Governance

We offer Compound DAO a unique distribution channel through our native iOS & Android app, which features real-time proposal tracking, push notifications, and seamless voting on both Snapshot polls and on-chain Governor proposals.

Our solution is biased towards a mobile user experience (UX), allowing COMP holders and delegates to vote, discuss, and stay informed anywhere, anytime, while maintaining robust on-chain infrastructure support (e.g. Safe multisig voting). We are also pushing for stronger Safe infrastructure.

It should be noted that we do not plan on focusing on proposal creation/execution in the near term. Existing vendors like Tally do a great job at this and it does not make sense to duplicate efforts.

Lighthouse Dispatch, For WG Leaders

We have a working messaging system we could freely offer to pilot with the DAO. This unlocks a secure manner in which DAO leaders can message key token holders.

Without Dispatch, there is no way to easily message Compound’s 200k+ holders. Our system saves users from having to reveal their email addresses to register, and our delivery platform has been purpose-built to reach users at scale.

In addition to proposals, DAO leaders or WG leads could have permissioned access to broadcast announcements, events or other notices to all DAO members. These messages could also be archived on-chain for ultimate transparency, laying the groundwork to establish a DUNA-compliant communications framework, aiding overall strategic objectives.

Signals Protocol

We have designed a brand new sensemaking protocol that addresses some of the biggest challenges DAOs face when trying to achieve community alignment. Signals is still under active development, which means that as a customer, Compound would be invited to help shape the design of the final product. Read more about it here.

1b) Service Tiers and Customization Levels

Lighthouse Labs will provide a modern, mobile-first governance service to Compound DAO.

We acknowledge that as a new vendor with a unique distribution channel, our approach may differ from other vendors. Our goal is to target those DAO members who would be particularly activated by the unique strategies our native mobile experience provides.

Our services under this agreement will include:

• Voting Service: We will continue to provide a best-in-class native mobile voting experience. Users receive real-time alerts ensuring no one misses critical votes.

  • We will add tailored alerts for key stages in the COMP governance lifecycle

• Priority Service: Our work spans many layers of the governance stack. As a paying customer, this means that for all ecosystem improvements we unlock through our R&D efforts, Compound DAO will receive priority access and customisation. Example projects include:

  • Safe Multisig voting on the latest Governor contracts
  • Concierge onboarding for COMP users
    • Buy COMP
    • Delegate COMP
    • Stake COMP
  • Delegate activation (smart notifications and UI)

• Delegation Campaigns: Delegation is core to Compound’s governance architecture. Instead of providing passive dashboards, we will explore ways to proactively encourage in-app delegation flows that will prompt users to assign or change their COMP voting power seamlessly, highlighting top delegates to improve governance engagement.

• Active Engagement and Communication: We commit to joining relevant community calls as needed for the duration of the engagement in an effort to share with members and delegates to discuss progress and gather feedback. We will operate closely with Compound’s Governance Working Group (GWG), Foundation or other providers to explore and refine quarterly priorities.

• Ongoing Maintenance & Custom Requests: As a Compound VSP, we will commit to maintaining 99%+ uptime for our service. We offer wide device support, including compatibility for older operating systems, which allows users with older or cheaper hardware to still access the application.

In summary, Lighthouse will provide Compound with a modern, feature-rich governance platform that improves UX, enhances community engagement, and upholds transparency and security. By leveraging Lighthouse, Compound can offer its participants a modern native mobile voting experience, including notifications, in-app voting and discussions, without having to build or maintain these products in-house.

Our expectation is a mutual agreement of collaboration to solve participation and engagement challenges.

1c) Existing Partnerships

We have a proven track record of collaborating with major DAO ecosystems: for example, we received a grant from SafeDAO to build the first ever native mobile implementation of Safe voting on Snapshot, pioneering a more secure and convenient way for treasury multi-signers to vote via mobile.

We recently contributed to ENS DAO’s governance tooling by building a custom interface and participating in protocol design for their Service Provider Program 2, for which we earned a retroactive grant.

We are also actively working on a new sensemaking protocol called Signals, which has received recognition (and financial awards) from Arbitrum and Uniswap Foundation.

Our work serves to uplift the ecosystem, all of which has a direct impact on aspects of Compound’s meta-governance initiatives. In the Safe/Bybit hack, we were the first team to highlight and propose a focus on decentralisation with Safe’s Transaction Relay which has become a key focus of SAFE’s OBRA Wave 2.

Our grant funding has been openly documented: Grants – Lighthouse Docs

Alchemix is also a fan, https://x.com/AlchemixFi/status/1929545288756445368 and we will be working with them in the near future on their v3 Governance.

We also have started meaningful dialogues with notable teams in the space such as Event Horizon, Butter and Gitcoin to field test some of our more advanced research ideas.

Section 2: Technical Integration and Security Assessment

2a) Audit History and Security Reviews

We are currency unaudited. However, we plan to obtain a SOC-2 and ISO 27001 audit once we raise sufficient funding. Based on our experience building enterprise systems and knowledge of PCI-DSS requirements, we operate isolated environments with limited access and everything is managed over terraform.

We would also be open to working with a trusted engineer from the foundation to assess our systems with the relevant agreements in place as part of due diligence.

2b) Integration Requirements and Implementation Timeline

• Compound is already supported on Lighthouse and up-to-date with the latest Governor contracts and Snapshot. You can download and use it now! Download App | Lighthouse

• Engaging with us will enable us to prioritise additional platform functionality and work through edge cases.

• We intend to complete the body of work documented over the duration of the agreement. We would communicate individual deadlines as needed via our Active Engagement and Communication mandate.

• As an agile, bootstrapped team, we are strategic in how we deploy our resources to maximise impact. For example, when we integrated the latest Governor upgrade we strategically had to omit historical compatibility with the previous two Governor versions.

We wish to be upfront about these choices as we are not VC funded, and our strategy at this time is to focus on new activations and campaigns instead of backwards compatibility.

Our systems already cater for many contract customisations, so we do foresee any particular challenges in accommodating future contract upgrades or requirements and are already at or above par with VC-backed offerings.

Our roadmap has built-in flexibility, ensuring that we can reprioritize features each quarter based on DAO feedback, while still delivering long term value to the DAO.

Any additional feature requests specific to Compound can be discussed with the community – minor features will be included in our service, while larger undertakings (e.g. a major new governance module) may need to be independently scoped in collaboration with the DAO. Our agile team is flexible and committed to evolving the platform in step with Compound DAO’s growth.

We are also more than happy to work with the CGWG to establish key priorities.

2c) On-chain/Off-chain Data Alignment and Proposal Verification

• For each Governor integration, we have integration tests which map on-chain data with our normalised schemas. Furthermore, we have been working on developing a standard to allow external parties to compute for themselves the data our API produces and compare it to on-chain data, however this is a long term, on-going project. For now, we include links to alternate providers (like Tally or Agora) to offer peace of mind.

• For Snapshot data, we rely upon the official Snapshot APIs.

• We can explore adding Tenderly transaction simulations to provide additional context for users who are considering a vote including an executable transaction, if this is a priority for the DAO.

2d) Developer Support:

• We do not have a developer platform, however we are more than happy to give legitimate Compound developers access to our indexers and/or code to support governance-related activity.

• We also have a history of meaningfully open-sourcing relevant work with full documentation and tests, as demonstrated with ENS and Snapshot.

• We are in the process of outlining a plan to allow other governance-focused developers to embed their unique work natively within Lighthouse, however this will be dependent on venture funding. If this sounds interesting to you, please reach out to me directly (Arnold, Founder and CTO) on Telegram via @x1a35e1.

2e) Threat Modeling:

We have specifically designed Lighthouse to act as a thin client on-top of Ethereum’s core cryptography. We use SIWE for all sessions and do not rely on emails or OAuth for identifying users.

This means the only surface area for attacks lies within the supply chain (external data sources, app stores, etc).

Communicating with users through proven technologies like APNS and FCM dramatically decreases risk compared to email or other communication channels, which are more prone to phishing attacks.

Threat	Likelihood	Cost to Exploit	Impact Severity	Mitigations In Place	Monitoring & Alerting Practices
Poisoned Binary	Low–Medium	High (requires app signing or account compromise)	Critical	Only manually signed builds released through official stores (App Store / Play Store).	Manual verifications. Limited App Store access.
Signing attacks	Low	High	Critical	We currently rely on Reown to securely connect and relay transactions with mobile wallets.	We monitor all transactions facilitated by our apps.
Man-in-the-Middle	Low	Medium	High	All app APIs use HTTPS with cert pinning. Tokens are encrypted at rest and in transit.	N/A
Poisoned Push Certificates	Low	Medium–High	Critical	Certs stored off disk and periodically rotated.Restricted access.	Reliant on Apple/Google.
Impersonation (User Sessions)	Medium	Low–Medium	High	Access tokens are issued using SIWE.	We monitor all transactions facilitated by our apps.

We are always open to suggestions and improvements in collaboration with the security council to improve our practices.

We employ an enterprise CI/CD pipeline with a robust set of E2E and unit tests. This allows us to catch any early conflicts in our isolated staging environment allowing us to move fast with peace of mind.

Section 3: Commercial Terms & Commitment

3a) Budget Request

• Given our stage of development and experimental nature of operations we are happy to extend a discount for our services so we can both grow and experiment in lockstep.

• We propose a $9500 USD per month commitment, for a total of $114,00 for the initial 12-month engagement. This is a 35% discount from what we would usually charge.

• We would cap any future renewal price increase to 30% as a good faith provision.

• We also request a nominal sum (TBD) to be determined by the CGWG to be strictly used for campaign incentives allocated to active voters at our discretion with oversight from the CGWG. This would be issued to a documented, isolated Safe for transparency.

3b) Milestone-Based Payment Structure

• We agree to meet and document the Platform Maintenance, Reliability, and Uptime KPIs requested.

• With regard to Governance Feature Usage, Impact, and Platform Adoption KPIs, as mentioned earlier, the average voter turnout on the last 20 governor proposals is ~45. With no Compound-specific marketing or outreach, we currently have 11% of this audience subscribed for notifications on Lighthouse.

• With a formal engagement, we would expect this to naturally increase. A conservative estimate would be a 100% increase per quarter.

• We like to set ambitious goals and work backwards. For example, how could we meaningfully activate and engage 0.01% of the holder base (~20k holders)? For context 7.3k users are following the COMP Snapshot space

• Our goal toward the end of this engagement period would be to meet and surpass these numbers giving Compound access to these users for the first time. Thus, we embrace a single north star metric of {n} users reachable.

We recognize that accountability is critical when a DAO entrusts a third party with important infrastructure.

We will maintain an open dialogue via the forum – posting regular updates and soliciting feedback. If at any point we fall short, we will work diligently (and publicly) to course-correct.

By adhering to these KPIs, Lighthouse aims to demonstrate measurable value: higher participation, robust uptime, timely delivery of improvements, and a well-informed community.

We are confident that our success can be transparently verified through these metrics, ensuring that Compound DAO’s engagement in Lighthouse as a VSP is continually justified by results.

3c) Offboarding, Data Portability, and Sunset Plans

• We would work with respective parties to explore all options for continuity.

• Everything we have designed will continue to work as a trustless system, so aspirationally the blockchain will be the historical data store.

• Commercial data such as push notification records, follow lists, open rates, etc, could be sanitized and exported for archival purposes.

• As mentioned above, one of our ongoing R&D projects is to ensure that core data such as voting activity and metadata can be indexed and archived in a well-known format. This will serve not only this purpose, but also aid ongoing academic research.

---

Lighthouse is excited about the opportunity to formally serve Compound DAO. Our mission is to make on-chain governance accessible and effective.

We look forward to working closely with Compound’s stakeholders to deliver a next-generation governance experience.

By supporting Lighthouse, Compound will gain a partner committed to innovation, community empowerment, and long-term transparency in governance.

We encourage all readers to download the Lighthouse Governance app and follow the Compound space to receive real-time push notification updates. Feedback welcome!

[PGov]

Hello @cylon, Thanks for the suggestions, and you raise some great points.

We have spun up a forum post here to formally authorize the CGWG to help facilitate and hosts RFPs for the community.

We see hosting RFPs as a way to steward governance discussions for the DAO and make things easily presentable to delegates. This should hopefully be a good starting point to get these RFPs standardized, and we also make sure to state that if teams like the foundation want to host RFPs in the future, we will happily work with them; by no means is this a sole power for the CGWG. Thanks!

[aurelianoB]

Snapshot proposal for Compound DAO RFP

We are excited to propose the integration of Compound Governor into the Snapshot interface. This will deliver a streamlined, end‑to‑end governance experience, encompassing proposal creation, voting and execution. Additionally, we will develop an organizational view to consolidate proposals from multiple protocols, including Snapshot offchain,Compound Governor and Discourse discussions.

General Overview

Company/Protocol Name and Brief Background:
Snapshot Labs, based in Switzerland, was established in 2020. We built and maintain Snapshot, the leading governance protocol, widely adopted by thousands of DAOs globally, including Compound DAO. Our entire stack is fully open source under the MIT license.

Snapshot uses gasless offchain voting, providing the lowest-friction experience with the highest customization and flexibility. Continuous feedback from leading communities lets us iterate fast and today, Snapshot drives governance processes for most DAOs (96%) and sees over 50k monthly active voters.

Our current roadmap is centered around unifying every governance vertical within Snapshot. We’re building a governance experience where community ideation, discussion, delegation, both offchain and onchain voting, and execution come together.

Existing History with Compound Protocol/DAO:
Compound DAO has utilized Snapshot’s voting protocol for approximately four years, generating roughly 2,600 votes over 13 proposals. Its Snapshot space currently counts 7,300 followers. The ongoing VSP selection will likewise begin its process on Snapshot. Throughout this time, we’ve been supporting Compound DAO on Snapshot at no cost.

Section 1: Platform Functionality

1a) Platform Overview and Feature Set

Snapshot proposes to integrate the Compound Governor protocol into our existing platform. Below is a detailed breakdown of current features and proposed enhancements:

Full Integration of Compound Governor Protocol [scope for new work]

• Complete lifecycle support for proposals including creation, voting, and execution
• Timelock integration with the ability to veto an execution directly within the interface

Proposal Creation and Management

• A robust draft system, allowing managing multiple drafts
• Full markdown support with image upload from the interface directly
• Visual editor, to create structured proposal without having to write markdown, author can choose between visual editor and markdown editor [scope for new work]

Execution

• Easily insert ERC-20 or NFT transfer(s) into a proposal
• Add custom transactions with ABI auto-detection using Etherscan API
• Visibility of transaction calldata within the interface
• Transaction simulation via Tenderly
• WalletConnect integration lets proposal author connect to dapps to populate transactions within a proposal.
• No‑code helper for up to 2 common onchain execution actions [scope for new work]

Treasury Management

• Track multiple treasuries, Timelock, Safe, on multiple chains, showing tokens and NFTs balances
• Wallet-like experience to send NFTs or ERC-20s from the treasury page and insert those transactions into a proposal

Voting Experience

• Gasless voting through Mana, our open-source meta-transaction relayer. We can also support OpenZeppelin relayers if required.
• Users can vote directly from the feed of proposals
• The proposals page displays status: active, succeeded/rejected or executed
• Proposal creators can link to a Discourse discussion, which will be shown within the proposal page on a dedicated tab
• Users can supply a reason with their vote
• A dedicated votes page offers sorting by time, choice, and voting power, and includes vote reasons
• AI summary of proposal

Delegate Dashboards and Delegation Tools

• Intuitive delegate dashboard, ranking COMP token delegates by voting power
• Personalized delegate profiles with DAO-specific statements
• Clear visibility of current delegate assignments
• Easily delegate or undelegate directly from the interface
• Leaderboard page ranking all voters by activity

Notifications and Alerts

• Snapshot will integrate with Zapier, enabling automated triggers for events such as proposal creation, start, end, or new votes. This will unlock integrations with over 8,000 apps, including Discord, Slack, Telegram, X (Twitter), Email, and Discourse [scope for new work]
• Ability for users to subscribe to email notifications for new proposals directly within the interface [scope for new work]
• Admin or malicious actions can trigger security-alert emails warning users of potential governance attack [scope for new work]
• Integrated with Domino and Push services for custom notifications

On-chain/Off-chain Interoperability

• Snapshot will develop an organizational entity feature to manage multiple voting spaces using different governance protocols, including Snapshot offchain and Compound Governor. This will offer a unified view of all proposals, streamlining governance workflows and reducing participation friction [scope for new work]
• From a proposal’s page, users will be able to see links to the whole governance flow, including discussion, offchain and/or onchain proposal and execution [scope for new work]
• Discourse discussions are integrated with a read‑only view directly in the interface

Custom Domain

• We support custom domains with custom logos and colors, e.g. https://signal.aave.com. Hundreds of DAOs already use this in Snapshot.

1b) Service Tiers and Customization Levels

As part of this proposal, Compound DAO will receive:

• Development of every new feature listed above
• Ongoing support for Snapshot’s offchain protocol
• SLA: 99.99% uptime.
• Dedicated users and admin support, including:
  • 24/7 basic support access with a response time average of 4mn,
  • dev-level technical support within 3 hours

Snapshot Labs also offers a service arm for custom developments, which can:

• Collaborate with a top-tier design agency to develop a custom frontend for Compound governance that aligns with Compound’s aesthetic. A dedicated quote for this effort can be provided upon request.
• Provide custom feature development not included in this proposal upon request.

1c) Existing Partnerships

Snapshot stands as the most adopted and recognized leader in governance solutions, serving thousands of DAOs and estimated by Messari and DeepDAO to cover 96% of the market.

Note that while many Snapshot proposals are non-executable, the platform already offers robust execution capabilities through integrations with UMA (oSnap) and Reality (SafeSnap). These integrations have facilitated 729 executable proposals, securing over $628 million in Total Value, demonstrating their relevance for use cases comparable to Compound.

Section 2: Technical Integration and Security Assessment

2a) Audit History and Security Reviews

There are no new contracts to audit as we will integrate existing Compound contracts already audited.

2b) Integration Requirements and Implementation Timeline

Smart Contract Compatibility
The proposed integration is fully compatible with the current Compound Governor contract

On-chain Proposal Requirements
Using the integration won’t require any onchain proposal, it will work seamlessly

Design Assumptions and Limitations
We will integrate fully with Compound Governor, there will be no limitations and the entire flow will be supported

Governor Compatibility and Upgrade Constraints
The integration will be fully compatible with Compound Governor, and it will support updates of the Governor settings via a proposal

Timeline:

• Integration of Compound Governor (4 weeks)
• Support unified organization view (6 weeks)
• Support for 2 custom execution UI helpers (2 weeks)
• Support for Zapier and email notification for users in our interface (1 week)
• Support for a visual editor (1 week)

We estimate the full integration will take approximately 3 months from DAO approval to launch, with some features developed in parallel. However, the service will be usable after the first month, offering complete Compound Governor support and Zapier integration for the governance flow. The organization view and remaining features will be implemented at a later stage.

Dependencies and Risk Management
Our integration relies on three core, open-source infrastructure components (MIT license), all of which can be run independently: an indexer, the interface, and a meta-transaction relayer. For redundancy, we operate multiple indexers. These services are bundled in a single, easy-to-run monorepo: https://github.com/snapshot-labs/sx-monorepo.

2c) On-chain/Off-chain Data Alignment and Proposal Verification

Our service ensures accurate data alignment and proposal verification through several key features:

• Transaction call data is fully visible within our interface.
• We utilize Tenderly for transaction simulation, allowing for a clear understanding of potential outcomes.
• Calldata is decoded using ABI information retrieved from the Etherscan API for readability.
• Should an execution be undecodable, our interface will display a warning. We also provide Zapier notification support for such scenarios.
• Our indexer can be run by external parties, enabling independent verification of execution authenticity.

2d) Developer Support

• Our documentation is available at https://docs.snapshot.box, and users can find support at our help center: https://help.snapshot.box.

• Support Availability and Tier-based Access:

  • Basic support 24/7 with a response time average of 4mn
  • Advanced technical support from our developers with a response time under 3h
  • Monthly calls to provide grant updates and gather feedback/feature requests.
  • A dedicated manager will be assigned to this project.

• Contact person is Guillem from Snapshot, available on Telegram @macondoDev or email guillem@snapshot.org

2e) Threat Modeling

We take security seriously and have identified these key attack vectors:

• DDoS attack - Mitigated through CloudFlare protection and multiple server instances
• Calldata spoofing - Prevented by transaction simulation via Tenderly, ABI verification and email notifications
• DNS hijacking - Protected through DNSSEC and ENS integration
• API abuse - Controlled through rate limiting

We maintain continuous monitoring with automated alerts.

Section 3: Commercial Terms & Commitment

3a) Budget Request

Proposed 12-month budget
We are requesting $80,000 for the comprehensive integration and implementation of the features described above, which will be made available to Compound DAO.

Long-term Financial Considerations
Use and support for the Governor integration will require a $6,000 annual subscription fee from the 2nd year onwards.

3b) Milestone-Based Payment Structure

We are requesting an initial payment of half of the total requested grant amount ($40,000) at the commencement of the project. The outstanding balance of $40,000 will be due upon the successful completion and delivery of the integration. We can accept payment in either stablecoin or COMP.

Platform Maintenance, Reliability, and Uptime KPIs:

• Maintain 99.99% frontend and API uptime on a monthly basis
• Respond to technical support requests within 3 hours
• Notify the DAO at least 7 days in advance of any platform upgrades affecting governance UI

3c) Offboarding, Data Portability, and Sunset Plans

• Should the DAO choose to discontinue its collaboration with Snapshot or cease the annual $6,000 fee, we commit to a 2-month grace period. During this time, we will provide support to any successor team to ensure a seamless transition.
• All data is accessible via our API, which anyone can operate.
• Snapshot is fully open source under the MIT license. Our core infrastructure, consisting of a static site, an indexer, and a meta transaction relayer, can be openly and independently run.
• The static site is pinned on IPFS and accessible at snapshot.eth.limo, and can also be downloaded for local operation.
• There are no vendor lock-in constraints, ensuring a smooth transition to new providers.

Final Considerations

Our goal is to enhance the governance experience by providing a unified interface that integrates Discourse discussions, offchain voting, onchain voting, and execution. This streamlined approach minimizes friction and promotes increased participation throughout the entire process.

Snapshot’s integration offers a smoother path with minimal migration effort and low security risk.. Being fully open-source under the MIT license, Snapshot promotes transparency and eliminates vendor lock-in for the DAO.

Our pricing model is designed for long-term collaboration, costing half of existing solutions in the first year and a significantly reduced fee thereafter. We firmly believe this proposal presents a practical and cost-efficient method for strengthening Compound DAO’s governance.

[AranaDigital]

This RFP has closed. Thank you to @nathanvdh, @coolhorsegirl, @1a35e1, and @aurelianoB for submitting proposals on behalf of your organizations. The CGWG will provide a summary of the responses shortly, outlining the different options that will move forward to the Snapshot stage, allowing delegates to review the choices prior to voting.

—CGWG