Launched in 2020, Venus Protocol (a.k.a. “Venus”) pushed the edges of decentralized finance through its composition of two pre-existing solutions and deployment on BNB chain, lowering the barrier to entry for millions of new users around the globe. By combining the stablecoin minting facility introduced by Maker and algorithmic money markets developed by Compound, Venus simplified the user experience and provided core capabilities that enabled decentralized finance to flourish in a single application. As a result, Venus found remarkable success and quickly rose to be one of the most widely used decentralized applications in web3.

The latest iteration of Venus Protocol, the most trusted and battle-tested lending and borrowing protocol on the BNB Chain, builds on prior successes and lessons learned to improve in 3 key areas:

1. Risk management

2. Decentralization

3. User experience

In doing so, Venus continues to push the boundaries of what's possible within the realm of decentralized finance.

What is Venus Protocol?

Venus Protocol is a trusted decentralized finance lending and borrowing protocol that's deployed on the BNB Chain. Initially launched in 2020, it combines the stablecoin minting facility of Maker and the algorithmic money markets developed by Compound, providing a simplified user experience and core capabilities in a single application.

Overview:

Stable Rate Borrowing is a distinctive feature of the Venus Protocol that provides an alternative to variable interest rate loans. Stable-rate loans set their interest rates at issuance until a rebalancing event occurs. This approach shields users who borrow at a stable rate from being affected by individual actions of other users and large fluctuations in the market.

Rate Determination:

The interest rates for stable and variable rate borrowing are determined based on several calculations involving parameters such as utilization rate, stable loan adoption rate, and total supply. For instance, the stable interest rate will include a base premium plus an additional premium that depends on the stable loan adoption rate.

Model Parameters:

The model parameters involved in the calculations include slopes for the variable interest rate, a base rate per block, the optimal utilization rate (kink), a reserve factor, base premium, and other parameters related to stable loan borrowing.

Rebalancing Conditions:

The fixed rate of a stable loan persists until certain rebalancing conditions are met. These conditions involve the utilization rate and the comparison between the market average borrow rate and the variable borrow rate. The stable rate provides predictability for the borrower but may come at a cost of higher interest rates compared to the variable rate.

Overview

The Venus Protocol introduces E-Mode (Efficiency Mode) to the BNB Chain Core Pool, a new feature designed to boost capital efficiency for specific asset pools, such as stablecoins or ETH-based tokens. It also aims to isolate risk within these pools while reusing liquidity from the Core Pool.

E-Mode allows users to activate specialized pools within the Core Pool, each with customized risk settings. By selecting an E-Mode pool, your eligible assets follow optimized parameters for collateral factor (CF) and liquidation threshold (LT), which are increased, while the liquidation incentive (LI) is decreased, making borrowing more efficient and cost-effective while keeping risks contained.

What’s Changed

To support E-Mode, the Core Pool itself has been enhanced with new risk mechanics:

• Liquidation Threshold (LT) Support – Similar to isolated pools, LT is now used to determine liquidation conditions, separate from CF.

• Per-Market Liquidation Incentive (LI) – LI is no longer global; each market has its own incentive, configurable by Governance.

• User-Specific Risk Factors – Effective CF, LT, and LI now depend on the user’s selected E-Mode pool, giving each user a tailored borrowing and collateral profile.

Architecture Overview

E-Mode operates as a lightweight overlay on the Core Pool, enabling per-user risk management without moving funds to separate pools.

• Core Pool (poolId = 0): The default pool for all users. Supports per-market LIs and LT, even for non-E-Mode users.

• E-Mode Pools (poolId > 0): Each pool defines a set of assets (e.g., Stablecoin Pool, ETH Pool) with customized CF, LT, and LI for each asset in the pool. Users select a pool to activate its risk parameters.

• Pool-Market: Markets are tracked per pool, allowing pool-specific overrides while preserving Core Pool compatibility.

This architecture ensures flexibility, backward compatibility, and gas efficiency, while giving users higher borrowing efficiency and better risk isolation.

Impact on Users

• No Action Needed – Users remain in the Core Pool by default. Their positions continue to function normally without switching to E-Mode.

• Optional Upgrade – By entering an E-Mode pool, your account will use its risk settings for approved assets.

• Note: Improved Risk Mechanics – Even without switching, Core Pool users now benefit from per-market liquidation incentives (LI) and liquidation threshold (LT) support, making liquidation calculations and account health evaluations more precise.

Impact on Liquidators

E-Mode introduces more precision and flexibility for liquidators in the Core Pool:

• Per-Market Liquidation Incentives – Liquidation incentives (LI) are now set on a per-market basis rather than being global. Before liquidating, liquidators should check the LI for each asset. If a user is in an E-Mode pool and uses collateral that isn’t enabled in that pool, the LI for that asset can be zero.

• Liquidation Thresholds (LT) – LT now determines when accounts can be liquidated, replacing the older CF-based check for liquidations.

• User-Specific Risk Factors – Effective CF, LT, and LI can vary per user depending on their E-Mode pool, making liquidation decisions more targeted and strategic.

This gives liquidators smarter targeting, higher transparency, and better reward optimization across markets.

How It Works

1. Default in the Core Pool All users start in the Core Pool and can continue their positions normally.

2. Select an E-Mode Pool Explore available pools (e.g., Stablecoin) via the Venus App or Venus Lens.

3. Check Your Borrows Borrowed assets must be approved in the selected pool. Repay any disallowed assets first.

4. Check Core Pool Fallback Each E-Mode pool has a flag allowCorePoolFallback

For a detailed technical explanation, including implementation and user examples, check out the .

Overview

The Venus Reward Distributor allows for the configuration and management of rewards for lenders and borrowers, dependent on the user's activity within the associated markets. The addition of one or more reward distributors to a pool is facilitated through the addRewardsDistributor feature, enhancing the protocol's capability to customize distribution rates on a per-market basis.

In the Venus Protocol V4, the reward system has been upgraded to allow for rewards per market and lending activity, as well as the support for multiple reward tokens. This revamp serves to provide further incentives and yield opportunities for users.

Overview

Venus Protocol offers variable interest rates for markets using two different models: the Jump Rate Model and the Whitepaper Rate Model. Each market operates under one of these models with specifically set risk parameters at the market's inception. Notably, the community can update these parameters through the Governance process. Moreover, some markets feature a stable rate, introduced in Venus V4.

Want to try out e-mode?

Head to the Venus dApp () and ensure you are connected to the BNB Chain.

Click on the “E-mode” icon to view current e-mode groups.

Make sure your wallet is connected.

