Smart Contract Audit Report for Possum

Management Summary

Possum contacted Sayfer to perform a security audit on their smart contracts.

This report documents the research carried out by Sayfer targeting the selected resources defined under the research scope. Particularly, this report displays the security posture review for Possum’s smart contracts.

Over the research period of 40 research hours, we discovered 7 vulnerabilities in the contract.

After a review by the Sayfer team, we certify that all the security issues mentioned in this report have been addressed or acknowledged by the Possum team.

Risk Methodology

At Sayfer, we are committed to delivering the highest quality smart contract audits to our clients. That’s why we have implemented a comprehensive risk assessment model to evaluate the severity of our findings and provide our clients with the best possible recommendations for mitigation.

Our risk assessment model is based on two key factors: IMPACT and LIKELIHOOD. Impact refers to the potential harm that could result from an issue, such as financial loss, reputational damage, or a non-operational system. Likelihood refers to the probability that an issue will occur, taking into account factors such as the complexity of the contract and the number of potential attackers.

By combining these two factors, we can create a comprehensive understanding of the risk posed by a particular issue and provide our clients with a clear and actionable assessment of the severity of the issue. This approach allows us to prioritize our recommendations and ensure that our clients receive the best possible advice on how to protect their smart contracts.

Risk is defined as follows:

Protocol Overview

Protocol Introduction

Possum Labs is a novel DeFi concept focused on building a diverse range of self-regulating financial products. It is named ‘Possum’ to reflect the goal of creating a system where everyone is fairly rewarded. Possum Labs vision is centered on addressing longstanding issues in the current financial system, particularly the excessive control wielded by a few major players over global assets. This dominance often leads to misaligned incentives, like asset managers prioritizing their own fees over their clients’ investments. To make this vision a reality, Possum Labs is developing innovative financial tools, all governed by an on-chain system. The first of these products is called Possum Portals.

Audit Findings

Debt Deduction When Unstaking Can Underflow

Description

unstake(uint256) deducts

(_amount * maxLockDuration) / secondsPerYear

from maxStakeDebt and the function forceUnstakeAll() does the same for portalEnergy.

• Portal.sol:242; unstake(uint256)

accounts[msg.sender].maxStakeDebt -= (_amount * maxLockDuration) /
secondsPerYear;

• Portal.sol:279; forceUnstakeAll()

uint256 remainingDebt = accounts[msg.sender].maxStakeDebt -
accounts[msg.sender].portalEnergy;

As long as maxLockDuration does not change, this calculation can never underflow and the subtraction is fine. However, the value can be increased by calling updateMaxLockDuration(). In such scenarios, unstaking can fail, although a user’s position would be eligible for it.

For instance, consider the example where maxLockDuration is 91.25 days when a user creates a position with 100 tokens. maxStakeDebt will be set to 25. Directly afterwards, maxStakeDebt is increased to 100 days. In theory, the user should be able to unstake the whole position, but this request would try to decrease maxStakeDebt by ~27.4, which would underflow. In this case, the transaction will always revert and the user’s funds will remain locked until the maxLockDuration is changed again.

Mitigation

Set the value to 0 if the amount to deduct is larger than the position’s maxStakeDebt.

Positions Cannot Be Deleted or Recreated

Description

In stake(uint256), the logic for creating new positions and updating existing ones is different.

/ @dev Check if the user has a staking position, else initialize a new
stake
if(accounts[msg.sender].isExist = true){
    / @dev Update the user's stake info
    _updateAccount(msg.sender, _amount);
}
else {
        [...]
}

For new positions, the user can directly withdraw the staked tokens and get portal energy based on the current maximum lock duration.

else {
    uint256 maxStakeDebt = (_amount * maxLockDuration) / secondsPerYear;
    uint256 availableToWithdraw = _amount;
    uint256 portalEnergy = maxStakeDebt;
 
    accounts[msg.sender] = Account(true,
      block.timestamp,
      _amount,
      maxStakeDebt,
      portalEnergy,
      availableToWithdraw);
}

But when a position is updated, the portal energy is determined based on the staked balance.

