Q1 2025 Web3 Security ReportAccess control failures led to $1.63 billion in losses
Discover report insights
  • Hacken
  • Audits
  • hot-wallet
  • [SCA] HOT Wallet / Hot Omni Token / Sep2024
Hot Wallet logo

Hot Wallet

Audit name:

[SCA] HOT Wallet / Hot Omni Token / Sep2024

Date:

Oct 9, 2024

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Hot Wallet team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

The HOT Omni token wallet consists of a multi-chain system that allows transfers of tokens among different chains (bridge).

Document

NameSmart Contract Code Review and Security Analysis Report for Hot Wallet
Audited ByDavid Camps Novi, Nataliia Balashova
Approved ByPrzemyslaw Swiatowiec
Website-
Changelog24/09/2024 - Preliminary Report; 09/10/2024 - Final Report;
PlatformEthereum, Base, Arbitrum and Polygon. In the future, integration with more EVM chains will be introduced.
LanguageSolidity
TagsBridge, Signatures, Wallet.
Methodologyhttps://hackenio.cc/sc_methodology→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Hot Wallet
    Audited By
    David Camps Novi, Nataliia Balashova
    Approved By
    Przemyslaw Swiatowiec
    Website
    -
    Changelog
    24/09/2024 - Preliminary Report; 09/10/2024 - Final Report;
    Platform
    Ethereum, Base, Arbitrum and Polygon. In the future, integration with more EVM chains will be introduced.
    Language
    Solidity
    Tags
    Bridge, Signatures, Wallet.
    Methodology
    https://hackenio.cc/sc_methodology→

Review Scope

Repositoryhttps://github.com/hot-dao/omni-wallet-solidity→
Commit40ff89f

Audit Summary

11Total Findings
4Resolved
7Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Functional requirements are mostly provided.

  • Technical description is partially provided.

Code quality

  • NatSpec is provided for MetaWallet but missing for RlpEncode..

  • The development environment is configured.

  • Best Practices are not followed: F-2024-6235, F-2024-6223, F-2024-6221.

Test coverage

Code coverage of the project is ~60%.

  • Deployment and basic interactions are covered with tests.

  • Negative cases coverage are partially covered.

  • Interactions by several users are not tested thoroughly.

System Overview

The HOT Omni token wallet consists of a multi-chain system allowing token transfers among chains (bridge).

  • MetaWallet - Contract that handles deposits and withdrawals of native and ERC20 tokens via signature.

  • RlpEncode - Library to manage the encoding required for signature validation.

Privileged roles

  • Owner:

    • Updates the addresses of the owner and the verifyAddress.

    • Closes the wallet contract deposit and withdraw operations.

    • Can withdraw native and ERC20 tokens from the contract.

Potential Risks

The nonces used for deposits and withdraws have different origin: whilst the deposit nonce is calculated on-chain in the MetaWallet contract, the withdraw nonce is generated in another part of the system that cannot be validated. Since the input nonce is divided by the constant NONCE_TS_SHIFT, it should be created taking solidity division truncation into account so that it does not provide a nonce of 0, or avoiding undesired values.

During withdraw, a require statement checks whether the nonce timestamp is expired. In case it is, the user can make a refund. However, this refund is managed outside of the scope.

The MetaWallet contract includes the functions withdrawToken() and withdrawEth(), which allow the contract owner to retrieve any funds.

Assembly code is present in the audited contracts, decreasing the readability and reliance of the system.

The audited project works as a bridge and, as such, it has a high dependency on off-chain and centralized processes to manage the communication and funds across different chains. This is a big part of the functionality that cannot be reviewed in this audit. A user relies on the protocol managers to correctly and fairly manage their funds once they perform a deposit and in case such a user requires a withdraw.

The project utilizes Solidity version 0.8.20 or highe, 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.

The methods deposit() for tokens, and withdraw() are payable, allowing callers to send some msg.value as a fee. However, there is no mechanism to control this fee or set any limits (i.e. there is no percentage fee or value recorded in the contract).

Findings

Code
―
Title
Status
Severity
F-2024-6207Precompile ecrecover May Lead to Signature Malleability
fixed

Medium
F-2024-6228Unchecked Return Value in Token Transfer May Lead to Unexpected Behavior
fixed

Low
F-2024-6225Lack of EIP712 Compliance May Result in Signature Replay
accepted

Low
F-2024-6222Use of transfer() to Send Native Assets may Revert
fixed

Low
F-2024-6223Visibility of State Variable is Not Defined
accepted

Observation
F-2024-6221Old Solidity Version May Result in Unsafe Code
accepted

Observation
F-2024-6262Unused Code Should be Removed
fixed

Observation
F-2024-6261Missing Zero Address Checks
accepted

Observation
F-2024-6260Single-Step Owner Transfer May Cause DOS
accepted

Observation
F-2024-6236 Missing Event Emission
accepted

Observation
1-10 of 11 findings

Identify vulnerabilities in your smart contracts.

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

Repositoryhttps://github.com/hot-dao/omni-wallet-solidity→
Commit40ff89f
Whitepaper-
Requirements./README.md
Technical Requirements./README.md

Assets in Scope

MetaWallet.sol - MetaWallet.sol
RlpEncode.sol - RlpEncode.sol

Disclaimer