Quantum Audit Logo
Launch App

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

Is Coinbase Wrapped MEGA Safe?

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

The audit of FiatTokenV2_2, an upgradeable ERC-20 stablecoin implementation, reveals a robust design with standard security practices like SafeMath and EIP-712 support.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Admin is EOA
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top1 unlocked holder = 84.1%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is EOA (single key controls upgrades)
  • Top-10 concentration > 70% (93.1% total → 76.9% effective; 66.1% in EOAs, 27.0% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($40,924 across 3 pairs — thin market)
  • LP top1 unlocked holder = 84.1% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 1 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
27.0%Contracts66.1%Wallets6.9%Everyone else
27.0%Contracts66.1%Wallets6.9%
ContractsWalletsEveryone elseBubble area = share of supply
93.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking27.0%
  • Walletsanonymous holders, free to sell66.1%
  • Everyone elsethe rest of the supply6.9%
Effective concentrationwhat the score reads76.9%
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$40.9K across 3 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$40.9KShare of depth100.0%
Top-1 Unlocked Holder84.1%
Top-3 Unlocked100.0%
Unlocked LP held by
0x8815…288b0xdb6d…9ab30x3662…ba860x5e87…ae24

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

Security Findings

1 High1 Medium1 Low2 Info
High

Centralized Control over Blacklisting and Pausing

The contract inherits and implements functionalities for blacklisting accounts and pausing transfers, typically controlled by privileged roles (e.g., owner, masterMinter). These functions grant significant centralized power, allowing the freezing of funds or prevention of transfers for any address. This is an inherent design choice for many stablecoins but represents a high economic and operational risk (7.3 Access Control, 7.4 Economic, 7.8 Operations).H-01

Issue

The contract inherits and implements functionalities for blacklisting accounts and pausing transfers, typically controlled by privileged roles (e.g., owner, masterMinter). These functions grant significant centralized power, allowing the freezing of funds or prevention of transfers for any address. This is an inherent design choice for many stablecoins but represents a high economic and operational risk (7.3 Access Control, 7.4 Economic, 7.8 Operations).

Fix

Ensure that the private keys controlling these privileged roles are secured with the highest possible standards, such as multi-signature wallets, hardware security modules, and robust access control policies. Implement clear, transparent policies regarding the use of these powers.

Status

Unresolved

Medium

Custom Storage Layout for Balance and Blacklist State

The contract uses a non-standard bit manipulation technique to store both an account's balance and its blacklist status within a single uint256 value in the balanceAndBlacklistStates mapping. The most significant bit (MSB) indicates blacklisting, while the lower 255 bits store the balance. This custom storage pattern, while functional, increases complexity and the potential for subtle bugs if not perfectly aligned across all interacting functions and future upgrades (7.1 Architecture, 7.2 Code Security, 7.7 Upgrades). Additionally, balances are capped at 2^255 - 1 due to this design.M-01

Issue

The contract uses a non-standard bit manipulation technique to store both an account's balance and its blacklist status within a single uint256 value in the balanceAndBlacklistStates mapping. The most significant bit (MSB) indicates blacklisting, while the lower 255 bits store the balance. This custom storage pattern, while functional, increases complexity and the potential for subtle bugs if not perfectly aligned across all interacting functions and future upgrades (7.1 Architecture, 7.2 Code Security, 7.7 Upgrades). Additionally, balances are capped at 2^255 - 1 due to this design.

Fix

Thoroughly test all functions interacting with balanceAndBlacklistStates (e.g., _setBlacklistState, _setBalance, _isBlacklisted, _balanceOf) to ensure correct behavior under all conditions. Document this custom storage layout extensively for future development and auditing. Future upgrades must meticulously verify storage slot compatibility.

Status

Unresolved

Low

EIP-712 Authorization Front-Running Risk

Functions such as permit, transferWithAuthorization, receiveWithAuthorization, and cancelAuthorization rely on EIP-712 signed messages. While the deadline parameter helps mitigate some risks, these transactions are still susceptible to front-running. A malicious actor could observe a valid signed message in the mempool and submit their own transaction with a higher gas price to execute the authorized action before the legitimate user, potentially leading to denial of service or unexpected transaction ordering (7.2 Code Security).L-01

Issue

Functions such as permit, transferWithAuthorization, receiveWithAuthorization, and cancelAuthorization rely on EIP-712 signed messages. While the deadline parameter helps mitigate some risks, these transactions are still susceptible to front-running. A malicious actor could observe a valid signed message in the mempool and submit their own transaction with a higher gas price to execute the authorized action before the legitimate user, potentially leading to denial of service or unexpected transaction ordering (7.2 Code Security).

Fix

Users should be advised to set reasonable deadline values and be aware of mempool monitoring risks. Off-chain mechanisms or privacy-enhancing transaction relays could be considered to mitigate front-running, though this is often an inherent risk of such patterns.

Status

Unresolved

Info

Deprecated Blacklist Migration Logic

The initializeV2_2 function includes specific logic to migrate accounts from a _deprecatedBlacklisted mapping to the new balanceAndBlacklistStates system. This involves iterating through an array of accounts, requiring them to be previously blacklisted, then blacklisting them in the new system and deleting them from the old. This is a critical state migration step during an upgrade (7.7 Upgrades, 7.8 Operations).I-01

Issue

The initializeV2_2 function includes specific logic to migrate accounts from a _deprecatedBlacklisted mapping to the new balanceAndBlacklistStates system. This involves iterating through an array of accounts, requiring them to be previously blacklisted, then blacklisting them in the new system and deleting them from the old. This is a critical state migration step during an upgrade (7.7 Upgrades, 7.8 Operations).

Fix

Ensure this migration logic has been thoroughly tested in a staging environment before deployment to production. Verify that all intended accounts are correctly migrated and no unintended state changes occur. The require statement preventing blacklisting previously unblacklisted accounts is a good safety measure.

Status

Unresolved

Info

Use of _chainId() via Assembly

The _chainId() function retrieves the chain ID using inline assembly (chainId := chainid()). While this is a common and gas-efficient pattern for Solidity versions prior to 0.8.0, direct assembly can be less readable and potentially more error-prone than native Solidity constructs (7.2 Code Security).I-02

Issue

The _chainId() function retrieves the chain ID using inline assembly (chainId := chainid()). While this is a common and gas-efficient pattern for Solidity versions prior to 0.8.0, direct assembly can be less readable and potentially more error-prone than native Solidity constructs (7.2 Code Security).

Fix

For future upgrades or new contracts using Solidity 0.8.0+, consider using the native block.chainid global variable for improved readability and safety. For the current version, ensure the assembly code is well-understood and tested.

Status

Unresolved

Analysis

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

The audit of FiatTokenV2_2, an upgradeable ERC-20 stablecoin implementation, reveals a robust design with standard security practices like SafeMath and EIP-712 support. Key features include blacklisting and pausing, which are inherent to centralized stablecoins. The contract introduces a custom storage mechanism for balances and blacklist states, and a specific migration process for blacklisted accounts during upgrade. While generally well-implemented, the centralized control and custom storage introduce specific risk considerations.

Technical4/10Medium risk

The contract demonstrates good code security (7.2) through the use of SafeMath for arithmetic operations and clear adherence to ERC-20 standards. The EIP-712 authorization functions are correctly implemented. However, the custom storage layout for combining balance and blacklist state (7.1 Architecture) introduces complexity, requiring careful handling to prevent subtle bugs. The use of assembly for _chainId() is a minor technical note (7.2 Code Security).

Governance1/10High risk

The protocol exhibits a high degree of centralization (7.5 Governance) through privileged roles that can blacklist accounts and pause transfers. While typical for stablecoins, this represents a significant economic risk (7.4 Economic) as these roles can unilaterally freeze user funds or disrupt operations. The initializeV2_2 function also includes a critical migration of deprecated blacklisted accounts, which is a sensitive operational step (7.8 Operations).

Upgrades1/10High risk

The contract is designed as an upgradeable implementation (7.7 Upgrades) behind a proxy, utilizing an initializer (initializeV2_2) that correctly prevents re-initialization. The upgrade logic includes a specific migration of blacklisted accounts, which is a complex but necessary step for state consistency. The custom storage layout for balanceAndBlacklistStates requires careful consideration during future upgrades to ensure storage slot compatibility and prevent data corruption.

Final RecommendationWhat to do about this score

It is recommended to maintain stringent operational security for all privileged roles, especially those controlling blacklisting and pausing, given their significant impact on user funds.

Comprehensive testing, particularly for the custom storage logic and any future upgrade migrations, is crucial to ensure data integrity and prevent unexpected behavior. Users should be fully aware of the centralized control inherent in this stablecoin design.

Contract & Record

1 audit on record
TypeFiatTokenProxy
NetworkBase
Token age1y
Contract0xcb11…7d23
Deployer0x3d2e…5965
Proxy Upgrade Controls
Proxy TypeZeppelin Os Legacy
AdminEOA (single key controls upgrades)
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Coinbase Wrapped MEGA 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, 202685Critical
  2. Aug 16, 202679High

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

Frequently Asked Questions

What is the CBMEGA contract address?

The Coinbase Wrapped MEGA (CBMEGA) contract on Base is 0xcb111e6a2a3bde90856d299d61341ac302167d23. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Coinbase Wrapped MEGA a scam?

Quantum Audit's risk score for Coinbase Wrapped MEGA is 85/100 (Critical risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; 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 CBMEGA liquidity locked?

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

Who holds CBMEGA?

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

Related Audits

6 more on the recordAll audits
FLock.ioFLOCK · Base85Criticalbasedpad.funBPAD · Base85CriticalCysicCYS · Base84HighWrapped L1coinWL1 · Base84HighStrike RobotSR · Base87CriticalCrynux TokenCNX · Base87Critical

Would You Like a More Detailed Audit of Coinbase Wrapped MEGA?

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