• Portal.sol; _updateAccount(address, uint256)

function _updateAccount(address _user, uint256 _amount) private {
    / @dev Calculate the accrued portalEnergy since the last update
    uint256 portalEnergyEarned = (accounts[_user].stakedBalance *
    (block.timestamp - accounts[_user].lastUpdateTime)) / secondsPerYear;
 
        [...]
 
    / @dev Update the user's portalEnergy
    accounts[_user].portalEnergy += portalEnergyEarned;
 
        [...]
 
}

After a position is created for a user (and isExist is set to true), there is no way to delete it, even if all balances are withdrawn and no more portal energy is withdrawn.

This may lead to undesired behavior in users who haven’t interacted with the system for a long time. Consider a user that has withdrawn all tokens two years ago and has no portal energy left. If they decide to stake again, the update logic would be applied and the portal energy would not be increased based on the staked amount, although this is conceptually a completely new position. If they created the position from a different address instead, they would get the portal energy based on the staked amount.

Mitigation

Create a way for users to delete old inactive positions, perhaps ones that saw no activity for months or years

Funding Exchange Ratio Cannot Be a Decimal

Description

The fundingBalance in activatePortal() is directly multiplied by fundingExchangeRatio to calculate the required liquidity. Because of this logic, this ratio can only be an integer, values like 2.5 (which may be feasible in certain deployments) cannot be represented in the contract.

• Portal.sol:647; activatePortal()

uint256 requiredPortalEnergyLiquidity = fundingBalance *fundingExchangeRatio;

Mitigation

Consider storing the ratio as a decimal number with 18 decimal places and then dividing by 1e18 after the calculation.

Rounding of Earned Portal Energy Leads to Lower Rewards

Description

_updateAccount(address, uint256) divides the value earned since last time by 31536000 (the number of seconds each year) every time it is called, i.e. on every modification of the staked position.

uint256 portalEnergyEarned = (accounts[_user].stakedBalance *
    (block.timestamp - accounts[_user].lastUpdateTime)) / secondsPerYear;

Because division rounds down in Solidity, this can lead to situations where less rewards than expected are accrued.

Consider an extreme example where the user’s balance is 3153599. If, for example, _updateAccount(address, uint256) is called every 10 seconds, no rewards at all are accrued, because the division always rounds down to zero. If it were only called once after a year, the accrued portal energy would be 3153599, i.e. the user loses 3153599 in rewards.

Mitigation

Consider not dividing by secondsPerYear when accruing and only doing the division when the value is used. Like this, the impact of rounding is reduced significantly.

Contracts May not Be Deployable on Arbitrum

Description

All contracts are configured to be compiled with Solidity 0.8.20:

pragma solidity ^0.8.20;

Solidity 0.8.20 introduced the PUSH0 opcode, which currently is not supported on Arbitrum. For a deployment on Arbitrum, an older version of Solidity needs to be used or the EVM version needs to be set explicitly in the used framework (if this is not done already).

Mitigation

require(IERC20(portalEnergyToken).balanceOf(address(msg.sender)) =
remainingDebt, "Not enough Portal Energy Tokens");

require(IERC20(tokenToAcquire).balanceOf(msg.sender) = _amountInput,
"Insufficient balance");

require(accounts[_user].isExist = true);

/ @dev Update the user's stake info
accounts[msg.sender].stakedBalance -= _amount;
accounts[msg.sender].maxStakeDebt -= (_amount * maxLockDuration) /
secondsPerYear;
accounts[msg.sender].availableToWithdraw -= _amount;
        
        [...]
       
/ @dev Emit an event with the updated stake information
emit StakePositionUpdated(msg.sender,
accounts[msg.sender].lastUpdateTime,
accounts[msg.sender].stakedBalance,
accounts[msg.sender].maxStakeDebt,
accounts[msg.sender].portalEnergy,
accounts[msg.sender].availableToWithdraw);

if(accounts[msg.sender].portalEnergy <
accounts[msg.sender].maxStakeDebt) {
 
uint256 remainingDebt = accounts[msg.sender].maxStakeDebt -
accounts[msg.sender].portalEnergy;