Halborn Logo

New Staking Saloon - Seascape


Prepared by:

Halborn Logo

HALBORN

Last Updated 04/26/2024

Date of Engagement by: May 11th, 2022 - May 12th, 2022

Summary

83% of all REPORTED Findings have been addressed

All findings

6

Critical

0

High

0

Medium

2

Low

1

Informational

3


1. INTRODUCTION

\client engaged Halborn to conduct a security audit on their smart contracts beginning on 2022-05-11 and ending on May 12th, 2022. The security assessment was scoped to the smart contracts provided to the Halborn team.

The contract in scope was an updated version of the Staking Saloon minigame, with a new reward mechanism.

2. AUDIT SUMMARY

The team at Halborn was provided one week for the engagement and assigned a full-time security engineer to audit the security of the smart contract. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.

The purpose of this audit is to:

    • Ensure that smart contract functions operate as intended

    • Identify potential security issues with the smart contracts

In summary, Halborn identified some security risks that were mostly addressed by the \client team.

3. TEST APPROACH & METHODOLOGY

Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of this audit. While manual testing is recommended to uncover flaws in logic, process, and implementation, automated testing techniques help enhance coverage of the bridge code and can quickly identify items that do not follow security best practices. The following phases and associated tools were used throughout the term of the audit:

    • Research into architecture and purpose

    • Smart contract manual code review and walkthrough

    • Graphing out functionality and contract logic/connectivity/functions (solgraph)

    • Manual assessment of use and safety for the critical Solidity variables and functions in scope to identify any arithmetic related vulnerability classes

    • Manual testing by custom scripts

    • Static Analysis of security for scoped contract, and imported functions (Slither)

    • Testnet deployment (Brownie, Remix IDE)

4. SCOPE

The assessment was scoped to the smart contract available in \href{https://github.com/liumaosong/seascape-smartcontracts/blob/main/contracts/mini-game/game-3/NewStakingSaloon.sol}{GitHub} at commit ID 3a438cc3d4f7dc615b0609c67785d340c820da62.

Remediations were checked up until commit f4d62567a58fdbcb582cb83bac36eca846917148.

5. RISK METHODOLOGY

Vulnerabilities or issues observed by Halborn are ranked based on the risk assessment methodology by measuring the LIKELIHOOD of a security incident and the IMPACT should an incident occur. This framework works for communicating the characteristics and impacts of technology vulnerabilities. The quantitative model ensures repeatable and accurate measurement while enabling users to see the underlying vulnerability characteristics that were used to generate the Risk scores. For every vulnerability, a risk level will be calculated on a scale of 5 to 1 with 5 being the highest likelihood or impact.
RISK SCALE - LIKELIHOOD
  • 5 - Almost certain an incident will occur.
  • 4 - High probability of an incident occurring.
  • 3 - Potential of a security incident in the long term.
  • 2 - Low probability of an incident occurring.
  • 1 - Very unlikely issue will cause an incident.
RISK SCALE - IMPACT
  • 5 - May cause devastating and unrecoverable impact or loss.
  • 4 - May cause a significant level of impact or loss.
  • 3 - May cause a partial impact or loss to many.
  • 2 - May cause temporary impact or loss.
  • 1 - May cause minimal or un-noticeable impact.
The risk level is then calculated using a sum of these two values, creating a value of 10 to 1 with 10 being the highest level of security risk.
Critical
High
Medium
Low
Informational
  • 10 - CRITICAL
  • 9 - 8 - HIGH
  • 7 - 6 - MEDIUM
  • 5 - 4 - LOW
  • 3 - 1 - VERY LOW AND INFORMATIONAL

6. SCOPE

Out-of-Scope: New features/implementations after the remediation commit IDs.

7. Assessment Summary & Findings Overview

Critical

0

High

0

Medium

2

Low

1

Informational

3

Impact x Likelihood

HAL-01

HAL-02

HAL-03

HAL-04

HAL-05

HAL-06

Security analysisRisk levelRemediation Date
ADMIN CAN CHANGE SESSION DETAILS AFTER THE START OF A SESSIONMediumSolved - 05/30/2022
NOT CHECKING BALANCE BEFORE AND AFTER UNTRUSTED TOKENS TRANSFERSMediumRisk Accepted
UNCHECKED CONTRACT BALANCELowSolved - 05/30/2022
COMMENTED OUT CODEInformationalSolved - 05/30/2022
POSSIBLE SIGNATURE REPLAYInformational-
USING ++I CONSUMES LESS GAS THAN I++ IN LOOPSInformationalSolved - 05/30/2022

8. Findings & Tech Details

8.1 ADMIN CAN CHANGE SESSION DETAILS AFTER THE START OF A SESSION

// Medium

Description

Testing revealed that the setType function allowed the owner of the contract to change details regarding running sessions. Should this privilege be abused or the private key of the owner be stolen, users might risk of burning their NFTs without their knowledge when unstaking. This is due to the function allowing to set the NFTs in a certain session to burn and whether users get a bonus by playing the game.

Code Location

NewStakingSaloon.sol Lines#

//change type about session
  function setType(uint256 _sessionId, bool _burn, bool _specify) external onlyOwner{
      Session storage _session = sessions[_sessionId];
      require(block.timestamp <= (_session.startTime + _session.period), "saloon: session end");
      _session.burn    = _burn;
      _session.specify = _specify;
  }
Score
Impact: 5
Likelihood: 1
Recommendation

SOLVED: The Seascape team removed the function.

\newpage

8.2 NOT CHECKING BALANCE BEFORE AND AFTER UNTRUSTED TOKENS TRANSFERS

// Medium

Description

None

Code Location

NewStakingSaloon.sol Lines# 512-540

    //Get check-in revenue
    function getSignInReward(uint256 _sessionId, uint8 _tagNum, uint8 v, bytes32 r, bytes32 s) external 
        Params storage params = signinRewards[_sessionId][_tagNum];
        Session storage _session = sessions[_sessionId];
        require(received[_sessionId][msg.sender][_tagNum] == false, "saloon: this signid reward is already received");
        require(_tagNum <= _session.signinRewardNum, "saloon: this reward do not _tagNum");
        IERC20 token = IERC20(params.token);
        uint256 NftId = 0;

        {
            bytes32 _messageNoPrefix = keccak256(abi.encodePacked(_sessionId, _tagNum, msg.sender));
            bytes32 _message = keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", _messageNoPrefix));
            address _recover = ecrecover(_message, v, r, s);
            require(_recover == verifier,  "Verification failed");
        }

        if (params.quality > 0) {
           NftId = nftFactory.mintQuality(msg.sender, params.generation, params.quality);
        }

        if (params.amount > 0) {
            require(token.transferFrom(owner(), msg.sender, params.amount), "saloon: transferFrom reward failed");
        }
        received[_sessionId][msg.sender][_tagNum] = true;
        emit GetSignInReward(msg.sender, _sessionId, _tagNum, NftId, params.amount);
    }
