- Hacken
- Audits
- hello-labs
- [SCA] Hello Labs | Bridge | Apr2025
Audit name:
[SCA] Hello Labs | Bridge | Apr2025
Date:
May 16, 2025
Table of Content
Introduction
We express our gratitude to the HELLO Labs team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
HELLO Labs is a Web3 ecosystem built around producing, incubating and distributing exclusive TV shows, games, NFTs and live events.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for HELLO Labs |
| Audited By | Lukasz Mikula; Olesia Bilenka |
| Approved By | Ivan Bondar |
| Website | https://www.hello.one/killerwhales, http://www.hello.one/→ |
| Changelog | 30/04/2025 - Preliminary Report |
| 16/05/2025 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | Bridge |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for HELLO Labs
- Audited By
- Lukasz Mikula; Olesia Bilenka
- Approved By
- Ivan Bondar
- Changelog
- 30/04/2025 - Preliminary Report
- 16/05/2025 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- Bridge
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Hello1Official/bridge-contract-evm→ |
| Commit | 71f5debf90ea7d4f289536e5b125444c19f13081 |
| Retest Commit | 74fc67c8df5390284ccea56332fccbf47da56910 |
Review Scope
- Commit
- 71f5debf90ea7d4f289536e5b125444c19f13081
- Retest Commit
- 74fc67c8df5390284ccea56332fccbf47da56910
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are detailed.
Technical description is limited.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 0% (branch coverage).
There are errors occurring when running the coverage.
System Overview
HelloBridge is a cross-chain bridge system for transferring tokens between different blockchains with the following main contracts:
HelloToken (Hello) — A standard ERC-20 token with blacklisting capabilities based on OpenZeppelin's upgradeable contracts:
Name: Hello
Symbol: HELLO
Decimals: 18
Total supply: 1 billion tokens (minted to deployer during initialization)
HelloBridge — The core bridge contract that handles cross-chain token transfers:
Allows users to bridge tokens to supported chains
Charges configurable fees on transfers (default 2%)
Requires signatures from two trusted validators for token claims
Fee distribution: 0.5% to burn, 0.5% to staking pool, 1% to treasury
HelloBridgeStore — Storage contract tracking deposits and withdrawals:
Records how much users have deposited to destination chains
Tracks how much users have withdrawn from source chains
Only allows the bridge contract to update state
HelloBridgeSolanaAdapter — Specialized adapter for Solana bridging:
Handles Solana-specific signatures and bridging logic
Includes migration capabilities from a previous adapter contract
Maintains its own tracking for Solana-specific deposits and withdrawals
Privileged roles
The owner of each contract has extensive control, including:
Setting fee percentages and recipient wallets
Pausing/unpausing deposits and claims
Managing supported chains
Setting withdrawal signers who authorize token claims
Migrating contracts and replacing adapters
Blacklisting addresses in the token contract
Withdrawal signers must sign messages to authorize token claims on destination chains, giving them significant power over when users can access their bridged funds.
Potential Risks
Bridge Availability: Reliance on external signers for validating withdrawals creates a centralization risk where unavailable signers could effectively freeze the bridge, preventing users from withdrawing their tokens.
Centralized Minting to a Single Address: The project concentrates minting tokens in a single address, raising the risk of fund mismanagement or theft, especially if key storage security is compromised.
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.
Absence of Time-lock Mechanisms for Critical Operations: Without time-locks on critical operations, there is no buffer to review or revert potentially harmful actions, increasing the risk of rapid exploitation and irreversible changes.
Single Points of Failure and Control: The project is fully or partially 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.
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.
Single Entity Upgrade Authority: The token ecosystem grants a single entity the authority to implement upgrades or changes. This centralization of power risks unilateral decisions that may not align with the community or stakeholders' interests, undermining trust and security.
Flexibility and Risk in Contract Upgrades: The project's HelloToken.sol token is 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.
Dependency on Off-Chain Components: The system relies on off-chain components and infrastructure that were not included in the scope of this audit. This dependency introduces potential risks, as vulnerabilities, misconfigurations, or failures in these off-chain components could impact the security, availability, or correct functioning of the audited smart contracts.
Total Supply Exceeds Defined Limit Due to Per-Chain Minting: According to the specification, the total token supply should be capped at 1 billion tokens. However, the current implementation mints 1 billion tokens on each chain, effectively multiplying the total supply across all chains.
Commits Containing Additional Code in the Remediation Stage: During the remediation phase of this audit, code that was not directly related to the fixes was introduced. This poses a risk of new vulnerabilities emerging from the additional code, which was not reviewed by Hacken's team. To ensure that no security issues are overlooked in these commits, we recommend conducting a re-audit.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1012 | Missing Cross-Chain Token Transfer Mechanism in HelloBridge | accepted | Critical | |
| F-2025-1009 | Incorrect Global Deposit Handling in _claimFromBridge Causes DoS and Accounting Inconsistencies | accepted | Critical | |
| F-2025-1011 | Out-of-Order Cumulative Signatures in claimFromChainSolana Permanently Block Remaining Withdrawals | accepted | High | |
| F-2025-1011 | Mutable oldSolanaAdapter Reference Enables Signature-Bound Double Withdrawal | accepted | High | |
| F-2025-1009 | Potential Balance Inconsistency in HelloBridgeSolanaAdapter Caused by Fee Mismatch | fixed | High | |
| F-2025-1010 | Fee Splitting Logic Inconsistency Causes Incorrect Token Transfers and Potential Reverts | mitigated | Medium | |
| F-2025-1005 | Incomplete blacklisting implementation | fixed | Medium | |
| F-2025-1011 | Lack of Nonce-Based Accounting in Claim Logic Increases Off-Chain Complexity | accepted | Low | |
| F-2025-1011 | Missing Chain Source Validation in sendToChain and claimFromChain Enables Bypassing of Adapter Enforcement and Fee Logic | mitigated | Low | |
| F-2025-1011 | Separate Solana Handling in HelloBridge Leading to Unnecessary Complexity and Gas Overhead | mitigated | Low |
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/Hello1Official/bridge-contract-evm→ |
| Commit | 71f5debf90ea7d4f289536e5b125444c19f13081 |
| Retest Commit | 74fc67c8df5390284ccea56332fccbf47da56910 |
| Whitepaper | https://isurutmv.notion.site/HELLO-Platform-Smart-Contracts-Documentation-1df3b21ac92580e6b88cfc07eb63b2ad→ |
| Requirements | README.md |
| Technical Requirements | README.md; NatSpec |
Scope Details
- Commit
- 71f5debf90ea7d4f289536e5b125444c19f13081
- Retest Commit
- 74fc67c8df5390284ccea56332fccbf47da56910
- Requirements
- README.md
- Technical Requirements
- README.md; NatSpec
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.