- Hacken
- Audits
- openware-yellow-network
- [SCA] Yellow Network | Vault | Sept 2024
Introduction
We express our gratitude to the Openware (Yellow Network) team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Yellow Network is a decentralized Layer-3 peer-to-peer mesh network allowing brokers to communicate, trade, and aggregate the liquidity of connected nodes.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Openware (Yellow Network) |
| Audited By | Seher Saylik, Giovanni Franchi |
| Approved By | Grzegorz Trawinski |
| Website | https://www.yellow.org/→ |
| Changelog | 12/09/2024 - Preliminary Report |
| Changelog | 25/09/2024 - Final Report |
| Platform | Ethereum, Polygon, Linea |
| Language | Solidity |
| Tags | Vault, ERC20 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Openware (Yellow Network)
- Audited By
- Seher Saylik, Giovanni Franchi
- Approved By
- Grzegorz Trawinski
- Website
- https://www.yellow.org/→
- Changelog
- 12/09/2024 - Preliminary Report
- Changelog
- 25/09/2024 - Final Report
- Platform
- Ethereum, Polygon, Linea
- Language
- Solidity
- Tags
- Vault, ERC20
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/layer-3/broker-contracts/tree/master→ |
| Commit | fff15f5 |
| Remediation commit | 9190fd8 |
Review Scope
- Commit
- fff15f5
- Remediation commit
- 9190fd8
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are missed.
Technical description is not provided.
NatSpecs are insightful and complete.
Code quality
The code violates best practises in terms of data validation, readability and external interactions.
The code does not adhere to optimal standards regarding external dependencies handling and compilation directives.
The contracts present some gas inefficiency.
The development environment is configured.
Test coverage
Code coverage of the project is 91.67% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is covered.
Interactions by several users are not tested.
System Overview
Yellow Network is a vault design with the following contracts:
LiteVault — a contract that allows users to deposit and withdraw ERC20 tokens or ETH, while maintaining user balances and requiring authorization for withdrawals. Authorization conditions, specified by an external authorization contract, must be met for withdrawals, and these conditions can be updated by the protocol owner at any time.
BrokerToken — a utility token that is simple ERC20 token with permit functionality.
It has the following attributes:
Name: will be assigned during the deployment.
Symbol: will be assigned during the deployment.
Decimals: will be assigned during the deployment.
Total supply: will be assigned during the deployment.
TimeRangeAuthorizer — a contract that restricts actions based on a specified time range, allowing only those occurring outside the forbidden period. It validates the time range at initialization and implements the authorize() function to check if the current time is within or outside the forbidden range.
IAuthorize — Interface for an authorization contract that validates if certain actions are allowed.
IVault — interface for a vault contract that allows users to deposit, withdraw, and check balances of tokens and ETH.
Privileged roles
The owner of the LiteVault contract can set the authorizer address.
Potential Risks
The contract owner has the ability to set an invalid or malicious authorizer, potentially leading to scenarios where users' funds could become inaccessible, or the expected time-based restrictions can be altered at will. This introduces a centralization risk, as users may lose trust in the system if the authorizer is changed arbitrarily, resulting in disrupted functionality or locking of user funds.
The absence of a cap on the Broker token supply might expose users to inflation, dilution, and potential market instability, which can undermine the token's value and disrupt its ecosystem.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-5999 | Use of transfer() Instead of call() to Send Native Tokens | fixed | Low | |
| F-2024-6005 | Constructor Not Setting Authorizer and Missing Zero Address Check in setAuthorizer() Function | fixed | Low | |
| F-2024-6004 | Lack of Token Whitelisting Check in deposit() Function | accepted | Low | |
| F-2024-6002 | Potential Abuse by Owner in setAuthorizer() Function | fixed | Low | |
| F-2024-6007 | Functions not Used Internally Can be Marked as External | fixed | Observation | |
| F-2024-6001 | Missing Event Emitting | fixed | Observation | |
| F-2024-6000 | Missing Zero Address Validation | fixed | Observation | |
| F-2024-5997 | Floating Pragma | mitigated | Observation | |
| F-2024-6016 | Variables Only Defined in the Constructor Should be Marked as Immutable | fixed | Observation | |
| F-2024-6015 | Lack of Named Parameters in Mappings | 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, 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.
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/layer-3/broker-contracts/tree/master→ |
| Commit | fff15f51b0e6c3963aeeb01b0f3ce661721c8c9b |
| Remediation commit | 9190fd813c33b33297906a96a41c14c9689852c6 |
| Whitepaper | https://docs.yellow.org/→ |
| Requirements | N/A |
| Technical Requirements | N/A |
Scope Details
- Commit
- fff15f51b0e6c3963aeeb01b0f3ce661721c8c9b
- Remediation commit
- 9190fd813c33b33297906a96a41c14c9689852c6
- Whitepaper
- https://docs.yellow.org/→
- Requirements
- N/A
- Technical Requirements
- N/A