Click “Enable” in the e-mode group you would like to enable. Just like that, enjoy increased LTV on the assets listed in that e-mode group!

Vaults within Venus Protocol provide a secure and efficient mechanism for users to stake their tokens, whether XVS or VAI, and earn passive income. This staking process allows users to actively participate in and contribute to the stability and security of the Venus ecosystem, while maximizing returns on their holdings.

Staking in XVS Vault

1. Navigate to the Venus app (app.venus.io) and connect your BNB Chain Wallet or other supported wallet apps.

2. On the left side of the screen, click on the 'Vault' tab.

Overview

Protocol revenues, sourced from reserve interests and liquidations, are processed through the module. Once allocated, these underlying tokens are subsequently sent to various Token Converters, each transforming the received income into specific tokens, automating and optimizing this conversion process.

FlashLoanFacet

This facet contract contains functions for flash loan operations

Solidity API

Overview

XVS is the native token of Venus Protocol and serves as its governance token. By staking XVS tokens in the vault, users gain voting power proportionate to the amount staked. This voting power enables them to participate in the voting process for Venus Improvement Proposals (VIPs), thereby playing a critical role in the development and evolution of the Venus Protocol.

Furthermore, users who stake their XVS tokens in the vault have the potential to earn yield, creating an incentive for participation in the Venus governance process. This aligns the interests of XVS holders with the overall health and success of the Venus Protocol.

DiamondConsolidated

This contract contains the functions defined in the different facets of the Diamond, plus the getters to the public variables. This contract cannot be deployed, due to its size. Its main purpose is to allow the easy generation of an ABI and the typechain to interact with the Unitroller contract in a simple way

InterestRateModelLens

Lens for querying interest rate model simulations

Solidity API

Overview

Isolated Pools are made up of separate collections of assets with tailored risk management configurations. This design offers users broader opportunities to manage risk and allocate assets to earn yield. Moreover, it prevents hypothetical failures from affecting the liquidity of the entire protocol as they are confined to isolated markets.

Isolated Pools also offer custom rewards for each market in the pool, incentivizing users accordingly.

Overview

The 2-Kink Interest Rate Curve introduces a new model to optimize interest rates and utilization across Venus protocol markets. By incorporating two separate "kinks", this model aims to provide more flexible control over market dynamics, enhancing both the predictability and efficiency of APYs (Annual Percentage Yields) for borrowers and suppliers.

This design helps reduce the volatility of APYs during periods of high demand, such as during launchpool events, and encourages greater participation by offering more predictable costs and returns.

This guide will walk you through the steps to interact with Venus Protocol on ZKsync without needing ETH to cover gas fees, thanks to the integration of . All transactions will be sponsored, so you can focus on using the protocol without worrying about gas expenses.

Step-by-Step Guide

Overview

Venus Protocol's governance relies on participants locking XVS tokens into a vault to acquire voting power for Venus Improvement Proposals (VIPs). A 48-hour timelock period after voting ensures transparency and protection against malicious proposals. However, the initial model's rigidity prompted the introduction of a new governance structure in Venus V4. This upgraded model incorporates fast-track VIPs, role-based access control, and a fine-grained pause mechanism for enhanced flexibility and timely adjustments.

Governance Upgrade

Venus V4 introduces an improved governance structure with the following components:

• Fast-track and Critical VIPs

• Role-based access control

• Fine-grained pause

Fast-track and Critical Improvement Proposals

Venus Governance has now categorized VIPs into three types: Normal, Fast-track, and Critical.

• Normal VIPs encompass significant updates like contract upgrades or changes in access controls.

• Fast-track VIPs deal with risk parameter adjustments such as interest rates or collateral factors.

• Critical VIPs are utilized during emergencies demanding an immediate reaction.

Each VIP type has its unique proposal threshold, timelock, and voting periods, reflecting the potential risk and impact of the proposed changes.

The initial voting and delay periods for these types are as follows:

• Normal VIP: 24 hour voting period + 48 hour delay (+ 48 hour delay to execute commands on networks other than BNB Chain)

• Fast-track VIP: 24 hour voting period + 6 hour delay (+ 6 hour delay to execute commands on networks other than BNB Chain)

• Critical VIP: 6 hour voting period + 1 hour delay (+ 1 hour delay to execute commands on networks other than BNB Chain)

Role-based Access Control

Venus V4 employs a separate Access Control Manager contract that validates access permissions rather than merely verifying the caller as an "admin". This allows certain actions to bypass voting, enabling them to take the fast-track or critical route, or even to be executed directly through a multisig by guardians. It can be particularly useful for implementing borrowing and supply caps, pausing specific market actions, or responding to rapid market fluctuations.

Fine-grained Pause

A fine-grained pause mechanism allows the pause guardian to individually halt any action on any market. Unlike previous versions, where the entire protocol was paused for damage control or protection against attacks, the updated model enables guardians to pause individual market actions like supply, borrow, and enabling collateral, offering greater control and flexibility.

Overview

VAI is the primary stablecoin of the Venus Protocol. It is carefully designed and integrated with a series of stability mechanisms to maintain its peg to 1 USD.

Stability Fee and Optimised Minting

VAI sustains its value via a stability fee system. This fee is a charge that users incur when they repay their minted VAI. Calculated on a block-by-block basis, this fee gets added to the user's minted VAI balance. This fee system encourages users to either mint or burn VAI in response to its price fluctuations, thereby contributing to its stability.

The stability fee is determined through the following formula:

The baseRate is a fixed rate that users must always pay, while max(0, (1 - currentPriceOfVAI)) * floatingRate is a variable rate that users pay based on outstanding VAI. This incentivizes users to burn or mint VAI according to its price. The variable rate will always be greater or equal to zero, meaning the minimum stability fee will be the base rate.

Revenue generated from the stability fee serves as a financial cushion during extreme market conditions, such as bad debt scenarios.

VAI Vault Proxy

Proxy contract for the VAI Vault

Solidity API

_setPendingImplementation

• Admin Functions **

_acceptImplementation

Accepts new implementation of VAI Vault. msg.sender must be pendingImplementation

Return Values

_setPendingAdmin

Begins transfer of admin rights. The newPendingAdmin must call _acceptAdmin to finalize the transfer.

Parameters

Return Values

_acceptAdmin

Accepts transfer of admin rights. msg.sender must be pendingAdmin

Return Values

Overview

Venus Protocol manages risks of high volatility tokens with isolated pools. Each pool (Isolated Pools and the Core pool) has an associated risk fund receiving a percentage of the pool's income (interest and liquidation bonus) in USDT to prevent insolvency. The specific percentage is defined by the tokenomics of the project. The risk fund also covers bad debt in case of bankruptcy without a liquidator.

