- Hacken
- Audits
- bloqhouse-technologies-b-v
- [SCA] Bloqhouse Technologies | RWA | Mar2023
Audit name:
[SCA] Bloqhouse Technologies | RWA | Mar2023
Date:
Mar 22, 2023
Table of Content
Introduction
We express our gratitude to the Bloqhouse Technologies B.V. team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Bloqhouse Technologies offers a real world asset tokenization protocol, which aims to enable asset providers to fractionalize assets such as, but not limited to, real estate, land, property, on the blockchain as NFTs.
| title | content |
|---|---|
| Platform | EVM |
| Language | Solidity |
| Tags | ERC721; RWA |
| Timeline | 06/03/2023 - 24/03/2023 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://bitbucket.org/alfredpersson/token-shares-solidity/src/master→ |
| Commit | cbdc7c0d6162346b96cf62cb2ff93c15f416819e |
Review Scope
- Commit
- cbdc7c0d6162346b96cf62cb2ff93c15f416819e
Audit Summary
10/10
100%
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 Bloqhouse Technologies B.V. |
| Audited By | Hacken |
| Website | http://www.bloqhouse.com/→ |
| Changelog | 13/03/2023 - Initial Review |
| 24/03/2023 - Second Review |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Bloqhouse Technologies B.V.
- Audited By
- Hacken
- Website
- http://www.bloqhouse.com/→
- Changelog
- 13/03/2023 - Initial Review
- 24/03/2023 - Second Review
System Overview
The project is a real world asset tokenization protocol, which aims to enable asset providers to fractionalize assets such as, but not limited to, real estate, land, property, on the blockchain as NFTs.
RWATP (Real World Asset Tokenization Protocol) is an ERC721 based tokenization protocol. One instance of RWATP can have multiple assets, this enables one asset provider to handle several assets in one contract. An asset is a set of NFTs, one NFT represents a share of the asset. E.g if an asset consists of 100 NFTs then one NFT represents 1% of the asset.
The contract admin (asset provider or someone else) can decide how to mint and distribute the NFTs, either through minting the NFTs to the asset provider, to a user, or delegating the minting to a separate contract that can then add additional logic to the distribution process, for example crypto payment.
The supply of an asset is not fixed, but controlled by the contract admin. The contract enables issuance of new NFTs for an asset, thus diluting the supply, at their discretion. Likewise the admin can enable burning of NFTs, concentrating the supply. However, these features can be locked in perpetuity to ensure a constant number of NFTs for an asset.
The admin of the contract has rights to the funds such as burning, minting, pausing transfers, setting whitelist functionality(only allowing whitelisted addresses to transfer their tokens), and transferring them from users. This functionality can be locked by the admin to never be enabled again.
The files in the scope:
RWAT.sol: The ERC721 contract that represents the assets. Can be controlled by the admin.
ISNR.sol: The interface for obtaining the Token URI.
Privileged roles
DEFAULTADMINROLE: The DEFAULTADMINROLE is inherited from the OpenZeppelin AccessControl.sol contract. It is the role that can grant or revoke all other roles. Presumably this should be given to a secure multisig and not used for anything other than granting/revoking the other roles.
Admin: The ADMIN role controls all issuance, burning and settings of the contract.
Handler: HANDLER can be given to a separate contract adding additional logic to the minting process. This role can only control the minting of new NFTs.
Whitelister: There is one role for adding users to the whitelist, this is separate from the admin role to add an extra level of security.
User: A user has no special privileges unless the whitelist is enabled, then the user must be on the whitelist in order to do anything other than holding the NFT.
Executive Summary
Documentation quality
The total Documentation quality score is 10 out of 10.
Functional requirements are comprehensive.
Technical description is detailed.
NatSpec is consistent.
Code quality
The total Code quality score is 10 out of 10.
Solidity best practices are followed.
Style guides are followed.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is present.
Interactions with several users are tested thoroughly.
Security score
Upon auditing, the code was found to contain 0 critical, 4 high, 0 medium, and 3 low severity issues. Out of these, 7 issues have been addressed and resolved, 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 10. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
The admin has comprehensive rights to user funds which makes the project centralized. These rights include forcing funds out of wallets without a user's permission, pausing transfers, changing name, symbol, and asset caps.
The contracts are upgradable and the current audit covers only the implementation at the time of the review. Any further implementations are not covered by this audit.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-0609 | Contradiction | fixed | High | |
| F-2023-0608 | Double-Spending | fixed | High | |
| F-2023-0607 | Data Consistency | fixed | High | |
| F-2023-0606 | EIP Standard Violation | fixed | High | |
| F-2023-0612 | Unindexed Events | fixed | Low | |
| F-2023-0611 | Shadowing State Variable | fixed | Low | |
| F-2023-0610 | Floating Pragma | fixed | Low |
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://bitbucket.org/alfredpersson/token-shares-solidity/src/master→ |
| Commit | cbdc7c0d6162346b96cf62cb2ff93c15f416819e |
| Whitepaper | Not provided |
| Requirements | Provided→ |
| Technical Requirements | Provided→ |