Q1 2026 Security & Compliance Report44 incidents, $482M in losses, insights from 11 industry leaders.
Read the report

Audit name:

[SCA] Makachain | Makachain SC | May2026

Date:

Jun 9, 2026

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 Makachain team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Makachain Contracts provides a cross-chain bridge infrastructure built on the Hyperlane messaging protocol, targeting the Makachain network. A modified Hyperlane synthetic ERC-20 token is extended with a flat fee mechanism — denominated in the transferred token's own units — that is deducted on every on-chain transfer, with fee proceeds coordinated through a centralized oracle.

Document

NameSmart Contract Code Review and Security Analysis Report for Makachain
Audited ByKhrystyna Tkachuk
Approved ByKornel Światłowski
Websitemakachain.io
Changelog26/05/2026 - Preliminary Report
03/06/2026 - Final Report
PlatformMakachain
LanguageSolidity
TagsERC20; Upgradable; Bridge; Centralization
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Makachain
    Audited By
    Khrystyna Tkachuk
    Approved By
    Kornel Światłowski
    Website
    makachain.io
    Changelog
    26/05/2026 - Preliminary Report
    03/06/2026 - Final Report
    Platform
    Makachain
    Language
    Solidity
    Tags
    ERC20; Upgradable; Bridge; Centralization

Review Scope

Repositoryhttps://github.com/MakaChain_contracts
Commite6437f5
Final Commit7442225

Audit Summary

14Total Findings
9Resolved
5Accepted
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 are partially provided.

  • NatSpec comments are sufficient.

  • Expected behavior for edge cases is not documented.

Code quality

  • The code leverages OpenZeppelin contracts and follows established patterns.

  • The development environment is not configured.

Test coverage

Code coverage of the project is 0%.

  • No test suite was provided by the client.

System Overview

The bridge subsystem is composed of two contracts that collectively implement a fee-bearing cross-chain synthetic token. HypERC20 is a modified Hyperlane TokenRouter / ERC20Upgradeable synthetic token whose _transfer override intercepts every token movement. When an oracle address is configured, the override first instructs TrustedOracle to perform a native-coin gas subsidy via gasBack, then queries it for the applicable fee. If a non-zero fee is returned and passes the require(feeAmount < amount) validation, the transfer is split into a fee portion (sent to the oracle) and a net portion (sent to the transfer recipient). When the oracle is not set, transfers fall through to the standard ERC-20 behaviour unchanged. Cross-chain minting and burning are inherited unmodified from the upstream Hyperlane TokenRouter stack, which routes messages through a Hyperlane Mailbox and InterchainSecurityModule.

