PotionVault

Smart Contract Audit Report

Audit Summary

Poison Finance is releasing PotionVault which allows users to mint synthetic tokens representing various assets by depositing collateral.

For this audit, we reviewed the project team's PotionVault contract at 0xd5e31fc5f4a009A49312C20742DF187b35975528 on the Arbitrum Mainnet.

Audit Findings

Low findings were identified and the team should consider resolving these issues. In addition, some centralized aspects are present.
Date: January 25th, 2023.
Updated: January 26th 2023, with updates to Findings and mainnet address.

Finding #1 - PotionVault - High (Resolved)

Description: Users are able to use MIM tokens as collateral, which has a history of depegging.
Risk/Impact: As all collateral tokens are treated as 1 USD, if MIM tokens depeg and the value is less than 1 USD users can mint an excess amount of synth tokens and liquidate other users at an unfair rate; ultimately resulting in a loss of users' funds.
Recommendation: Due to MIM's two previous depegs we recommend the team remove MIM as a collateral token as soon as possible.
Resolution: The team has disabled the canMint value for MIM on the Arbitrum address at this transaction and will not add MIM as a collateral token in future deployments on other chains.

---

Finding #2 - PotionVault - Medium (Acknowledged)

Description: The contract attempts to round any fractional token values beyond a token's amount of decimals to the nearest value in the token's decimals.
Risk/Impact: The liquidate() function can result in a user being unable to exit a Safe through the close() function. The scenario is as follows:

1. A user creates a Safe with a collateral token with less than 18 decimals.
2. The position is liquidated resulting in the Safe containing a fractional amount of collateral tokens with 0.5 or more fractional tokens.
3. The Safe's collateral token balance will be rounded up 1 wei.
4. The user calls the close() function on the Safe.
5. The user cannot withdraw as the contract's collateral token balance is 1 wei short of the amount required in the close() function.

Recommendation: The rounding mechanism saves only fractional amounts of a token at best and introduces the possibility of the sum of all Safes' collateral value being larger than the total collateral in the contract. As such, we recommend the team remove this rounding mechanism.
Resolution: The team does not plan on redeploying the Arbitrum contract, but will provide us an updated contract before deploying to Ethereum mainnet and Binance Smart Chain mainnet.

---

Finding #3 - PotionVault - Low

Description: Users are allowed to fully leverage their collateral and mint the max amount of synth tokens directly after depositing.
Risk/Impact: If the price of the synthetic token increases immediately after a user opens their position they can be immediately liquidated.
Recommendation: The team should add a buffer amount between the max amount a user can mint and the minimum collateralization ratio to prevent immediate liquidations.
Resolution: The team has not yet addressed this issue.

---

Finding #4 - PotionVault - Informational

Description: The contract uses long-form representations for decimal and precision values that are repeated throughout the contract.
Recommendation: The team should consider using constant variables for these values. This will result in gas savings on each call as well as improving the code's readability.

Contract Overview

