- Hacken
- Audits
- galileo-protocol
- [SCA] Galileo Protocol | Marketplace + Escrow | Feb2024
Audit name:
[SCA] Galileo Protocol | Marketplace + Escrow | Feb2024
Date:
Apr 30, 2024
Table of Content
Introduction
We express our gratitude to the Galileo Protocol team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
| title | content |
|---|---|
| Platform | EVM |
| Language | Solidity. |
| Tags | ERC721, Marketplace, RWA. |
| Timeline | 08/04/2024 - 29/04/2024 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/Galileo-Protocol-io/Galileo_Contracts→ |
| Commit | 8f73fe8c79aae71c0ede587abbd1689a963e6144 |
Review Scope
- Commit
- 8f73fe8c79aae71c0ede587abbd1689a963e6144
Audit Summary
10/10
87.31%
10/10
9/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 Galileo Protocol |
| Audited By | Carlo Parisi, Viktor Raboshchuk |
| Approved By | Przemyslaw Swiatowiec |
| Website | https://www.galileoprotocol.io/→ |
| Changelog | 14/03/2024 - Preliminary Report |
| 05/04/2024 - Final Report | |
| 15/04/2024 - Re-Audit | |
| 29/04/2024 - Final Report |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Galileo Protocol
- Audited By
- Carlo Parisi, Viktor Raboshchuk
- Approved By
- Przemyslaw Swiatowiec
- Changelog
- 14/03/2024 - Preliminary Report
- 05/04/2024 - Final Report
- 15/04/2024 - Re-Audit
- 29/04/2024 - Final Report
System Overview
The Galileo Protocol is a tokenisation platform that aims to revolutionise the authentication and ownership of luxury goods and real-world assets. The protocol has following contracts:
The GalileoEscrow - smart contract designed to handle escrow functionality for the Galileo Protocol marketplace. It utilizes OpenZeppelin contracts for access control, reentrancy protection, and ERC-721 and ERC-20 token standards. The contract allows users to submit and manage disputes related to the purchase of non-fungible tokens (NFTs) on the Galileo Protocol platform and fund distribution in a decentralized manner.
GalileoFactory - smart contract employees OpenZeppelin libraries for access control and upgradeability, serving as a factory for deploying and managing instances of the "GalileoProtocol" contract. The contract tracks and updates the total deployed GalileoProtocols smart contracts, manages a mapping associating serial numbers with contract addresses and token IDs, and enforces the uniqueness of initials against each NFT of the collection.
GalileoMarketplace - The Galileo Marketplace is a decentralized marketplace smart contract. The contract facilitates NFTs' listing, buying, and reselling, integrating features such as royalties, referral fees, and flexible pricing. Users can create and list NFTs for sale, and buyers can purchase them with a flexible pricing structure that includes fees for royalties, referrals, and marketplace fees. The contract also supports the redemption of NFTs and provides functionality for adjusting prices, changing fees, and managing the marketplace address. The contract incorporates access control, EIP-712 for structured domain-specific data, and various OpenZeppelin libraries for security and upgradability. The Galileo Marketplace aims to provide a versatile and secure platform for NFT transactions.
GalileoProtocol - smart contract is an Ethereum-based NFT protocol. It inherits from several OpenZeppelin libraries, including ERC721URIStorage for NFT functionality, AccessControl for role-based access control, and EIP712 for signature verification. The contract introduces a unique minting mechanism where sub-admins can mint NFTs, pay minting fees in ERC20 tokens, and transfer ownership of the minted NFTs. The contract also supports bulk minting and URI updates, a lazy minting feature that involves signed vouchers for NFT purchases, and a dynamic fee structure for minting operations.
interfaces/IEscrow.sol - Interface for the Escrow contract.
interfaces/IFactory.sol - Interface for the Factory contract.
interfaces/IMarket.sol - Interface for the Market contract.
interfaces/IProtocol.sol - Interface for the Protocol contract.
lib/GalileoRoyalties.sol - smart contract serves as a utility contract that facilitates the management of royalty data associated with non-fungible tokens. It introduces a DataStruct that includes arrays for addresses and corresponding royalty percentages, along with an overall royalty amount. The addData function allows users to input and update royalty-related information for a specific NFT, associating addresses with their respective royalty percentages. The getData function retrieves this stored data for a given NFT. The contract provides a flexible and organized way to handle royalty information, which can be utilized by the main GalileoMarketplace contract for transparent and customizable royalty distribution among NFT stakeholders.
lib/ReferralStruct.sol - smart contract that contains ReferralParameters solidity structure type.
Privileged roles
GalileoEscrow
ESCROWMANAGERROLE: Manages the escrow process, including dispute resolution.
ADMIN_ROLE: Administers the contract, making decisions on disputes, and withdrawing funds.
MARKETPLACE_ROLE: Assigned to the Galileo Marketplace contract, allowing it to configure collections and add asset data.
GalileoFactory
DEFAULTADMINROLE - default admin role for all roles. Can deploy the new smart contract.
ASSIGN_ROLE - can update serial number and serial mapping
GalileoMarketplace
SUBADMINROLE - can change the fee of the marketplace, and change the address of the one who received a fee.
VALIDATOR_ROLE - able to purchase auto redeem of multiple items, buy multiple NFTs, and to redeem pNFT.
SUPERADMINROLE - able to set the address of galileo escrow contract.
GalileoProtocol
SUBADMINROLE - can mint NFT, mint NFT to a specific user address, mint multiple tokens in a single transaction, can purchase NFTs using vouchers. Can set the value of referral bool to true or false.
SUPERADMINROLE - can set the referral fee for a specified price range.
Executive Summary
Documentation quality
The total Documentation Quality score is 9 out of 10.
Functional requirements are mostly provided.
Technical description is provided.
NatSpec is provided.
Code quality
The total Code Quality score is 10 out of 10.
Test coverage
Code coverage of the project is 87.31% (branch coverage).
Deployment and basic user interactions are covered with tests.
Security score
Upon auditing, the code was found to contain 9 critical, 5 high, 3 medium, and 4 low severity issues. All issues were fixed, leading to a security score of 0 out of 10, upon performing the remediation check, every issue was found to have been resolved, the code contains 0 critical, 0 high, 0 medium and 0 low severity issues, 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.4. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
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.
In the GalileoProtocol contract, SUBADMINROLE can mint an unrestricted amount of NFTs.
The admin can change the URI of any NFT and burn specific token ID. This could potentially allow the owner to change the URI of the NFT or destroy NFTs they do not own, resulting in substantial losses for the rightful owners of the NFTs.
The admin role of the GalileoMarketplace contract can withdraw user funds.
The require statements for referFee, royaltyAmount, feePercent, and the fee amount in setReferralFees are checked for a high fee value equal to 100%, meaning that fees can be set to excessively high values.
The protocol contains multiple violations of the CEI (Check-Effect-Interact) pattern, which can lead to a known attack vector in Solidity called a "reentrancy attack." In this attack, a malicious actor can exploit the call to an external contract to re-enter and manipulate the calling contract.
processAssetsQuery and processAssetsUpdate could potentially facilitate a Denial of Service attack if the length of the array _assets.tokenIds is too big of a number.
In the function makeDecision of the contract GalileoEscrow transfers of tokens are made without checking the return value of those transfers.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-1639 | Skipping elements in for loop | fixed | Critical | |
| F-2024-2110 | Inability to redeem NFTs bought with buyNFT function | mitigated | Critical | |
| F-2024-2109 | Inability to list NFTs minted with mintTo function on GalileoMarketplace | mitigated | Critical | |
| F-2024-2107 | Potential for frontrunning in _recover function | fixed | Critical | |
| F-2024-2096 | Lost shipment fee in NFT purchase | fixed | Critical | |
| F-2024-2048 | Unnecessary token id validation | fixed | Critical | |
| F-2024-1469 | Unauthorized listing of NFTs | fixed | Critical | |
| F-2024-1452 | Incorrect royalty calculation for multiple NFTs | fixed | Critical | |
| F-2024-1451 | User pay tax twice in _buyNFT function | fixed | Critical | |
| F-2024-2106 | Inconsistent state in redeem function of GalileoMarketplace contract | fixed | High |
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/Galileo-Protocol-io/Galileo_Contracts→ |
| Commit | 8f73fe8c79aae71c0ede587abbd1689a963e6144 |
| Whitepaper | |
| Requirements | Detail Document of Functionality.docs |
| Technical Requirements | Detail Document of Functionality.docs |
Scope Details
- Commit
- 8f73fe8c79aae71c0ede587abbd1689a963e6144
- Whitepaper
- Requirements
- Detail Document of Functionality.docs
- Technical Requirements
- Detail Document of Functionality.docs