Quantum Audit Logo

Is KarratCoin Safe?

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

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

KarratCoin KARRAT
0xacd2…3650
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The Karrat token contract is an ERC-20 implementation utilizing battle-tested OpenZeppelin libraries for its core functionalities, including ERC20, ERC20Permit, and ERC20Votes. The contract's custom logic is minimal, primarily handling the initial minting of the entire token supply to two specified multisig addresses. No critical or high-severity vulnerabilities were identified. The primary risks are related to the non-upgradeable nature of the contract and the centralized initial distribution, which are design choices rather than implementation flaws.

2 Low2 Informational
Volume 24h
$164.1K
Liquidity
$81.7K
Price
$0.003505
Token Age
1y
Top 10 Holders
78.1%

Security Findings

2 Low2 Info
Low

Non-Upgradeable Contract Design

L-01The Karrat token contract is deployed as a standard, non-upgradeable contract. While this eliminates upgrade-related risks (7.7 Upgrades), it means the contract's logic cannot be modified or patched in the future without a new deployment and token migration. This lack of flexibility could be a concern if critical bugs are discovered or if new features are required post-deployment (7.8 Operations).
IssueThe Karrat token contract is deployed as a standard, non-upgradeable contract. While this eliminates upgrade-related risks (7.7 Upgrades), it means the contract's logic cannot be modified or patched in the future without a new deployment and token migration. This lack of flexibility could be a concern if critical bugs are discovered or if new features are required post-deployment (7.8 Operations).
FixAcknowledge the implications of a non-upgradeable design. For core token contracts, this is often an acceptable trade-off for simplicity and reduced attack surface. If future flexibility is desired, consider an upgradeable proxy pattern for future contracts, but be aware of the added complexity and attack vectors.
StatusUnresolved
Low

Centralized Initial Token Distribution

L-02The entire token supply (1 billion KARRAT) is minted to two specified `MULTISIGONE` and `MULTISIGTWO` addresses in the constructor. This centralizes initial control of the token supply, meaning the security of these two multisig addresses is critical to the overall integrity and safety of the token (7.3 Access Control, 7.4 Economic). Compromise of these addresses could lead to the loss or misuse of the entire token supply.
IssueThe entire token supply (1 billion KARRAT) is minted to two specified `MULTISIGONE` and `MULTISIGTWO` addresses in the constructor. This centralizes initial control of the token supply, meaning the security of these two multisig addresses is critical to the overall integrity and safety of the token (7.3 Access Control, 7.4 Economic). Compromise of these addresses could lead to the loss or misuse of the entire token supply.
FixEnsure that the `MULTISIGONE` and `MULTISIGTWO` addresses are controlled by robust, multi-signature wallets with strong operational security practices. Implement strict internal policies and procedures for managing these keys and executing transactions. This is a design choice, so the recommendation focuses on mitigating the associated operational risk.
StatusUnresolved
Info

High Reliance on OpenZeppelin Standard Libraries

I-01The Karrat contract heavily relies on battle-tested and widely audited OpenZeppelin contracts (`ERC20`, `ERC20Permit`, `ERC20Votes`). This significantly reduces the attack surface and the likelihood of common vulnerabilities being present in the core token logic (7.2 Code Security). The custom logic is minimal, primarily consisting of constructor initialization and necessary overrides.
IssueThe Karrat contract heavily relies on battle-tested and widely audited OpenZeppelin contracts (`ERC20`, `ERC20Permit`, `ERC20Votes`). This significantly reduces the attack surface and the likelihood of common vulnerabilities being present in the core token logic (7.2 Code Security). The custom logic is minimal, primarily consisting of constructor initialization and necessary overrides.
FixContinue to leverage well-audited libraries for core functionalities. Regularly monitor OpenZeppelin's security advisories and updates, although direct upgrades are not possible for this non-upgradeable contract.
StatusUnresolved
Info

ERC20Votes Checkpoint Mechanism

I-02The `ERC20Votes` implementation uses `block.number` for its checkpointing mechanism to track voting power over time. While this is a standard and gas-efficient approach, `block.number` can be subject to minor manipulation by miners (e.g., delaying a block or including a transaction in a slightly earlier/later block) (7.4 Economic). For most governance applications, this level of manipulation is not a significant concern, but it's a known characteristic of `block.number` based systems.
IssueThe `ERC20Votes` implementation uses `block.number` for its checkpointing mechanism to track voting power over time. While this is a standard and gas-efficient approach, `block.number` can be subject to minor manipulation by miners (e.g., delaying a block or including a transaction in a slightly earlier/later block) (7.4 Economic). For most governance applications, this level of manipulation is not a significant concern, but it's a known characteristic of `block.number` based systems.
FixNo direct action is required as this is a standard and accepted design pattern for `ERC20Votes`. Be aware of this characteristic if extremely precise, unmanipulable timing for vote calculations becomes a critical requirement for future governance mechanisms.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The Karrat contract demonstrates high technical quality by leveraging well-audited OpenZeppelin libraries for its ERC-20, ERC-20 Permit, and ERC-20 Votes functionalities (7.2 Code Security). The custom logic is minimal and correctly implements the required overrides for `_update` and `nonces`. No reentrancy, integer overflow/underflow, or other common technical vulnerabilities were found (7.2 Code Security). The contract's architecture is straightforward, focusing on standard token behavior (7.1 Architecture).

GovernanceHigh1/10

The economic model involves a fixed total supply minted entirely to two multisig addresses at deployment (7.4 Economic). This centralized initial distribution means the security of these multisigs is paramount (7.3 Access Control). The inclusion of ERC20Votes enables future decentralized governance mechanisms, allowing token holders to delegate voting power (7.5 Governance).

UpgradesMedium6/10

The Karrat token contract is deployed as a standard, non-upgradeable implementation (7.7 Upgrades). This design choice eliminates all upgrade-related risks, such as proxy misconfigurations or implementation bugs during upgrades. However, it also means that the contract's logic cannot be modified or patched in the future without a new deployment and a potentially complex token migration process (7.8 Operations).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

78.1% in top 10
51.7% in wallets26.4% in contracts
Effective Concentration62.2%

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

$81.9K across 2 pairs
Uniswap v4ETHanalysed$81.7K99.7%Uniswap v3WETH$2290.3%

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
0x1ba2…ab48
Unlocked LP Held By
0xc659…7aab0x084e…f167

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

What Raised This Score

6 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 50% (78.1% total → 62.2% effective; 51.7% in EOAs, 26.4% 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 = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 2 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
Chainlink (LINK)Medium RiskKiteMedium RiskOctra (OCT)Medium RiskArtificial Superintelligence Alliance (FET)Medium RiskOndoMedium RiskRequest Token (REQ)Medium Risk

Would You Like a More Detailed Audit of KarratCoin?

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

Get Detailed Audit