Quantum Audit Logo
Launch App

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

Is Cysic a Scam?

CYSBase
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 recordNew Launch · 1d old
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical5/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 Critical · 1 High · 1 Medium · 1 Low4
SummaryAI Copilot

The CYS token contract is an ERC20 implementation with additional features including minting, burning, pausing, blacklisting, and batch transfers.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • 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
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • Token age < 7 days
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

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.

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
44.0%Contracts56.0%Everyone else
44.0%Contracts56.0%Everyone else
ContractsEveryone elseBubble area = share of supply
44.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking44.0%
  • Everyone elsethe rest of the supply56.0%
Effective concentrationwhat the score reads17.6%
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$241.3200 across 4 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$194Share of depth80.6%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xabee…bc42

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

Security Findings

1 Critical1 High1 Medium1 Low
Critical

Immutable BRIDGE_ROLE Assignment

The 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).C-01

Issue

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

Fix

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

Status

Unresolved

High

Centralized Control by Owner

The 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).H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Blacklist Functionality Risks

The 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).M-01

Issue

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

Fix

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

Status

Unresolved

Low

Potential for High Gas Costs in Batch Transfer

The 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).L-01

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical5/10Medium risk

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.

Governance1/10High risk

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.

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to re-evaluate the design of the BRIDGE_ROLE to introduce a mechanism for its management (e.g., via DEFAULT_ADMIN_ROLE or a multi-signature wallet) to mitigate the critical risk of permanent loss of minting/burning capabilities.

Additionally, consider implementing a timelock for sensitive owner-controlled actions like pausing or blacklisting to provide a window for community review and reaction. Ensure that the owner and bridge addresses are secured with robust multi-signature wallets and follow best practices for key management.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age1d
Contract0x19e8…ffa6
Deployer0x66a5…3e2b
Badge for your website
Cysic 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. Sep 4, 202684High
  2. Aug 8, 202661Medium

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

Related Audits

6 more on the recordAll audits
Wrapped L1coinWL1 · Base84HighFLock.ioFLOCK · Base85CriticalCoinbase Wrapped MEGACBMEGA · Base85Criticalbasedpad.funBPAD · Base85CriticalzipcoinZC · Base83HighStrike RobotSR · Base87Critical

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 Is this your token? Publish your own audit on this page