• This contract allows users to deposit approved tokens as collateral to mint "synth tokens".
• The synthetic tokens being minted are out of scope of this audit so we are unable to give an assessment in regard to security.
• Users must first open a "Safe" in order to interact with the contract.
• Any address may open a Safe when the contract's minting is enabled, the collateral token's minting is enabled, and the synth token's minting is enabled.
• Users may not open more than the "max safes" amount of Safes.
• Safes may only be opened between 9:30 AM EST and 4:00 PM EST Monday to Friday if the synth token has "Nasdaq timer" enabled.
• The amount of tokens being provided as collateral must be within the minimum collateral and maximum collateral amounts.
• Users will be minted synth tokens if an amount was specified.
• Users may only mint up to the "max amount" of synth tokens based on the amount of collateral provided, the current price returned by the Oracle associated with the synth token, and the synth token's "minimum collateralization ratio".
• The Oracle contract for synth tokens was out of scope for this audit so we are unable to provide an assessment in regard to security.
• Users may "close" one of their Safes given any user has not already interacted with the Safe in the same block.
• The current total amount of synth tokens minted through the Safe will be burned.
• The user will then receive the current total amount of collateral in the Safe.
• A 1% fee will be taken from the withdrawn collateral and transferred to the Collector address controlled by the team.
• Users may deposit additional collateral into one of their Safes given any user has not already interacted with the Safe in the same block and the collateral token's minting is enabled.
• A minimum of 1 token must be deposited when adding additional collateral.
• The total collateral in the safe must remain under the max collateral amount.
• Users may withdraw collateral from one of their Safes given any user has not already interacted with the Safe in the same block, the collateral token's minting is enabled, and the contract's minting is enabled.
• Collateral may only be withdrawn during 9:30 AM EST and 4:00 PM EST Monday to Friday if the synth token has Nasdaq timer enabled.
• The total amount of collateral in the safe after the withdrawal must remain above the minimum collateral amount.
• Users may only withdraw up to the "max amount" of collateral tokens based on the amount of collateral in the Safe, the current price returned by the Oracle associated with the synth token, and the synth token's "minimum collateralization ratio".
• A 1% fee is taken from the collateral being withdrawn and transferred to the Collector address controlled by the team.
• Users may burn a specified amount of synth tokens minted through one of their Safes given any user has not already interacted with the Safe in the same block.
• Users may mint a specified amount of synth tokens through one of their Safes given any user has not already interacted with the Safe in the same block, the synth token's minting is enabled, and the contract's minting is enabled.
• Synth token may only be minted during 9:30 AM EST and 4:00 PM EST Monday to Friday if the synth token has Nasdaq timer enabled.
• Users may only mint up to the "max amount" of synth tokens based on the amount of collateral provided, the current price returned by the Oracle associated with the synth token, and the synth token's "minimum collateralization ratio".
• Users may liquidate a specified amount of synth tokens from another user's Safe given that the synth token minting is enabled, the contract's minting is enabled, and the specified Safe is below the minimum collateralization ratio.
• The team must ensure that the minimum collateralization ratio remains high enough relative to the liquidation reward so that a Safe cannot be undercollateralized such that it is not worth liquidating.
• Safe's may only be liquidated during 9:30 AM EST and 4:00 PM EST Monday to Friday if the synth token it mints has Nasdaq timer enabled.
• The total amount of collateral liquidated from the safe will be proportional to the ratio of the amount of synth tokens provided out of the total supply.
• A 2% fee will be taken from the total liquidated collateral and transferred to the Collector address controlled by the team.
• The liquidating user will receive 80% of the liquidated collateral after fees.
• The Safe owner will receive the remaining liquidated collateral.
• The admin may update its own address at any time.
• The admin may update the Collector address at any time.
• The admin may enable and disable the contract's minting at any time.
• The admin may set the maximum and minimum collateral amounts to any values at any time.
• The admin may set the start time at any time. This must be set to 12:00 AM EST for the Nasdaq timer to function properly.
• The admin may enable and disable synth token minting and collateral token minting at any time.
• The admin may set the Oracle address for any synth token at any time.
• The admin may add a new synth token and collateral token at any time.
• The team must exercise caution when assigning the collateral token to avoid using fee-on-transfer tokens.
• The team must exercise extreme caution when selecting assets to be used as collateral. If a single stablecoin used as collateral depegs substantially, users will be able to mint an excess amount of synth tokens and liquidate other users at an unfair rate; ultimately resulting in a loss of users' funds.
• As the contracts are implemented with Solidity v0.8, they are safe from any possible overflows/underflows.

Audit Results

Inheritance Chart

Function Graph

