Is GoPlus Security (GPS) Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low1 Info

High

Centralized Control over Critical Interchain Security Parameters

H-01The `owner` (a multisig) has exclusive control over setting the `interchainSecurityModule` and `hook` contracts via `setInterchainSecurityModule` and `setHook` functions. These contracts are fundamental to the security and functionality of cross-chain message verification and post-dispatch logic. A compromise of the owner's private keys or the multisig itself could allow a malicious actor to replace these critical components with arbitrary contracts, potentially leading to unauthorized minting, burning, or other severe exploits. This impacts 7.3 Access Control, 7.4 Economic, 7.5 Governance, and 7.6 External.

IssueThe `owner` (a multisig) has exclusive control over setting the `interchainSecurityModule` and `hook` contracts via `setInterchainSecurityModule` and `setHook` functions. These contracts are fundamental to the security and functionality of cross-chain message verification and post-dispatch logic. A compromise of the owner's private keys or the multisig itself could allow a malicious actor to replace these critical components with arbitrary contracts, potentially leading to unauthorized minting, burning, or other severe exploits. This impacts 7.3 Access Control, 7.4 Economic, 7.5 Governance, and 7.6 External.

FixWhile centralized control is common in early-stage protocols, consider a phased approach to decentralization. Implement time-locks for changes to critical parameters, or introduce a more robust governance mechanism (e.g., a DAO) for such sensitive operations. Ensure the multisig itself has strong operational security, including multi-factor authentication and strict key management policies.

StatusUnresolved

Medium

Initial Token Supply Concentrated with Owner

M-01The `initialize` function of `HypERC20` mints the entire `_totalSupply` to `msg.sender`, which, in the context of a proxy, is the address that calls `initialize` (the proxy admin owner, a multisig in this case). This design concentrates the entire initial token supply in the hands of the owner multisig. While this might be an intended distribution model, it creates a single point of failure for the token's initial liquidity and distribution. A compromise of this multisig would give an attacker control over the entire initial supply. This impacts 7.4 Economic and 7.5 Governance.

IssueThe `initialize` function of `HypERC20` mints the entire `_totalSupply` to `msg.sender`, which, in the context of a proxy, is the address that calls `initialize` (the proxy admin owner, a multisig in this case). This design concentrates the entire initial token supply in the hands of the owner multisig. While this might be an intended distribution model, it creates a single point of failure for the token's initial liquidity and distribution. A compromise of this multisig would give an attacker control over the entire initial supply. This impacts 7.4 Economic and 7.5 Governance.

FixEvaluate if this level of centralization for the initial supply is appropriate for the project's long-term decentralization goals. Consider distributing the initial supply across multiple secure wallets, vesting contracts, or a more decentralized distribution mechanism to mitigate the risk associated with a single large holder.

StatusUnresolved

Medium

Operational Risk from Owner-Controlled Gas Configuration

M-02The `setDestinationGas` function in `GasRouter` allows the `owner` to configure the gas limits for cross-chain messages to different destination domains. If these gas limits are set incorrectly (e.g., too low), cross-chain transactions might consistently fail, leading to operational disruptions, stuck funds, or a poor user experience. While this does not directly lead to fund loss through a vulnerability, it can significantly impact the protocol's reliability and usability. This impacts 7.4 Economic and 7.8 Operations.

IssueThe `setDestinationGas` function in `GasRouter` allows the `owner` to configure the gas limits for cross-chain messages to different destination domains. If these gas limits are set incorrectly (e.g., too low), cross-chain transactions might consistently fail, leading to operational disruptions, stuck funds, or a poor user experience. While this does not directly lead to fund loss through a vulnerability, it can significantly impact the protocol's reliability and usability. This impacts 7.4 Economic and 7.8 Operations.

FixImplement robust monitoring for cross-chain transaction failures related to gas limits. Consider adding a mechanism for users or a decentralized oracle to propose or vote on gas settings, or at least a public dashboard to track current settings and their impact. Ensure the owner has clear operational procedures for setting and updating these values.

StatusUnresolved

Low

Immutable Decimals Limit Future Flexibility

L-01The `_decimals` variable is declared as `immutable` in the `HypERC20` constructor. This means the token's decimal precision is permanently fixed at deployment of the implementation contract and cannot be altered through upgrades. While this is a common and often desirable characteristic for ERC-20 tokens to maintain consistency, it removes any potential flexibility for future protocol changes that might benefit from adjusting the decimal precision. This impacts 7.7 Upgrades.