Score
Impact: 5
Likelihood: 1
Recommendation

RISK ACCEPTED: The Seascape team accepted the risk, as they will only use a trusted token, Crowns.

\newpage

8.3 UNCHECKED CONTRACT BALANCE

// Low

Description

Testing revealed that when a session is created, there are no checks to ensure that the contract balance is enough to pay the reward. This could lead to failed transactions when users unstake or claim their rewards.

Code Location

NewStakingSaloon.sol Lines# 117-156

function startSession(
    address _rewardToken,
    uint256 _totalReward,
    uint256 _period,
    uint256 _startTime,
    address _verifier
)
    external
    onlyOwner
{
    require(_rewardToken != address(0), "Token can't be zero address");
    require(_startTime > block.timestamp, "Seascape Staking: Seassion should start in the future");
    require(_period > 0, "Seascape Staking: Session duration should be greater than 0");
  require(_totalReward > 0, "Seascape Staking: Reward amount should be greater than 0");
    require(_verifier != address(0), "verifier can't be zero address");

    if (lastSessionId > 0) {
        require(!isActive(lastSessionId), "Seascape Staking: Can't start when session is active");
    }

    /// @dev required CWS balance of this contract
    // require(crowns.balanceOf(address(this)) >= _totalReward, "Seascape Staking: Not enough balance of Crowns for reward");

    //--------------------------------------------------------------------
    // creating the session
    //--------------------------------------------------------------------
    uint256 _sessionId = sessionId.current();
    uint256 _rewardUnit = _totalReward.mul(MULTIPLIER).div(_period);
    sessions[_sessionId] = Session(_totalReward, _period, _startTime, 0, 0, _rewardUnit, 0, 0, _startTime, true, false, 0);

    //--------------------------------------------------------------------
    // updating rest of session related data
    //--------------------------------------------------------------------
    sessionId.increment();
    rewardToken = IERC20(_rewardToken);
    lastSessionId = _sessionId;
    verifier = _verifier;

    emit SessionStarted(_sessionId, _totalReward, _startTime, _startTime + _period);
}
Score
Impact: 2
Likelihood: 2
Recommendation

SOLVED: The Seascape team amended the code to add contract balance checks.

\newpage

8.4 COMMENTED OUT CODE

// Informational

Description

There are instances within the code where commented code is left from previous development iterations. While this does not cause any security concerns, it makes the contract less readable.

Code Location

NewStakingSaloon.sol Lines# 137-138

Score
Impact: 1
Likelihood: 1
Recommendation

SOLVED: The Seascape team removed commented code for readability.

\newpage

8.5 POSSIBLE SIGNATURE REPLAY

// Informational

Description
Finding description placeholder
Score
Impact:
Likelihood:

8.6 USING ++I CONSUMES LESS GAS THAN I++ IN LOOPS

// Informational

Description

In the loop below, the variable i is incremented using i++. It is known that, in loops, using ++i costs less gas per iteration than i++. This does not only apply to the iterator variable. It also applies to variables declared within the loop code block.

Code Location

NewStakingSaloon.sol Line #372-374

   for(uint _index = 0; _index < 3; _index++){
        _interests = _interests.add(calculateInterest(_sessionId, msg.sender, _index));
    }
Score
Impact: 1
Likelihood: 1
Recommendation

SOLVED: The Seascape team amended the code as suggested to optimize the contract.

\newpage

Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.

© Halborn 2024. All rights reserved.