- Hacken
- Audits
- warp-green
- [SCA] warp.green | Warp Green | May2024
Audit name:
[SCA] warp.green | Warp Green | May2024
Date:
May 21, 2024
Table of Content
Introduction
We express our gratitude to The warp.green Team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
warp.green is a protocol that facilitates the communication of messages across supported blockchains (Chia, Ethereum, and Base) through a trusted set of validators.
| title | content |
|---|---|
| Platform | EVM |
| Language | Solidity |
| Tags | Bridge; Fungible Token; Permit Token; Signatures; Centralization; Upgradable |
| Timeline | 14/05/2024 - 21/05/2024 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/warpdotgreen/cli/tree/master/contracts→ |
| Commit | dddc8a5 |
Review Scope
- Commit
- dddc8a5
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 warp.green |
| Audited By | Ivan Bondar |
| Approved By | |
| Website | https://warp.green/→ |
| Changelog | 17/05/2024 - Preliminary Report |
| 21/05/2024 - Final Report |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for warp.green
- Audited By
- Ivan Bondar
- Approved By
- Website
- https://warp.green/→
- Changelog
- 17/05/2024 - Preliminary Report
- 21/05/2024 - Final Report
System Overview
warp.green is a protocol that facilitates the communication of messages across supported blockchains (Chia, Ethereum, and Base) through a trusted set of validators. Applications can integrate with the protocol to enable cross-chain communication. At launch, two primary applications were introduced: an ERC-20 bridge and a CAT bridge.
The warp.green protocol uses a set of smart contracts deployed on the blockchain to manage the wrapping and unwrapping of assets and the sending and receiving of cross-chain messages.
The files in the scope:
ERC20Bridge.sol - Manages the bridging of ERC-20 tokens between Ethereum and Chia. It handles the wrapping of ERC-20 tokens on Chia and unwrapping them back to the original network.
Key Functions:
initializePuzzleHashes: Sets the puzzle hashes for burning and minting CATs on Chia.
receiveMessage: Receives and processes messages from the warp.green portal.
bridgeToChia: Bridges ERC-20 tokens to Chia.
bridgeEtherToChia: Bridges native Ether to Chia by wrapping it into milliETH.
bridgeToChiaWithPermit: Bridges ERC-20 tokens to Chia using a permit for gas-efficient token approval and transfer.
MilliETH.sol - Implements an ERC-20 token (milliETH) which is equivalent to 1/1000th of one ether. It allows the conversion between ether and milliETH.
Key Functions:
deposit: Mints milliETH tokens equivalent to the deposited ether value.
withdraw: Burns milliETH tokens and returns the equivalent amount of ether.
receive: Allows the contract to accept direct ether transfers and mints corresponding milliETH tokens.
WrappedCAT.sol - Manages the wrapping of Chia Asset Tokens (CATs) into ERC-20 tokens on Ethereum, allowing these CATs to be used within the Ethereum ecosystem.
Key Functions:
initializePuzzleHashes: Sets the puzzle hashes for locking and unlocking CATs on Chia.
receiveMessage: Processes messages from the warp.green portal to handle unwrapping of CATs.
bridgeBack: Burns Wrapped CAT tokens and sends a message to unlock the original CAT tokens on Chia.
Portal.sol - Handles the sending and receiving of cross-chain messages via a trusted set of validators.
Key Functions:
sendMessage: Sends a cross-chain message to another blockchain.
receiveMessage: Receives and relays a cross-chain message from another blockchain.
rescueEther: Allows the owner to transfer ether owned by the contract to specified addresses.
rescueAsset: Allows the owner to transfer ERC-20 tokens owned by the contract to specified addresses.
updateSigner: Updates the authorization status of a signer (validator).
updateSignatureThreshold: Updates the threshold of required signatures for message verification.
updateMessageToll: Updates the toll fee required to send messages.
IPortal.sol - Interface defining the functions and events for the warp.green portal contract.
IPortalMessageReceiver.sol - Interface defining the function for receiving messages from the warp.green portal.
IWETH.sol - Interface defining the deposit and withdraw functions for WETH (Wrapped Ether).
Privileged roles
Portal.sol:
Owner (validator cold key multisig): can manage signers, signature thresholds, message tolls, and assets held by the contract.
Executive Summary
Documentation quality
The total Documentation quality score is 10 out of 10.
Functional requirements have some gaps.
Basic system description is provided.
All roles in the system are described.
Use cases are described.
Technical description is detailed.
Run instructions are provided.
Technical specification is provided.
The NatSpec documentation is sufficient.
Code quality
The total Code quality score is 10 out of 10.
The development environment is configured.
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 by several users are tested.
Security score
Upon auditing, the code was found to contain 0 critical, 0 high, 2 medium, and 5 low severity issues. Out of these, 4 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
Dependency on Trusted Validators: The warp.green protocol relies on a trusted set of validators to verify and relay cross-chain messages. This dependency introduces risks associated with validator behavior and consensus. If validators fail to perform their duties correctly or act maliciously, it could compromise the integrity of the bridge, leading to delays, message loss, or incorrect message relays, ultimately affecting user trust and the protocol's reliability.
Administrative Control Over Protocol Parameters: The protocol's administrative roles, such as the owner of the Portal contract, have the ability to modify key parameters, including message toll fees, signer authorization, and signature thresholds. While these controls are necessary for maintaining and updating the protocol, they also introduce risks of misuse or arbitrary changes that could affect the protocol's stability and user trust. Users should remain vigilant about potential adjustments and the impact on their interactions with the protocol.
Risk of Message Toll Adjustments: The message toll fee required to send messages via the Portal can be updated by the owner. Sudden or significant increases in the toll fee could make it more expensive for users to send cross-chain messages, potentially reducing the protocol's usability and accessibility.
Absence of Time-lock Mechanisms for Critical Operations: The protocol currently does not implement time-lock mechanisms for critical administrative operations, such as updating signers or modifying toll fees. The absence of time-locks increases the risk of rapid and potentially harmful changes being executed without sufficient review or the ability to revert actions.
Flexibility and Risk in Contract Upgrades: The use of upgradable contracts allows the protocol to evolve and address issues promptly. However, this flexibility also introduces risks if the upgrade processes are not properly secured. Unauthorized or malicious upgrades could compromise the protocol's integrity.
Dependency on Off-chain Components: The sendMessage function in Portal.sol is responsible for integrating other Dapps and sending messages from the EVM to the Chia network. The warp.green protocol relies heavily on off-chain components and logic to process these messages. This reliance introduces several risks:
Compromise of Off-chain Components: If the off-chain components are compromised, they could lead to unauthorized message relays or message tampering.
Malfunction or Failures: Any malfunction or operational failure in the off-chain components could result in message delivery delays, failures, or incorrect message processing.
Uncovered Vulnerabilities: Off-chain logic is not part of this audit, which means potential vulnerabilities in the off-chain components remain unidentified and unaddressed.
Impact on Integrity and Security: Any issues with the off-chain logic can compromise the overall integrity and security of the warp.green protocol. This could lead to security breaches or loss of user assets.
Dynamic Chain Support: The protocol introduces the ability to dynamically update the list of supported chains. While this provides flexibility in managing and maintaining cross-chain interactions, it also introduces several risks:
Temporary Removal of Supported Chains: Chains that were previously supported can be removed from the list of supported chains. This can result in bridged funds being stuck on the bridged chain until support for that chain is reinstated.
Impact on User Assets: Users with assets bridged to or from a chain that is temporarily unsupported may face delays in accessing or recovering their funds.
Operational Flexibility: This mechanism allows for the suspension of support for chains undergoing maintenance or experiencing issues, providing operational flexibility. However, users should be aware of this risk and stay informed about the status of chain support.
User Awareness: Users should be vigilant and regularly check the list of supported chains to ensure their transactions are not affected by dynamic changes in chain support.
Solidity Version Compatibility and Cross-Chain Deployment: 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.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-2988 | Potential Fee Bypass in bridgeToChia and bridgeEtherToChia Functions | mitigated | Medium | |
| F-2024-2859 | Inadequate Signature Validation and Nonce Management in receiveMessage | fixed | Medium | |
| F-2024-3062 | Lack of Minimum Amount Leads to Zero Transfer | fixed | Low | |
| F-2024-2996 | Potential Failures in Ether Transfer Using transfer Function | fixed | Low | |
| F-2024-2987 | Incompatibility with Fee-On-Transfer and Rebasing Tokens in ERC20Bridge.sol | accepted | Low | |
| F-2024-2950 | Unrestricted messageToll Updates Pose Risk of Unexpected Fee Changes | fixed | Low | |
| F-2024-2948 | Front-Running Risk Due to Lack of Access Control in initializePuzzleHashes | mitigated | Low | |
| F-2024-2947 | Floating Pragma | fixed | Observation | |
| F-2024-2852 | Missing Validation for Supported Chains | fixed | Observation | |
| F-2024-2847 | Lack of Upper Bound on tip Parameter in WrappedCAT.sol and ERC20Bridge.sol | fixed | Observation |
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/warpdotgreen/cli/tree/master/contracts→ |
| Commit | dddc8a5f4876ce27ad5078616da074a2472bad24 |
| Whitepaper | |
| Requirements | https://docs.warp.green→ |
| Technical Requirements | https://docs.warp.green→ |
Scope Details
- Commit
- dddc8a5f4876ce27ad5078616da074a2472bad24
- Whitepaper
- Requirements
- https://docs.warp.green→
- Technical Requirements
- https://docs.warp.green→