IssueThe `_decimals` variable is declared as `immutable` in the `HypERC20` constructor. This means the token's decimal precision is permanently fixed at deployment of the implementation contract and cannot be altered through upgrades. While this is a common and often desirable characteristic for ERC-20 tokens to maintain consistency, it removes any potential flexibility for future protocol changes that might benefit from adjusting the decimal precision. This impacts 7.7 Upgrades.

FixAcknowledge this design choice. Ensure that the chosen decimal value is robust and suitable for all foreseeable future use cases of the token, as it cannot be changed.

StatusUnresolved

Info

High Reliance on External Interchain Components

I-01The `HypERC20` contract, as an interchain token, heavily relies on the security and correct functioning of several external contracts: `IMailbox`, `IInterchainSecurityModule`, and `IPostDispatchHook`. The integrity of cross-chain transfers (minting and burning) is directly dependent on these components. Any vulnerability or misconfiguration in these external contracts could directly impact the security and economic stability of the `HypERC20` token. This impacts 7.6 External and 7.1 Architecture.

IssueThe `HypERC20` contract, as an interchain token, heavily relies on the security and correct functioning of several external contracts: `IMailbox`, `IInterchainSecurityModule`, and `IPostDispatchHook`. The integrity of cross-chain transfers (minting and burning) is directly dependent on these components. Any vulnerability or misconfiguration in these external contracts could directly impact the security and economic stability of the `HypERC20` token. This impacts 7.6 External and 7.1 Architecture.

FixEnsure that all integrated external contracts (`IMailbox`, `IInterchainSecurityModule`, `IPostDispatchHook`) are thoroughly audited, well-maintained, and have robust security practices. Implement continuous monitoring for these dependencies and have a clear incident response plan in case of issues with any of them.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The HypERC20 contract demonstrates good architectural design for an interchain token, utilizing a modular approach with clear separation of concerns for token logic, routing, and gas management (7.1 Architecture). It leverages OpenZeppelin's upgradeable contracts and standard ERC-20 patterns, contributing to code security (7.2 Code Security). However, the reliance on external interchain components like the Mailbox, Interchain Security Module (ISM), and Hooks introduces complexity and external dependencies (7.6 External). The owner's ability to set critical interchain security parameters (ISM, Hook) and gas configurations presents a significant technical risk if these external contracts are compromised or misconfigured.

GovernanceHigh1/10

The contract's economic model is a burn-and-mint cross-chain token, which is a standard approach. Access control is primarily managed through an `onlyOwner` modifier, with the owner being a multisig, which is a positive security practice (7.3 Access Control). However, the owner multisig holds significant centralized control over critical interchain security parameters, such as the `interchainSecurityModule` and `hook` contracts, which directly impact the economic integrity of cross-chain transfers (7.4 Economic). Additionally, the initial token supply is minted entirely to the owner multisig during initialization, concentrating economic power (7.5 Governance).

UpgradesHigh3/10

The contract is designed for upgradeability using OpenZeppelin's `ERC20Upgradeable` and `OwnableUpgradeable` patterns, including `initializer` functions and `__GAP` storage slots (7.7 Upgrades). This allows for future enhancements and bug fixes without redeploying the token. The `initialize` function correctly sets up the token and ownership. A design choice to note is that the `_decimals` variable is immutable, meaning it cannot be changed in future upgrades, which is generally acceptable for tokens but limits flexibility.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminOZ ProxyAdmin → Multisig 2-of-3

ImplementationVerified source

Holder Composition

95.3% in top 10

87.3% in wallets7.9% in contracts

Effective Concentration90.5%

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

$157.4K across 2 pairs

Pancakeswap v3WBNBanalysed$157.4K Pancakeswap v2WBNB$2

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 Holder50.5%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0xa7ec…d9ba

Unlocked LP Held By

0x797d…eb550x745b…d37f

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 — Multisig (2-of-3)
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 70% (95.3% total → 90.5% effective; 87.3% in EOAs, 7.9% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 50.5% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
1 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

Is GoPlus Security Safe?

Security Findings

Centralized Control over Critical Interchain Security Parameters

Initial Token Supply Concentrated with Owner

Operational Risk from Owner-Controlled Gas Configuration

Immutable Decimals Limit Future Flexibility

High Reliance on External Interchain Components

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of GoPlus Security?