Risk fund

The risk fund concerns three main contracts:

• ProtocolShareReserve

• RiskFund

• ReserveHelpers

These three contracts are designed to hold funds that have been accumulated from interest reserves and liquidation incentives, send a portion to the protocol treasury, and send the remainder to the RiskFund contract. When reduceReserves() is called in a vToken contract, all accumulated liquidation fees and interests reserves are sent to the ProtocolShareReserve contract. Once funds are transferred to the ProtocolShareReserve, anyone can call releaseFunds() to transfer 50% to the protocolIncome address and the other 50% to the riskFund contract. Once in the riskFund contract, the tokens can be swapped via PancakeSwap pairs to the convertible base asset, which can be updated by the authorized accounts. When tokens are converted to the convertibleBaseAsset, they can be used in the Shortfall contract to auction off the pool's bad debt. Note that just as each pool is isolated, the risk funds for each pool are also isolated: only the associated risk fund for a pool can be used when auctioning off the bad debt of the pool.

Shortfall

When a borrower's shortfall (total borrowed amount converted to USD is greater than the total supplied amount converted to USD) is detected in a market in the Isolated Pools, Venus halts the interest accrual, writes off the borrower's balance, and tracks the bad debt.

Shortfall is an auction contract designed to auction off the convertibleBaseAsset accumulated in RiskFund. The convertibleBaseAsset is auctioned in exchange for users paying off the pool's bad debt. An auction can be started by anyone once a pool's bad debt has reached a minimum value (see Shortfall.minimumPoolBadDebt()). This value is set and can be changed by the authorized accounts. If the pool’s bad debt exceeds the risk fund plus a 10% incentive, then the auction winner is determined by who will pay off the largest percentage of the pool's bad debt. The auction winner repays the bid percentage of the bad debt in exchange for the entire risk fund. Otherwise, if the risk fund covers the pool's bad debt plus the 10% incentive, then the auction winner is determined by who will take the smallest percentage of the risk fund in exchange for paying off all the pool's bad debt.

The main configurable (via VIP) parameters in the Shortfall contract , and their initial values, are:

• minimumPoolBadDebt - Minimum USD bad debt in the pool to allow the initiation of an auction. Initial value set to 1,000 USD

• waitForFirstBidder - Blocks to wait for first bidder. Initial value sets to 100 blocks

• nextBidderBlockLimit - Time to wait for next bidder. Initial value set to 100 blocks

VAI Unitroller

This is the proxy contract for the VAIComptroller

Solidity API

_setPendingImplementation

• Admin Functions **

_acceptImplementation

Accepts new implementation of comptroller. msg.sender must be pendingImplementation

Return Values

_setPendingAdmin

Begins transfer of admin rights. The newPendingAdmin must call _acceptAdmin to finalize the transfer.

Parameters

Return Values

_acceptAdmin

Accepts transfer of admin rights. msg.sender must be pendingAdmin

Return Values

XVS Vault Proxy

XVS Vault Proxy contract

Solidity API

_setPendingImplementation

• Admin Functions **

_acceptImplementation

Accepts new implementation of XVS Vault. msg.sender must be pendingImplementation

Return Values

_setPendingAdmin

Begins transfer of admin rights. The newPendingAdmin must call _acceptAdmin to finalize the transfer.

Parameters

Return Values

_acceptAdmin

Accepts transfer of admin rights. msg.sender must be pendingAdmin

Return Values

XVSVaultTreasury

This contract stores XVS received from XVSVaultConverter and funds XVSVault

Solidity API

XVS_ADDRESS

The xvs token address

xvsVault

The xvsvault address

fundXVSVault

This function transfers funds to the XVS vault

Parameters

📅 Events

• FundsTransferredToXVSStore emits on success

⛔️ Access Requirements

• Restricted by ACM

❌ Errors

• InsufficientBalance is thrown when amount entered is greater than balance

sweepToken

This function sweep tokens from the contract

Parameters

📅 Events

• SweepToken emits on success

⛔️ Access Requirements

• Restricted by ACM

VTreasury

Contract for treasury all tokens as fee and transfer to governance

Solidity API

fallback

To receive BNB

withdrawTreasuryBEP20

Withdraw Treasury BEP20 Tokens, Only owner call it

Parameters

withdrawTreasuryBNB

Withdraw Treasury BNB, Only owner call it

Parameters

Let's take a quick look at the Venus interface and the features available in each menu of the navigation bar.

Dashboard

In the center of the Dashboard interface, you will find the Supply and Borrow markets. You'll also notice a new column called 'Pool' which identifies the pool to which each market belongs. The Supply market allows you to lend your cryptocurrency assets and earn interest on them. You can choose which assets to supply and specify the amount you want to lend. On the other hand, the Borrow market allows you to borrow cryptocurrency assets by using your supplied assets as collateral. You can select the assets you want to borrow and specify the amount you need.

Account

The Account interface provides an overview of your supplied and borrowed assets. Here, you can keep track of your balances and monitor the status of your transactions.

Core Pool

The Core Pool interface is your hub for exploring all primary markets available. It allows you to click on each market to examine essential metrics such as 'Supply APY', 'Borrow APY', and 'Total Liquidity', among others. This interface centralizes all your lending and borrowing activities within the main markets.

Pools

The Pools interface allows you to explore all isolated pools available. You can click on each pool to view all the markets within it. In the markets, you can see various metrics such as 'Supply APY', 'Borrow APY', 'Total Liquidity', and more.

Vaults

The Vaults interface allows you to access and manage the vaults associated with Venus Protocol. Vaults are designed to provide users with automated strategies for optimizing their yields and managing their assets more efficiently.

Swap

The Swap interface enables you to swap one cryptocurrency for another within the Venus Protocol. You can exchange your assets conveniently and quickly.

History

In the History interface, you can review transaction history and track your previous activities on the Protocol.

Governance

The Governance interface provides access to Venus Protocol's governance features. Here, users can participate in voting and contribute to decision-making processes that shape the future of the protocol.

XVS

The XVS interface displays the current daily reward distribution rate for each of the protocol markets.

VAI

The VAI interface is where you can mint and manage the VAI stablecoin. VAI is created on Venus Protocol and is pegged to the value of one USD.

Introduction

This guide provides step-by-step instructions on how to borrow VAI, the stablecoin of Venus Protocol, available exclusively for prime users. Borrowing involves using your account's total core pool collateral to secure the loan, and this tutorial will walk you through the VAI UI to accomplish this.

Steps for Borrowing VAI

