Q1 2025 Web3 Security ReportAccess control failures led to $1.63 billion in losses
Discover report insights
  • Hacken
  • Audits
  • kaia
  • [SCA] KAIA / Bridge + Staking / Mar2024
Kaia logo

Kaia

Audit name:

[SCA] KAIA / Bridge + Staking / Mar2024

Date:

Apr 25, 2024

Table of Content

→Introduction
→Audit Summary
→Document Information
→System Overview
→Executive Summary
→Risks
→Findings
→Appendix 1. Severity Definitions
→Appendix 2. Scope
→Disclaimer

Want a comprehensive audit report like this?

Introduction

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

Dragon smart contracts is a set of service programs actively used in Klaytn blockchain. The contracts include service chain bridge, KIP-103. KIP-113, KIP-149, AddressBook and Staking implementations.

titlecontent
PlatformKlaytn (EVM)
LanguageSolidity
TagsBridge, Staking, Registry
Timeline20/03/2024 - 25/04/2024
Methodologyhttps://hackenio.cc/sc_methodology→

    Review Scope

    Repositoryhttps://github.com/klaytn/dragon→
    Initial Commitcecafe841eb090d8ac94ae9adbbce117cb3e02e6
    Remediation Commitb4610903172049d97363cfff98e8c1a189330809

    Audit Summary

    Total8.6/10
    Security Score

    10/10

    Test Coverage

    85.3%

    Code Quality Score

    8/10

    Documentation Quality Score

    5/10

    28Total Findings
    12Resolved
    11Accepted
    5Mitigated

    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

    NameSmart Contract Code Review and Security Analysis Report for Kaia
    Audited ByStepan Chekhovskoi / Lead SC Auditor
    Olesia Bilenka / SC Auditor
    Approved ByGrzegorz Trawinski / Expert SC Auditor
    Websitehttps://klaytn.foundation→
    Changelog12/04/2024 - Preliminary Report
    25/04/2024 - Remediation Report

    • Document

      Name
      Smart Contract Code Review and Security Analysis Report for Kaia
      Audited By
      Stepan Chekhovskoi / Lead SC Auditor
      Olesia Bilenka / SC Auditor
      Approved By
      Grzegorz Trawinski / Expert SC Auditor
      Website
      https://klaytn.foundation→
      Changelog
      12/04/2024 - Preliminary Report
      25/04/2024 - Remediation Report

    System Overview

    Service Chain Bridge

    This is a centralized bridge implementation which aims to connect Service Chains → with the main Klaytn chain.

    The bridge is managed by the operators. According to the concept, operators are the nodes managing the service chain. However, anyone is able to deploy the bridge between any pair of chains and set arbitrary operators. Operators should manually process transfer requests on the destination side with no delivery guarantee.

    The bridge implementation supports ERC20, ERC721, and native tokens.

    The bridge contracts can be configured to operate in mint/burn mode, which means ERC20 and ERC721 tokens must allow mint/burn operations for both sides of the bridge implementation. Then, incoming tokens would be burned at initial chain and minted at the destination chain. The mint/burn mode allows the bridge to operate without a balance; otherwise, the bridge requires a corresponding amount of tokens at the destination chain to correctly process the transfer.

    The bridge owner is able to whitelist ERC20 and ERC721 tokens processed by the bridge.

    System Governance

    This is a centralized configuration parameters registry implementation.

    The registry allows the owner to set parameters by name and the block since which the parameter should be applied.

    The registry allows querying parameters by the block number, utilizing an effective checkpoint architecture internally.

    System KIP

    This is a centralized treasury funds rebalancing helper.

    The smart contract allows the owner to interactively register accounts for rebalancing. Then, it requires approval from the accounts for retirement. When the actions are approved, the contract state is locked indicating the rebalance result.

    System KIP

    This is a centralized nodes public keys registry implementation.

    The smart contract allows the owner to add CN nodes (registered at the Address Book) with their public keys and POPs to the registry.

    The list of nodes can be queried from the smart contract to retrieve the registered public keys and POPs.

    System KIP

    This is a centralized configuration address registry implementation.

    The registry allows the owner to set system addresses by name and the block since which the address should be activated.

    The registry allows to check whether an address is active or not and query  the active addresses list.

    System Consensus

    This is a decentralized registry managed by a quorum of admins.

    The Address Book manages the list of addresses of POC, KIR, CN Staking, and Spare contracts.

    The CN Staking allows to lock/withdraw KLAY and manage some configuration parameters by the admins.

    Executive Summary

    Documentation quality

    The total Documentation Quality score is 5 out of 10.

    • NatSpecs are partially provided.

    • A brief system overview is provided; however, the functional requirements are insufficient.

    • The technical description is not finalized.

    • A brief description of privileged roles is provided.

    Code quality

    The total Code Quality score is 8 out of 10.

    • Solidity naming conventions are violated.

    • Gas optimizations can be performed.

    Test coverage

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

    • Coverage of the long-deployed Bridge and Consensus contracts is estimated at 80%.

    Security score

    Upon auditing, the code was found to contain 0 critical, 0 high, 2 medium, and 9 low severity issues. The findings were resolved with source code update, 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 8.6. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.

    Risks

    Single Points of Failure and Control: The project is mostly 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. Additionally, there are several privileges that worth mentioning:

    • Bridge: There is no guarantee that the bridging request would be processed.

    • Bridge: The owner is able to set arbitrary bridging fee for native and ERC-20 tokens.

    • Bridge: The operators are able to withdraw any funds from the smart contract.

    • KIP113: The owner is privileged to change the registered public keys to the arbitrary ones without the nodes approval.

    Dynamic Array Iteration Gas Limit Risks: Some view functions of the smart contracts return unlimited amount of data or iterate an unbounded loop. Usage of the functions within other smart contracts may lead to DoS issues due to data amount growth.

    Findings

    Code
    ―
    Title
    Status
    Severity
    F-2024-1899KIP103: Possible Finalizing Process Stuck due to Unlimited Admin Lists Looping
    mitigated

    Medium
    F-2024-1720Bridge: Possible Native Token Transfer Stuck due to Custom Receiver Receive Logic
    fixed

    Medium
    F-2024-2084Consensus: Possible Requests Execution Stuck due to Unlimited Requests List Looping
    accepted

    Low
    F-2024-2075Consensus: Possible Reward Address Revising Block due to Unlimited Stakings List Looping
    mitigated

    Low
    F-2024-2071Consensus: Possible Staking Withdraw Block due to Custom Receiver Receive Logic
    accepted

    Low
    F-2024-1873KIP113: Possible Unregister Process Block due to Unlimited Nodes List Looping
    mitigated

    Low
    F-2024-1761Bridge: Possible Token Transfers Stuck due to EIP-3298 Merge
    fixed

    Low
    F-2024-1726Bridge: Possible Registered Tokens List Corruption due to Lack of Validation
    fixed

    Low
    F-2024-1711Bridge: Possible Native Token Transfers Block due to Custom Fee Receiver Receive Logic
    fixed

    Low
    F-2024-1709Bridge: Lack of Support For Non-Compliant EIP-20 Tokens
    fixed

    Low
    1-10 of 28 findings

    Identify vulnerabilities in your smart contracts.

    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

    Repositoryhttps://github.com/klaytn/dragon→
    Initial Commitcecafe841eb090d8ac94ae9adbbce117cb3e02e6
    Remediation Commitb4610903172049d97363cfff98e8c1a189330809
    Whitepaperhttps://kips.klaytn.foundation→
    Requirementshttps://docs.klaytn.foundation→
    Technical Requirementscontracts/README.md

    Contracts in Scope

    contracts
    service_chain - contracts/service_chain
    system_contracts
    gov - contracts/system_contracts/gov
    kip103 - contracts/system_contracts/kip103
    kip113 - contracts/system_contracts/kip113
    kip149 - contracts/system_contracts/kip149
    consensus - contracts/system_contracts/consensus
    misc - contracts/system_contracts/misc

    Disclaimer