Quantum Audit Logo

Is Chainflip Safe?

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

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

Chainflip FLIP
0x8261…678a
Ethereum
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 9d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FLIP token contract is an ERC-20 compliant token with a centralized 'issuer' role responsible for minting and burning tokens. While the code quality is good and standard ERC20 functionalities are correctly implemented, the high degree of centralization around the 'issuer' poses significant economic and operational risks. The contract is not upgradeable.

1 High1 Medium1 Informational
Volume 24h
$90.5K
Liquidity
$218.1K
Price
$0.3196
Token Age
2y
Top 10 Holders
73.3%

Security Findings

1 High1 Med1 Info
High

Centralized Control over Token Supply

H-01The `issuer` address has exclusive control over the `mint` and `burn` functions, allowing arbitrary changes to the token supply. This introduces significant centralization risk, as a single entity can inflate or deflate the token supply at will, directly impacting token economics and value. This is a design choice but represents a major trust assumption (7.4 Economic, 7.3 Access Control).
IssueThe `issuer` address has exclusive control over the `mint` and `burn` functions, allowing arbitrary changes to the token supply. This introduces significant centralization risk, as a single entity can inflate or deflate the token supply at will, directly impacting token economics and value. This is a design choice but represents a major trust assumption (7.4 Economic, 7.3 Access Control).
FixIf possible, consider implementing a multi-signature wallet for the `issuer` role or a time-locked mechanism for large supply changes. If centralized control is intentional, ensure robust operational security for the `issuer` key and transparent communication regarding supply management policies.
StatusUnresolved
Medium

Single Point of Failure for Issuer Role

M-01The `issuer` address is a single point of failure. If the private key for this address is compromised, lost, or becomes inaccessible, an attacker could gain full control over token minting/burning, or legitimate operations could be halted. The `updateIssuer` function, while allowing transfer of the role, is also controlled solely by the current `issuer` (7.3 Access Control, 7.8 Operations).
IssueThe `issuer` address is a single point of failure. If the private key for this address is compromised, lost, or becomes inaccessible, an attacker could gain full control over token minting/burning, or legitimate operations could be halted. The `updateIssuer` function, while allowing transfer of the role, is also controlled solely by the current `issuer` (7.3 Access Control, 7.8 Operations).
FixImplement a multi-signature wallet for the `issuer` role to distribute control and significantly reduce the risk associated with a single point of failure. Establish clear operational procedures for key management, role transfers, and emergency scenarios.
StatusUnresolved
Info

Standard ERC20 Front-Running Vulnerabilities

I-01Functions like `approve`, `increaseAllowance`, and `decreaseAllowance` are susceptible to front-running attacks. For example, if a user calls `approve(spender, newAmount)` to reduce an allowance, a malicious `spender` could front-run this transaction, spend the original allowance, and then the `newAmount` would still be approved, leading to a double-spend of the intended allowance (7.2 Code Security).
IssueFunctions like `approve`, `increaseAllowance`, and `decreaseAllowance` are susceptible to front-running attacks. For example, if a user calls `approve(spender, newAmount)` to reduce an allowance, a malicious `spender` could front-run this transaction, spend the original allowance, and then the `newAmount` would still be approved, leading to a double-spend of the intended allowance (7.2 Code Security).
FixUsers should be aware of this standard ERC20 behavior. For critical operations, consider using `increaseAllowance` and `decreaseAllowance` instead of direct `approve` calls, although `decreaseAllowance` still has a front-running risk if the `spender` spends the allowance before the `decreaseAllowance` transaction confirms. The OpenZeppelin `_spendAllowance` function mitigates some risks by checking `currentAllowance >= amount` before decrementing.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages standard ERC20 implementation patterns, including robust handling of token transfers, approvals, minting, and burning. It uses `unchecked` blocks appropriately after `require` statements to prevent overflows/underflows (7.2 Code Security). Input validation for non-zero addresses and amounts is present in the constructor and `updateIssuer` (7.2 Code Security). However, the core technical design grants significant power to a single `issuer` address, which controls token supply and can update its own role (7.3 Access Control).

GovernanceHigh1/10

The economic model of the FLIP token is highly centralized, with the `issuer` having absolute control over the token supply through `mint` and `burn` functions (7.4 Economic). This design choice means the token's value is heavily reliant on the trustworthiness and operational security of the `issuer`. The `issuer` can also unilaterally transfer its role to any address (7.5 Governance), posing a significant governance risk if the issuer key is compromised.

UpgradesHigh3/10

The FLIP token contract is not designed with an upgradeability mechanism (7.7 Upgrades). This means its logic is immutable once deployed, preventing future modifications or bug fixes without a full redeployment and migration of assets. This design choice eliminates upgrade-related risks but limits future flexibility.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

73.3% in top 10
8.6% in wallets64.7% in contracts
Effective Concentration34.5%

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

$325.2K across 6 pairs
Uniswap v3USDCanalysed$218.1K67.1%Uniswap v3USDT$105.6K32.5%Uniswap v3WETH$1.5K0.5%

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

3 addresses
Deployer
0xb9e6…bc36
Unlocked LP Held By
0x95bb…e7880x8335…cf30

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

What Raised This Score

8 factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (73.3% total → 34.5% effective; 8.6% in EOAs, 64.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 67% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 67% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 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
Tether Gold (XAUT)High RiskMatrix (MTX)High RiskAnimecoin (ANIME)High RiskCentrifuge (CFG)High RiskAPI3High RiskRova Protocol (ROVA)High Risk

Would You Like a More Detailed Audit of Chainflip?

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

Get Detailed Audit