Introduction
We express our gratitude to the BlockSquare team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Blocksquare is a comprehensive real estate tokenization platform designed to cater to a diverse range of businesses, from those with extensive international real estate portfolios to boutique investment clubs focusing on local investment models.
title | content |
---|---|
Platform | EVM |
Language | Solidity |
Tags | Factory; Upgradable; Proxy; Yield Farming |
Timeline | 26/01/2024 - 20/02/2024 |
Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
---|---|
Repository | https://github.com/blocksquare/oceanpoint-contracts/→ |
Commit | d9c5ebf |
Review Scope
- Commit
- d9c5ebf
Audit Summary
10/10
85.6%
10/10
10/10
The system users should acknowledge all the risks summed up in the risks section of the report
Document Information
This report may contain confidential information about IT systems and the intellectual property of the Customer, as well as information about potential vulnerabilities and methods of their exploitation.
The report can be disclosed publicly after prior consent by another Party. Any subsequent publication of this report shall be without mandatory consent.
Document | |
---|---|
Name | Smart Contract Code Review and Security Analysis Report for BlockSquare |
Audited By | Ivan Bondar |
Approved By | Ataberk Yavuzer |
Website | https://blocksquare.io/→ |
Changelog | 30/01/2024 - Preliminary Report |
20/02/2024 - Final Report |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for BlockSquare
- Audited By
- Ivan Bondar
- Approved By
- Ataberk Yavuzer
- Website
- https://blocksquare.io/→
- Changelog
- 30/01/2024 - Preliminary Report
- 20/02/2024 - Final Report
System Overview
The Blocksquare Marketplace Pool System represents a sophisticated smart contract framework, aimed at streamlining investment and reward distribution processes in real estate projects. This system is uniquely structured to balance the interests of Certified Partners (CPs) and investors, promoting transparent and secure financial interactions.
Files in the scope:
MarketplacePoolProxyFactory.sol - functions as the core factory for creating individual Marketplace Pool Proxies. It maintains critical configurations such as logic contract addresses, BST staking contracts, and governance wallets. Key functionalities include:
Marketplace Pool Creation: Generates new Marketplace Pool Proxies, each linked to a specific Certified Partner (CP).
Configuration Management: Allows for updating key components like implementation logic, BST staking contracts, and governance wallets.
MarketplacePoolProxy.sol - Serves as a Transparent Upgradeable Proxy for each Marketplace Pool. It leverages the ERC1967Proxy pattern.
MarketplacePool.sol - the primary contract where investment and reward mechanisms are actualized. It is upgradeable, owned, and reentrancy-guarded, incorporating ERC20 functionalities for internal accounting:
CP and Investor Interaction: Facilitates CPs to initialize pools with collateral and set lock periods, while allowing investors to contribute during designated campaign periods.
Investment Campaign Management: Manages the campaign's start time, duration, and maximum pledges, dynamically adjusting investment caps.
Reward Distribution: Implements a mechanism for distributing rewards based on individual stakes and total pool balance.
Collateral and Lock Management: Provides functions for CP collateral withdrawal, liquidation, and lock period extensions, governed by ownership privileges.
Privileged roles
MarketplacePoolProxyFactory.sol:
Owner :
Manages the creation of new pools, updates implementation logic, and configures key contracts like BST staking and governance wallet.
MarketplacePool.sol:
Owner:
Holds the power to allow CP collateral withdrawal, extend lock periods, and liquidate CP collateral under defined conditions.
Executive Summary
Documentation quality
The total Documentation Quality score is 10 out of 10.
Functional requirements have some gaps:
Project overview is detailed.
Roles and permissions are described.
Use cases are described.
For each contract all futures are described.
Technical description is robust:
Run instructions are provided.
Technical specification is provided.
NatSpec is sufficient.
Code quality
The total Code Quality score is 10 out of 10.
The development environment is configured.
Test coverage
Code coverage of the project is 85.6% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is partially missed.
Interactions by several users are not tested thoroughly.
Security score
Upon auditing, the code was found to contain 1 critical, 0 high, 2 medium, and 4 low severity issues. All issues were fixed in the remediation part of this audit, leading to a security score of 10 out of 10.
All identified issues are detailed in the “Findings” section of this report.
Summary
The comprehensive audit of the customer's smart contract yields an overall score of 9.5. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
Centralized Upgrades: The factory contract acts as a central point for upgrading the implementation logic of all proxy contracts. By updating the implementation address in the factory contract, all associated proxies will use the new logic.
Solidity Version Compatibility and Cross-Chain Deployment: The project utilizes Solidity version 0.8.20 or higher, which includes the introduction of the PUSH0
(0x5f
) opcode. This opcode is currently supported on the Ethereum mainnet but may not be universally supported across other blockchain networks. Consequently, deploying the contract on chains other than the Ethereum mainnet, such as certain Layer 2 (L2) chains or alternative networks, might lead to compatibility issues or execution errors due to the lack of support for the PUSH0 opcode. In scenarios where deployment on various chains is anticipated, selecting an appropriate Ethereum Virtual Machine (EVM) version that is widely supported across these networks is crucial to avoid potential operational disruptions or deployment failures.
Conditional Reward Distribution: Rewards can only be added to pools that are marked as successful. This introduces an element of uncertainty, as rewards depend on the successful status of the pool.
Dependence on External Action: Rewards are allocated manually through the addReward
function and only after the pool ends. This means there's no guaranteed reward during the pool's active period.
Variable Reward Amounts: The total reward depends on the amount specified in addReward
call. This can lead to variability in reward amounts, with no predefined or fixed reward structure.
Findings
Code ― | Title | Status | Severity | |
---|---|---|---|---|
F-2024-0664 | Calculation Discrepancy in MarketplacePool Post-Campaign Distribution | fixed | Critical | |
F-2024-0658 | Incorrect Maximum Pledge Calculation in depositInCampaign Function | fixed | Medium | |
F-2024-0629 | Inconsistent Use of Upgradeable Contracts and Incomplete Initialization in MarketplacePool | fixed | Medium | |
F-2024-0662 | Owner-Controlled Liquidation of CP Collateral | fixed | Low | |
F-2024-0661 | Restrictive CP Wallet Collateral Withdrawal Logic in MarketplacePool Contract | fixed | Low | |
F-2024-0635 | Lack of Validation for Start Time and Duration in MarketplacePool's Campaign | fixed | Low | |
F-2024-0631 | Variable Shadowing in MarketplacePool Contract | fixed | Low | |
F-2024-0663 | Absence of Deposit Verification in Withdraw Function | fixed | Observation | |
F-2024-0660 | Missing Error Messages in require Statements | fixed | Observation | |
F-2024-0659 | Checks-Effects-Interactions Pattern Violation in _deposit Function | fixed | Observation |
Identify vulnerabilities in your smart contracts.
Appendix 1. Severity Definitions
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
---|---|
Repository | https://github.com/blocksquare/oceanpoint-contracts/→ |
Commit | bdb3d6372e35685c7bdb96d0693f9f5cc55b1a90 |
Whitepaper | N/A |
Requirements | NatSpec |
Technical Requirements | https://docs.oceanpoint.fi/for-developers/marketplace-pools; NatSpec→ |
Scope Details
- Commit
- bdb3d6372e35685c7bdb96d0693f9f5cc55b1a90
- Whitepaper
- N/A
- Requirements
- NatSpec
- Technical Requirements
- https://docs.oceanpoint.fi/for-developers/marketplace-pools; NatSpec→