Quantum Audit Logo

Is Circle Internet Group Inc. Safe?

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

Is this your token? Publish your own audit on this page →

Circle Internet Group Inc. CRCLB
0x80f3…ffc0
BNB Chain
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit of the SecuritiesToken contract, deployed as an upgradeable Beacon Proxy on BSC, reveals a well-structured token implementation utilizing OpenZeppelin's upgradeable patterns and custom ERC8056 scaling logic. The contract incorporates robust access control, compliance, and pausing mechanisms. Key findings include a critical initialization vulnerability that could lead to administrative lockout, and significant economic control vested in the ISSUER_ROLE. While the upgradeability model is sound, the high degree of centralization in administrative and issuer roles necessitates careful management of privileged keys.

2 High1 Medium1 Low1 Informational
Volume 24h
$3.70M
Liquidity
$1.11M
Price
$94.1000
Token Age
1mo
Top 10 Holders
96.0%

Security Findings

2 High1 Med1 Low1 Info
High

Unchecked `admin_` address in `initialize`

H-01The `initialize` function grants the `DEFAULT_ADMIN_ROLE` to the `admin_` address provided as an argument. If `admin_` is set to `address(0)`, the `DEFAULT_ADMIN_ROLE` will be assigned to the zero address. This would effectively lock out all administrative control over the contract, making it unmanageable and potentially bricking critical functionalities that rely on the `DEFAULT_ADMIN_ROLE`.
IssueThe `initialize` function grants the `DEFAULT_ADMIN_ROLE` to the `admin_` address provided as an argument. If `admin_` is set to `address(0)`, the `DEFAULT_ADMIN_ROLE` will be assigned to the zero address. This would effectively lock out all administrative control over the contract, making it unmanageable and potentially bricking critical functionalities that rely on the `DEFAULT_ADMIN_ROLE`.
FixImplement a check in the `initialize` function to ensure that the `admin_` address is not `address(0)`. For example: `require(admin_ != address(0), "SecuritiesToken: Admin cannot be zero address");`
StatusUnresolved
High

Broad Powers of `ISSUER_ROLE` to Affect Token Value

H-02The `ISSUER_ROLE` has the ability to mint, burn, and crucially, authorize changes to the `uiMultiplier` via the `_authorizeMultiplierUpdate` function. The `uiMultiplier` directly impacts the effective value of the token, as it scales user balances. While the `DEFAULT_ADMIN_ROLE` manages `ISSUER_ROLE` assignments and the multiplier has defined bounds (`1e9` to `1e27`), granting this significant economic control to a potentially broader set of `ISSUER_ROLE` holders increases the attack surface for economic manipulation or misuse compared to restricting it solely to the `DEFAULT_ADMIN_ROLE`.
IssueThe `ISSUER_ROLE` has the ability to mint, burn, and crucially, authorize changes to the `uiMultiplier` via the `_authorizeMultiplierUpdate` function. The `uiMultiplier` directly impacts the effective value of the token, as it scales user balances. While the `DEFAULT_ADMIN_ROLE` manages `ISSUER_ROLE` assignments and the multiplier has defined bounds (`1e9` to `1e27`), granting this significant economic control to a potentially broader set of `ISSUER_ROLE` holders increases the attack surface for economic manipulation or misuse compared to restricting it solely to the `DEFAULT_ADMIN_ROLE`.
FixRe-evaluate if the `ISSUER_ROLE` should have the authority to authorize `uiMultiplier` updates. Consider restricting this specific power solely to the `DEFAULT_ADMIN_ROLE` to centralize control over the token's value scaling, or implement a multi-signature scheme for such critical operations. Ensure robust processes for managing `ISSUER_ROLE` assignments.
StatusUnresolved
Medium

Gas Limit Risk for `issuers_` Array in `initialize`

M-01The `initialize` function iterates through the `issuers_` array to grant the `ISSUER_ROLE` to each address. If this array contains an excessively large number of addresses, the transaction to initialize the contract could exceed the block gas limit. This would prevent the contract from being successfully deployed and initialized, leading to operational failure.
IssueThe `initialize` function iterates through the `issuers_` array to grant the `ISSUER_ROLE` to each address. If this array contains an excessively large number of addresses, the transaction to initialize the contract could exceed the block gas limit. This would prevent the contract from being successfully deployed and initialized, leading to operational failure.
FixLimit the maximum size of the `issuers_` array passed during initialization. If a large number of issuers is anticipated, consider implementing a separate, batched function callable by the `DEFAULT_ADMIN_ROLE` after initialization to grant roles incrementally, or use a more gas-efficient method for initial role assignment.
StatusUnresolved
Low

High Reliance on External Contracts

