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 | |
|---|---|
| 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 |
| Methodology | https://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 | |
|---|---|
| Repository | https://github.com/MakaChain_contracts→ |
| Commit | e6437f5 |
| Final Commit | 7442225 |
Review Scope
- Repository
- https://github.com/MakaChain_contracts→
- Commit
- e6437f5
- Final Commit
- 7442225
Audit Summary
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,
_transferis overridden to intercept transfers and route fees through an oracle with an explicitrequire(feeAmount < amount)validation, andsetOracleis 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 viagasBack(gated by theregisteredContractsallowlist), 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
setOracleto set or disable the oracle address used for transfer-fee calculation and gas-back logic.Can call
setHookto replace the post-dispatch hook contract.Can call
setInterchainSecurityModuleto replace the interchain security module contract.Can call
enrollRemoteRouterto register a trusted remote router for a given destination domain.Can call
enrollRemoteRoutersto batch-register trusted remote routers for multiple destination domains.Can call
unenrollRemoteRouterto remove a trusted remote router for a given destination domain.Can call
unenrollRemoteRoutersto batch-remove trusted remote routers for multiple destination domains.Can call
setDestinationGasto configure the gas limit for cross-chain dispatches to a specific domain (single or batch).Can call
setFeeRecipientto set the address that receives Hyperlane router-level transfer fees.Can call
setFeeHookto set the fee hook contract used for external fee calculation.Can call
transferOwnershipto transfer the owner role to a new address.Can call
renounceOwnershipto 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
setFeesto configure per-token transfer fees (batch).Can call
setRegisteredContractsto explicitly register or deregister contract addresses authorized to callgasBack(batch).Can call
setRecipientto set the recipient address used in fee-exemption checks.Can call
setTokenAdminsto assign token-specific admin addresses (batch).Can call
setPricesto set prices for token symbols (batch).Can call
transferAdminto 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
setWhitelistto add or remove addresses from the fee-exemption whitelist for the token they administer (batch).Can call
withdrawFeesto withdraw accumulated fee balances of the administered token held by the oracle contract.
registeredContract (explicit; managed via
setRegisteredContractsby the admin): Authorized to invoke gas-back operations on behalf of integrated tokens.Can call
gasBackto 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 — TokenRouter → GasRouter → Router → MailboxClient → OwnableUpgradeable — 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-1737 | Pool Insolvency Causes Transfer Denial-of-Service | fixed | High | |
| F-2026-1739 | Flat Fee Without Amount Validation in _transfer Causes Silent Zero-Value Transfers and DoS on Small Amounts | fixed | Medium | |
| F-2026-1737 | Wrong Token Used in chargeMaka Fallback Path Results in Incorrect Asset Distribution | fixed | Medium | |
| F-2026-1737 | Authorization-Fee Conflation Bricks All Transfers When MAKA Fee Is Set to Zero | fixed | Medium | |
| F-2026-1739 | Lack 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-1737 | Missing Zero-Address Validation for _owner Parameter in initialize May Lead to Loss of Administrative Control | accepted | Low | |
| F-2026-1739 | Lack of Two Step Ownership Transfer Mechanism | accepted | Observation | |
| F-2026-1739 | Unchecked Return Value in chargeMaka Fallback Path Causes Silent Transfer Failure | fixed | Observation | |
| F-2026-1737 | Redundant Default Value Initialization | fixed | Observation |
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/MakaChain_contracts→ |
| Commit | e6437f571cfa2cd892e2ed92de6117c34fb27033 |
| FInal Commit | 7442225489583cd906e190367b3e2fe7ba796296 |
| Whitepaper | - |
| Requirements | README.md |
| Technical Requirements | README.md |
Scope Details
- Repository
- https://github.com/MakaChain_contracts→
- Commit
- e6437f571cfa2cd892e2ed92de6117c34fb27033
- FInal Commit
- 7442225489583cd906e190367b3e2fe7ba796296
- Whitepaper
- -
- Requirements
- README.md
- Technical Requirements
- README.md
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.
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.