Intro
Staking the protocol token is a fundamental part of the ecosystem’s internal economy, we conducted in-depth research on the topic.
The goals of the instrument:
- Pull reserves to support fee distribution
- Keep a fair distribution of the fees among COMP stakers
- Integrate the instrument with existing governance mechanisms
We view these goals within a broader context. In addition to the core values and requirements outlined in the proposal, the COMP staking mechanism should:
- Discourage speculative activity around the COMP token and focus on strengthening the protocol’s underlying economy.
- Preserve the integrity of the existing governance system and ensure full compatibility with it.
- Maintain the integrity of the voting process by fully integrating staked COMP into it.
- Introduce modular and flexible design to enable customization necessary for its governing, management, and growth, seamlessly integrated with the protocol governance.
- Engage the community across multiple chains, while keeping Ethereum as the primary governance hub.
- Introduce automated fee distribution pipelines through a secure, reusable framework to eliminate the need for manual operations.
- Do not compromise the protocol’s security but deposit into it.
From our perspective, these goals are not only achievable but also contribute to strengthening the protocol by introducing automated pipelines and flexible management. However, designing such a system involves addressing several critical inflection points, which we will explore in the next section.
Main points to resolve
1. Liquid Staking vs Non-liquid Staking
The pros and cons of both approaches are known:
- Non-liquid staking is more secure as it creates no new value to manipulate with and it serves to secure the protocol and decrease the circulated liquidity;
- Liquid staking creates a synthetic value to work with as a derivative from staked value, and it gives a space for new instrument building, but on behalf of partly compromising the security of the protocol.
Therefore, the discussion centers on identifying the model that best fits Compound’s needs.
Should the protocol have stComp token as a derivative from staked COMP?
Minting a derivative or synthetic token as proof of a staked asset is a common practice in DeFi. However, it appears that introducing another token like stCOMP offers no clear benefits for Compound:
- COMP is a utility token that serves as a governance tool for the protocol. Therefore, additional tokens will create a “gray area” for the COMP, bringing a speculative aspect and contradicting the original goal of the staking instrument.
- stCOMP would not introduce any meaningful improvements to the governance model, particularly the voting process. The core architecture of the COMP token is already built around a delegation mechanism, which can be effectively leveraged even when COMP is staked and locked within the staking system—eliminating the need for a new token.
- Introducing an additional token effectively creates speculative liquidity equivalent to the staked amount, doubling the virtual supply without any additional underlying value. This could trigger a new wave of derivative products based on synthetic activity, increasing the risk of mass liquidations when these derivatives are unwound and converted back to the original assets.
- While wrapped tokens will lead to the LST modules building, it will also increase the complexity of retrieving COMP back from the staking.
- Security considerations - a new asset means a new attack vector on the protocol. In general, new asset support creates new risks associated with it.
However, the main concern lies in the separation between COMP’s voting power—which is tied to its built-in delegation mechanism—and its value, which would be transferred to stCOMP. This split not only introduces UX complexities in terms of token usage and vote tracking, but also undermines the utility of COMP as a governance token.
Recommendation: Avoid issuing an additional asset and instead adopt a non-liquid staking model
Why is non-liquid staking a better fit for COMP than liquid staking?
While the main reasons are already described in the previous point, we can summarize them in the next points:
- There is no need for LST, as COMP’s core function (voting and governance) is already fully supported by the existing governance architecture
- The LST approach compromises the utility of the token by creating a “gray area” that invites speculative behavior.
- LSTs deviate from the original purpose of staking, which is focused on fee distribution rather than liquidity.
- LSTs reduce protocol security by introducing new vectors for price manipulation and synthetic value creation around COMP.
- Non-liquid staking offers a more secure and aligned approach, helping to preserve COMP’s value and supply—key objectives of the new staking module.
Recommendation: Adopt a non-liquid staking model to avoid introducing additional assets or derivatives. While the community may choose to launch new assets or LST instruments in the future, doing so would require a carefully planned architecture to ensure alignment with protocol goals and maintain security.
2. Fees Withdrawal And Distribution Mechanism
One of the core requirements is the programmatic extraction of fees from reserves. Several key considerations should be addressed during implementation to ensure this mechanism is efficient, secure, and aligned with protocol objectives:
- Compatibility: Reserve management falls under governance and carries a high security profile—accumulated funds cannot be withdrawn without community approval. Therefore, the fee withdrawal mechanism must not only be compatible with the existing governance framework but also be strictly proposal-based.
- Automation: Fee extraction is expected to be a regular process, which calls for a degree of automation to eliminate time-consuming manual operations. The implementation should include an automated pipeline where proposals are generated, pre-filled with recommended or requested values, assessed for risk, bundled into transactions, and seamlessly submitted for governance voting.
- Re-usability: The pipeline for fee withdrawal proposals should be optimized for this specific task. However, since it is being developed to serve the broader needs of the community, it should be thoughtfully designed for reuse in future projects, ensuring flexibility, scalability, and long-term value.
- Built-in Recommendations: The selection of tokens and the amounts to extract as fees should remain a community-driven process, as curating this activity must not be centralized. However, it is valuable to regularly analyze the community’s current needs, the structure of reserves, and the overall state of the protocol’s economy. These insights can be shared as recommendations during pre-proposal discussions. While this approach requires additional tooling and enhancements to the pipeline, it offers well-informed guidance based on ongoing analysis, supporting more effective and transparent decision-making.
- Security Considerations: Every proposal, including routine fee withdrawals, must undergo a security review. Since the recommended proposal delivery system is based on an automated pipeline, security measures should be integrated directly into that pipeline. This includes mandatory transaction simulations, result analysis, preliminary risk assessments, and a thorough review of how the proposal would impact funds on the staking side. These built-in checks ensure the integrity and safety of each proposal before it reaches the voting stage.
- Risk Assessment: Since each proposal in the pipeline involves transferring funds—particularly to the staking contract—every operation must include a mandatory risk assessment. This assessment should evaluate the potential impact on Compound markets and the COMP token itself. The distribution of new fees acts as a stimulus, potentially encouraging new liquidity inflows and cyclic borrowing that can influence further COMP distribution. Conversely, it may also trigger increased COMP movement in response to fee incentives. Therefore, each new fee withdrawal proposal should be accompanied by a risk analysis tied to the specific economic stimulus it introduces.
Therefore, the new COMP staking mechanism should also include a dedicated delivery pipeline for submitting regular fee withdrawal proposals.
3. Choosing Reward Tokens
Avoid COMP Rewards
The goal of the staking mechanism is to prevent inflationary pressure on the COMP token. Therefore, rewards distributed through the instrument should not include COMP, preserving the token’s value and long-term sustainability.
Single vs Multiple Reward Tokens
Relying on a single reward token would require complex conversion procedures or the creation of multiple staking pools to accommodate different assets. While multiple reward pools are common in DeFi, they do not align well with the goals of COMP staking.
In contrast, distributing rewards in multiple tokens offers several advantages. It eliminates the need for mandatory swaps of reserves—an especially important consideration when certain tokens face liquidity constraints. This approach also reduces market pressure and mitigates the risk of manipulation during swap operations, enhancing overall protocol security.
Recommendation: Implement a single staking pool that distributes multiple reward tokens. This approach aligns with the core requirements, addresses key security considerations, and supports the overall goals of the COMP staking mechanism.
Mechanism of Rewards Choice
Q1: What is the initial list of reward tokens?
A: The initial list of reward tokens should include major blue-chip assets such as USDT, USDC, USDS, DAI, and WETH. These tokens are liquid, stable, and widely used across DeFi, making them well-suited for initial reward distribution.
Q2: Can the list of reward tokens be extended or modified?
A: Yes, the list of eligible reward tokens can and should remain flexible. There should be minimal restrictions on adding or removing tokens from the list, provided all changes are made through formal governance proposals.
Additionally, any proposal to modify the reward token list should include updated reward distribution rates for the newly defined set of tokens. These rate changes can be handled in batches, which is especially valuable from a security perspective during periods of market volatility.
Q3: How is the amount of rewards and distribution period determined?
This question also touches on the broader design of the staking reward structure:
Should staking deliver a fixed APY, or should it follow a variable, pool-based model typical in DeFi?
A:
- Update Frequency: It is recommended to update reward distribution rates on a quarterly basis. This allows sufficient time for proposal creation, discussion, and execution, while keeping the system adaptable to changing market conditions.
- Fixed APY vs Pool-Based Approach:
- A fixed APY model requires a dedicated backend to recalculate individual rewards, manage regular rebalancing, and trigger more frequent fund requests from the treasury as user participation scales.
- A pool-based approach sets APY dynamically based on the amount of COMP staked and the total rewards available in the pool. It is fully implemented via smart contracts, needs no backend maintenance, and adjusts naturally toward equilibrium. However, it is less resistant to whales and may require additional safeguards.
Recommended Approach:
The pool-based model is preferred due to its simplicity, alignment with common DeFi practices, reduced operational overhead, and minimal interaction with the treasury.
Determining Reward Amounts: The actual amount of rewards to be distributed on a monthly, quarterly, or other periodic basis should be decided through governance proposals. To support this, a recommendation mechanism should be developed using predictive heuristics that suggest optimal reward amounts for upcoming periods
Q4: What types of tokens should be allowed as rewards?
Should there be a curated allowlist, or should any token listed in the market and held in the treasury be eligible? At what point does a newly created, potentially volatile token become eligible for reward distribution?
A:
It is recommended to avoid a hardcoded allowlist of reward tokens—aside from a few core blue-chip assets (e.g., USDC, DAI, WETH)—to preserve flexibility. Reward assets should be addable or removable via governance proposals, allowing the community to evolve the reward structure without rigid constraints.
To prevent excessive changes or rushed decisions, the proposal structure should be limited to managing one reward token per governance cycle—either an addition or removal. This keeps the process transparent, deliberate, and easier to evaluate from a risk standpoint.
The curation of new reward tokens is entirely up to the community. While the proposal pipeline may include non-binding recommendations based on market analysis, treasury composition, and risk metrics, the final decision remains with the governance voters. This ensures a balance between informed guidance and decentralized decision-making.
4. Single chain vs Multi-chain
Q1: Should the staking mechanism be available on a single chain (and what) or on multiple chains?
A: The recommended approach is to keep staking on a single chain—Ethereum. This aligns with the fact that both Compound governance and the majority of COMP supply are based on Ethereum.
While this may initially lead to increased bridging of COMP from other chains, the market is expected to find an equilibrium over time, minimizing long-term liquidity migration.
Q2: How can reserves from other chains be utilized if staking remains on Ethereum?
A: The community should benefit from fees collected across all chains, even if staking is restricted to Ethereum. The proposed implementation includes the following principles:
- COMP staking will remain exclusive to Ethereum—no additional staking pools will be created on other chains.
- Rewards withdrawal across all chains should follow the same governance-based proposal process used on Ethereum.
- The existing governance and cross-chain proposal infrastructure should be extended to support multi-chain reward distribution.
To avoid protocol-initiated cross-chain transfers, the following architecture is recommended:
- New reward distribution contracts should be deployed on target chains.
- Users will be responsible for claiming rewards directly on those chains and managing any cross-chain transfers themselves.
- Foreign-chain fee distribution will be handled retrospectively, based on stakers with matured stakes on Ethereum during the distribution period.
This approach requires several components:
- A service to generate a Merkle Tree and include the Merkle Root in the proposal. So, users will claim their rewards based on Merkle proofs.
- Cross-chain governance mechanisms will deliver distribution instructions to the appropriate chain.
- Collected fees on foreign chains will be transferred to the respective distribution contracts.
Summary:
- Staking occurs only on Ethereum.
- Rewards from other chains are distributed via dedicated contracts.
- No protocol-owned cross-chain transfers.
- Users are responsible for claiming and moving their rewards.
- Distribution is based on Ethereum staking, tracked and processed via Merkle-based proofs.
Q3: How should reserves from other chains be bridged to Ethereum?
A: A: No bridging of reserves to Ethereum will be performed by the protocol. Instead, fees collected on each chain will be distributed locally. Users can then choose to transfer their rewards cross-chain at their own discretion. This approach avoids introducing protocol-level bridging risks and complexity.
Q4: Which chains and token reserves should be used?
A: While the proposal pipeline may provide recommendations, the final decision on supported chains and token reserves should be left to the community. WOOF! recommends starting with Ethereum as the primary chain and using the previously defined blue-chip tokens (USDT, USDC, DAI, USDS, WETH) as the initial reward assets.
Review of proposed solutions
veComp
The veCOMP concept has been proposed by the Aragon team as a general idea. While veTokenomics offers an innovative approach to governance token utility, it introduces several challenges and trade-offs that must be carefully considered in the context of Compound. These concerns fall into several key areas:
Emission Control and Utility Redesign
veTokenomics is fundamentally designed to control governance token emissions. In Compound’s case, adopting this model would go beyond the idea of fee distribution through staking, effectively reshaping the entire COMP emission and utility structure.
Such a shift would represent a global change in how COMP functions within the protocol, moving far beyond the scope of the current proposal.
Inflationary Pressure
veTokenomics relies on additional token emissions to incentivize participation. This would increase inflationary pressure on COMP, counteracting the current goal of preserving token value and avoiding new COMP rewards in staking.
Lock Duration Complexity
veTokenomics operates with long-term token locks. If the community demands shorter lock periods or more flexible staking, the ve-model loses its effectiveness and adds unnecessary complexity without delivering its full benefits.
Governance System Overhaul
The model introduces adjustable voting power based on lock duration, along with gauge-based voting mechanisms. Even if applied solely to COMP emissions and distributions, implementing this system would require significant changes to Compound’s governance.
Complexity from New Token (veCOMP)
veTokenomics requires the creation of a new, non-transferable token (veCOMP) to represent voting power. This adds complexity to supply tracking, accounting, and integration with other protocol components
Incompatibility with Multiple Rewards
veTokenomics frameworks do not support multiple reward tokens or require extensive modifications to do so. This is a significant limitation, as the proposed staking model for Compound is built around multiple token rewards and non-inflationary incentives.
NFT-Based Implementation Issues
Some veTokenomics systems use NFTs to represent locked positions, introducing further complexity:
- Liquidity tracking becomes harder and more fragmented.
- This can lead to liquidity fractionalization, complicating the analysis of staking behavior and governance dynamics.
Conclusion
While veTokenomics provides a robust framework for certain protocols, it introduces a level of structural, economic, and technical complexity that makes it unsuitable for Compound’s current goals—particularly in the context of non-liquid staking, preserving COMP value, maintaining governance stability, and supporting multiple token rewards.
Symbiotic
The Symbiotic approach (referenced in [1], [2]) proposes a modular staking structure built on the following components:
- Vaults for storing assets that receive rewards
- A middleware layer to manage and distribute rewards from these vaults
- A wrapped asset that grants stakers access to the middleware
While this architecture is commonly used across DeFi protocols, it introduces unnecessary complexity when applied to Compound’s specific needs and goals. Key issues include:
Misalignment with COMP’s Staking Objective
- The primary goal of staking in Compound is fee distribution, not yield farming or complex asset strategies.
- Since cTokens are already reward-bearing assets, vaults would need to be tuned specifically for cTokens rather than COMP.
- This would necessitate locking cTokens, potentially disrupting borrowing and liquidation mechanics and possibly requiring adjustments to the Compound core codebase.
Middleware and Wrapped Asset Complexity
- The middleware layer would require COMP to be locked in order for users to mint a wrapped asset that interacts with the system.
- This introduces an additional layer of complexity by requiring the development of interfaces for delegation and voting to maintain governance functionality for staked COMP.
- The introduction of wrapped assets brings back the earlier discussed issues around supply tracking, governance dilution, and user experience friction.
Limited Cross-Chain Flexibility
- The Symbiotic framework is not designed with cross-chain functionality in mind.
- To support multiple chains, the entire system would need to be replicated across chains, introducing governance fragmentation and operational overhead.
- This conflicts with Compound’s governance model, which is currently centralized on Ethereum and benefits from a unified decision-making process.
Conclusion
While the Symbiotic architecture is widely adopted in the DeFi ecosystem, its structure and technical requirements make it ill-suited for Compound’s staking mechanism. It introduces unnecessary complexity, risks interference with core protocol operations, and lacks the flexibility needed for cross-chain reward distribution.
Staker by Tally & Gauntlet
Proposals from Gauntlet and WOOF! suggest leveraging the Staker protocol as a foundation for implementing a simple, reliable, and non-liquid staking mechanism for COMP. This approach builds upon a well-understood and widely accepted model, aligning closely with Compound’s current architecture and governance design.
Features
- Non-liquid staking of COMP, directly locking tokens into the protocol while maintaining alignment with existing Compound voting mechanisms.
- Focus on protocol reserve distribution, avoiding any changes to COMP emission or introducing inflationary effects.
- Ethereum-centric design, reinforcing the current governance structure without fragmenting decision-making across chains.
- Support for multi-chain rewards, with the ability to include reserves from other chains while keeping staking strictly on Ethereum.
- No new asset required, preserving clarity in token supply, reducing governance complexity, and minimizing attack surfaces.
- Full integration with Compound’s existing governance framework, maintaining continuity and reducing implementation friction.
Limitations & Required Adjustments
While Staker offers a solid foundation, several technical modifications will be necessary to align it fully with Compound’s staking goals:
- The default implementation is designed for a single reward token. To support Compound’s multi-token reward model, Staker must be extended to manage multiple reward streams.
- Improvements are needed to handle operational scenarios such as:
- Halting reward distribution when balances are insufficient.
- Updating or replacing the notifier module responsible for feeding reward information to the contract.
- Reward logic must shift from rate-per-block-based distribution to amount-based distributions triggered by proposals, ensuring alignment with governance-controlled treasury withdrawals.
Architectural Strengths
Despite the above limitations, Staker brings important architectural flexibility:
- It already supports various delegation and voting power models, making it highly adaptable to Compound’s needs.
- Its design accommodates custom notifiers, which simplifies integration of governance-based reward distribution mechanisms.
- Crucially, Staker does not require any changes to the Compound core codebase, making it the least invasive option from a protocol governance and security standpoint.
Conclusion
The Staker presents the most balanced and viable solution for implementing COMP staking. It satisfies the core requirements—non-inflationary, governance-aligned, Ethereum-focused, and secure—while maintaining full compatibility with Compound’s architecture. With a few targeted modifications to support multi-token rewards and amount-based distribution, Staker can serve as the foundation for a robust, sustainable, and community-driven staking module.
Proposed Improvements
From WOOF!'s perspective, the approach outlined by Gauntlet and Tally provides a strong foundation, and WOOF! fully supports the use of the Staker as the primary direction for COMP staking implementation. However, we propose an extended version of the Staker approach, tailored specifically to meet the needs of the Compound ecosystem.
WOOF!'s proposal goes beyond a basic staking mechanism by introducing a comprehensive architecture that includes:
- A generalized reserve withdrawal mechanism, structured as a secure, automated pipeline fully compatible with Compound’s existing governance system and built strictly around the proposals logic.
- Multichain support, enabling the protocol to handle and distribute rewards across all chains where Compound is deployed.
- A suite of supporting tools, including:
- UI components for user interaction.
- Reserve tracking mechanisms.
- Allocated rewards monitoring.
- Analytics and reporting dashboards.
A fully integrated solution stack, covering:
- Infrastructure
- On-chain components
- Backend services
- Frontend applications and user interface
Proposal-Based Reward Distribution Pipeline
WOOF! strongly advocates for a proposal-based approach to reward distribution, implemented via a reusable and extensible delivery pipeline. This system will:
- Enable structured, secure reward releases.
- Facilitate governance participation.
- Serve as a foundation for future protocol features that rely on proposal-based execution.
Proposed Enhancements to the Staker
To align Staker with Compound’s needs, WOOF! proposes the following technical improvements:
- Multi-token reward support to align with the non-inflationary, multi-asset reward model.
- A new notifier module capable of tracking the exact amount of rewards transferred, removing the need for ongoing management of
rewardPerToken based on availability.
- A distribution completion mechanism to automatically conclude rewards disbursement, avoiding the need for manual intervention.
- Oracle integration for real-time dollar value calculations across multiple reward tokens, improving transparency and analytics.
Multichain Rewards Pipeline Implementation
WOOF! also proposes the integration of a multichain rewards pipeline as outlined in the research. Key components include:
- Additional distribution contracts deployed on target chains, with COMP staking remaining strictly on Ethereum.
- Utilization and adaptation of existing multichain proposal infrastructure.
- Integration of cross-chain proposal delivery into the automated governance pipeline, ensuring secure and reliable reward distribution on each supported chain.
Conlusion
The proposed improvements by WOOF! aim to build a robust, flexible, and secure staking infrastructure for Compound, rooted in proven protocols but extended to meet the protocol’s long-term goals. By focusing on compatibility, composability, and governance-first design, this solution ensures a non-inflationary, decentralized, and future-proof approach to COMP staking.
Outro
The WOOF! team has conducted a comprehensive analysis in response to the community’s request for implementing staking functionality for COMP. This included a deep dive into the proposed requirements, the intended goals of the staking instrument, and an evaluation of multiple approaches. We assessed key architectural considerations, security implications, long-term scalability, and potential challenges that may arise.
Based on this research, WOOF! recommends adopting the Staker architecture as the foundation for COMP staking. This approach avoids the introduction of new derivative assets and maintains Ethereum as the home chain for staking operations, aligning with Compound’s governance and token distribution model.
In addition, WOOF! proposes the following contributions:
- A secure, proposal-based pipeline for reserve withdrawal and rewards distribution
- UI dashboards for reserve tracking and distribution transparency
- Integrated risk assessment and security tools, developed in close collaboration with Gauntlet
- All necessary on-chain adjustments to support the staking module
- Full integration with Compound’s existing voting and delegation system
- Development of all required backend services, infrastructure, and user interface modules
- Ongoing maintenance, support, and enhancement of the staking framework
WOOF! is confident in the long-term value of a well-designed staking module and is fully committed to addressing the outlined challenges, delivering a secure, efficient, and governance-aligned solution for the Compound community.
Next Steps
- Community feedback and prioritization
- Requirements formalization
- Snapshot voting
