Quantum Audit Logo

Is Cysic a Scam?

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

Cysic CYS
0x19e8…ffa6
Base Not verifiedLast checked 3d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The CYS token contract is an ERC20 implementation with additional features including minting, burning, pausing, blacklisting, and batch transfers. It leverages OpenZeppelin contracts for core functionalities. A critical design decision involves the immutable assignment of the BRIDGE_ROLE, which grants minting and burning capabilities. This immutability, coupled with significant centralized control by the owner, introduces substantial operational and governance risks.

1 Critical1 High1 Medium1 Low
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$20.1200
Liquidity
$194.5000
Price
$0.5254
Token Age
1d
Top 10 Holders
44.0%

Security Findings

1 Crit1 High1 Med1 Low
Critical

Immutable BRIDGE_ROLE Assignment

C-01The `BRIDGE_ROLE`, which controls the `mint` and `burnFromAddress` functions, is granted to a single `bridge` address in the constructor. The contract explicitly states that 'No DEFAULT_ADMIN_ROLE is granted, so no one can manage BRIDGE_ROLE after deployment.' This means the `BRIDGE_ROLE` is permanently locked to the initial address. If this `bridge` address is compromised, becomes inactive, or needs to be changed for any reason, the critical minting and burning functionalities of the token will be permanently lost or controlled by an attacker. This represents a single point of failure with no recovery mechanism (7.3 Access Control, 7.5 Governance, 7.8 Operations).
IssueThe `BRIDGE_ROLE`, which controls the `mint` and `burnFromAddress` functions, is granted to a single `bridge` address in the constructor. The contract explicitly states that 'No DEFAULT_ADMIN_ROLE is granted, so no one can manage BRIDGE_ROLE after deployment.' This means the `BRIDGE_ROLE` is permanently locked to the initial address. If this `bridge` address is compromised, becomes inactive, or needs to be changed for any reason, the critical minting and burning functionalities of the token will be permanently lost or controlled by an attacker. This represents a single point of failure with no recovery mechanism (7.3 Access Control, 7.5 Governance, 7.8 Operations).
FixImplement a mechanism to manage the `BRIDGE_ROLE` post-deployment. This could involve granting the `DEFAULT_ADMIN_ROLE` to a secure multi-signature wallet or a governance contract, allowing for the `BRIDGE_ROLE` to be revoked or reassigned if necessary. Alternatively, if immutability is a strict design requirement, ensure the `bridge` address is an immutable, audited contract that itself has robust security and upgradeability, or accept the permanent risk.
StatusUnresolved
High

Centralized Control by Owner

H-01The contract owner, defined by the `Ownable` role, possesses significant centralized control over the token. The owner can `pause` all token transfers and `addToBlacklist` or `removeFromBlacklist` any address. This level of control allows a single entity to halt all token activity or arbitrarily restrict users, posing a high risk of censorship, fund freezing, or denial of service (7.3 Access Control, 7.4 Economic, 7.5 Governance).
IssueThe contract owner, defined by the `Ownable` role, possesses significant centralized control over the token. The owner can `pause` all token transfers and `addToBlacklist` or `removeFromBlacklist` any address. This level of control allows a single entity to halt all token activity or arbitrarily restrict users, posing a high risk of censorship, fund freezing, or denial of service (7.3 Access Control, 7.4 Economic, 7.5 Governance).
FixConsider decentralizing control over sensitive functions. For example, implement a multi-signature wallet for the owner address, or introduce a timelock for critical actions like pausing or blacklisting. This would provide a delay for community oversight and reaction, reducing the immediate impact of a compromised owner key or malicious action.
StatusUnresolved
Medium

Blacklist Functionality Risks

