Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is MITO Safe?

BNB Chain
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades3/10Checks passed4 of 7Findings2 High · 2 Medium · 1 Low · 1 Info6
SummaryAI Copilot

The audit of the HypERC20 contract, an upgradeable ERC20 token integrated with the Hyperlane cross-chain messaging system, identified several areas of concern.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a role-gated executor contract
  • Proxy contract
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 92.3%
  • LP top3 unlocked holders = 100.0%
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a role-gated executor contract
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (92.1% total → 92.1% effective; 92.1% in EOAs, 0.0% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 92.3% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
92.1%Wallets7.9%Everyone else
92.1%Wallets7.9%
WalletsEveryone elseBubble area = share of supply
92.1%of supply sits with the top 10 holders
  • Walletsanonymous holders, free to sell92.1%
  • Everyone elsethe rest of the supply7.9%
Effective concentrationwhat the score reads92.1%
How holder types affect the score

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$72.1K across 2 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$72.1KShare of depth100.0%
Top-1 Unlocked Holder92.3%
Top-3 Unlocked100.0%
Unlocked LP held by
0xe4cc…dd830x7069…69fc

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

Security Findings

2 High2 Medium1 Low1 Info
High

Centralized Control over Critical Bridge Parameters

The owner (set via _MailboxClient_initialize) has sole control over critical bridge configuration functions such as setHook, setInterchainSecurityModule, setDestinationGas, enrollRemoteRouter, and unenrollRemoteRouter. These functions directly impact the security and functionality of the cross-chain bridge. A compromise of the owner's private key or a malicious owner could lead to severe consequences, including routing messages through an insecure Interchain Security Module (ISM), setting a malicious hook, or disabling cross-chain transfers.H-01

Issue

The owner (set via _MailboxClient_initialize) has sole control over critical bridge configuration functions such as setHook, setInterchainSecurityModule, setDestinationGas, enrollRemoteRouter, and unenrollRemoteRouter. These functions directly impact the security and functionality of the cross-chain bridge. A compromise of the owner's private key or a malicious owner could lead to severe consequences, including routing messages through an insecure Interchain Security Module (ISM), setting a malicious hook, or disabling cross-chain transfers.

Fix

Implement a robust multi-signature wallet or a time-locked governance mechanism for the owner role, especially for critical functions like setInterchainSecurityModule and setHook. This decentralizes control and adds a layer of security against single points of failure.

Status

Unresolved

High

Initial Token Supply Mints to initialize Caller

The initialize function mints the entire _totalSupply to msg.sender. In a proxy deployment, msg.sender will be the address that calls initialize on the proxy, typically the deployer or a ProxyAdmin contract. If this address is not the intended final recipient (e.g., a treasury multisig), the tokens must be manually transferred, introducing an operational risk of misdirection or loss.H-02

Issue

The initialize function mints the entire _totalSupply to msg.sender. In a proxy deployment, msg.sender will be the address that calls initialize on the proxy, typically the deployer or a ProxyAdmin contract. If this address is not the intended final recipient (e.g., a treasury multisig), the tokens must be manually transferred, introducing an operational risk of misdirection or loss.

Fix

Ensure the address calling initialize is a secure, intended recipient (e.g., a multisig wallet) or modify the initialize function to accept an explicit _initialSupplyRecipient address to which the initial supply should be minted.

Status

Unresolved

Medium

Reliance on External Interchain Security Module (ISM)

The contract's cross-chain security heavily relies on the _interchainSecurityModule for message verification. The setInterchainSecurityModule function allows the owner to change this critical component. If the configured ISM is vulnerable, malicious, or misconfigured, the integrity of cross-chain messages and the security of the bridged tokens could be compromised.M-01

Issue

The contract's cross-chain security heavily relies on the _interchainSecurityModule for message verification. The setInterchainSecurityModule function allows the owner to change this critical component. If the configured ISM is vulnerable, malicious, or misconfigured, the integrity of cross-chain messages and the security of the bridged tokens could be compromised.

Fix

Thoroughly audit and continuously monitor the configured interchainSecurityModule. Implement a robust change management process for updating the ISM, ideally involving a time-lock or governance vote to prevent immediate malicious changes.

Status

Unresolved

Medium

Potential for Malicious Hook Configuration

The setHook function allows the owner to set an IPostDispatchHook contract. While the onlyContractOrNull modifier prevents setting an Externally Owned Account (EOA), a malicious or vulnerable hook contract could potentially intercept or manipulate cross-chain messages, or execute unintended logic after dispatch, leading to security or economic issues.M-02

Issue

The setHook function allows the owner to set an IPostDispatchHook contract. While the onlyContractOrNull modifier prevents setting an Externally Owned Account (EOA), a malicious or vulnerable hook contract could potentially intercept or manipulate cross-chain messages, or execute unintended logic after dispatch, leading to security or economic issues.

Fix

Ensure any configured hook contract is thoroughly audited and its functionality is well-understood. Consider implementing a whitelist for approved hook contracts or a time-lock for changes to the hook address.

Status

Unresolved

Low

Multiple Pragma Directives

The codebase uses different pragma solidity versions across its files (e.g., >=0.8.0 and >=0.6.11). While the main HypERC20 contract uses 0.8.0, having mixed pragmas can sometimes lead to compilation issues or subtle behavior differences if not handled carefully by the build system.L-01

Issue

The codebase uses different pragma solidity versions across its files (e.g., >=0.8.0 and >=0.6.11). While the main HypERC20 contract uses 0.8.0, having mixed pragmas can sometimes lead to compilation issues or subtle behavior differences if not handled carefully by the build system.

Fix

Standardize all pragma solidity directives to a single, consistent version (e.g., 0.8.22 as per compiler version) across the entire codebase to avoid potential inconsistencies and simplify compilation.

Status

Unresolved

Info

Redundant OwnershipTransferred Event Emission

The _MailboxClient_initialize function first calls __Ownable_init(), which transfers ownership to msg.sender and emits an OwnershipTransferred event. Subsequently, it calls _transferOwnership(_owner), which transfers ownership again to the specified _owner and emits another OwnershipTransferred event. While functionally correct, this results in two OwnershipTransferred events being emitted during initialization, which could be confusing for event listeners.I-01

Issue

The _MailboxClient_initialize function first calls __Ownable_init(), which transfers ownership to msg.sender and emits an OwnershipTransferred event. Subsequently, it calls _transferOwnership(_owner), which transfers ownership again to the specified _owner and emits another OwnershipTransferred event. While functionally correct, this results in two OwnershipTransferred events being emitted during initialization, which could be confusing for event listeners.

Fix

Consider if the initial _transferOwnership(msg.sender) within __Ownable_init() is strictly necessary when _MailboxClient_initialize immediately overrides it. A common pattern is to initialize Ownable with the final _owner directly to avoid redundant event emissions.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The audit of the HypERC20 contract, an upgradeable ERC20 token integrated with the Hyperlane cross-chain messaging system, identified several areas of concern. The contract leverages OpenZeppelin's upgradeable patterns and implements a burn/mint mechanism for cross-chain transfers. Key findings include significant centralized control by the owner over critical bridge parameters and an operational risk related to the initial token supply distribution.

Technical6/10Medium risk

The HypERC20 contract utilizes OpenZeppelin's upgradeable ERC20 and Ownable patterns, demonstrating good adherence to established standards (7.2 Code Security). The cross-chain logic is built upon the Hyperlane MailboxClient and Router, employing onlyContract modifiers for critical address settings, enhancing security against misconfiguration (7.3 Access Control). However, the owner retains extensive control over vital bridge parameters such as the Interchain Security Module and dispatch hooks, presenting a significant centralization risk (7.3 Access Control). The initial token supply is minted to the initialize caller, which is an operational consideration for secure deployment (7.4 Economic).

Governance1/10High risk

The economic model revolves around a standard ERC20 token with a burn/mint mechanism for cross-chain transfers, which is a common and understood pattern (7.4 Economic). However, the governance model is highly centralized, with a single owner having complete control over critical bridge configurations, including the interchainSecurityModule and hook addresses (7.5 Governance). This centralization introduces a single point of failure and a high economic risk if the owner's key is compromised or acts maliciously, potentially leading to unauthorized message validation or token minting (7.4 Economic, 7.5 Governance).

Upgrades3/10High risk

The contract is designed for upgradeability using the TransparentUpgradeableProxy pattern and OpenZeppelin's upgradeable contracts (7.7 Upgrades). The inclusion of __GAP storage slots in parent contracts like MailboxClient and Router mitigates common storage collision risks during upgrades (7.7 Upgrades). However, the multi-inheritance structure and the complexity of the cross-chain logic increase the potential for subtle re-initialization bugs or unexpected behavior if upgrade procedures are not meticulously planned and executed (7.7 Upgrades). The immutable _decimals variable in the constructor is a good design choice for upgrade safety.

Final RecommendationWhat to do about this score

It is strongly recommended to implement a robust multi-signature wallet or a time-locked governance mechanism for the owner role to mitigate the high centralization risk, especially for functions that control the interchainSecurityModule and hook addresses.

Additionally, ensure that the address calling the initialize function is a secure, intended recipient for the initial token supply to prevent operational errors. All external dependencies, particularly the interchainSecurityModule and any configured hook contracts, must undergo thorough security audits.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBNB Chain
Token age1y
Contract0x8e1e…caef
Deployer0xa7ec…d9ba
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → RoleGatedExecutor
ImplementationVerified source
Badge for your website
MITO security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 2, 202679High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
RheaBNB Chain79HighBased TokenBASED · BNB Chain78HighGRVTBNB Chain78HighFalcon FinanceFF · BNB Chain78HighKGENBNB Chain78HighBinance BrokersBBROKERS · BNB Chain78High

Would You Like a More Detailed Audit of MITO?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page