L-01The `SecuritiesToken` contract heavily relies on external contracts, specifically `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable`. The security, availability, and correct functioning of these external contracts are critical to the `SecuritiesToken`'s operation, including transfer restrictions and pausing capabilities. Any vulnerability, compromise, or malicious action within these external contracts could directly impact the functionality and security of the token.
IssueThe `SecuritiesToken` contract heavily relies on external contracts, specifically `ComplianceClientUpgradeable` and `PauseManagerClientUpgradeable`. The security, availability, and correct functioning of these external contracts are critical to the `SecuritiesToken`'s operation, including transfer restrictions and pausing capabilities. Any vulnerability, compromise, or malicious action within these external contracts could directly impact the functionality and security of the token.
FixEnsure that the external `ComplianceClient` and `PauseManagerClient` contracts are thoroughly audited, well-maintained, and secured. Implement robust monitoring for these external dependencies. Consider adding circuit breakers or emergency mechanisms in the `SecuritiesToken` to mitigate risks if an integrated external contract becomes compromised or malfunctions.
StatusUnresolved
Info

Centralized Control of `DEFAULT_ADMIN_ROLE`

I-01The `DEFAULT_ADMIN_ROLE` holds extensive power over the contract, including managing all roles (granting/revoking `ISSUER_ROLE`), setting critical external contracts (compliance, pause manager), enabling/disabling core token functionalities like minting and burning, and changing token metadata (name, symbol, identifier). While common for managed tokens, this high degree of centralization represents a significant single point of failure and trust assumption, as a compromise of the admin key could lead to severe consequences.
IssueThe `DEFAULT_ADMIN_ROLE` holds extensive power over the contract, including managing all roles (granting/revoking `ISSUER_ROLE`), setting critical external contracts (compliance, pause manager), enabling/disabling core token functionalities like minting and burning, and changing token metadata (name, symbol, identifier). While common for managed tokens, this high degree of centralization represents a significant single point of failure and trust assumption, as a compromise of the admin key could lead to severe consequences.
FixImplement robust security measures for the `DEFAULT_ADMIN_ROLE` key, such as multi-signature wallets (e.g., Gnosis Safe) and strict operational procedures. Consider decentralizing certain administrative functions over time or introducing time-locks for critical changes to reduce immediate impact of a compromise.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract leverages OpenZeppelin's upgradeable patterns and Solidity 0.8.x, benefiting from built-in overflow/underflow protection and secure ERC-20 implementations (7.2 Code Security). The `_update` function correctly integrates compliance and pause checks, ensuring token transfers adhere to defined rules. However, a critical initialization vulnerability exists where providing `address(0)` for the `admin_` parameter can permanently lock administrative control (H-01). Additionally, a very large `issuers_` array during initialization could lead to gas limit issues, preventing successful deployment (M-01).

GovernanceHigh1/10

The `SecuritiesToken` implements a robust role-based access control system using `AccessControlEnumerableUpgradeable`, defining `DEFAULT_ADMIN_ROLE` and `ISSUER_ROLE`. The `DEFAULT_ADMIN_ROLE` holds extensive power, including managing all roles, setting critical external contracts (compliance, pause manager), and enabling/disabling core token functionalities (7.3 Access Control). The `ISSUER_ROLE` also possesses substantial authority, notably the ability to mint, burn, and authorize changes to the `uiMultiplier`, which directly impacts the token's effective value (H-02). This high degree of centralization and the broad powers granted to these roles represent a significant trust assumption and potential single point of failure (7.4 Economic).

UpgradesHigh1/10

The contract is designed for upgradeability, inheriting from OpenZeppelin's upgradeable contracts and correctly using `_disableInitializers()` in the constructor and an `initializer` function. The presence of a `__gap` storage variable ensures future upgrades can introduce new state variables without storage collisions (7.7 Upgrades). It is deployed behind a Beacon Proxy, which centralizes the implementation address for multiple proxy instances, streamlining upgrades. The security of the Beacon contract's admin is paramount for the integrity of the entire system.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

96.0% in top 10
93.7% in wallets2.3% in contracts
Effective Concentration94.6%

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

$1.12M across 7 pairs
Pancakeswap v3USDTanalysed$1.11M99.1%Pancakeswap v3WBNB$7.7K0.7%Pancakeswap v2AIBT$1.1K0.1%Pancakeswap v24$7790.1%Pancakeswap v24$520.0%Pancakeswap v2WBNB$40.0%
Show 1 more pairShow less
Pancakeswap v3BTCB$20.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 Holder35.7%
Top-3 Unlocked72.1%

Key Addresses

11 addresses
Deployer
0x64fd…8d53
Unlocked LP Held By
0x5df8…976d0x4e63…cb980x556b…d59e0xde6a…c0550xbe1b…3e320x0b82…fa250xef6e…cce70x4d82…e4360x57a8…26150x8c28…ab51

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 70% (96.0% total → 94.6% effective; 93.7% in EOAs, 2.3% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 2 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
MonkeyCritical RiskMonkeyCritical RiskInvesqo QQQ (QQQB)Critical RiskETHGas (GWEI)Critical RiskWIKI CAT (WKC)Critical RiskTether Gold (XAUT)Critical Risk

Would You Like a More Detailed Audit of Circle Internet Group Inc.?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit