Quantum Audit Logo
Launch App

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

Is GoPlus Security Safe?

GPSBNB 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 passed2 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The HypERC20 contract implements an upgradeable ERC-20 token with interchain capabilities, leveraging Hyperlane's Mailbox system for cross-chain transfers.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • 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 = 50.5%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
7.9%Contracts87.3%Wallets4.7%
7.9%87.3%Wallets4.7%
ContractsWalletsEveryone elseBubble area = share of supply
95.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking7.9%
  • Walletsanonymous holders, free to sell87.3%
  • Everyone elsethe rest of the supply4.7%
Effective concentrationwhat the score reads90.5%
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$157.4K 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$157.4KShare of depth100.0%
Top-1 Unlocked Holder50.5%
Top-3 Unlocked100.0%
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.

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Control over Critical Interchain Security Parameters

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Initial Token Supply Concentrated with Owner

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Medium

Operational Risk from Owner-Controlled Gas Configuration

The 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.M-02

Issue

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

Fix

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

Status

Unresolved

Low

Immutable Decimals Limit Future Flexibility

The _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.L-01

Issue

The _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.

Fix

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

Status

Unresolved

Info

High Reliance on External Interchain Components

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

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

The HypERC20 contract implements an upgradeable ERC-20 token with interchain capabilities, leveraging Hyperlane's Mailbox system for cross-chain transfers. The contract utilizes OpenZeppelin's upgradeable patterns and standard ERC-20 functionalities, with custom logic for burning tokens on the source chain and minting on the destination chain. Key strengths include the use of battle-tested OpenZeppelin libraries and a multisig for ownership. However, the system exhibits a high degree of centralized control by the owner multisig over critical interchain security parameters and initial token distribution, posing significant trust assumptions and potential single points of failure. Operational risks related to gas configuration also exist.

Technical6/10Medium risk

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.

Governance1/10High risk

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

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

Prioritize strengthening the governance and operational security around the owner multisig, given its extensive control over critical interchain components and initial token supply.

Implement robust monitoring for all external dependencies and cross-chain transaction health. Consider a roadmap for progressive decentralization of key parameters, potentially through time-locks or community governance, to reduce single points of failure and enhance the protocol's long-term resilience.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBNB Chain
Token age1y
Contract0x9a4a…642e
Deployer0xa7ec…d9ba
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 2-of-3
ImplementationVerified source
Badge for your website
GoPlus Security 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. Aug 14, 202665High

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

Frequently Asked Questions

What is the GPS contract address?

The GoPlus Security (GPS) contract on BNB Chain is 0x9a4a67721573f2c9209dfff972c52be4e3f6642e. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is GoPlus Security a scam?

Quantum Audit's risk score for GoPlus Security is 65/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is GPS liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $157.4K.

Who holds GPS?

As of Sep 4, 2026, the 10 largest holders own 95.3% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Asteroid ShibaASTEROID · BNB Chain65HighPro TokenPRO · BNB Chain64MediumXPULSBNB Chain66HighHana TokenHANA · BNB Chain66HighElonCoinBNB Chain64MediumUpstartyUPY · BNB Chain66High

Would You Like a More Detailed Audit of GoPlus Security?

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