TrustedOracle serves as the fee authority and the single administrative hub. Per-token flat fee amounts (in the transferred token's denomination), per-token whitelist administrators, and admin-controlled price feeds stored by bytes32 symbol are maintained as configuration state. Fee calculation via calculateFee returns zero when either party is the zero address, the configured recipient, or a whitelisted address for the given token, and otherwise returns the flat fee for that token. A gasBack function automatically tops up the native-coin balance of participating EOAs to a 0.2 ether threshold, sourcing funds through a chain-specific mint precompile when the oracle's own native balance falls below 1,000 ether. Access to gasBack is gated by an explicit registeredContracts allowlist managed by the admin via setRegisteredContracts, decoupling authorization from fee configuration. Core configuration — fees, prices, the MAKA token address, token administrators, and the fee recipient — is managed exclusively by a single admin address, while per-token whitelist management and fee withdrawal are delegated to individually assigned token administrators.

Files in Scope

  • HypERC20Flat.sol — Contains the custom HypERC20 contract (the sole modified contract in a flattened upstream Hyperlane token stack). Inheritance from ERC20Upgradeable and TokenRouter is used, _transfer is overridden to intercept transfers and route fees through an oracle with an explicit require(feeAmount < amount) validation, and setOracle is provided for the contract owner to enable or disable the fee mechanism.

  • TrustedOracle.sol — The centralized fee and configuration authority. Per-token flat fees are computed via calculateFee (respecting whitelist exemptions, zero-address guards, and recipient-address exemptions). Automatic native-coin gas subsidies are provided via gasBack (gated by the registeredContracts allowlist), and admin-only setters are exposed for fees, prices, whitelists, token admins, registered contracts, and the recipient.

Privileged roles

HypERC20 (HypERC20Flat.sol):

  • owner (inherited from OwnableUpgradeable via MailboxClient → Router → GasRouter → TokenRouter): Controls all administrative functions of the Hyperlane token router.

    • Can call setOracle to set or disable the oracle address used for transfer-fee calculation and gas-back logic.

    • Can call setHook to replace the post-dispatch hook contract.

    • Can call setInterchainSecurityModule to replace the interchain security module contract.

    • Can call enrollRemoteRouter to register a trusted remote router for a given destination domain.

    • Can call enrollRemoteRouters to batch-register trusted remote routers for multiple destination domains.

    • Can call unenrollRemoteRouter to remove a trusted remote router for a given destination domain.

    • Can call unenrollRemoteRouters to batch-remove trusted remote routers for multiple destination domains.

    • Can call setDestinationGas to configure the gas limit for cross-chain dispatches to a specific domain (single or batch).

    • Can call setFeeRecipient to set the address that receives Hyperlane router-level transfer fees.

    • Can call setFeeHook to set the fee hook contract used for external fee calculation.

    • Can call transferOwnership to transfer the owner role to a new address.

    • Can call renounceOwnership to irrevocably renounce the owner role, disabling all owner-gated functions.

TrustedOracle.sol

  • admin: Full administrative control over fee configuration, pool assignments, pricing, and role management.

    • Can call setFees to configure per-token transfer fees (batch).

    • Can call setRegisteredContracts to explicitly register or deregister contract addresses authorized to call gasBack (batch).

    • Can call setRecipient to set the recipient address used in fee-exemption checks.

    • Can call setTokenAdmins to assign token-specific admin addresses (batch).

    • Can call setPrices to set prices for token symbols (batch).

    • Can call transferAdmin to transfer the admin role to a new address.

  • tokenAdmin (per-token, assigned by admin via setTokenAdmins): Per-token administrative role for whitelist management and fee withdrawal.

    • Can call setWhitelist to add or remove addresses from the fee-exemption whitelist for the token they administer (batch).

    • Can call withdrawFees to withdraw accumulated fee balances of the administered token held by the oracle contract.

  • registeredContract (explicit; managed via setRegisteredContracts by the admin): Authorized to invoke gas-back operations on behalf of integrated tokens.

    • Can call gasBack to auto-refill native coin balances of EOA addresses involved in a transfer, minting native coins via the MintPrecompile if the oracle's own balance is low.

Potential Risks

Dependency on Hyperlane Framework Inheritance Chain: HypERC20 inherits through a deep chain — TokenRouterGasRouterRouterMailboxClientOwnableUpgradeable — all embedded in the flattened file as Hyperlane framework code. Critical behaviours such as cross-chain message dispatch via _Router_dispatch, inbound token minting via _handle, remote router enrollment via enrollRemoteRouter, and the onlyOwner access control modifier are defined entirely in these parent contracts. Any latent defect in this inherited logic would propagate into HypERC20 without being addressed by the current scope.

System Reliance on the Hyperlane Mailbox: All cross-chain functionality in HypERC20 depends on an immutable IMailbox address set in the MailboxClient constructor and used by _Router_dispatch for outbound message dispatch and the onlyMailbox modifier for inbound message handling. The Mailbox contract is external to the repository and cannot be upgraded or replaced without redeploying the entire HypERC20 proxy. Unavailability, compromise, or misconfiguration of the Mailbox would halt all bridge operations.

MakaChain Native-Coin Mint Precompile Dependency: The gasBack function in TrustedOracle invokes mintNativeCoin on a hardcoded precompile at address 0x0200000000000000000000000000000000000001 to refill the contract's native-coin balance when it falls below 1,000 ether. This is a MakaChain-specific infrastructure component whose behaviour, availability, and access-control semantics are defined at the chain level and are not auditable from Solidity source. If the precompile interface changes, is deprecated during a chain upgrade, or enforces caller restrictions not currently present, the gas-subsidy mechanism would revert, blocking all transfers on HypERC20 for which the oracle is configured and the contract's native balance has been depleted.

Fixed Total Supply Post-Deployment: The token’s total supply is determined at deployment and cannot be verified beforehand, potentially limiting the project’s adaptability and economic model flexibility.

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.

Absence of Timelock Mechanisms on All Critical Operations: Every administrative function across HypERC20 and TrustedOracle executes immediately upon transaction confirmation. Operations such as setOracle, setFees, setRegisteredContracts, setPrices, setInterchainSecurityModule, enrollRemoteRouter, and transferAdmin take effect in the same block, providing no window for users or monitoring systems to detect and react to potentially harmful parameter changes before they impact live transfers.

Arbitrary Oracle Address Setting on HypERC20: The HypERC20 owner can replace the oracle address at any time via setOracle with no validation, timelock, or multi-signature requirement. The oracle intercepts every ERC-20 _transfer call to execute gasBack and calculateFee, meaning a malicious or incorrect oracle address could extract fees, mint arbitrary native coins, or revert all token transfers chain-wide.

Unrestricted Fee and Price Modification by TrustedOracle Admin: The TrustedOracle admin can call setFees to set arbitrary feesForToken values per token, setPrices to set arbitrary token symbol prices, and setRecipient to redirect fee proceeds — all without bounds checking, rate limits, or timelocks. A compromised or malicious admin key could set prohibitively high fees to effectively freeze transfers or redirect fee revenue to an attacker-controlled address.

Centralized Arbitrary Token Admin Setting: The TrustedOracle contract admin can assign arbitrary addresses as token admins for any token via setTokenAdmin without restrictions on the number of admins or token coverage, granting each appointed admin the ability to withdraw any amount of that token from the oracle contract. A compromised or malicious admin can appoint colluding addresses that collectively drain all token balances held by the oracle, with no on-chain safeguards such as timelocks, multisig requirements, or withdrawal caps to limit the damage.

Centralized Fee Oracle Without Fallback or External Validation: TrustedOracle serves as the sole fee-calculation authority for all HypERC20 transfers, with fee amounts set exclusively by the admin via setFees and no secondary oracle, on-chain price feed, or sanity-check bounds to validate or override these admin-supplied values. If the admin key becomes unavailable, there is no fallback mechanism, and fee parameters will remain at whatever values were last configured.

Uncapped Fund Drainage: The withdrawFees function lacks fee accounting, allowing the token admin to withdraw the entire oracle contract balance.

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

Explicit Contract Registration Requirement: The onlyRegisteredContract modifier in TrustedOracle authorizes callers via an explicit registeredContracts allowlist managed by the admin through setRegisteredContracts. gasBack — the sole function gated by this modifier — is called unconditionally by HypERC20._transfer when an oracle is configured, meaning any HypERC20 token contract must be registered before transfers will succeed. If a token contract is not registered (e.g., after an upgrade deploys a new oracle version with an empty mapping, or if the admin deregisters a token), all transfers on that HypERC20 instance will revert with Unauthorized() until registration is restored. Conversely, registering any arbitrary address grants it permission to trigger native-coin minting through gasBack, bounded by the per-EOA 0.2 ether subsidy cap.

Findings

Code
Title
Status
Severity
F-2026-1737Pool Insolvency Causes Transfer Denial-of-Service
fixed

High
F-2026-1739Flat Fee Without Amount Validation in _transfer Causes Silent Zero-Value Transfers and DoS on Small Amounts
fixed

Medium
F-2026-1737Wrong Token Used in chargeMaka Fallback Path Results in Incorrect Asset Distribution
fixed

Medium
F-2026-1737Authorization-Fee Conflation Bricks All Transfers When MAKA Fee Is Set to Zero
fixed

Medium
F-2026-1739Lack of Admin Withdraw Function for Excess MAKA Tokens
fixed

Low
F-2026-1739_isEOA Bypass via extcodesize During Construction Enables Gas Subsidy Extraction
accepted

Low
F-2026-1737Missing Zero-Address Validation for _owner Parameter in initialize May Lead to Loss of Administrative Control
accepted

Low
F-2026-1739Lack of Two Step Ownership Transfer Mechanism
accepted

Observation
F-2026-1739Unchecked Return Value in chargeMaka Fallback Path Causes Silent Transfer Failure
fixed

Observation
F-2026-1737Redundant Default Value Initialization
fixed

Observation
1-10 of 14 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/MakaChain_contracts
Commite6437f571cfa2cd892e2ed92de6117c34fb27033
FInal Commit7442225489583cd906e190367b3e2fe7ba796296
Whitepaper-
RequirementsREADME.md
Technical RequirementsREADME.md
  • Scope Details

    Commit
    e6437f571cfa2cd892e2ed92de6117c34fb27033
    FInal Commit
    7442225489583cd906e190367b3e2fe7ba796296
    Whitepaper
    -
    Requirements
    README.md
    Technical Requirements
    README.md

Assets in Scope

src
bridge
HypERC20Flat.sol - src › bridge › HypERC20Flat.sol
Pool.sol - src › bridge › Pool.sol
TrustedOracle.sol - src › bridge › TrustedOracle.sol

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.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment , and the Penetration Testing Execution Standard (PTES) , These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer