Liquity V2 Governance Explained

Who is this article for

This article is for those studying the next piece about fuzzing this contract, and it's also useful for anyone wanting to understand the governance system and how Liquity V2 governance works.

Liquity V2 Overview

Before diving into Liquity V2 , let's first get a summary of what Liquity V2 is all about.
Liquity V2 is a decentralized finance (DeFi) system. It is a lending and borrowing protocol. Users can borrow BOLD tokens against WETH and ETH. Borrowers have the freedom to set the interest rate for their loans. When users repay the loan with interest, 75% of the funds go to the stability pool and 25% is allocated to the protocol for stakeholders to invest in the initiative.

---

Liquity V2 and BOLD Explained

Here is a brief overview of the core Liquity V2 lending and borrowing protocol, which is the next version of the Liquity V1 protocol.

• It introduces a new stablecoin called BOLD, which is linked to the USD, meaning 1 BOLD equals 1 USD.

• Just like Liquity V1 had LUSD, V2 will have BOLD, backed by ETH.

But here’s the challenge:
When a new stablecoin like BOLD is launched, it needs liquidity on decentralized exchanges like Uniswap or Curve to be useful (people need to be able to buy/sell it easily).

This is where PIL (Protocol Incentivized Liquidity) feature of the protocol comes in.

1. Liquity V2 Explained With Real World Analogy

   To better understand how Liquity V2 works, let’s imagine a traditional banking system, but with a decentralized twist.

   In a traditional bank:

   • You walk in with gold or other assets as collateral.

   • The bank assesses your collateral and gives you a loan in fiat currency (like $ USD, ₹ INR).

   • You agree to repay the loan with interest.

   • The interest you pay gets distributed to lenders (people who deposited money in the bank) and bank stakeholders(owners, employees, investors, etc.).

Now let’s map this onto Liquity V2:

• Instead of walking into a bank, you interact with a smart contract.

• You deposit ETH or WETH as collateral.

• The smart contract gives you a loan in BOLD (a stablecoin pegged to USD).

• But in Liquity V2 you have authority to decide the interest rate you're willing to pay.

• When you repay the loan, the funds are distributed, and the interest get split into two parts:

  • 75% goes to stability pool (analogous to the bank’s depositors).

  • 25% goes to the Liquity V2 Governance System, which acts like the bank's stakeholders. This portion is used to fund public goods or initiatives that support the protocol.

Note:
In Liquity V2, interest on loans doesn’t accrue and get distributed only when you repay the loan. Instead, it accrues continuously over time and is compounded (added to your debt and minted as BOLD) only when you interact with your Trove like depositing collateral, adjusting your interest rate, or repaying. This interest is then automatically split between the Stability Pool and Governance.

If you're curious, check out this article for a deeper explanation of how interest accrual and minting work in Liquity V2 or even if you want to learn more about Liquity V2.

But here’s the challenge:
When a new stablecoin like BOLD is launched, it needs liquidity on decentralized exchanges like Uniswap or Curve to be useful (people need to be able to buy/sell it easily), that’s where 25% of marketing or PIL is allocated.

2. Where Does This Marketing Budget (PIL) Come From?

   Just like a bank earns interest and allocates part of it to expanding services or marketing, Liquity V2 collects interest from borrowers and uses 25% of it to fund liquidity efforts and growth initiatives.

   That interest is split:
   a. 75% → of revenue goes to Stability Pool rewards.

   b. 25% → of revenues is given to governance, where LQTY holders decide how these funds are used.

   This means that as long as users continue borrowing BOLD, the PIL mechanism remains sustainably funded through interest payments.

In this section, we'll understand how the 25% of funds are allocated using the governance system.

---

Liquity V2 Governance Flow

Overview

Now that we've understood how Governance contract is funded, let’s look at how these funds are distributed—enter Liquity’s governance.

At this juncture, the allocation of the 25% is where the governance of Liquity V2 comes into play, which is the central focus of this article.

The 25% is distributed to initiatives that promote the development and adoption of Liquity V2 and the BOLD stablecoin.

The allocation of the 25% is determined through a voting and vetoing system, employing a democratic principle with certain limitations. These limitations will be explored in detail in this article.