Step 1: Access VAI Borrowing UI

Navigate to the Venus Protocol website and select the "VAI" option from the sidebar menu. This will take you to the VAI dashboard, where you can manage your borrowings and repayments.

Step 2: Connect Your Wallet

Click on the "Connect wallet" button in the top right corner of the VAI dashboard to connect your wallet. This is necessary to interact with the Venus Protocol and manage your VAI borrowings.

Step 3: Enter Borrow Amount

In the "Borrow" tab, enter the amount of VAI you wish to borrow in the provided field. You can also see your maximum borrow limit based on your account's total collateral. Ensure that the amount you wish to borrow does not exceed this limit.

Step 4: Review and Confirm Borrowing

After entering the desired amount, review the details of your borrowing transaction, including the collateral used and the borrow limit. Once you've confirmed that everything is correct, click on the "Borrow" button to initiate the transaction.

A wallet pop-up will appear, asking for your confirmation to proceed with the transaction. Confirm to finalize the borrowing process.

Repaying VAI Debt

Step 1: Navigate to Repay Tab

To repay your VAI debt, access the VAI dashboard again and select the "Repay" tab. This interface allows you to make repayments towards your borrowed VAI.

Step 2: Enter Repayment Amount

In the "Repay" tab, enter the amount of VAI you wish to repay. You can choose to repay part of your debt or the entire amount.

Step 3: Review and Confirm Repayment

Review your repayment details carefully. Once you are ready, click on the "Repay VAI" button to proceed. Confirm the transaction in your wallet pop-up to complete the repayment process.

Conclusion

Borrowing and repaying VAI on Venus Protocol is straightforward with the VAI UI. By following these steps and ensuring you have enough collateral, you can manage your stablecoin needs effectively. Always be mindful of your borrow limits and repayment responsibilities to maintain a healthy financial position within the protocol.

The NativeTokenGateway contract serves the purpose of facilitating seamless interaction with Wrapped Native Token markets, even for users who do not possess any Wrapped Native Tokens. It achieves this by allowing users to utilize the native currency in their wallets directly.

Overview

The Venus contracts deployed on the new networks do not directly support native currencies. For example on Ethereum instead of a native ether market there is a market for WETH. Wrapped Native Token markets address this limitation by facilitating the conversion of native currency into a format compatible with the ERC-20 standard.

To streamline user experience and eliminate the need for an additional transaction to convert native tokens into wrapped tokens, wrapping an unwrapping of native tokens is done behind the scenes when users interact with the market.

Introduction

Venus Protocol is deeply committed to ensuring the highest level of security and risk management for our users. This section of the documentation outlines our comprehensive approach to risk management, emphasizing our continuous monitoring practices, partnerships for enhanced security, real-time alert systems, and ongoing risk assessments.

Some assets, such as Liquid Staking Tokens (LSTs), are closely tied to an underlying asset, often featuring an added growth component.

The exchange rate between an asset and its underlying is typically sourced from an onchain smart contract, which can be susceptible to manipulation. A capped oracle is a design mechanism that mitigates potential losses from such manipulation by limiting the rate at which the exchange rate is allowed to grow.

The capped oracle mechanism should be used for any asset whose price is derived through an intermediary token, where the exchange rate between the source asset and the intermediary is fetched onchain and includes a growth component.

At a high level, the capped oracle determines the maximum allowable exchange rate at the queried block based on a predefined growth rate. It then compares this with the current onchain exchange rate, and if the current rate exceeds the calculated maximum, it caps it to that maximum value.

Typically, the current maximum exchange rate at a given block is calculated by taking a historical exchange rate from a past block and applying a predefined per-second growth rate up to the current block timestamp. However, since the exchange rate may not grow consistently over time, the historical reference rate is periodically updated to ensure a more accurate and reliable maximum exchange rate.

The historical reference rate is periodically refreshed through a process called snapshotting. During this process, the new reference rate is set to the lower of the current onchain exchange rate or the maximum rate derived from the previous reference rate, helping maintain a more accurate and robust cap. Before querying an asset’s price from the capped oracle, the consumer should trigger the snapshotting process. If the configured interval has elapsed, a new snapshot will be taken.

Overview

Venus Protocol incorporates Risk Oracles and Risk Stewards to ensure risk parameters remain up-to-date, resilient, and aligned with real-time market conditions—all while preserving decentralized governance. Previously, Venus relied on manually created VIPs to apply risk updates based on Chaos Labs recommendations. With the introduction of the Risk Steward and its on-chain receiver, this process is now automated through a secure and permissioned mechanism. In the initial phase, only market cap-related parameters—specifically supply caps and borrow caps—will be updated automatically, improving responsiveness and operational efficiency.

Overview

The Venus Protocol tokenomics have been reevaluated to optimize income distribution and cater to the protocol's present and future needs. of the Venus Protocol revenue distribution model addresses the need and optimizes the allocation between rewards, treasury reserves, a risk fund and BNB burns.

Introduction

This guide provides step-by-step instructions on how to import your supply positions from other DeFi platforms into the Venus Protocol.

Steps for importing supply positions from other DeFi platforms)

Introduction

This guide provides step-by-step instructions on how to bridge XVS tokens from the BNB Chain to the Ethereum network.

Steps for Bridging XVS from BNB Chain to Ethereum

Overview

The contracts under the Venus Protocol employ a system called Exponential.sol. This system uses exponential mathematics to represent fractional quantities with high precision.

Most numbers in this system are represented by a mantissa, an unsigned integer scaled by a factor of 1 * 10^18. This scaling ensures basic mathematical operations can be performed with a high degree of accuracy.

vToken and Underlying Decimals

Prices and exchange rates are adjusted according to the unique decimal scaling of each asset. vTokens, which are BEP-20 tokens, are scaled with 8 decimal places. However, their underlying tokens may have different decimal scaling, which is indicated by a public member called 'decimals'.

For further details, please refer to the respective token contract addresses.

Interpreting Exchange Rates

The exchange rate of vTokens is adjusted based on the decimal difference between the vToken and its underlying asset.

Here is an example illustrating how to determine the value of one vBUSD in BUSD using the Web3.js JavaScript library.

As BNB lacks an underlying contract, you must set the 'underlyingDecimals' to 18 when dealing with vBNB.

To calculate the number of underlying tokens that can be redeemed using vTokens, you should multiply the total amount of vTokens by the previously computed 'oneVTokenInUnderlying' value.

Calculating Accrued Interest

Interest rates for each market are updated in any block where there is a change in the ratio of borrowed assets to supplied assets. The magnitude of this change in interest rates depends on the interest rate model smart contract in place for the market, and the degree of change in the aforementioned ratio.

