Quantum Audit Logo

Is Kyber Network Crystal v2 a Scam?

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

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

Kyber Network Crystal v2 KNC
0xdefa…7202
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 8d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The Kyber Network Crystal v2 (KNC) token contract, implemented as an upgradeable ERC20, was audited for security vulnerabilities. The contract leverages OpenZeppelin's upgradeable standards for token functionality and access control. Key features include a dedicated minter role, a migration mechanism from an old KNC token, and an owner-controlled emergency drain function. While the architecture is standard for upgradeable tokens, a significant access control issue was identified where the owner lacks direct control over the minter role, posing a centralization risk. A potential reentrancy vector in the migration function was also noted.

1 High1 Medium1 Informational
! Early-stage analysis. This token has limited on-chain history (3d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$142.8K
Liquidity
$845.4K
Price
$0.1389
Token Age
3d
Top 10 Holders
67.5%

Security Findings

1 High1 Med1 Info
High

Minter Role Autonomy and Owner's Limited Control

H-01The `changeMinter` function is restricted to `onlyMinter`, meaning only the current `minter` address can transfer the `minter` role. The contract `owner` (who controls upgrades and `emergencyERC20Drain`) cannot directly revoke or reassign the `minter` role. This creates a significant access control limitation for the `owner` and a single point of failure for token supply control (7.3, 7.5).
IssueThe `changeMinter` function is restricted to `onlyMinter`, meaning only the current `minter` address can transfer the `minter` role. The contract `owner` (who controls upgrades and `emergencyERC20Drain`) cannot directly revoke or reassign the `minter` role. This creates a significant access control limitation for the `owner` and a single point of failure for token supply control (7.3, 7.5).
FixModify the `changeMinter` function to allow the `owner` to also change the `minter` role. Alternatively, implement a multi-signature wallet for the `minter` role or a time-locked mechanism for `minter` changes to provide a recovery mechanism and enhance security.
StatusUnresolved
Medium

Potential Reentrancy in `mintWithOldKnc`

M-01The `mintWithOldKnc` function performs an external call `IERC20Burnable(oldKNC).burnFrom(msg.sender, amount)` before updating the contract's internal state (`super._mint(msg.sender, amount)`). This violates the Checks-Effects-Interactions pattern (7.2, 7.6). If the `oldKNC` token contract is malicious or has a reentrant `burnFrom` implementation, it could potentially call back into `mintWithOldKnc` before the `_mint` operation completes, leading to `msg.sender` receiving more new KNC tokens than intended for a single burn.
IssueThe `mintWithOldKnc` function performs an external call `IERC20Burnable(oldKNC).burnFrom(msg.sender, amount)` before updating the contract's internal state (`super._mint(msg.sender, amount)`). This violates the Checks-Effects-Interactions pattern (7.2, 7.6). If the `oldKNC` token contract is malicious or has a reentrant `burnFrom` implementation, it could potentially call back into `mintWithOldKnc` before the `_mint` operation completes, leading to `msg.sender` receiving more new KNC tokens than intended for a single burn.
FixReorder the operations within `mintWithOldKnc` to follow the Checks-Effects-Interactions pattern. First, perform all checks, then update the contract's state (mint the new tokens), and finally, interact with external contracts (burn the old tokens). Consider adding a reentrancy guard if the `oldKNC` contract is not fully trusted.
StatusUnresolved
Info

Centralized Control of Critical Roles

I-01The `minter` role has the sole authority to mint new tokens, and the `owner` role has the sole authority to drain any ERC20 tokens accidentally sent to the contract (7.1, 7.3). While these are standard patterns for token contracts, they represent significant centralized control. Compromise of the `minter` key leads to arbitrary token minting, and compromise of the `owner` key leads to loss of funds sent to the contract.
IssueThe `minter` role has the sole authority to mint new tokens, and the `owner` role has the sole authority to drain any ERC20 tokens accidentally sent to the contract (7.1, 7.3). While these are standard patterns for token contracts, they represent significant centralized control. Compromise of the `minter` key leads to arbitrary token minting, and compromise of the `owner` key leads to loss of funds sent to the contract.
FixFor critical roles like `minter` and `owner`, consider implementing multi-signature wallets or a robust governance mechanism to distribute control and reduce the risk associated with a single point of failure.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes well-vetted OpenZeppelin upgradeable libraries for ERC20, Ownable, and Burnable functionalities, enhancing code security (7.2). The use of `SafeERC20` for external transfers mitigates common integer overflow/underflow risks. However, the `mintWithOldKnc` function performs an external call to `oldKNC.burnFrom` before updating its internal state, creating a potential reentrancy vulnerability (7.2, 7.6). This interaction pattern could be exploited if the `oldKNC` contract is malicious or reentrant.

GovernanceHigh1/10

The contract defines distinct `owner` and `minter` roles for access control (7.3). The `owner` has the power to recover accidentally sent ERC20 tokens via `emergencyERC20Drain`, which is a positive operational feature (7.8). However, a significant governance risk (7.5) exists because the `changeMinter` function is `onlyMinter`, meaning the `owner` cannot directly revoke or reassign the `minter` role. This grants the `minter` complete autonomy over token supply control, creating a single point of failure if the `minter` key is compromised or becomes unresponsive, potentially leading to economic instability (7.4).

UpgradesHigh1/10

The contract is designed as an upgradeable proxy using OpenZeppelin's `AdminUpgradeabilityProxy` and `initializer` pattern, which is a robust architecture (7.1, 7.7). The `owner` and `proxy_admin_owner` are both contracts, suggesting a multi-signature or governance mechanism controls upgrades, which is a strong security practice. However, the `owner`'s inability to directly control the `minter` role means that addressing a compromised or unresponsive `minter` would necessitate a contract upgrade, which is a more complex and potentially slower process than direct role management.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

67.5% in top 10
49.4% in wallets18.0% in contracts
Effective Concentration56.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

$854.4K across 10 pairs
Uniswap v4USDTanalysed$845.4K98.9%Uniswap v4ETH$7.7K0.9%Uniswap v4ZIK$8100.1%KyberswapUSDC$1520.0%KyberswapWBTC$1410.0%SushiswapWETH$1090.0%
Show 3 more pairsShow less
0x5F1d…D50aWETH$410.0%0x5F1d…D50aWBTC$90.0%0x5F1d…D50aUSDC$70.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x2948…177c
Unlocked LP Held By
0xd69d…c30e

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 — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • OZ ProxyAdmin -> Admin is unclassified contract
  • Top-10 concentration > 50% (67.5% total → 56.6% effective; 49.4% in EOAs, 18.0% in contracts — heavy)
  • 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 = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 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
Global Dollar (USDG)Critical RiskBigShortBets (BIGSB)Critical RiskFrankencoin (ZCHF)Critical RiskHeyAnon (ANON)Critical RiskRe Protocol reUSD (REUSD)Critical RiskRallyCritical Risk

Would You Like a More Detailed Audit of Kyber Network Crystal v2?

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

Get Detailed Audit