1. Who can vote on these initiatives ?

   LQTY holders can stake their tokens in the governance contract and receive voting power. This allows them to:

   • Vote for initiatives they support.

   • Veto for initiatives they oppose.

2. What is voting power and how is it calculated ?

   Voting power represents the influence you have on the protocol, which depends directly on two factors.

   • Amount of LQTY staked

   • Duration of staking

It is calculated using a simple formula: VP = Quantity of LQTY Staked x Time it is Staked for.

As depicted in the image provided by Liquity V2, users when stake LQTY the voting power increases with time.

Since there is no lock-up period for users who have LQTY staked in the governance contract, LQTY stakeholders can withdraw at any time, and their voting power will decrease proportionally.

3. Who can create proposals ?

   Anyone with enough voting power can propose initiatives.

4. How does voting work and how long does voting last ?

   Once the proposal is created, then in the upcoming week is put for voting.

   • First 6 days: Users can vote and veto Initiatives.

   • Last day: Only vetos are allowed (to prevent last-minute manipulation).

   • At the end of the week, votes are counted, and rewards are distributed to qualifying Initiatives.

   • Now voting/vetoing process last for 7 days which is equal to 1 Epoch.

5. Bribe feature of the contract

   In the protocol’s bribery feature, external parties may engage in bribery of LQTY stakers to influence their voting decisions in favour of specific initiatives. Upon the initiative’s success, users who have cast their votes in support of the initiative will be entitled to a proportion of the bribe, which is directly proportional to the voting power allocated to that initiative for its victory.

6. What Are the Rewards for LQTY Stakers?

   LQTY stakers earn rewards by:

   • From Liquity V1: LUSD and ETH rewards.

   • From Liquity V2: Voting power and influence over PIL allocation.

   • Receive bribes from external initiatives.

This creates a synergy, users continue to benefit from V1 while actively participating in V2.

7. Governance Contract Summary

   • Governance Fund Allocation: 25% of funds are allocated to governance.

   • Staking LQTY Tokens: Users stake their LQTY tokens to become stakers.

   • Voting Power Increases Over Time: The longer you stake, the more voting power you accumulate.

   • Proposal Registration: Anyone can create and register initiatives with sufficient voting power.

   • Proposal Unregistration: Users can also unregister the initiatives that have been created or initiatives could be unregistered if they receive vetos in a single epoch or not enough votes for 4 epochs.

   • Unstaking LQTY Tokens: Users can unstake their LQTY tokens, and their voting power will be decreased proportionally there is no lockup mechanism in the protocol.

In the next section, we will explore the technical details of the smart contract. We will understand the important state variables and functions used in the Governance smart contract.

---

Governance Smart Contract Details

Overview

In this section, we explore the inner workings of the Liquity V2 governance smart contract. It is divided into three key parts:

In this section, we will explore only the important functions and state variables of the Liquity V2 governance smart contract, which could broadly be divided into three categories:

• A. State Variables – These are the core configuration parameters that define how voting power is calculated, when initiatives are registered/unregistered, how rewards are distributed, and more.

• B. Initiative States – These are the different lifecycle stages an initiative can transition through (like WARM_UP, CLAIMABLE, or DISABLED) depending on governance participation and protocol-defined rules.

• C. Governance Functions – These are the actual functions in the contract that users interact with: depositing LQTY, registering initiatives, allocating votes, claiming rewards, and more.

Understanding these components is essential for grasping how proposals are managed and how governance ensures fair distribution of BOLD.

A. State Variables

1. REGISTRATION_FEE

   • Meaning: This is the fee required to register a new initiative is paid in BOLD tokens.

   • Purpose: It acts as a spam prevention mechanism only serious proposals should be submitted.

2. REGISTRATION_THRESHOLD_FACTOR

   • Meaning: This establishes the minimum percentage of total voting power required for a user to register an initiative. The threshold is dynamic, calculated by multiplying the total number of votes received by the winning initiative in the preceding epoch by the REGISTRATION_THRESHOLD_FACTOR.

   • Purpose: To ensure that users with a minimum voting power are only permitted to register initiatives. This measure is necessary to prevent new stakeholders with limited voting power from overwhelming the system with initiatives.