For a visualization of the current interest rate model applied to each market, refer to the market pages at the .

The accrual of interest to suppliers and borrowers in a market occurs when any wallet interacts with the market's vToken contract. This interaction could be any of the following functions: mint, redeem, borrow, or repay. A successful execution of any of these functions triggers the accrueInterest method, leading to the addition of interest to the underlying balance of every supplier and borrower in the market. Interest accrues for the current block, as well as any previous blocks where the accrueInterest method was not triggered due to lack of interaction with the vToken contract. Interest only accumulates during blocks where one of the aforementioned methods is invoked on the vToken contract.

Let's consider an example of supply interest accrual: Alice supplies 1 BNB to the Venus Protocol. At the time of her supply, the supplyRatePerBlock is 37893605 Wei, which equates to 0.000000000037893605 BNB per block. For 3 blocks, no interactions occur with the vBNB contract. On the subsequent 4th block, Bob borrows some BNB. As a result, Alice’s underlying balance is updated to 1.000000000151574420 BNB (calculated by multiplying 37893605 Wei by 4 blocks and adding the original 1 BNB). From this point onwards, the accrued interest on Alice’s underlying BNB balance will be based on the updated value of 1.000000000151574420 BNB, rather than the initial 1 BNB. It is important to note that the supplyRatePerBlock value may alter at any given time.

Calculating the APY Using Rate Per Block

The Annual Percentage Yield (APY) for either supplying or borrowing in each market can be computed using the supplyRatePerBlock (for Supply APY) or borrowRatePerBlock (for Borrow APY) values. These rates can be used in the following formula (assuming a daily compound):

Here is an example of calculating the supply and borrow APY with Web3.js JavaScript:

The purpose of this document is to explain the technical details for distributing incomes generated by the Venus Protocol. The distributed incomes are generated from the spread of lending rates (borrow minus supply rates) and liquidations (part of the liquidation incentives). The distribution process for both the Core Pool and Isolated Pools as well as how the different amounts are allocated to different destinations based on specific rules and the approach for near-streaming income distribution are covered.

Income Distribution Schema

The Venus Protocol generates income from two main sources:

• Spread between the borrowing rate and the supply rate

• Part of the liquidation incentives

goes into more detail about the distribution schema and desired outcomes.

The initial distribution excludes VAI funds, which are kept in the VTreasury.

Streaming Income Distribution

The Venus Protocol aims to distribute accumulated reserves in the markets automatically and in near-real-time, leveraging transactions executed by users. This approach eliminates the need for external tools to manage the distribution process. The ProtocolShareReserve contract serves as the designated destination for liquidation incomes, allowing for tracking and distribution within the Venus Protocol.

Core Pool - Spread Income

Accumulated reserves in the Core Pool markets will be distributed after reaching a specified threshold. The threshold is based on the number of blocks since the last transfer of reserves. This strategy helps socialize part of the cost associated with distribution.

Core Pook - Liquidation Income

In the Core Pool, liquidation income is transferred to the Liquidator contract in the form of vTokens. During a liquidation transaction, the Liquidator contract will try to redeem the protocol's portion of the liquidation incentive in vTokens for the underlying tokens. If the redemption process is successful, the underlying tokens will be sent to the ProtocolShareReserve contract. However, if the redemption fails the underlying tokens will be added to a list of pending redemptions and the Liquidator contract will try to redeem the pending redemptions again in subsequent liquidation transactions.

Isolated Pool - Spread Income

Distribution of income generated by the interest rate spread in Isolated Pools is socialized and distributed periodically just like in the Core Pool

Isolated Pool - Liquidation Income

The Isolated Pools liquidations are managed by the VToken contracts. During a liquidation transaction, the protocol's percentage of the seized amount is transferred directly to the ProtocolShareReserve contract. No other action is required.

Distribution of Collected Incomes

The distribution of collected incomes is facilitated by the ProtocolShareReserve contract. It supports WBNB transfers but not BNB transfers. Therefore, BNB needs to be wrapped into WBNB before transferring to the ProtocolShareReserve contract.

updateAssetsState Function

The updateAssetsState function enables the transfer of funds to the ProtocolShareReserve contract. After transferring funds to the ProtocolShareReserve contract, the updateAssetsState function is invoked with the following parameters:

• address comptroller: The Comptroller where the market generated the income.

• address asset: The asset transferred to the ProtocolShareReserve.

• IncomeOrigin origin: The origin type, either "spread" or "liquidation."

Within the updateAssetsState function, the following steps are performed:

• Calculate the transferred balance, taking into account the previous balance of the asset.

• Assign the received amount to the appropriate entry (comptroller - asset - schema).

• Track the total balance of the received asset for future distribution.

releaseFunds Function

The releaseFunds function is responsible for distributing the accumulated funds to the different destinations. This function can be invoked by anyone and follows a two-step process:

1. Transfer the tokens to the destination addresses.

2. Invoke the updateAssetsState function in the receiver contract.

VBNBAdmin

VBNBAdmin contract is the admin of the vBNB vToken. All the other vToken contracts send revenue to PSR directly whereas vBNB sends the reserves to the admin i.e., the vBNBAdmin contract. This pattern is different for vBNB because it's not a upgradable contract.

Whenever the VBNBAdmin receives BNB from the vBNB contract it converts it to WBNB and then sends it to the Protocol share reserve contract.

To release the reserves of vBNB contract you need to call the reduceReserves() function of the VBNBAdmin contract.

JumpRateModel

Solidity API

constructor

Construct an interest rate model

Parameters

utilizationRate

Calculates the utilization rate of the market: borrows / (cash + borrows - reserves)

Parameters

Return Values

getBorrowRate

Calculates the current borrow rate per block, with the error code expected by the market

Parameters

Return Values

getSupplyRate

Calculates the current supply rate per block

Parameters

Return Values

Overview

Venus Protocol's governance model allows XVS token holders to propose and vote on Venus Improvement Proposals (VIPs). Here's a step-by-step guide to help you create and submit a proposal.

Step 1: Visit the Venus Governance Portal

Navigate to the Venus Governance Portal using your preferred web browser. You can access the portal at .

Step 2: Connect Your Wallet

To submit a proposal, you need to connect your wallet by clicking on the "Connect Wallet" button at the top right corner of the screen. A menu will appear listing various wallets that the Venus Governance Portal supports. Select your wallet from the menu and follow the instructions to connect your wallet to the portal.

Step 3: Create a Proposal

