Introduction
We express our gratitude to the LIFT team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
LIFT’s powerful AI Agents extract data from real-time content like sports, gaming, social and streaming, enabling mainstream adoption of AI Vision at massive scale.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for LIFT |
| Audited By | Stepan Chekhovskoi |
| Approved By | Grzegorz Trawinski, Przemyslaw Swiatowiec |
| Website | https://liftdata.ai→ |
| Changelog | 06/12/2024 - Initial Report |
| 18/12/2024 - Secondary Report | |
| Platform | Base |
| Language | Solidity |
| Tags | ERC-20, Staking |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for LIFT
- Audited By
- Stepan Chekhovskoi
- Approved By
- Grzegorz Trawinski, Przemyslaw Swiatowiec
- Website
- https://liftdata.ai→
- Changelog
- 06/12/2024 - Initial Report
- 18/12/2024 - Secondary Report
- Platform
- Base
- Language
- Solidity
- Tags
- ERC-20, Staking
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/PlayFi-Labs/playchain-contracts→ |
| Initial Commit | 7d5ade952192277c0a9b2d926b4ec04a8ddd432c |
| Secondary Commit | 19e045b76369a80e5ee57dc9593a3f098670d81f |
| Repository | https://github.com/PlayFi-Labs/data-machines-contracts→ |
| Initial Commit | 49067067fad02657e39d96624e765ce7e5665dc3 |
| Secondary Commit | 4a2ca2ec4d3a3f4058257c0c36c5fd663f545ef4 |
Review Scope
- Initial Commit
- 7d5ade952192277c0a9b2d926b4ec04a8ddd432c
- Secondary Commit
- 19e045b76369a80e5ee57dc9593a3f098670d81f
- Initial Commit
- 49067067fad02657e39d96624e765ce7e5665dc3
- Secondary Commit
- 4a2ca2ec4d3a3f4058257c0c36c5fd663f545ef4
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are partially missed.
Technical description do not cover the project setup process.
Contract interfaces are covered with NatSpecs.
Code quality
The code is well-structured.
Some redundancies are identified.
The development environment is configured.
Floating pragma is used in the token contract.
Test coverage
Code coverage of the project is 70% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is partially missed.
System Overview
Data Machines creates a slightly gamified way by which users can engage with our system before launch, and acts as a basic framework for our delegated proof-of-stake services. The audit covers DataGold Token, Data Machines Staking and Payment contracts.
DataGold Token has the following properties:
Name: DataGold
Symbol: dGOLD
Decimals: 18
Initial Supply: 10 000 000
Data Machines Payment is a simple contract forwarding ETH and WETH to stored payment received.
Data Machines Staking contract provides ETH staking with centralized rewards distribution. Users deposit WETH or ETH which converted to wstETH, user shares are stored in equivalent amount of stETH. Ratio of wstETH to stETH is expected to grow decreasing the amount of wstETH locked as user deposits. Excessive wstETH tokens are converted to WETH and then are distributed through out the investors according to off-chain calculated Merkle tree.
Privileged roles
The DataGold Token Admins are able to manage token Minters and Burners.
The DataGold Token Minters are able to infinitely mint the token.
The DataGold Token Burners are able to burn tokens they own.
The Data Machines Payment contract Admins are able to update the payment receiver and manage contract Pause Managers.
The Data Machines Payment contract Pause Managers are able to pause and unpause the payment processing functionality.
The Data Machines Staking contract Admins are able to adjust the swap slippage rate and manage Yield Harvesters, Pause Managers, Merkle Managers.
The Data Machines Staking contract Pause Managers are able to pause and unpause the deposits, withdrawals and reward claims.
The Data Machines Staking contract Yield Harvesters are able to trigger excessive wstETH tokens swap to WETH for further distribution.
The Data Machines Staking contract Merkle Managers are able to update rewards epoch providing new rewards distribution Merkle tree root.
Potential Risks
Centralized Control of Minting Process: The DataGold token contract’s design allows for centralized control over the minting process, posing a risk of unauthorized token issuance, potentially diluting the token value and undermining trust in the project's economic governance.
Single Points of Failure and Control: The project is fully centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.
Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.
System Reliance on External Contracts: The functioning of the system significantly relies on wstETH farming, Oracles and Dex external contracts. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-7521 | Possibly Invalid Swap Rate due to Lack of Oracle Output Validation | fixed | Medium | |
| F-2024-7522 | Lack of ERC20 Operation Success Validation | fixed | Low | |
| F-2024-7526 | Inefficient Merkle Proof Verification | fixed | Observation | |
| F-2024-7525 | Redundant Modifiers | accepted | Observation | |
| F-2024-7524 | Public Functions that Can be External | 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/PlayFi-Labs/playchain-contracts→ |
| Initial Commit | 7d5ade952192277c0a9b2d926b4ec04a8ddd432c |
| Secondary Commit | 19e045b76369a80e5ee57dc9593a3f098670d81f |
| Repository | https://github.com/PlayFi-Labs/data-machines-contracts→ |
| Initial Commit | 49067067fad02657e39d96624e765ce7e5665dc3 |
| Secondary Commit | 4a2ca2ec4d3a3f4058257c0c36c5fd663f545ef4 |
| Whitepaper | N/A |
| Requirements | NatSpec comments |
| Technical Requirements | README.md |
Scope Details
- Initial Commit
- 7d5ade952192277c0a9b2d926b4ec04a8ddd432c
- Secondary Commit
- 19e045b76369a80e5ee57dc9593a3f098670d81f
- Initial Commit
- 49067067fad02657e39d96624e765ce7e5665dc3
- Secondary Commit
- 4a2ca2ec4d3a3f4058257c0c36c5fd663f545ef4
- Whitepaper
- N/A
- Requirements
- NatSpec comments
- Technical Requirements
- README.md
Assets in Scope
Appendix 3. Additional Valuables
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.