3. UNREGISTRATION_THRESHOLD_FACTOR

   • Meaning: This establishes the minimum voting power threshold that an initiative must attain in a specific epoch to be permanently removed from voting.

   • Purpose: If stakeholders believe that an initiative is not in accordance with protocol, they can vote against it. If there is an initiative so bad and if the initiative receives the minimum unregistration threshold voting power factor, it will be permanently removed from voting and hence be unregistered forever.

4. UNREGISTRATION_AFTER_EPOCHS

   • Meaning: An initiative fail to gain traction for 4 consecutive epochs than it is automatically unregistered.

   • Purpose: Prevents instant removal of underperforming initiatives and allows time to gain support.

5. VOTING_THRESHOLD_FACTOR

   • Meaning: This state variable establishes the minimum voting power required for an initiative to be considered for winning.

   • Purpose: Consider a theoretical analogy, an election scenario with total 100 voters and two parties, Democrats and Republicans. Out of the 100 voters, only 1 casted a vote for Democrats and 99 other voters didn't even cast the vote. While this may be interpreted as a fair and square victory for the Democrats, but it raises concerns about the lack of participation.

     To ensure a more representative outcome, we determine that at least 40% or 50% of the total votes must be cast for a party to win the election.

     Similarly, in the Liquity V2 protocol, an initiative must receive a minimum voting power equal to at least 40% or 50% (in our case we take 0.04e18 % of total voting power) of the total voting power combined from all users to be considered for victory during a epoch.

     Similarly, in the Liquity V2 protocol, an initiative requires a minimum number of votes based on the previous epoch.

     For instance, if 100 voting power was casted in the previous epoch, at least 2% or 4% of the voting power should be casted in the current epoch. See this is why this is required because staked LQTY earns voting power that grows linearly over time, and thus the total votes per epoch will tend to increase in the long-run than so should the voting threshold factor for an initiative to win.

Default: If an initiative fails to meet the voting power requirement, the 25% of funds are rolled over to the next epoch.

6. MIN_CLAIM

   • Meaning: Minimum BOLD amount that must be claimed if an initiative lacks sufficient votes to meet the requirement.

   • This state variable is set to zero, so it’s doesn’t play any crucial role in the smart contract.

7. MIN_ACCRUAL

   • Meaning: The governance contract now receives 25% of the BOLD funds from the core protocol (Liquity V2) to transfer BOLD to the winning initiative. For this to occur, a specific amount of BOLD funds must be received.

     Now let's understand this with an example. Suppose in the first week, the governance contract receives 25% of the BOLD funds, which is 2000 BOLD tokens. At the end of the week, the winning initiative will receive 2000 BOLD tokens.

     In the second week, the 25% is transferred to the governance contract, but this 25% is reduced to 10 BOLD tokens. So, at the end of the week, if an initiative wins, it will only receive 10 BOLD tokens.

     This arrangement may not be fair, so a minimum amount should be received by the winning initiative, right !!. Therefore, if the funds accured are less than a certain amount, then that amount is rolled over to the next epoch.

8. EPOCH_DURATION

   • Meaning: It is the duration of one voting epoch.

   • Value: 604800 seconds = 1 week

9. EPOCH_VOTING_CUTOFF

   • Definition: This is the deadline for voting in the current epoch, after this point only vetoing will be available.

   • Value: 518400 seconds = 6 days.

B. States In Which The Initiative Could Be

• NONEXISTENT: An initiative is created but has not been registered to the governance contract. Now only action that this initiative address could perform is, it can only register on the governance contract.

• WARM_UP: An initiative has been registered in this epoch and will be able to vote and veto in the next epoch.

• SKIP: This default condition arises when other conditions are not met, allowing users to vote and veto. It also occurs when an initial initiative has been registered by the owner and those initiative don't have to pass through the WARM_UP phase. In this state, the initiative cannot be claimed nor unregistered.

• CLAIMABLE: If the initiative wins, which depends on the voting threshold established based on the previous epoch and the number of vetoes received, the Initiative is eligible to claim BOLD rewards. Voting and veto allocation and deallocation are still possible.

• CLAIMED: The initiative has been claimed in this or previous epoch, and voting and veto allocation and deallocation are still possible.