M-01The contract includes a `blacklist` functionality, allowing the owner to prevent specific addresses from sending or receiving tokens. While intended for security or compliance, this feature grants the owner the power to arbitrarily freeze or restrict user funds. This capability introduces a risk of censorship, abuse, or unintended consequences if the owner's address is compromised or acts maliciously (7.4 Economic, 7.5 Governance).
IssueThe contract includes a `blacklist` functionality, allowing the owner to prevent specific addresses from sending or receiving tokens. While intended for security or compliance, this feature grants the owner the power to arbitrarily freeze or restrict user funds. This capability introduces a risk of censorship, abuse, or unintended consequences if the owner's address is compromised or acts maliciously (7.4 Economic, 7.5 Governance).
FixClearly document the intended use cases and operational policies for the blacklist. Consider implementing a governance mechanism or multi-signature approval for blacklisting actions to increase transparency and accountability. If possible, explore alternative, less centralized methods for addressing security or compliance concerns.
StatusUnresolved
Low

Potential for High Gas Costs in Batch Transfer

L-01The `batchTransfer` function allows up to `MAX_BATCH` (100) transfers in a single transaction. While the `MAX_BATCH` limit prevents excessively large batches, executing 100 individual `_transfer` operations can still incur significant gas costs, especially during periods of high network congestion. This could lead to high transaction fees for users or transaction failures if the block gas limit is approached (7.2 Code Security).
IssueThe `batchTransfer` function allows up to `MAX_BATCH` (100) transfers in a single transaction. While the `MAX_BATCH` limit prevents excessively large batches, executing 100 individual `_transfer` operations can still incur significant gas costs, especially during periods of high network congestion. This could lead to high transaction fees for users or transaction failures if the block gas limit is approached (7.2 Code Security).
FixWhile not a critical vulnerability, users should be aware of potential gas costs. Consider optimizing the batch transfer mechanism if gas efficiency becomes a significant concern, though the current implementation is standard. Ensure `MAX_BATCH` is an appropriate limit for expected network conditions.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract demonstrates good code quality by utilizing battle-tested OpenZeppelin libraries for ERC20, burnable, pausable, and access control functionalities (7.2 Code Security). The `batchTransfer` function includes necessary input validation, and the `_update` override correctly integrates blacklist checks. However, a significant technical risk lies in the immutable assignment of the `BRIDGE_ROLE` in the constructor, preventing any future changes to the minter/burner address (7.3 Access Control). This design choice creates a single point of failure for critical token operations.

GovernanceHigh1/10

The contract's economic and governance model is highly centralized. The `Ownable` role holds extensive power, including the ability to pause all token transfers and blacklist any address (7.4 Economic, 7.5 Governance). This allows for potential censorship or freezing of funds. Critically, the `BRIDGE_ROLE`, responsible for minting and burning, is permanently assigned to a single address during deployment, with no mechanism for revocation or reassignment (7.5 Governance, 7.8 Operations). This immutability poses a severe risk if the bridge address is compromised or becomes inactive, as it would permanently disable core token functionalities.

UpgradesHigh3/10

The CYS token contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, there are no upgrade-related risks such as proxy implementation mismatches, storage collisions, or uninitialized proxy issues. Any changes to the contract's logic would require a new deployment and migration.

Security Checklist

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

Holder Composition

44.0% in top 10
0.0% in wallets44.0% in contracts
Effective Concentration17.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

$241.3200 across 4 pairs
Uniswap v4USDCanalysed$19480.6%Uniswap v4USDC$3113.0%Uniswap v4USDC$156.4%

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

Key Addresses

2 addresses
Deployer
0x66a5…3e2b
Unlocked LP Held By
0xabee…bc42

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

What Raised This Score

11 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Mintable supply — no cap found, dilution unbounded
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $10k ($241 across 4 pairs — easily drained)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 81% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 81% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 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 RiskCoinbase Wrapped MEGA (CBMEGA)Critical Riskbasedpad.fun (BPAD)Critical RiskStrike Robot (SR)Critical RiskRatspeakCritical RiskMineBean (BEAN)Critical Risk

Would You Like a More Detailed Audit of Cysic?

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

Get Detailed Audit