Quantum Audit Logo

Is MITO Safe?

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

Is this your token? Publish your own audit on this page →

MITO MITO
0x8e1e…caef
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive 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. 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.

2 High2 Medium1 Low1 Informational
Volume 24h
$181.4K
Liquidity
$72.1K
Price
$0.01723
Token Age
1y
Top 10 Holders
92.1%

Security Findings

2 High2 Med1 Low1 Info
High

Centralized Control over Critical Bridge Parameters

H-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
High

Initial Token Supply Mints to `initialize` Caller

H-02The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Medium

Reliance on External Interchain Security Module (ISM)

M-01The 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.
IssueThe 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.
FixThoroughly 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.
StatusUnresolved
Medium

Potential for Malicious Hook Configuration

M-02The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Low

Multiple Pragma Directives

L-01The 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.
IssueThe 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.
FixStandardize 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.
StatusUnresolved
Info

Redundant `OwnershipTransferred` Event Emission

I-01The `_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.
IssueThe `_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.
FixConsider 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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).

GovernanceHigh1/10

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).

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationVerified source

Holder Composition

92.1% in top 10
92.1% in wallets0.0% in contracts
Effective Concentration92.1%

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.

Liquidity Depth

$72.1K across 2 pairs
Pancakeswap v3WBNBanalysed$72.1K100.0%UniswapUSDT$320.0%

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder92.3%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0xa7ec…d9ba
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.

What Raised This Score

9 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

Related Audits

6 more on the record
Based Token (BASED)Critical RiskGRVTCritical RiskFalcon Finance (FF)Critical RiskKGENCritical RiskBinance Brokers (BBROKERS)Critical RiskSpaceX (SPCXB)Critical Risk

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