Quantum Audit Logo

Is Kite Safe?

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

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

Kite KITE
0x9045…16be
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 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The Kite token contract is an ERC-20 token with LayerZero Omnichain Fungible Token (OFT) capabilities and pausable functionality, inheriting from OpenZeppelin and LayerZero standard libraries. The contract exhibits a high degree of centralization, with the owner having control over initial minting, pausing transfers, and LayerZero configurations. While the code quality is good and standard libraries are used, the centralized control points introduce significant governance and economic risks. The contract is not upgradeable, which simplifies its architecture but removes flexibility for future changes or bug fixes.

1 High1 Medium3 Informational
Volume 24h
$496.8K
Liquidity
$812.8K
Price
$0.1127
Token Age
6mo
Top 10 Holders
66.9%

Security Findings

1 High1 Med3 Info
High

Centralized Control by Owner

H-01The `Ownable` pattern grants significant control to a single `owner` address. This includes the ability to `initialize` the token supply (minting all tokens to themselves), `pause` and `unpause` all token transfers, and `transferOwnership`. This centralization introduces a single point of failure; compromise of the owner's private key could lead to a complete loss of control over the token's functionality and potentially its economic stability.
IssueThe `Ownable` pattern grants significant control to a single `owner` address. This includes the ability to `initialize` the token supply (minting all tokens to themselves), `pause` and `unpause` all token transfers, and `transferOwnership`. This centralization introduces a single point of failure; compromise of the owner's private key could lead to a complete loss of control over the token's functionality and potentially its economic stability.
FixConsider implementing a multi-signature wallet for the `owner` address to distribute control and reduce the risk associated with a single point of failure. For critical operations, explore time-locks or a more decentralized governance mechanism.
StatusUnresolved
Medium

Single Point of Failure for LayerZero Configuration

M-01The `OFT` constructor sets the `_delegate` for LayerZero configurations to the `_owner` address. This means the same single owner address is responsible for managing critical cross-chain parameters and security settings within the LayerZero endpoint. A compromise of this owner key could allow an attacker to manipulate cross-chain message passing, potentially leading to unauthorized token transfers or denial of service for cross-chain operations.
IssueThe `OFT` constructor sets the `_delegate` for LayerZero configurations to the `_owner` address. This means the same single owner address is responsible for managing critical cross-chain parameters and security settings within the LayerZero endpoint. A compromise of this owner key could allow an attacker to manipulate cross-chain message passing, potentially leading to unauthorized token transfers or denial of service for cross-chain operations.
FixWhile the `OFT` contract itself doesn't expose delegate management functions, ensure the `owner` address (which acts as the LayerZero delegate) is secured with a robust multi-signature setup. Regularly review LayerZero configurations and permissions.
StatusUnresolved
Info

Irreversible `isNativeChain` Flag

I-01The `isNativeChain` boolean variable, which determines if the `initialize()` function can be called and where the total supply is minted, is set in the constructor and cannot be modified thereafter. This design ensures that the native chain designation is immutable, preventing accidental or malicious changes post-deployment.
IssueThe `isNativeChain` boolean variable, which determines if the `initialize()` function can be called and where the total supply is minted, is set in the constructor and cannot be modified thereafter. This design ensures that the native chain designation is immutable, preventing accidental or malicious changes post-deployment.
FixNo direct recommendation, as this is an intentional design choice. Ensure the initial deployment parameter for `_isNativeChain` is correctly set for each deployed instance.
StatusUnresolved
Info

Initial Token Distribution to Owner

I-02The `initialize()` function, callable only once by the `owner` on the native chain, mints the entire `TOTAL_SUPPLY` (10 billion KITE tokens) directly to the `msg.sender` (the owner). This design places the entire initial token supply under the control of the owner, who is then responsible for its distribution.
IssueThe `initialize()` function, callable only once by the `owner` on the native chain, mints the entire `TOTAL_SUPPLY` (10 billion KITE tokens) directly to the `msg.sender` (the owner). This design places the entire initial token supply under the control of the owner, who is then responsible for its distribution.
FixThis is a common initial distribution strategy. Ensure the owner has a clear and secure plan for distributing the tokens to avoid centralization concerns post-minting.
StatusUnresolved
Info

