- Hacken
- Audits
- digital-oro-international
- [SCA] Digital Oro | Sweepstakes | Dec2024
Audit name:
[SCA] Digital Oro | Sweepstakes | Dec2024
Date:
Jan 21, 2025
Table of Content
Introduction
We express our gratitude to the Digital Oro team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Digital Oro is an organization that tokenizes real-world assets into NFTs that can be used as financial digital assets.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Digital Oro |
| Audited By | Kornel Światłowski, Andy Cho |
| Approved By | Przemyslaw Swiatowiec, Ataberk Yavuzer |
| Website | https://doi.global/→ |
| Changelog | 16/12/2024 - Preliminary Report |
| 21/01/2025 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | Non-fungible Token (NFT), Token Sales, ERC-721, Lottery |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Digital Oro
- Audited By
- Kornel Światłowski, Andy Cho
- Approved By
- Przemyslaw Swiatowiec, Ataberk Yavuzer
- Website
- https://doi.global/→
- Changelog
- 16/12/2024 - Preliminary Report
- 21/01/2025 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- Non-fungible Token (NFT), Token Sales, ERC-721, Lottery
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/digitaloro/sweepstakes→ |
| Commit | 3a37181023acb05d80f25d24eefe559cddf93b92 |
| Remediation commit | a59038370fc32e0abf88696cd1f495a40723c14e |
Review Scope
- Commit
- 3a37181023acb05d80f25d24eefe559cddf93b92
- Remediation commit
- a59038370fc32e0abf88696cd1f495a40723c14e
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are provided.
Technical description is provided.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 67.54% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is partially missed.
System Overview
The DOI_Token is a ERC721 token, that allows for creating and managing unique tokens that serve dual purposes: Gold Membership access and raffle participation. It facilitates the minting of tokens in exchange for 100 USDT, with payments securely handled using OpenZeppelin’s SafeERC20 library. The contract includes mechanisms to track token usage for membership claims and raffles, ensuring tokens cannot be reused for these purposes.
The DOI_Raffle contract implements a decentralized raffle system where participants use eligible tokens to enter draws conducted in waves. Each wave operates with predefined parameters, including participant limits and prize configurations. The contract ensures fair winner selection through a pseudorandom shuffle of entries, and the winner receives a payout distributed over a specified duration via the DOI_PayoutManager contract.
The DOI_PayoutManager manages periodic asset distributions, specifically in USDT, to users. It enables authorized parties to initialize, deactivate, reactivate, and claim payouts while enforcing user-specific schedules and limits. The contract integrates with a raffle system for automated payout initialization.
The DOI_Gold is an ERC721 token for managing Gold Membership NFTs, designed to reward users of the DOI platform. It integrates with the DOI_Token contract to validate ticket eligibility, requiring 20 DOI_Token tokens for minting. The contract enforces a maximum supply cap of 5,000 tokens. Upon transfer, the verification status of tokens is reset to ensure validity control.
The DOI_AdminManager contract is a utility contract that manages a dynamic list of admin addresses with elevated privileges. It uses an EnumerableSet to efficiently store and retrieve admin addresses, ensuring uniqueness and allowing iteration.
The DOI_AccessControl contract provides a modular access control mechanism by integrating with an external DOI_AdminManager contract. It restricts certain function calls to addresses designated as admins within the DOI_AdminManager or the contract owner. The owner, managed via OpenZeppelin's Ownable2Step, can update the reference to a new DOI_AdminManager contract to maintain flexibility in access control.
The DOI_RaffleVRF contract facilitates the secure generation of random numbers using Chainlink VRF v2.5 for a raffle system. It manages requests for random values, tracks their fulfillment status, and stores the results, ensuring that only the designated DOI_Raffle contract can initiate these requests.
Privileged roles
The DOI_Token contract uses a Ownable2Step library from OpenZeppelin to restrict access to important functions. Contract owner can:
Update the USDT contract address.
Sets the address for the
DOI_GoldMembership contract.Sets the address for the
DOI_Rafflecontract.Withdraw the USDT from the contract to the owner address.
The DOI_Raffle contract uses a DOI_AccessControl contract to restrict access to important functions.
Contract owner can:
Updates the
DOI_Tokencontract address.Updates the
DOI_PayoutManagercontract address.Pauses the contract.
Unpauses the contract.
Admin address can:
Finalizes the current wave and selects a winner.
Draw a winner of current wave.
Starts a new raffle wave.
The DOI_Gold contract uses a DOI_AccessControl contract to restrict access to important functions. Contract owner can update the DOI_Token contract address. Admin address can update the verification status of a token.
The DOI_PayoutManager contract uses a DOI_AccessControl contract to restrict access to important functions. Contract owner can update the DOI_Token contract address. Admin address can update the verification status of a token.
The DOI_AdminManager contract uses a Ownable2Step library from OpenZeppelin to restrict access to important functions. Contract owner can remove and add a new admi.
The DOI_AccessControl contract uses a Ownable2Step library from OpenZeppelin to restrict access to important functions. Contract owner can set a new DOI_AdminManager contract address.
Potential Risks
External Calls in Iteration Risks: Making external calls within loops increases the risk of gas exhaustion, potentially leading to failed transactions and reduced contract reliability, especially when processing large datasets.
Dynamic Array Iteration Gas Limit Risks: The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.
Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases. Like verification status of the Gold ERC721 token or addresses of contracts.
Administrative Key Control Risks: The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-7612 | Lack of Prize Coverage Validation in Raffle Contract | accepted | High | |
| F-2024-7595 | Pseudo-Randomness Enables Raffle Outcome Manipulation | fixed | High | |
| F-2024-7645 | Potential Front-Running When DOIToken Is Sold in Secondary Market | fixed | Medium | |
| F-2025-8353 | Multiple Payouts Possible Due to Insufficient Validation in FinalizeWave() | fixed | Medium | |
| F-2024-7679 | Absence of Setter Restrictions Allows for Arbitrary Address Updates | fixed | Low | |
| F-2024-7658 | Missing Input Validation for Wave Parameters Causes Denial of Service of Raffle Contract | fixed | Low | |
| F-2024-7681 | Misleading Description for Payout::monthlyAmount Field | fixed | Observation | |
| F-2024-7680 | Redundant Imports | fixed | Observation | |
| F-2024-7653 | Potential Gas Optimization by Declaring Immutable Variables as Constant | fixed | Observation | |
| F-2024-7651 | Unnecessary Receive Function in Contracts Rejecting Ether Transfers | fixed | Observation |
Appendix 1. Definitions
Severities
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. |
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.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/digitaloro/sweepstakes→ |
| Commit | 3a37181023acb05d80f25d24eefe559cddf93b92 |
| Remediation commit | a59038370fc32e0abf88696cd1f495a40723c14e |
| Whitepaper | N/A |
| Requirements | README.md |
| Technical Requirements | README.md |
Scope Details
- Commit
- 3a37181023acb05d80f25d24eefe559cddf93b92
- Remediation commit
- a59038370fc32e0abf88696cd1f495a40723c14e
- Whitepaper
- N/A
- Requirements
- README.md
- Technical Requirements
- README.md
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Digital Oro, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 6 invariants and fuzzing scenarios were tested over 10,000 runs each. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant and Fuzzing | Test Result | Run Count |
|---|---|---|
| Mint random amount of DOI Token | Passed | 10,000 |
| Mint Gold Token with random amount of DOI Token | Passed | 10,000 |
| Mint Gold Token multiple times | Passed | 10,000 |
| Claim prize before first month | Passed | 10,000 |
| Claim prize between first and second month | Passed | 10,000 |
| Claim prize after whole release period | Passed | 10,000 |
Invariant and Fuzzing
- Mint random amount of DOI Token
Test Result
- Passed
Run Count
- 10,000
Invariant and Fuzzing
- Mint Gold Token with random amount of DOI Token
Test Result
- Passed
Run Count
- 10,000
Invariant and Fuzzing
- Mint Gold Token multiple times
Test Result
- Passed
Run Count
- 10,000
Invariant and Fuzzing
- Claim prize before first month
Test Result
- Passed
Run Count
- 10,000
Invariant and Fuzzing
- Claim prize between first and second month
Test Result
- Passed
Run Count
- 10,000
Invariant and Fuzzing
- Claim prize after whole release period
Test Result
- Passed
Run Count
- 10,000
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.