Now that your wallet is connected, you can create a proposal. Look for the "Create Proposal" button at the top right corner of the screen and click on it.

This action will open a modal presenting two options - "Upload file" and "Create Manually":

Step 4: Upload a proposal file

The fastest way to create a proposal is by importing a VIP file. The import uses a JSON file containing all the information needed to create a VIP, such as the proposal's title, type, actions and parameters.

Venus makes available a tool to generate VIP files, which you can find . You can also check an example of a valid proposal file . Note that all the fields will be validated according to their requirements and types.

Step 4.1: Choose a VIP file

Clicking "Upload file" will lead you to choose the proposal file you want to upload. After uploading the desired file, it will be parsed and validated and any possible errors found will be reported by the interface.

Step 4.2: Confirm the Proposal

Once the import is successfully validated, the interface will present all the VIP data for your review:

If everything looks good, click "Create" at the bottom of the modal to confirm the creation of your VIP.

Step 5: Create a Proposal Manually

Proposals can also be created manually by clicking on "Create manually".

Step 5.1: Choose the Proposal Type

After clicking the "Create manually" button, a new interface will pop up prompting you to select the proposal type. Select the relevant proposal type for the change you want to propose.

Step 5.2: Enter Proposal Information

The next step is to provide detailed information about your proposal. This includes the proposal's title, a brief description, and a link to an off-chain discussion related to your proposal. Ensure the information you provide is clear and concise to facilitate understanding by other community members.

Step 5.3: Set the Voting Options

The third screen is where you can specify descriptions for the voting options (for, against, abstain).

Step 5.4: Specify the Actions

Next add the actions that will take place if the proposal is approved. An action requires an contract address, function signature and arguments so that the operation can be created correctly.

Step 5.5: Confirm the Proposal Submission

Finally, just like after the VIP import, you will be able to review your proposal to ensure all details are accurate. After confirming everything is correct, click the "Submit" button to submit your proposal. You'll see a confirmation prompt on your connected wallet. Confirm the transaction to complete the proposal submission process.

Congratulations! You've successfully submitted a Venus Improvement Proposal. The Venus community will now review your proposal and vote on it. Remember, your active involvement in Venus Protocol's governance process is crucial for its continued development and success.

Overview

This innovation is designed to distribute the incomes generated by Venus Protocol seamlessly, channeling them to different destinations according to specific rules and percentages. This functionality will incorporate incomes generated through various sources, including interest reserves and liquidation incentives, for both the Core pools and Isolated pools. The goal is to distribute these incomes in underlying tokens and not in vTokens, based on the latest protocol tokenomics.

Key Aspects of Automatic Income Allocation

• Near-Streaming Distribution: The income will be distributed in a near-streaming fashion, from the different pools to the ProtocolShareReserve contract.

• Flexible Distribution Rules: The incomes generated by Venus Protocol will be distributed according to two schemas:

  • Schema (PROTOCOL_RESERVES): Applied specifically to income generated by the interest reserves in every Venus market.

Benefits

• Efficiency: Automating the income distribution process allows for quicker and more accurate allocation.

• Transparency: All distributions are recorded on the blockchain, reinforcing Venus Protocol's commitment to clear and open practices.

• Flexibility: The ability to define specific rules and percentages for different destinations ensures that the distribution aligns with the community's needs and goals.

Architecture

The dashed lines represent transactions initiated by external agents (VIP’s, scripts, arbitrage bots, etc.), and the solid lines represent transfers of funds.

In this guide, we will focus on using Venus Protocol to earn interest and borrow assets. If you’re looking for a more technical understanding of what’s happening under the hood, check out .

Once you’ve created your Web3 wallet on or any other supported wallet App, open the Venus app (). The interface will ask you to connect your Web3 wallet. Connecting your wallet to Venus Protocol enables you to authorize transactions, view balances, and perform other essential actions.

After successfully connecting your wallet, you will gain access to all the features of the Venus Protocol interface. In the Dashboard menu you will find all the markets. Clicking one of the markets a new modal will pop out, enabling you to interact with the selected market. Just make sure you are under the "Supply" or "Borrow" tab, depending on the desired action.

XVS Store

XVS Store responsible for distributing XVS rewards

Solidity API

VAI Vault

The VAI Vault is configured for users to stake VAI And receive XVS as a reward.

Solidity API

VBNBAdmin

This contract is the "admin" of the vBNB market, reducing the reserves of the market, sending them to the ProtocolShareReserve contract, and allowing the executions of the rest of the privileged functions in the vBNB contract (after checking if the sender has the required permissions).

ComptrollerStorage

Storage layout for the Comptroller contract.

Overview

Venus Protocol is excited to announce Venus Prime, a revolutionary incentive program aimed to bolster user engagement and growth within the protocol. An integral part of Venus Tokenomics v3.1, Venus Prime aims to enhance rewards and promote $XVS staking, focusing on markets including USDT, USDC, BTC and ETH.

Venus Prime Essentials

Venus Prime's uniqueness lies in its self-sustaining rewards system, instead of external sources, rewards are derived from the protocol's revenue, fostering a sustainable and ever-growing program.

Eligible $XVS holders will receive a unique, non-transferable Soulbound Token, which boosts rewards across selected markets.

Prime Tokens:

Venus Prime encourages user commitment through two unique Prime Tokens:

1. Revocable Prime Token:

   • Users need to stake at least 1,000 XVS for 90 days in a row.

   • After these 90 days, users can mint their Prime Token.

Expected Impact and Launch

Venus Prime aims to incentivize larger stake sizes and diverse user participation. This is expected to significantly increase the staking of XVS, the Total Value Locked (TVL), and market growth.

Venus Prime intends to promote user loyalty and the overall growth of the protocol. By endorsing long-term staking, discouraging premature withdrawals, and incentivizing larger stakes, Venus Prime sets a new course in user engagement and liquidity, contributing to Venus Protocol's success.

Stake your $XVS tokens today to be eligible for Venus Prime, an exciting new venture in the DeFi landscape.

Technical Reward Details

Reward Formula: Cobb-Douglas function

Where:

• = Rewards for user in market

• = Protocol Reserve Revenue for market

• = Proportion to be distributed as rewards

Qualifiable XVS Staked:

Qualifiable supply and borrow:

Note: There will be a limit for the qualifiable supply and borrow amounts, set by the staked XVS limit and the market multiplier.

User Reward Example:

Model Parameters

• = 0.5

• = 744,164

• = 8 BTC

• = 0.2

User Parameters

Qualifiable Staked XVS

Qualifiable Supply and Borrow

User Rewards

Expected Rewards Function