• UNREGISTERABLE: An initiative becomes unregisterable or permanently removed when two scenarios are met

  • when it has been in the SKIP (limbo state) or CLAIMABLE state for 4 epochs.

  • It also becomes unregisterable if it receives more vetos than votes and if the vetos exceed the unregistration threshold factor.

Now, it can never be claimed, and only existing votes and vetos will be deallocated.

• DISABLED: It occurs when the initiative has been unregistered, and voting and vetoing on this initiative is not possible. Existing votes and vetos will also be deallocated.

Here is an image provided by Liqiuty v2

C. Governance Functions

1. depositLQTY(uint256 _lqtyAmount)

   • Purpose: deposit or stake LQTY tokens to the governance contract.

   • Inputs: Users enter the quantity of LQTY to be deposited.

   • Requirements: User must have LQTY tokens in their EOA.

2. withdrawLQTY(uint256 _lqtyAmount)

   • Purpose: withdraw or unstake LQTY tokens to the governance contract.

   • Input: Users enter the quantity of LQTY to be withdrawn.

   • Requirements: User must have staked LQTY tokens in the governance contract.

3. registerInitiative(address _initiative)

   • Purpose: register a new initiative.

   • Inputs: Users should enter the initiative address that they want to register.

   • Requirements: User must have at least a minimum amount of voting power both allocated lqty and unallocated lqty.

4. unregisterInitiative(address _initiative)

   • Purpose: This function enables users to unregister a newly initiated project.

   • Inputs: Users must specify the initiative they wish to unregister.

   • Requirements: The initiative user attempting to unregister must be in the state of “Unregistration.” This state can only be reached if the initiative failed to garner sufficient traction of votes within the specified four epochs or received more vetoes than votes, with addition that the number of vetoes must be greater than or equal to UNREGISTRATION_THRESHOLD_FACTOR, which is itself dependent on the voting threshold.

5. claimFromStakingV1(address _rewardRecipient)

   • Purpose: User can claim governance rewards without unstaking LQTY.

   • Inputs: Users should enter the recipient who wants to receive the rewards.

   • Requirements: User should have staked some LQTY.

6. resetAllocations(address[] calldata _initiativesToReset, bool checkAll)

   • Purpose: Withdraw voting power from initiatives.

   • Inputs: Users can enter the initiatives addresses that they want to reset to 0, basically it removes or deallocates all the voting power from the initiatives.

7. allocateLQTY(address[] calldata initiativesToReset, address[] calldata initiatives, int256[] calldata absoluteLQTYVotes, int256[] calldata absoluteLQTYVetos)

   • Purpose: Allocate voting power to one or more initiatives.

   • Inputs:

     • _initiativesToReset: Initiatives that users wish to reset their allocated quantity to zero.

     • _initiatives: Initiatives that users intend to allocate LQTY for voting or vetoing.

     • _absoluteLQTYVotes: Allocate LQTY for the votes in favour of the initiative.

     • _absoluteLQTYVetos: Allocate LQTY for the vetoes against the initiative.

8. claimForInitiative(address _initiative)

   • Purpose: Initiatives who have won, can claim their BOLD tokens by calling this function.

   • Requirements: Initiative should be in the claimable state.

---

Conclusion

Liquity V2 introduces a governance model that empowers LQTY stakers to actively shape the protocol’s future. Through a dynamic voting and veto mechanism, stakeholders influence how the Protocol Incentivized Liquidity (PIL) budget is distributed across community-driven initiatives. This model rewards long-term commitment, promotes thoughtful proposal submission, and ensures that only the most supported ideas receive funding.

In the next blog post, we’ll dive into how the Liquity V2 governance contract is rigorously tested using fuzzing techniques—uncovering edge cases, identifying potential vulnerabilities, and ensuring the robustness and resilience of the system.

• Github link For the liquity V2 governance project - https://github.com/liquity/V2-gov

• Liquity V2 Docs

Thank you for reading the article! I hope you now understand the Liquity V2 governance contract. If you have any questions or thoughts, feel free to share them. I'd love to hear your feedback.😄

Connect with me on - Twitter, Linkedin, Github