An overview of the primary frameworks that define how decentralized lending protocols manage upgrades, parameter changes, and treasury allocation.
LABS
Guides
Governance in Lending Protocols
Chainscore © 2025
core_models
Core Governance Models
01
Token-Based Voting
Governance tokens grant proportional voting power. This is the most common model, where one token equals one vote.
- Proposals are created and voted on by token holders via on-chain or off-chain signaling.
- Example: Aave and Compound use this for adjusting collateral factors and listing new assets.
- This aligns control with economic stake but can lead to voter apathy and whale dominance.
02
Delegated Voting
Token holders delegate their voting power to representatives or experts who vote on their behalf.
- Delegates create public platforms explaining their stance on protocol issues.
- Example: Many Uniswap and Compound token holders delegate to known community members or institutions.
- This improves participation and decision quality but introduces principal-agent problems.
03
Multisig & Council Models
A multisignature wallet or elected council holds executive power for time-sensitive or technical upgrades.
- A small group of trusted signers can execute approved proposals without a full token vote for every action.
- Example: Early MakerDAO used a Maker Foundation multisig; some protocols have security councils for emergency pauses.
- This enables agility but centralizes critical power in a few entities.
04
Futarchy
Governance via prediction markets where decisions are evaluated based on their predicted impact on a key metric.
- Markets are created for and against a proposal; the outcome with the higher predicted token price is implemented.
- Proposed for complex decisions like major economic parameter changes in protocols like DXdao.
- This aims for meritocratic outcomes but is complex to implement and susceptible to market manipulation.
05
Conviction Voting
A continuous voting model where voting power accrues over time as tokens are staked on a proposal.
- Users signal preference by depositing tokens; influence grows the longer tokens remain committed.
- Used primarily for decentralized grant funding, such as in Aragon's ecosystem.
- This favors long-term, high-conviction ideas and reduces proposal spam, but can be slow for urgent decisions.
06
Liquid Democracy
A hybrid model combining direct and delegated voting, allowing voters to delegate votes per topic.
- A user can vote directly on one issue while delegating their vote on another issue to a specialist.
- This model is explored in blockchain governance research and by some DAOs for its flexibility.
- It enables nuanced representation but increases system complexity and interface design challenges.
The Governance Proposal Lifecycle
Process overview
1
Draft and Temperature Check
Formalize the idea and gauge initial community sentiment.
Detailed Instructions
Begin by drafting a formal proposal document, typically using a Governance Forum like Commonwealth or the protocol's dedicated forum. This draft should clearly articulate the problem statement, proposed solution, and any required on-chain actions, such as parameter adjustments or smart contract upgrades. Include a preliminary analysis of potential risks and impacts on protocol metrics like utilization rates or reserve factors.
- Sub-step 1: Post the draft proposal to the designated forum for discussion.
- Sub-step 2: Solicit feedback from delegates, core contributors, and the broader community.
- Sub-step 3: Run an informal temperature check poll to measure initial support before proceeding to a formal vote.
markdown**Proposal Title:** Increase ETH LTV from 80% to 82% **Summary:** Proposal to adjust the Loan-to-Value ratio for the ETH market to improve capital efficiency. **Forum Link:** governance.protocol.xyz/t/proposal-123
Tip: A successful temperature check typically requires a simple majority (>50%) of participating voting power to proceed.
2
On-Chain Proposal Submission
Deploy the finalized proposal to the governance smart contract.
Detailed Instructions
Once community feedback is incorporated, the proposal must be submitted on-chain. This requires a proposer to hold a minimum proposal threshold of governance tokens (e.g., 65,000 COMP, 100,000 AAVE). The submission involves calling the propose function on the governance contract, which creates a new proposal ID and starts the voting delay period.
- Sub-step 1: Ensure the proposer's wallet holds the required token balance and has delegated voting power to itself.
- Sub-step 2: Encode the target contract addresses and calldata for the proposed actions (e.g.,
Comptroller._setCollateralFactor). - Sub-step 3: Execute the transaction, paying the associated gas fees, and record the returned proposal ID for tracking.
solidity// Example for a Compound-style governor function propose( address[] memory targets, uint[] memory values, string[] memory signatures, bytes[] memory calldatas, string memory description ) public returns (uint256 proposalId);
Tip: The voting delay is a fixed period (e.g., 1-2 days) where delegates can review the final proposal before voting begins.
3
Active Voting Period
Token holders cast their votes for or against the proposal.
Detailed Instructions
After the voting delay, the active voting period begins, typically lasting 3-7 days. During this window, governance token holders (or their delegates) must cast their vote. Votes are weighted by the voter's voting power, which is a snapshot of their delegated token balance at the start of the block when the proposal was created. Most protocols use a binary For/Against system, though some include Abstain.
- Sub-step 1: Voters connect their wallet to the protocol's governance UI or interact directly with the
castVotefunction. - Sub-step 2: Review the proposal details and the vote differential (current For vs. Against totals).
- Sub-step 3: Submit the transaction to record the vote on-chain, which is immutable for the proposal's duration.
solidity// Casting a vote on-chain IGovernor(governorAddress).castVote(proposalId, support); // `support` = 1 for For, 0 for Against
Tip: Voting power is often non-transferable during the voting period to prevent manipulation via token buying/selling.
4
Quorum and Vote Execution
Assess if the proposal passed and execute its on-chain actions.
Detailed Instructions
Once the voting period ends, the proposal's outcome is determined. Two key thresholds must be met: the quorum (minimum total voting power participation) and a majority of votes cast in favor. For example, a proposal may require a quorum of 400,000 votes and a simple majority (>50%) of For votes. If these conditions are satisfied, the proposal state changes to Queued.
- Sub-step 1: After a successful vote, the proposal enters a timelock period (e.g., 2 days), allowing users to react to the passed changes.
- Sub-step 2: After the timelock expires, any account can call the
executefunction on the governance contract. - Sub-step 3: The execute transaction sends the encoded calldata to the target contracts, implementing the proposal's changes.
solidity// Executing a successful proposal IGovernor(governorAddress).execute( targets, values, calldatas, descriptionHash );
Tip: The timelock is a critical security feature, providing a final window to identify critical issues before code execution.
Key Protocol Parameters Under Governance
Comparison of core adjustable parameters across major lending protocols.
| Governance Parameter | Compound v2 | Aave v3 | MakerDAO |
|---|---|---|---|
Maximum Loan-to-Value (LTV) Ratio | 75% (ETH) | 80% (ETH) | 90% (ETH-A) |
Liquidation Threshold | 80% (ETH) | 82.5% (ETH) | 100% (ETH-A) |
Liquidation Penalty | 8% | 5% | 13% |
Reserve Factor | 15% (USDC) | 10% (USDC) | Stability Fee (DSR: 5%) |
Collateral Factor (Risk Weight) | Variable by asset | E-Mode categories (e.g., 97% LTV for correlated assets) | Debt Ceiling per Vault Type |
Interest Rate Model | Jump Rate Model (kink at 90% utilization) | Optimal Interest Rate Model (variable kink) | Stability Fee (set per collateral type) |
Governance Voting Delay | 2 days | 1 day | 0 days (Executive Votes) |
Governance Voting Period | 3 days | 3 days | 3 days |
Roles and Responsibilities in Protocol Governance
Understanding Governance Participants
Governance in lending protocols like Aave or Compound is the process by which stakeholders make collective decisions. It is not controlled by a single entity but by a decentralized community holding governance tokens.
Key Roles
- Token Holders/Voters: These are users who own the protocol's governance token (e.g., AAVE, COMP). Their primary responsibility is to vote on proposals that change the protocol, such as adjusting interest rate models or adding new collateral assets. Voting power is typically proportional to the number of tokens staked or delegated.
- Proposers: Any token holder who meets a minimum token threshold can submit a formal proposal for a protocol change. This requires creating a detailed specification and often involves community discussion on forums like the Aave Governance Forum before an on-chain vote.
- Delegates: Token holders who do not wish to vote directly can delegate their voting power to a trusted community member or expert who will vote on their behalf, increasing voter participation.
Example Process
When a user wants to propose adding a new stablecoin as collateral to Compound, they must first gain community support on the forum, then submit an on-chain proposal. COMP token holders then vote, and if the proposal passes, it is queued and executed by the protocol's Timelock contract after a delay.
token_mechanics
Governance Token Mechanics and Incentives
A technical breakdown of how governance tokens function within lending protocols, detailing their distribution, utility, and the economic incentives that drive protocol participation and security.
01
Token Distribution & Vesting
Initial distribution models like liquidity mining, airdrops, or private sales. Tokens are often subject to vesting schedules or lock-ups to prevent immediate sell pressure.
- Linear or cliff-based vesting for team and investors.
- Liquidity mining rewards distributed over epochs.
- This ensures long-term alignment of stakeholders with protocol health.
02
Voting Power & Delegation
Governance rights are typically proportional to token holdings. Vote-escrowed models (veTokens) lock tokens to boost voting power.
- Users can delegate voting power to experts or representatives.
- Snapshot voting for gas-free off-chain proposals.
- This system concentrates influence among committed, long-term holders.
03
Fee Sharing & Revenue Capture
A core incentive is direct protocol revenue distribution. Holders may receive a share of interest spreads, liquidation fees, or other income.
- Fees can be distributed as stablecoins or the native token.
- Some protocols use buyback-and-burn mechanisms.
- This transforms the token into a yield-bearing asset, creating a value accrual flywheel.
04
Collateral & Utility Integration
Tokens can be used as collateral within the protocol's own lending markets, often with favorable risk parameters.
- May have a higher collateral factor or lower liquidation penalty.
- Can be staked in safety modules to backstop protocol insolvency.
- This utility increases demand and integrates the token deeply into the protocol's economic security.
05
Incentive Alignment & Bribing
Bribe markets emerge in veToken systems, where protocols offer incentives to token holders to direct governance votes (e.g., gauge weights for liquidity).
- Platforms like Votium or Hidden Hand facilitate this.
- Creates a secondary income stream for lockers.
- This mechanism aligns liquidity provision incentives with governance outcomes.
06
Governance Attack Vectors
Understanding risks like proposal spam, vote buying, and 51% attacks is critical. Economic design must mitigate these threats.
- Quorum requirements and timelocks delay execution.
- Delegation can reduce voter apathy and centralize defense.
- These mechanisms protect the protocol from malicious or short-sighted governance actions.
Governance Risks and Attack Vectors
A governance proposal attack involves a malicious actor submitting a proposal that appears beneficial but contains hidden, harmful code. The attacker often uses a flash loan to temporarily acquire enough voting power (governance tokens) to pass the proposal. The malicious payload is typically embedded in the proposal's executable calldata, such as a function call to upgrade a contract to a malicious implementation or drain funds from a treasury. For example, an attacker might propose a routine parameter update that also includes a call to transferOwnership() of a critical contract to an attacker-controlled address. Voters must audit the full bytecode of any proposal, not just its description.