Rewards in the Venus Prime program will automatically increase as a user increases its XVS Stake, so long as the amount staked and market participation fall within the limits outlined in the "Technical Reward Details" section below.

The graph above demonstrates the relationship between an increased XVS staked amount and its effect on market rewards, assuming a constant participation of $2.5K USD in the BTC supply market. This helps visualize how an increase in the staked amount influences the APY.

As features continued to be introduced to the Core Pool Comptroller contract, it grew to exceed the maximum allowable size of 24KB. In response to this challenge and to preemptively address similar issues in the future, a multifaceted diamond pattern was implemented.

The original comptroller was refactored using the EIP-2535 diamond pattern into distinct facets. This restructuring aligns the storage layout with that of the Comptroller proxy, streamlining the contract's organization and enhancing efficiency. As a consequence user interactions now trigger two delegate calls.

Venus Comptroller - Refactored to EIP 2535

The previous implementation of Venus used a transparent upgrade proxy delegate pattern. For the diamond proxy we needed a slightly different implementation of fallback function.

• Comptroller proxy(Unitroller): https://bscscan.com/address/0xfd36e2c2a6789db23113685031d7f16329158384

• Comptroller implementation before enabling the Diamond Proxy: https://bscscan.com/address/0x909dd16b24cef96c7be13065a9a0eaf8a126ffa5

The following diagram shows the previous design:

The Unitroller contract delegated calls to the Comptroller. The Comptroller had the storage layout defined by ComptrollerV12Storage, which extended the UnitrollerAdminStorage.

EIP - 2535 Overview

The Diamond Proxy pattern is widely used in Solidity development for its ability to separate concerns and improve code maintainability. It is often used in complex contracts that require multiple facets with shared functionality.

1. The Diamond Proxy pattern involves creating a "proxy" contract that acts as a single entry point for all functionality shared by multiple contracts. This allows contracts to share functionality without having to duplicate code in each contract.

2. Each contract that needs to share functionality with the proxy contract is referred to as a "facet." Facets are separate contracts that can be upgraded or modified independently of each other and the proxy contract.

3. The proxy contract delegates function calls to the correct facet contract based on the function selector. This allows the proxy contract to act as a single entry point for all shared functionality.

Enabling Venus Integration with the existing Unitroller - Diamond and Transparent proxy combination

Step 1: The first step was creating the Diamond proxy contract. This contract contains a mapping to hold the addresses of the facet contracts and a fallback function that delegates the function call to the appropriate facet.

Chained delegate calls are used. This means calldata is delegated from Unitroller to the Diamond contract and then a chained delegate call is made to a specific facet based on the function selector.

The Diamond contract checks for the facet address in the selectors-to-facet-address mapping (_selectorToFacetAndPosition internal variable) and then makes a delegate call to that facet address. Facets inherit the ComptrollerStorage (ComptrollerV13Storage) to access the state.

Step 2: Division of the comptroller into multiple facets based on separation of concerns.

Generally is used with the diamond pattern. Since the Core Pool contracts still use Solidity 0.5.16 this wasn't an option and storage is handled using the same pattern as the original comptroller, by inheriting storage contracts.

Comptroller storage contains the facet addresses, mapping of the function selectors to the facet address, and mapping of all selectors to the facet address.

User interaction with new diamond pattern

Users will continue to interact with the Unitroller proxy contract same as before with one significant difference. Now the Diamond proxy serves as the implementation contract for the Unitroller, and the Comptroller's implementation has been divided into multiple facets. These facets will function as the various components of the Diamond proxy.

Following a user's interaction with the Unitroller, the delegateCall operation will be directed towards the Diamond proxy. Once the delegateCall reaches the Diamond proxy, it will analyze the function selector and determine the appropriate facet address to which the delegateCall will be forwarded.

How will new Upgrades work?

Scenario: A new state variable is to be introduced for an upgrade, which is being used by all or few facets.

Add a new state variable in the comptrollerStorage by extending the storage to ComptrollerV14Storage just like new state is added to facets by extending the previous storage.

Scenario: Add a new facet to the Diamond or update the existing facet by add/replace/remove function selectors.

Deploy the facet with the functions/methods that need to be added to the Comptroller Implementation.

Execute the diamondCut method(admin access) to add the new facet to the comptrollerStorage.

To execute the diamondCut through VIP, the cut argument can be generated using the by customizing the generateCutParams to provide the correct actions on the provided function seletors.

Diamond proxy implementation for Core Pool Comptroller

The Comptroller of the core pool is divided into 4 facets and 2 parent contracts extended by the facets. Facets will receive the function call through a chained delegateCall from Unitroller, and each facet holds its own responsibility as explained below:

Facets

: This facet contains all the external pre-hook functions related to vToken.

: This facet contains all setter configuration functions.

: This facet provides market information including account activity in the market. It is also responsible for entering and exiting the market.

: This facet provides the external functions related to all claims and rewards of the protocol.

Parent contracts

: This contract contains functions related to access and checks.

XVSRewardsHelper: This contract contains the shared functions used by the RewardFacet and PolicyFacet.

The following diagram shows the inheritance and association relationships among the different contracts:

Overview

The Peg Stability Module (PSM) is a crucial component of the Venus Protocol designed to maintain the value of the VAI stablecoin at $1. It functions similarly to the system provided by MakerDAO for DAI. The PSM contract utilizes two stablecoins: VAI (the target stablecoin) and USDT (used to help maintain the peg).

Features

Convert Functionality:

• Users can exchange VAI and USDT with a "fixed" conversion rate of 1 VAI = $1.

• Users can send VAI to the PSM and receive USDT if enough USDT is available in the PSM.

• Users can send USDT to the PSM and receive VAI, provided that the PSM hasn't reached its maximum allowed minted VAI limit.

No Stability Fee

The VAI minted through the PSM does not accrue any interest or stability fee.

Configurable Parameters:

The PSM contract has three configurable variables set via the Venus Improvement Proposal (VIP):

• feeIn: Fee charged when users send USDT to the PSM.

• feeOut: Fee charged when users send VAI to the PSM.

• maxMintedVAI: The maximum amount of VAI that the PSM can distribute. Conversions that exceed this limit will be reverted.

Fees Sent to Treasury: The collected fees are sent to the Venus Treasury contract in each operation.

Integration with Oracle Price: The PSM considers the USD value of the stablecoin to peg VAI to its value accurately.

Convert Functions

Function swapStableForVAI

This function allows users to exchange the paired stablecoin (USDT) for VAI.

Expected Parameters:

• receiver: Address of the user who will receive the VAI.

• amount: The amount of stablecoin (USDT) the sender wants to convert.