Functions Overview

 ($) = payable function
 # = non-constant function
 
 Int = Internal
 Ext = External
 Pub = Public

 + [Int] AggregatorV3Interface 
    - [Ext] decimals
    - [Ext] description
    - [Ext] version
    - [Ext] getRoundData
    - [Ext] latestRoundData

 + [Int] IPotionVault 
    - [Ext] open #
    - [Ext] close #
    - [Ext] deposit #
    - [Ext] withdraw #
    - [Ext] burn #
    - [Ext] mint #
    - [Ext] liquidate #

 + [Int] pToken 
    - [Ext] mint #
    - [Ext] burn #
    - [Ext] balanceOf

 +  PotionVault (IPotionVault)
    - [Pub] Constructor #
    - [Ext] open #
    - [Pub] getSafe
    - [Int] updateSafe #
    - [Pub] getNumSafes
    - [Ext] close #
    - [Ext] deposit #
    - [Ext] withdraw #
    - [Ext] burn #
    - [Ext] mint #
    - [Ext] liquidate #
    - [Ext] setAdmin #
    - [Ext] setCanMint #
    - [Ext] setCollector #
    - [Ext] setMinCollateral #
    - [Ext] setMaxCollateral #
    - [Ext] setStartTime #
    - [Ext] setSynCanMint #
    - [Ext] setStableTokenCanMint #
    - [Ext] setSynOracle #
    - [Ext] addStableToken #
    - [Ext] addSynToken #

 + [Lib] Address 
    - [Int] isContract
    - [Int] sendValue #
    - [Int] functionCall #
    - [Int] functionCall #
    - [Int] functionCallWithValue #
    - [Int] functionCallWithValue #
    - [Int] functionStaticCall
    - [Int] functionStaticCall
    - [Int] functionDelegateCall #
    - [Int] functionDelegateCall #
    - [Int] verifyCallResultFromTarget
    - [Int] verifyCallResult
    - [Prv] _revert

 + [Lib] SafeERC20 
    - [Int] safeTransfer #
    - [Int] safeTransferFrom #
    - [Int] safeApprove #
    - [Int] safeIncreaseAllowance #
    - [Int] safeDecreaseAllowance #
    - [Prv] _callOptionalReturn #

 + [Int] IERC20 
    - [Ext] totalSupply
    - [Ext] balanceOf
    - [Ext] transfer #
    - [Ext] allowance
    - [Ext] approve #
    - [Ext] transferFrom #

About SourceHat

SourceHat has quickly grown to have one of the most experienced and well-equipped smart contract auditing teams in the industry. Our team has conducted 1800+ solidity smart contract audits covering all major project types and protocols, securing a total of over $50 billion U.S. dollars in on-chain value!
Our firm is well-reputed in the community and is trusted as a top smart contract auditing company for the review of solidity code, no matter how complex. Our team of experienced solidity smart contract auditors performs audits for tokens, NFTs, crowdsales, marketplaces, gambling games, financial protocols, and more!

Contact us today to get a free quote for a smart contract audit of your project!

What is a SourceHat Audit?

Typically, a smart contract audit is a comprehensive review process designed to discover logical errors, security vulnerabilities, and optimization opportunities within code. A SourceHat Audit takes this a step further by verifying economic logic to ensure the stability of smart contracts and highlighting privileged functionality to create a report that is easy to understand for developers and community members alike.

How Do I Interpret the Findings?

Each of our Findings will be labeled with a Severity level. We always recommend the team resolve High, Medium, and Low severity findings prior to deploying the code to the mainnet. Here is a breakdown on what each Severity level means for the project:

• High severity indicates that the issue puts a large number of users' funds at risk and has a high probability of exploitation, or the smart contract contains serious logical issues which can prevent the code from operating as intended.
• Medium severity issues are those which place at least some users' funds at risk and has a medium to high probability of exploitation.
• Low severity issues have a relatively minor risk association; these issues have a low probability of occurring or may have a minimal impact.
• Informational issues pose no immediate risk, but inform the project team of opportunities for gas optimizations and following smart contract security best practices.

• Go Home