Q2 2026 Security & Compliance Report67 incidents, $764M in losses, 88% from operational failures.
Get the report →

Audit name:

[SCA] Sky Marvel | skyBridge-SmartContract | Jan2025

Date:

Jan 27, 2025

Table of Content

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

Want a comprehensive audit report like this?

Introduction

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

The BridgeSKY contract is a cross-chain token bridge enabling users to deposit tokens on one blockchain and mint equivalent tokens on another.

Document

NameSmart Contract Code Review and Security Analysis Report for Sky Marvel
Audited ByAndy Cho
Approved ByAtaberk Yavuzer
Websitehttps://skymarvel.io/→
Changelog17/01/2025 - Preliminary Report
27/01/2025 - Final Report
PlatformBSC, SKY Chain
LanguageSolidity
TagsBridge, ERC20; Claims
Methodologyhttps://hackenio.cc/sc_methodology→
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Sky Marvel
    Audited By
    Andy Cho
    Approved By
    Ataberk Yavuzer
    Changelog
    17/01/2025 - Preliminary Report
    27/01/2025 - Final Report
    Platform
    BSC, SKY Chain
    Language
    Solidity
    Tags
    Bridge, ERC20; Claims

Audit Summary

8Total Findings
0Resolved
8Accepted
0Mitigated

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 is provided.

Code quality

  • The development environment is configured.

Test coverage

Code coverage of the project is 24.92% (branch coverage).

  • Deployment and basic user interactions are covered with tests.

  • Negative cases coverage is missed.

  • Interactions by several users are not tested thoroughly.

System Overview

The BridgeSKY is a cross-chain token bridge enabling users to deposit tokens on one blockchain and mint equivalent tokens on another.

BridgeSKY — Allows users to burn a token on one chain and mint an equivalent token on another chain through the bridge.

TOKEN — Simple erc20 token contract.

SkytokenPriceFeed — Price oracle contract to get the Sky coin price.

Privileged roles

  • The owner of the BridgeSKY contract can set a new fee, an SMC amount for the fee amount, a max length of the airdrop, a new receiver, a price feed address, a max token limit, whitelist tokens, and enable/disable currencies.

  • The owner of the TOKEN contract can mint tokens.

  • The admin of the SkytokenPriceFeed contract can add/remove an updater.

Potential Risks

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.

Flexibility and Risk in Contract Upgrades: The project's contracts are upgradeable, 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.

Findings

F-2025-8274Duplicate Calculation in Each Iteration
Status
accepted
Severity

Low
F-2025-8284Inconsistent Type Declaration For _sourceChainType variable
Status
accepted
Severity

Observation
F-2025-8283Unused Modifier
Status
accepted
Severity

Observation
F-2025-8282Mismatch Between Documentation and Contract Logic
Status
accepted
Severity

Observation
F-2025-8276Inefficient Operation of Calculating The Amount to Be Airdropped
Status
accepted
Severity

Observation
F-2025-8180Unused State Variable
Status
accepted
Severity

Observation
F-2025-8179Missing _disableInitializers() in Upgradable Contract Constructor
Status
accepted
Severity

Observation
F-2025-8178Best Practice Violation: Non Upgradeable Ownable Inheritance
Status
accepted
Severity

Observation
Code
―
Title
Status
Severity
F-2025-8274Duplicate Calculation in Each Iteration
accepted

Low
F-2025-8284Inconsistent Type Declaration For _sourceChainType variable
accepted

Observation
F-2025-8283Unused Modifier
accepted

Observation
F-2025-8282Mismatch Between Documentation and Contract Logic
accepted

Observation
F-2025-8276Inefficient Operation of Calculating The Amount to Be Airdropped
accepted

Observation
F-2025-8180Unused State Variable
accepted

Observation
F-2025-8179Missing _disableInitializers() in Upgradable Contract Constructor
accepted

Observation
F-2025-8178Best Practice Violation: Non Upgradeable Ownable Inheritance
accepted

Observation
1-8 of 8 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/TheRavneet/skyBridge-SmartContract→
Commit203d5a34cb20074e1d6627f611c84877f43f94d4
WhitepaperN/A
RequirementsBridgeSKY Contract Documentation.pdf
Technical RequirementsNatSpec

Assets in Scope

.
contracts
BridgeSKY.sol - . › contracts › BridgeSKY.sol
interface
IBridge.sol - . › contracts › interface › IBridge.sol
IPriceFeed.sol - . › contracts › interface › IPriceFeed.sol
IToken.sol - . › contracts › interface › IToken.sol
libraries
BasicMetaTransaction.sol - . › contracts › libraries › BasicMetaTransaction.sol
Ownable.sol - . › contracts › libraries › Ownable.sol
TransferHelper.sol - . › contracts › libraries › TransferHelper.sol
UtilityHelper.sol - . › contracts › libraries › UtilityHelper.sol
SkytokenPriceFeed.sol - . › contracts › SkytokenPriceFeed.sol
TOKEN.sol - . › contracts › TOKEN.sol

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Sky Marvel, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.

Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Foundry fuzzing suite was prepared for this task, and throughout the assessment, 7 invariants were tested over 100,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant

Test Result

Run Count

Deposits should be performed correctlyPassed100k+
Claims should be performed correctlyPassed100k+
Prices should be updated correctlyPassed100k+
Updating prices requires all validators to signPassed100k+
Duplicate signatures are not allows to update pricesPassed100k+
Should use a valid soure chain type to update pricesPassed100k+
Airdrop should be performed correctlyPassed100k+
  • Invariant

    Deposits should be performed correctly

    Test Result

    Passed

    Run Count

    100k+

    Invariant

    Claims should be performed correctly

    Test Result

    Passed

    Run Count

    100k+

    Invariant

    Prices should be updated correctly

    Test Result

    Passed

    Run Count

    100k+

    Invariant

    Updating prices requires all validators to sign

    Test Result

    Passed

    Run Count

    100k+

    Invariant

    Duplicate signatures are not allows to update prices

    Test Result

    Passed

    Run Count

    100k+

    Invariant

    Should use a valid soure chain type to update prices

    Test Result

    Passed

    Run Count

    100k+

    Invariant

    Airdrop should be performed correctly

    Test Result

    Passed

    Run Count

    100k+

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.

Disclaimer