Non-Upgradeable Contract

I-03The `Kite` contract is implemented as a standard, non-proxy contract. This means it is not designed to be upgradeable. While this eliminates risks associated with upgrade mechanisms (e.g., proxy implementation bugs, upgrade path vulnerabilities), it also means that any discovered bugs or desired feature enhancements cannot be implemented without a complete redeployment and migration of assets.
IssueThe `Kite` contract is implemented as a standard, non-proxy contract. This means it is not designed to be upgradeable. While this eliminates risks associated with upgrade mechanisms (e.g., proxy implementation bugs, upgrade path vulnerabilities), it also means that any discovered bugs or desired feature enhancements cannot be implemented without a complete redeployment and migration of assets.
FixNo direct recommendation, as this is a design choice. Acknowledge the immutability and ensure thorough testing before deployment, as the contract cannot be modified once deployed.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages well-audited OpenZeppelin (ERC20, Pausable, Ownable) and LayerZero (OFT) libraries, contributing to robust code security (7.2 Code Security). The architecture (7.1 Architecture) is straightforward, combining standard token functionality with cross-chain capabilities. The `_update` function is correctly overridden to support both ERC20 and Pausable behaviors. A key technical dependency is the LayerZero endpoint (7.6 External), whose security is critical for cross-chain operations. The `isNativeChain` flag is immutably set in the constructor, ensuring consistent behavior for token initialization.

GovernanceMedium4/10

The contract design exhibits high centralization (7.3 Access Control, 7.5 Governance), with a single `owner` address controlling critical functions. The owner can mint the entire `TOTAL_SUPPLY` (10 billion tokens) to themselves via `initialize()`, pause all token transfers, and manage LayerZero configurations as the `_delegate`. This creates a significant single point of failure (7.4 Economic), where a compromise of the owner's key could lead to severe economic consequences, including frozen assets or manipulated cross-chain operations. There is no decentralized governance mechanism in place.

UpgradesLow7/10

The Kite contract is not designed as an upgradeable proxy (7.7 Upgrades). This eliminates the specific risks associated with upgrade mechanisms, such as proxy implementation bugs or insecure upgrade paths. However, it also means that the contract's logic is immutable post-deployment, preventing any future bug fixes or feature enhancements without a complete redeployment and asset migration.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

66.9% in top 10
0.0% in wallets66.9% in contracts
Effective Concentration26.7%

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

$814.7K across 2 pairs

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
0x148c…8799
Unlocked LP Held By
0x836d…f34f

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

What Raised This Score

7 factors
  • Ownership NOT renounced — strong Multisig (4-of-6)
  • Top-10 concentration > 20% (66.9% total → 26.7% effective; 0.0% in EOAs, 66.9% in contracts — mild)
  • 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 = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% 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

Frequently Asked Questions

Is Kite a scam?

Based solely on the provided data, we cannot definitively label Kite as a scam. However, its critical risk score of 75/100 is attributed to several significant red flags. Key concerns include a high concentration of tokens among the top 10 holders (68.5%), ownership of the contract not being renounced, and, critically, liquidity not being locked. These characteristics are often associated with high-risk projects and potential for adverse events.

Is Kite safe to buy?

Kite's current security profile indicates significant risks, making it unsafe to buy without extreme caution. The unrenounced ownership allows the contract deployer potential control, while the fact that 68.5% of the supply is concentrated in the top 10 wallets raises concerns about centralization and market manipulation. Most importantly, the liquidity for KITE is not locked, presenting a considerable 'rug pull' risk where funds could be withdrawn, impacting value.

Has Kite been audited?

The KITE contract is verified, meaning its code is publicly available and matches what's deployed on the blockchain. This transparency allows for community review. However, contract verification is not equivalent to a formal security audit. An audit involves an independent third-party expert review to identify vulnerabilities and confirm smart contract integrity. The provided data does not indicate that KITE has undergone such an audit.

Related Audits

6 more on the record
Chainlink (LINK)Medium RiskOctra (OCT)Medium RiskArtificial Superintelligence Alliance (FET)Medium RiskOndoMedium RiskRequest Token (REQ)Medium RiskProgrammable (V4)Medium Risk

Would You Like a More Detailed Audit of Kite?

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

Get Detailed Audit