Quantum Audit Logo

Is Cysic Token a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

Cysic Token CYS
0x0c69…07c7
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 20h old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The CYS token contract is an ERC20 implementation with standard OpenZeppelin extensions for burnable, pausable, and access control features. It includes a blacklisting mechanism and a bridge role for minting/burning. The contract exhibits a high degree of centralization, with the owner and bridge role possessing significant control over token supply, transfers, and user funds. While the code quality is high and standard security practices are followed, the centralized nature introduces inherent risks related to key management and operational security.

1 High2 Medium3 Informational
! Early-stage analysis. This token has limited on-chain history (20h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$0.5400
Liquidity
$7.8K
Price
$0.2601
Token Age
20h
Top 10 Holders
89.1%

Security Findings

1 High2 Med3 Info
High

Centralized Control Over Critical Functions

H-01The contract grants significant power to the `owner` role (inherited from `Ownable`) and the `BRIDGE_ROLE` (managed by `AccessControl`). The `owner` can pause/unpause transfers, add/remove addresses from a blacklist, and grant/revoke the `BRIDGE_ROLE`. The `BRIDGE_ROLE` can mint new tokens and burn existing ones. This high degree of centralization means that a compromise of the owner's keys or the bridge's keys could lead to severe consequences, including freezing user funds, arbitrary token minting/burning, or halting all token operations. (7.3 Access Control, 7.4 Economic, 7.8 Operations)
IssueThe contract grants significant power to the `owner` role (inherited from `Ownable`) and the `BRIDGE_ROLE` (managed by `AccessControl`). The `owner` can pause/unpause transfers, add/remove addresses from a blacklist, and grant/revoke the `BRIDGE_ROLE`. The `BRIDGE_ROLE` can mint new tokens and burn existing ones. This high degree of centralization means that a compromise of the owner's keys or the bridge's keys could lead to severe consequences, including freezing user funds, arbitrary token minting/burning, or halting all token operations. (7.3 Access Control, 7.4 Economic, 7.8 Operations)
FixEnsure the `owner` address is a robustly secured multisig wallet with a high threshold. Implement strict operational procedures and key management for both the `owner` and the `BRIDGE_ROLE` to minimize the risk of compromise. Consider a timelock for critical administrative actions if feasible for the project's operational needs.
StatusUnresolved
Medium

Owner's Ability to Blacklist Accounts

M-01The `onlyOwner` functions `addToBlacklist` and `removeFromBlacklist` allow the contract owner to prevent specific addresses from sending or receiving CYS tokens. The `_update` internal function enforces this blacklist for all transfers. While this feature can be useful for compliance or mitigating stolen funds, it introduces a single point of control that could be misused to censor legitimate users or arbitrarily freeze funds. (7.3 Access Control, 7.4 Economic)
IssueThe `onlyOwner` functions `addToBlacklist` and `removeFromBlacklist` allow the contract owner to prevent specific addresses from sending or receiving CYS tokens. The `_update` internal function enforces this blacklist for all transfers. While this feature can be useful for compliance or mitigating stolen funds, it introduces a single point of control that could be misused to censor legitimate users or arbitrarily freeze funds. (7.3 Access Control, 7.4 Economic)
FixClearly document the policy and criteria for blacklisting accounts. Implement a transparent process for blacklisting decisions, potentially involving community governance or a public announcement period. Consider adding a mechanism for users to appeal blacklisting decisions if appropriate for the project's design.
StatusUnresolved
Medium

Privileged Minting and Burning Authority

M-02The `mint` and `burnFromAddress` functions are protected by the `BRIDGE_ROLE`. This role has the exclusive ability to increase the total supply of CYS tokens and to reduce the supply by burning tokens from any address. This is a common pattern for bridged tokens, but it means the security of the bridge mechanism and the management of the `BRIDGE_ROLE` are paramount. An exploit in the bridge or a compromise of the `BRIDGE_ROLE` key could lead to uncontrolled inflation or arbitrary fund destruction. (7.3 Access Control, 7.4 Economic, 7.6 External)
IssueThe `mint` and `burnFromAddress` functions are protected by the `BRIDGE_ROLE`. This role has the exclusive ability to increase the total supply of CYS tokens and to reduce the supply by burning tokens from any address. This is a common pattern for bridged tokens, but it means the security of the bridge mechanism and the management of the `BRIDGE_ROLE` are paramount. An exploit in the bridge or a compromise of the `BRIDGE_ROLE` key could lead to uncontrolled inflation or arbitrary fund destruction. (7.3 Access Control, 7.4 Economic, 7.6 External)
FixImplement robust security measures for the bridge system, including multi-signature approvals for bridge operations, rate limits on minting/burning, and continuous monitoring. The private keys associated with the `BRIDGE_ROLE` should be secured with the highest industry standards, potentially using hardware security modules (HSMs) or multi-party computation (MPC).
StatusUnresolved
Info

Non-Upgradeable Contract

I-01The `CYS` contract is deployed directly and does not implement any proxy pattern (e.g., UUPS, Transparent) for upgradeability. This means that any future bug fixes, feature enhancements, or protocol changes would require deploying an entirely new contract and migrating all token holders and liquidity, which is a complex and costly process. (7.1 Architecture, 7.7 Upgrades)
IssueThe `CYS` contract is deployed directly and does not implement any proxy pattern (e.g., UUPS, Transparent) for upgradeability. This means that any future bug fixes, feature enhancements, or protocol changes would require deploying an entirely new contract and migrating all token holders and liquidity, which is a complex and costly process. (7.1 Architecture, 7.7 Upgrades)
FixAcknowledge that the contract is not upgradeable. For future projects, consider using an upgradeable proxy pattern if the project anticipates needing flexibility for future changes or bug fixes. For this contract, ensure thorough testing and auditing to minimize the need for future changes.
StatusUnresolved
Info

Potential High Gas Costs for Batch Transfers

I-02The `batchTransfer` function allows transferring tokens to up to `MAX_BATCH` (100) recipients in a single transaction. While the `MAX_BATCH` limit prevents excessively large arrays, processing 100 transfers in a single transaction can still incur significant gas costs, especially on networks like Ethereum or during periods of high network congestion. This could lead to transaction failures if the gas limit is exceeded or make the function economically unfeasible for users. (7.2 Code Security, 7.8 Operations)
IssueThe `batchTransfer` function allows transferring tokens to up to `MAX_BATCH` (100) recipients in a single transaction. While the `MAX_BATCH` limit prevents excessively large arrays, processing 100 transfers in a single transaction can still incur significant gas costs, especially on networks like Ethereum or during periods of high network congestion. This could lead to transaction failures if the gas limit is exceeded or make the function economically unfeasible for users. (7.2 Code Security, 7.8 Operations)
FixInform users about potential gas costs for large batch transfers. Consider providing alternative methods for distributing tokens or advise users to split very large distributions into smaller batches if gas costs become prohibitive. Monitor gas usage in production.
StatusUnresolved
Info

Initial Bridge Role Assignment

I-03The constructor allows the `bridge` address to be `address(0)`. If `bridge` is `address(0)`, the `BRIDGE_ROLE` is not granted during deployment. While this might be an intentional design choice to allow the owner to grant the role later, it means that minting and burning capabilities would be unavailable until the owner explicitly grants the role to a valid address. (7.3 Access Control, 7.8 Operations)
IssueThe constructor allows the `bridge` address to be `address(0)`. If `bridge` is `address(0)`, the `BRIDGE_ROLE` is not granted during deployment. While this might be an intentional design choice to allow the owner to grant the role later, it means that minting and burning capabilities would be unavailable until the owner explicitly grants the role to a valid address. (7.3 Access Control, 7.8 Operations)
FixEnsure that the deployment script correctly provides a valid `bridge` address if minting/burning functionality is required immediately after deployment. If the intention is to grant the role later, ensure the owner is aware of this operational step.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages well-audited OpenZeppelin libraries, ensuring a solid foundation for ERC20 functionality and extensions like burning and pausing. The `_update` override correctly integrates the blacklisting mechanism, preventing transfers to/from blacklisted addresses (7.2 Code Security). The `batchTransfer` function includes robust input validation, checking array lengths, zero addresses, and non-zero amounts, and limits batch size to 100, mitigating potential attack vectors and gas issues (7.2 Code Security). However, the centralized control over critical functions like minting, burning, pausing, and blacklisting introduces a technical risk, as the security of the owner and bridge role keys is paramount (7.3 Access Control).

GovernanceHigh1/10

The economic model is highly centralized, with the `owner` having extensive control over the token's operational state and user access. The owner can pause all transfers, effectively halting the token's utility, and can blacklist individual accounts, freezing their funds (7.4 Economic, 7.5 Governance). Furthermore, the `BRIDGE_ROLE` has the exclusive ability to mint new tokens and burn existing ones, directly impacting the total supply and potentially devaluing existing tokens if misused (7.4 Economic). The security and governance of the `owner` and `BRIDGE_ROLE` are critical to the economic stability and trustworthiness of the CYS token (7.5 Governance).

UpgradesMedium4/10

The CYS contract is deployed directly and does not implement any upgradeability pattern (e.g., UUPS, Transparent proxies). This means the contract's logic is immutable once deployed. While this eliminates risks associated with upgrade mechanisms, it also means that any future bug fixes or feature enhancements would require a new contract deployment and a complex token migration process (7.7 Upgrades).

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

89.1% in top 10
12.9% in wallets76.2% in contracts
Effective Concentration43.4%

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

$11.8K across 6 pairs
UniswapLUCKYanalysed$7.8K66.6%UniswapEV$3.6K30.6%Pancakeswap v3USDT$2962.5%Pancakeswap v2USDT$220.2%Pancakeswap v2Subject 3$140.1%UniswapUSDT$10.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 Holder72.2%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0x66a5…3e2b
Unlocked LP Held By
0x3410…73910xda13…946b

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

What Raised This Score

10 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (89.1% total → 43.4% effective; 12.9% in EOAs, 76.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($11,784 across 6 pairs — thin market)
  • LP top1 unlocked holder = 72.2% (independent LP — depth risk, pool = 67% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 67% of DEX liquidity)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 High finding(s) from audit
  • 2 Medium 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
SpaceX (SPCXB)Critical RiskLorenzo Governance Token (BANK)Critical RiskVenusCoinCritical RiskBedrock (BR)Critical RiskBased Token (BASED)Critical RiskZypher Token (POP)Critical Risk

Would You Like a More Detailed Audit of Cysic Token?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit