Quantum Audit Logo

Is Solana Safe?

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

Solana SOL
0x3119…cf82
Base Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Critical1 High2 Medium1 Low
Volume 24h
$1.19M
Liquidity
$737.0K
Price
$103.7000
Token Age
1mo
Top 10 Holders
83.0%

Security Findings

1 Crit1 High2 Med1 Low
Critical

Initialize Function Unusable Due to Constructor Call to `_disableInitializers()`

C-01The `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.
IssueThe `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.
FixIf 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.
StatusUnresolved
High

Immutable Bridge Address Lacks Operational Flexibility

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

Centralization Risk with Single Bridge Control

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

Lack of Emergency Pause Mechanism

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

Redundant Zero Address Checks for `_mint` and `_burn`

L-01The `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.
IssueThe `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.
FixNo 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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

UpgradesHigh1/10

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

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

83.0% in top 10
9.3% in wallets73.7% in contracts
Effective Concentration38.8%

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

$2.13M across 23 pairs
PancakeswapcbBTCanalysed$737.0K34.7%AerodromeUSDC$528.1K24.8%AerodromecbBTC$314.2K14.8%PancakeswapUSDC$147.2K6.9%PancakeswapWETH$146.3K6.9%AerodromefBOMB$100.1K4.7%
Show 4 more pairsShow less
AerodromeWETH$45.0K2.1%Uniswap v3USDC$35.7K1.7%EqualizeruSOL$23.7K1.1%PancakeswapcbBTC$20.5K1.0%

The 13 remaining pairs hold $28.1K between them and are not listed.

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.1%
Top-3 Unlocked67.5%

Key Addresses

11 addresses
Deployer
0xfb42…1e60
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.

What Raised This Score

11 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

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 record
AUTONOMOPOLY (AUTONO)High RiskTAOTHigh RiskCheckmate (CHECK)High RiskSoSoValue (SOSO)High RiskSally (A1C)High RiskHOMEHigh Risk

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