Quantum Audit Logo

Is Coinbase Wrapped MEGA Safe?

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

Coinbase Wrapped MEGA CBMEGA
0xcb11…7d23
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive 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. 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.

1 High1 Medium1 Low2 Informational
Volume 24h
$215.2K
Liquidity
$40.9K
Price
$0.03952
Token Age
1y
Top 10 Holders
93.1%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control over Blacklisting and Pausing

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

Custom Storage Layout for Balance and Blacklist State

M-01The 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.
IssueThe 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.
FixThoroughly 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.
StatusUnresolved
Low

EIP-712 Authorization Front-Running Risk

L-01Functions 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).
IssueFunctions 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).
FixUsers 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.
StatusUnresolved
Info

Deprecated Blacklist Migration Logic

I-01The `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).
IssueThe `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).
FixEnsure 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.
StatusUnresolved
Info

Use of `_chainId()` via Assembly

I-02The `_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).
IssueThe `_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).
FixFor 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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

UpgradesHigh1/10

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.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeZeppelin Os Legacy
AdminEOA (single key controls upgrades)
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

93.1% in top 10
66.1% in wallets27.0% in contracts
Effective Concentration76.9%

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

$40.9K across 3 pairs
AerodromeUSDCanalysed$40.9K100.0%EqualizerWETH$60.0%

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 Holder84.1%
Top-3 Unlocked100.0%

Key Addresses

5 addresses
Deployer
0x3d2e…5965
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.

What Raised This Score

12 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

Related Audits

6 more on the record
FLock.io (FLOCK)Critical Riskbasedpad.fun (BPAD)Critical RiskCysic (CYS)Critical RiskStrike Robot (SR)Critical RiskMineBean (BEAN)Critical RiskRatspeakCritical Risk

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