Quantum Audit Logo
Launch App

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

Is Solana Safe?

SOLBase
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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 2 Medium · 1 Low5
SummaryAI Copilot

The CrossChainERC20 contract implements a standard ERC20 token with minting and burning capabilities controlled by an immutable bridge address.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 50.1%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 30% (83.0% total → 38.8% effective; 9.3% in EOAs, 73.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 50.1% (independent LP — depth risk, pool = 35% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 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 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
73.7%Contracts9.3%Wallets17.0%Everyone else
73.7%Contracts9.3%17.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
83.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking73.7%
  • Walletsanonymous holders, free to sell9.3%
  • Everyone elsethe rest of the supply17.0%
Effective concentrationwhat the score reads38.8%
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$2.13M across 23 pairs
Show 4 more pairs

The 13 remaining pairs hold $28.1K between them and are not listed. 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$737.0KShare of depth34.7%
Top-1 Unlocked Holder50.1%
Top-3 Unlocked67.5%
Unlocked LP held by
0x7d27…fd550xbefd…ec9d0x97d1…59550x0c2f…6af40x5caa…bb0a0x2e33…47cf0x4cb0…160f0xcd19…c7350x130b…0f460x2e63…3202

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

Security Findings

1 Critical1 High2 Medium1 Low
Critical

Initialize Function Unusable Due to Constructor Call to _disableInitializers()

The CrossChainERC20 contract's constructor calls _disableInitializers(). This sets the _initializing state variable to 2, which prevents any subsequent calls to functions guarded by the initializer modifier. Consequently, the initialize function, crucial for setting the token's _remoteToken, _name, _symbol, and _decimals, can never be successfully called. This renders the contract non-functional as an ERC20 token with its intended metadata if deployed directly, as indicated by the is_proxy: false metadata.C-01

Issue

The CrossChainERC20 contract's constructor calls _disableInitializers(). This sets the _initializing state variable to 2, which prevents any subsequent calls to functions guarded by the initializer modifier. Consequently, the initialize function, crucial for setting the token's _remoteToken, _name, _symbol, and _decimals, can never be successfully called. This renders the contract non-functional as an ERC20 token with its intended metadata if deployed directly, as indicated by the is_proxy: false metadata.

Fix

If the contract is intended for direct deployment and initialization, remove _disableInitializers() from the constructor. If it is intended solely as an implementation contract for a proxy, ensure this is clearly documented and the deployment strategy aligns with proxy patterns, and update the is_proxy metadata accordingly.

Status

Unresolved

High

Immutable Bridge Address Lacks Operational Flexibility

The _BRIDGE address is set as immutable in the constructor. While this prevents unauthorized changes and provides strong security, it also means the bridge address cannot be updated. If the bridge contract needs to be upgraded, replaced due to a vulnerability, or if the underlying bridge architecture changes, there is no mechanism to update the _BRIDGE address in this token contract. This creates a single point of failure for operational continuity and limits future adaptability.H-01

Issue

The _BRIDGE address is set as immutable in the constructor. While this prevents unauthorized changes and provides strong security, it also means the bridge address cannot be updated. If the bridge contract needs to be upgraded, replaced due to a vulnerability, or if the underlying bridge architecture changes, there is no mechanism to update the _BRIDGE address in this token contract. This creates a single point of failure for operational continuity and limits future adaptability.

Fix

Consider implementing a mechanism to allow the _BRIDGE address to be updated by a trusted entity (e.g., a multi-signature wallet or governance contract) through a time-locked process. This would provide necessary operational flexibility while maintaining security safeguards.

Status

Unresolved

Medium

Centralization Risk with Single Bridge Control

The entire minting and burning capability of the token is controlled by a single _BRIDGE address. While this is the intended design for a cross-chain token, it introduces a significant centralization risk. A compromise of the _BRIDGE contract or its controlling private keys would allow an attacker to mint an arbitrary amount of tokens or burn existing tokens, leading to a complete loss of value for token holders.M-01

Issue

The entire minting and burning capability of the token is controlled by a single _BRIDGE address. While this is the intended design for a cross-chain token, it introduces a significant centralization risk. A compromise of the _BRIDGE contract or its controlling private keys would allow an attacker to mint an arbitrary amount of tokens or burn existing tokens, leading to a complete loss of value for token holders.

Fix

Ensure the _BRIDGE contract itself is highly secure, ideally controlled by a robust multi-signature wallet, a decentralized autonomous organization (DAO), or a battle-tested bridge protocol. Implement comprehensive monitoring and emergency response plans for the bridge.

Status

Unresolved

Medium

Lack of Emergency Pause Mechanism

The contract does not include any mechanism to pause critical functions such as minting, burning, or transfers in case of an emergency (e.g., a bridge exploit, critical vulnerability, or market manipulation). Without a pause mechanism, an ongoing attack could lead to irreversible damage before countermeasures can be deployed.M-02

Issue

The contract does not include any mechanism to pause critical functions such as minting, burning, or transfers in case of an emergency (e.g., a bridge exploit, critical vulnerability, or market manipulation). Without a pause mechanism, an ongoing attack could lead to irreversible damage before countermeasures can be deployed.

Fix

Implement a Pausable mechanism (e.g., from OpenZeppelin or Solady) that allows a trusted entity (like the _BRIDGE or a separate admin) to pause and unpause critical functions (mint, burn, transfer, transferFrom, approve). This should ideally be controlled by a multi-signature wallet or governance.

Status

Unresolved

Low

Redundant Zero Address Checks for _mint and _burn

The CrossChainERC20 contract explicitly checks for to != address(0) in mint and from != address(0) in burn. While these checks are good practice, the underlying Solady ERC20 implementation notes that it "WILL NOT revert for such actions" for performance. This means the explicit checks in CrossChainERC20 are necessary to enforce the desired behavior, but it's an observation on the interaction between the custom contract and the library's design philosophy.L-01

Issue

The CrossChainERC20 contract explicitly checks for to != address(0) in mint and from != address(0) in burn. While these checks are good practice, the underlying Solady ERC20 implementation notes that it "WILL NOT revert for such actions" for performance. This means the explicit checks in CrossChainERC20 are necessary to enforce the desired behavior, but it's an observation on the interaction between the custom contract and the library's design philosophy.

Fix

No change is strictly needed as the contract correctly implements the desired checks. This finding serves as an informational note regarding the library's behavior versus the contract's explicit requirements.

Status

Unresolved

Analysis

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

The CrossChainERC20 contract implements a standard ERC20 token with minting and burning capabilities controlled by an immutable bridge address. It leverages the well-regarded Solady library for its ERC20 base and Initializable pattern. A critical design flaw was identified where the initialize function, intended for token configuration, is rendered unusable due to a call to _disableInitializers() in the constructor, assuming direct deployment. The contract's security heavily relies on the external bridge's integrity, and its immutable bridge address lacks operational flexibility. The provided metadata indicates this is not a proxy, which makes the initialize issue critical.

Technical4/10Medium risk

The contract utilizes the Solady ERC20 implementation, known for its gas efficiency and security, and includes explicit zero-address checks for minting and burning (7.2 Code Security). The _BRIDGE address is correctly set as immutable, preventing unauthorized changes (7.3 Access Control). However, a critical flaw exists where the initialize function, vital for setting token metadata, is permanently disabled by the constructor's call to _disableInitializers(), rendering the token non-functional as intended if deployed directly (7.1 Architecture).

Governance1/10High risk

The economic model is highly centralized, with all minting and burning controlled by a single _BRIDGE address (7.4 Economic). This introduces a significant single point of failure; a compromise of the bridge would directly impact token supply and value. There is no explicit governance mechanism within the contract (7.5 Governance). The immutability of the _BRIDGE address, while secure against unauthorized changes, severely limits operational flexibility, preventing updates or replacements of the bridge contract (7.8 Operations).

Upgrades1/10High risk

The contract is not designed for direct upgradeability, as it does not implement a proxy pattern for itself (7.7 Upgrades). The use of Initializable is fundamentally flawed in this context, as the constructor disables the initialize function, preventing any initial configuration of the token's metadata. Furthermore, the immutable _BRIDGE address prevents any future operational upgrades or changes to the bridge's controlling entity (7.7 Upgrades, 7.8 Operations).

Final RecommendationWhat to do about this score

Address the critical issue regarding the unusable initialize function by either removing _disableInitializers() from the constructor if direct deployment is intended, or by clearly documenting its role as an implementation contract for a proxy.

Implement a robust emergency pause mechanism to mitigate risks from potential bridge exploits or other emergencies. Consider adding a controlled mechanism for updating the _BRIDGE address, possibly via a multi-signature wallet or governance, to enhance operational flexibility while maintaining security.

Contract & Record

2 audits on record
TypeToken
NetworkBase
Token age1mo
Contract0x3119…cf82
Deployer0xfb42…1e60
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Solana 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 4, 202653Medium
  2. Jul 27, 202643Medium
  3. Jul 25, 202663Medium

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

Frequently Asked Questions

Is Solana a scam?

Based on automated analysis, Solana scores 63/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Solana safe to buy?

Our scanner flagged a risk score of 63/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Solana been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
AUTONOMOPOLYAUTONO · Base53MediumTAOTBase53MediumCheckmateCHECK · Base53MediumSoSoValueSOSO · Base53MediumSallyA1C · Base53MediumOFCBase53Medium

Would You Like a More Detailed Audit of Solana?

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