The received stablecoins will be held by the PSM, and the fee specified by feeIn will be sent to the Treasury contract.

This function returns the amount of VAI transferred to the receiver.

Function swapVAIForStable

This function enables users to exchange VAI for the paired stablecoin (USDT).

Expected Parameters:

• receiver: Address of the user who will receive the stablecoin.

• amount: The expected amount of stablecoin (USDT) the user should receive.

The received VAI will be burnt, and the fee specified by feeOut will be sent to the Treasury contract.

This function returns the amount of VAI transferred from the sender (burnt + fee).

Preview Functions

The PSM also offers preview functions that help users estimate the outcome of convert operations:

previewSwapVAIForStable(uint256 stableTknAmount)

Returns the amount of VAI that the sender would transfer (burnt + fee) to receive the specified stablecoin amount.

previewSwapStableForVAI(uint256 stableTknAmount)

Returns the amount of VAI that the receiver would receive after executing the swapVAIForStable function with the specified stablecoin amount.

Integration of the Oracle Price

To protect the value of VAI and consider the USD value of the paired stablecoin, the PSM integrates with the Resilient Oracle. The following rules are applied:

swapVAIForStable (the user sends VAI and receives USDT)

• If the oracle price of the paired stablecoin is below $1, the conversion rate is 1 stablecoin = $1.

• If the oracle price of the paired stablecoin is above $1, the conversion rate is 1 stablecoin = oracle price.

swapStableForVAI (the user sends USDT and receives VAI)

• If the oracle price of the paired stablecoin is below $1, the conversion rate is 1 stablecoin = oracle price.

• If the oracle price of the paired stablecoin is above $1, the conversion rate is 1 stablecoin = $1.

Overview

Venus DAO is an autonomous and decentralized organization that functions via smart contracts on a blockchain, meaning it operates without any central authority or control. The purpose of DAOs is to facilitate trustless collaboration and decision-making among members, who can be individuals or entities involved in the organization. Governance within Venus DAO encompasses making decisions, establishing rules, and managing resources.

It includes the following components:

1/ Token Holders: DAOs typically have a native token, representing membership and voting rights within the organization. For Venus Protocol, this native token is XVS. Token holders partake in the decision-making process by voting on proposals.

2/ Proposals: Venus DAO members who stake XVS in the Vault can create proposals, which suggest changes, initiatives, or organizational actions. Proposals can span a variety of topics such as protocol upgrades, funding requests, or changes to the DAO's rules. To propose, one requires "Voting power" of 300,000 XVS. To vote on a proposal, one needs "Voting power" of 600,000 XVS, either individually owned or delegated by other members.

3/ Voting: Following a proposal's creation, token holders can vote on it. Venus DAO manages the voting process, queuing and voting on protocol updates within 48-hour timelocks. The voting method could entail a simple majority vote, a supermajority, or weighted voting based on each participant's token count, as is the case with Venus Protocol.

4/ Voting Period: Venus DAO recognizes three Venus Improvement Proposals (VIP) roles: Normal, Fast Track, and Critical. Each VIP role has a unique proposal threshold, timelock, and voting period, which can be configured by Governance. This duration allows token holders ample time to review, discuss, and cast their votes. The votes are tallied once the voting period concludes.

5/ Execution: After a proposal garners support and votes, all Venus DAO members can execute the VIP directly in the Venus dapp through smart contracts.

6/ Transparency and Auditability: All Venus DAO transactions and governance activities take place on a public blockchain, enabling transparency and auditability for anyone interested. This level of transparency helps maintain accountability and minimizes potential fraud or manipulation risks.

It's crucial to understand that DAO governance is an evolving field, with different DAOs adopting unique governance structures and processes. The specific rules and mechanisms are continually refined and adapted to best meet the needs of all Venus DAO members.\

Delegate Voting Power

Step 1: Visit the Venus Governance Portal

Access the Venus governance portal via your browser. The URL is .

Step 2: Connect Your Wallet

On the top right corner of the screen, click on the "Connect Wallet" button. Choose your wallet from the dropdown menu and follow the prompts to connect.

Step 3: Delegate Your Voting Power

Once your wallet is connected, click on the "Delegate" button in the Governance section. This will open up a new dialogue box.

Step 4: Enter Your Address

In the new dialogue box, click on the "Paste your address" field. Your connected wallet address should automatically populate.

Step 5: Redelegate Your Votes

Click on the "Redelegate" button. This will submit the address for vote delegation.

Step 6: Confirm the Transaction

A confirmation prompt will appear in your connected wallet (for example, MetaMask). Confirm the transaction to complete the voting power delegation process.

Congratulations, you've now enabled your XVS in the vault to participate in Venus Protocol's governance. Your tokens are now ready to vote on upcoming VIP proposals. Remember, your engagement in the protocol’s decision-making process is vital for its future development and success.

Vote for a VIP

Step 7: Select the VIP Proposal

To vote on a Venus Improvement Proposal (VIP), navigate to the list of active proposals on the Venus Governance Portal. Click on the title of the VIP you wish to vote on. Remember, your voting eligibility requires your address to be delegated.

Step 8: Cast Your Vote

After selecting the VIP, you'll see voting options for the proposal. You can choose 'For' to vote in favor of the proposal, 'Against' to vote against it, or 'Abstain' to remain neutral.

Step 9: Add a Comment

Before you submit your vote, you have an option to provide a comment explaining the reasoning behind your decision. This step is not mandatory, but it contributes to a more transparent and inclusive voting process.

Step 10: Submit Your Vote

Once you've made your decision and optionally left a comment, click the 'Submit Vote' button to cast your vote.

Congratulations, you've successfully voted on a VIP proposal! Your participation is integral to the development and success of the Venus Protocol. Thank you for your contribution to our community's decision-making process. Remember, every vote counts in shaping the future of Venus Protocol.

WhitePaperInterestRateModel

The parameterized model described in section 2.4 of the original Venus Protocol whitepaper

Solidity API

constructor

Construct an interest rate model

Parameters

utilizationRate

Calculates the utilization rate of the market: borrows / (cash + borrows - reserves)

Parameters

Return Values

getBorrowRate

Calculates the current borrow rate per block, with the error code expected by the market

Parameters

Return Values

getSupplyRate

Calculates the current supply rate per block

Parameters

Return Values

TwoKinksInterestRateModel

An interest rate model with two different slope increase or decrease each after a certain utilization threshold called kink is reached.

Solidity API

PrimeStorageV1

Storage for Prime Token

Solidity API

Diamond

This contract contains functions related to facets

Solidity API