Venus Prime Audit by OpenZeppelin

Article
Avatar
Author

OpenZeppelin conducted an audit of Venus Prime from August 21, 2023, to September 13, 2023. The audit focused on the VenusProtocol/venus-protocol repository, particularly the Comptroller, Diamond, Tokens, and XVSVault contracts. These contracts are integral to Venus Prime as they are designed to reward its holders based on their staking activity and associated balance in the Venus lending protocol.

Venus Prime is a reward distribution smart contract system tailored to reward its holders, often referred to as “Prime holders”. The distribution of rewards is based on a calculated score derived from an individual’s staking activity and their associated balance in the Venus lending protocol. To qualify for the Prime token and its reward system, a user must stake a minimum of 1,000 XVS for at least 90 days. The reward distribution is proportional to the calculated scores of each holder.

Venus Prime’s scoring function is determined by the equation \(xvs^𝝰 * capital^(1-𝝰)\), where “xvs” is the amount of XVS staked, and “capital” combines the user’s borrowed balance and vToken balance from the Venus lending protocol up to a specified cap. The parameter “𝝰” adjusts the weight of XVS in relation to “capital” for the score. Prime’s interactions with the Venus lending protocol are pivotal, with borrowed and vToken balances influencing individual scores and subsequent rewards. Notably, the XVSVault and Comptroller’s PolicyFacet have been updated to notify Prime of changes in staked XVS and vToken balances.

The Prime system offers flexibility with adjustable parameters, including alpha, rewardMultiplier, and borrowMultiplier, which set caps on VTokens and borrowed balances, influencing reward calculations. Trust is placed in the Protocol Share Reserve (PSR) for accurate accounting, and the system’s interactions with the broader lending protocol are essential for score computations.

In terms of access control, minimal changes were made, with the prime.sol contract having an owner address that can designate an access controller. This controller has permissions for various privileged functions, such as updating the alpha and multipliers in the score formula, adding new markets, setting Prime token minting limits, and directly issuing Prime tokens without staking prerequisites.

OpenZeppelin identified a total of 14 issues, of which 12 were resolved:

Critical Severity Issues:

  1. The updateAlpha and updateMultipliers functions could break rewards accounting and potentially make the rewards pool insolvent. This issue was resolved in pull request #196 at commit f5e3221.

Medium Severity Issues:

  1. The maximum XVS staked did not match the documentation. This was resolved in pull request #196 at commit 860c959.
  2. An irrevocable token could not be minted to a revocable token holder. This was resolved in pull request #196 at commit b98dc82.

Low Severity Issues:

  1. Alpha Value Setting: A check was missing to ensure alphaDenominator doesn’t exceed alphaNumerator. This was resolved in subsequent commits.
  2. Docstrings Absence: Several functions in Prime.sol lacked proper documentation. This was addressed in multiple commits.
  3. Unsafe Typecasting: Potential typecasting issues were identified in the FixedMath library’s uintDiv and uintMul functions. This was corrected in a later commit.
  4. Outdated Solidity Version: The file IPrime.sol used an outdated pragma directive. The Venus team acknowledged this but chose not to resolve it for design reasons.
  5. PrimePoolId Validation: The setPrimeToken function lacked a validation check for prime poolId. This was addressed and resolved in a subsequent commit.

Notes & Additional Information:

  1. Non-Explicit Imports: The codebase contained several instances of non-explicit imports, which could decrease code clarity and create potential naming conflicts. This was addressed in subsequent commits.
  2. Type Specification: The code often used int/uint instead of the more explicit int256/uint256. This was corrected in a later commit.
  3. Unused State Variable: The MAXIMUM_BPS state variable in the PrimeStorageV1 contract was initially unused but was later utilized in the _calculateUserAPR function.
  4. SPDX License Identifiers: Some files lacked SPDX license identifiers, which are crucial for legal clarity. This was resolved in a subsequent commit.
  5. Security Contact: The contracts did not specify a security contact, which is essential for vulnerability reporting. This was later addressed by the Venus team, directing individuals to their GitHub repo and Telegram chat for security concerns.
  6. Named Parameters in Mappings: The codebase had multiple mappings without named parameters, which could improve code readability. The Venus team acknowledged this but did not resolve it due to the Solidity version they were using.

Overall, the audit reflects positively on Venus Prime, with most identified issues being of low to medium severity and subsequently resolved. The Venus team’s proactive approach to addressing the issues highlighted their commitment to ensuring the security and functionality of the protocol.

Read the full article HERE

To stay up to date with the latest developments and progress, you can visit the Venus Protocol Website and Dapp.  For the latest news and events, we invite you to visit the Venus Community. To receive the latest updates, please follow us on Twitter and in our Telegram Announcement Group. We also invite you to join to our global community on Telegram for a broader discussion.

Related Tags: