Quantum Audit Logo
Launch App

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

Is CoW Protocol Token Safe?

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

The audit of the StandardArbERC20 implementation contract, used by a ClonableBeaconProxy, reveals a robust design for an L2 bridge token.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • 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 = 57.3%
  • 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 status UNKNOWN (owner could not be resolved)
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 30% (66.8% total → 34.5% effective; 12.9% in EOAs, 53.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 57.3% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
53.9%Contracts12.9%Wallets33.2%Everyone else
53.9%Contracts12.9%33.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
66.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking53.9%
  • Walletsanonymous holders, free to sell12.9%
  • Everyone elsethe rest of the supply33.2%
Effective concentrationwhat the score reads34.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$79.2K 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$78.1KShare of depth98.6%
Top-1 Unlocked Holder57.3%
Top-3 Unlocked100.0%
Unlocked LP held by
0x2537…dfab0x73e5…91ad

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

Centralization Risk of L2 Gateway

The l2Gateway address, set during initialization, holds exclusive control over the bridgeMint and bridgeBurn functions. This allows the l2Gateway to arbitrarily increase or decrease the token supply, posing a significant centralization risk. The security of this single address is critical to the integrity and stability of the token's economic model.H-01

Issue

The l2Gateway address, set during initialization, holds exclusive control over the bridgeMint and bridgeBurn functions. This allows the l2Gateway to arbitrarily increase or decrease the token supply, posing a significant centralization risk. The security of this single address is critical to the integrity and stability of the token's economic model.

Fix

Implement robust security measures for the l2Gateway address, such as a multi-signature wallet with a high threshold, a time-locked contract, or a decentralized governance mechanism. Clearly document the operational procedures and security protocols surrounding this address.

Status

Unresolved

Medium

Potential for Malformed Token Metadata

The bridgeInit function decodes token name, symbol, and decimals from _data. If this _data is malformed or empty, the availableGetters flags (ignoreName, ignoreSymbol, ignoreDecimals) are set to true, causing the respective getter functions (name(), symbol(), decimals()) to revert. While this prevents incorrect data from being returned, an improperly configured l2Gateway could initialize the token with unreadable metadata, leading to poor user experience or integration issues for applications relying on these standard ERC20 getters.M-01

Issue

The bridgeInit function decodes token name, symbol, and decimals from _data. If this _data is malformed or empty, the availableGetters flags (ignoreName, ignoreSymbol, ignoreDecimals) are set to true, causing the respective getter functions (name(), symbol(), decimals()) to revert. While this prevents incorrect data from being returned, an improperly configured l2Gateway could initialize the token with unreadable metadata, leading to poor user experience or integration issues for applications relying on these standard ERC20 getters.

Fix

Ensure that the l2Gateway is configured to always provide valid and well-formed _data during the bridgeInit call. Implement off-chain validation or additional on-chain checks (if feasible without excessive gas costs) to ensure metadata quality before initialization. Provide clear documentation on the expected _data format.

Status

Unresolved

Low

Complex Custom String Parsing Logic

The BytesParser.toString function contains custom logic for decoding strings from bytes, particularly for inputs of exactly 32 bytes. This involves checking the last byte for null, truncating trailing nulls, and using assembly. While designed to handle specific encoding patterns, such complex custom parsing logic can be a source of subtle bugs or unexpected behavior if the input _data does not strictly adhere to the assumed format, potentially leading to incorrect metadata display.L-01

Issue

The BytesParser.toString function contains custom logic for decoding strings from bytes, particularly for inputs of exactly 32 bytes. This involves checking the last byte for null, truncating trailing nulls, and using assembly. While designed to handle specific encoding patterns, such complex custom parsing logic can be a source of subtle bugs or unexpected behavior if the input _data does not strictly adhere to the assumed format, potentially leading to incorrect metadata display.

Fix

Thoroughly test the BytesParser.toString function with a wide range of valid and edge-case inputs, especially for 32-byte strings and strings of varying lengths. Consider adding more explicit comments to explain the specific encoding assumptions made by this parsing logic.

Status

Unresolved

Info

Unused TransferAndCallToken Import

The TransferAndCallToken interface and abstract contract are imported into contracts/tokenbridge/libraries/L2GatewayToken.sol and contracts/tokenbridge/libraries/aeERC20.sol (implied by truncation), but StandardArbERC20 does not directly inherit from TransferAndCallToken or explicitly use its functions. This suggests the import might be unnecessary for the current contract's functionality.I-01

Issue

The TransferAndCallToken interface and abstract contract are imported into contracts/tokenbridge/libraries/L2GatewayToken.sol and contracts/tokenbridge/libraries/aeERC20.sol (implied by truncation), but StandardArbERC20 does not directly inherit from TransferAndCallToken or explicitly use its functions. This suggests the import might be unnecessary for the current contract's functionality.

Fix

Review the dependency tree to determine if TransferAndCallToken is truly required by any parent contracts or if it can be removed to reduce contract size and complexity. If it's part of a broader ecosystem, ensure its presence is justified.

Status

Unresolved

Info

Cloned Instances Can Self-Destruct

The Cloneable base contract includes a safeSelfDestruct function, which is protected by require(!isMasterCopy, NOT_CLONE);. This design correctly prevents the master implementation contract from being self-destructed. However, it means that any cloned instances of this contract can be self-destructed by their respective owners. While this is an intended feature of the Cloneable pattern, it's an operational consideration for users deploying clones.I-02

Issue

The Cloneable base contract includes a safeSelfDestruct function, which is protected by require(!isMasterCopy, NOT_CLONE);. This design correctly prevents the master implementation contract from being self-destructed. However, it means that any cloned instances of this contract can be self-destructed by their respective owners. While this is an intended feature of the Cloneable pattern, it's an operational consideration for users deploying clones.

Fix

Ensure that the implications of safeSelfDestruct for cloned instances are well-understood by deployers and documented. Implement clear policies or safeguards around the ownership and lifecycle management of cloned contracts to prevent accidental or malicious self-destruction.

Status

Unresolved

Analysis

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

The audit of the StandardArbERC20 implementation contract, used by a ClonableBeaconProxy, reveals a robust design for an L2 bridge token. Key strengths include the use of OpenZeppelin upgradeable contracts, a well-defined initialization process, and strong access controls for critical minting and burning functions. The primary risk identified is the high centralization of power in the l2Gateway address, which controls token supply. Minor issues include complex custom string parsing and an unused import.

Technical8/10Low risk

The contract demonstrates good technical architecture (7.1) by inheriting from OpenZeppelin's upgradeable ERC20 and implementing a clear L2 gateway token pattern. Code security (7.2) is enhanced by the onlyGateway modifier protecting bridgeMint and bridgeBurn, and the _initialize function preventing re-initialization. Access control (7.3) is centralized around the l2Gateway address, which has significant power. The BytesParser library, while functional, contains custom assembly and specific logic for string decoding (7.2), which adds complexity and warrants careful review.

Governance1/10High risk

The economic model (7.4) relies heavily on the l2Gateway address, which has the sole authority to mint and burn tokens via bridgeMint and bridgeBurn. This represents a high centralization risk, as the security of this single address is paramount to the token's integrity. The bridgeInit function handles potentially malformed token metadata gracefully by setting ignore* flags, preventing reverts on getter calls but potentially leading to a token with unreadable metadata if not properly initialized (7.8 Operations). There is no explicit on-chain governance (7.5) within this contract.

Upgrades1/10High risk

The contract is designed as an implementation for a ClonableBeaconProxy (7.7), indicating a robust upgradeability pattern. The _initialize function includes a require(l2Gateway == address(0), "ALREADY_INIT"); check, preventing re-initialization after deployment, which is crucial for upgrade safety. The Cloneable base contract correctly distinguishes between the master copy and cloned instances, allowing only clones to safeSelfDestruct.

Final RecommendationWhat to do about this score

It is recommended to ensure the l2Gateway address is secured with robust multi-signature or governance mechanisms, given its critical role in token supply management.

Thorough testing of the BytesParser library, especially its string decoding logic, is advised to confirm expected behavior across all input scenarios. Finally, review the necessity of the TransferAndCallToken import to maintain a lean and focused codebase.

Contract & Record

1 audit on record
TypeClonableBeaconProxy
NetworkArbitrum
Token age2y
Contract0xcb8b…7a04
Deployer0xb4b8…1ffd
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
CoW Protocol Token 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 16, 202654Medium

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

Related Audits

6 more on the recordAll audits
Equilibria TokenEQB · Arbitrum55MediumArbitrum DogMILES · Arbitrum53MediumSubsquidSQD · Arbitrum52MediumWrapped BTCWBTC · Arbitrum57MediumSperax USDUSDS · Arbitrum51MediumNOXCATNOX · Arbitrum58Medium

Would You Like a More Detailed Audit of CoW Protocol Token?

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