Quantum Audit Logo

Is Kairence a Scam?

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

Kairence KAI
0xca18…5ca1
Base
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.
Last checked 8d ago 1 audit on record New Launch · 12h old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The AgentToken contract implements an ERC20 token with a custom 'Humanship' ownership pattern and an explicitly disabled 'burnFrom' function. The code leverages OpenZeppelin standards, contributing to a solid foundation. Key findings include the centralized control inherent in the Humanship pattern, a minor usability issue in ownership transfer, and informational notes regarding initial token distribution and the disabled 'burnFrom' functionality. Overall, the contract exhibits a medium risk level, primarily due to the centralized nature of its control mechanisms.

1 Medium1 Low2 Informational
! Early-stage analysis. This token has limited on-chain history (12h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$59.5K
Liquidity
$74.6K
Price
$0.001225
Token Age
12h
Top 10 Holders
60.6%

Security Findings

1 Med1 Low2 Info
Medium

Centralized Control via Humanship

M-01The `Humanship` contract implements an ownership pattern where a single `_human` address holds significant control over the contract. This `_human` address is the sole entity capable of initiating an ownership transfer via `transferHumanship`. This centralization creates a single point of failure, as compromise of this address would grant an attacker full control over the contract's administrative functions (7.3 Access Control, 7.5 Governance).
IssueThe `Humanship` contract implements an ownership pattern where a single `_human` address holds significant control over the contract. This `_human` address is the sole entity capable of initiating an ownership transfer via `transferHumanship`. This centralization creates a single point of failure, as compromise of this address would grant an attacker full control over the contract's administrative functions (7.3 Access Control, 7.5 Governance).
FixConsider using a multi-signature wallet (e.g., Gnosis Safe) for the `_human` address to distribute control and reduce the risk associated with a single point of failure. Alternatively, implement a time-lock mechanism for critical administrative actions, including ownership transfers, to provide a window for intervention.
StatusUnresolved
Low

`transferHumanship` allows setting `_pendingHuman` to `address(0)`

L-01The `transferHumanship` function does not validate the `newHuman` address, allowing it to be set to `address(0)`. If `_pendingHuman` is set to `address(0)`, the `acceptHumanship` function can never be successfully called, as `msg.sender` can never be `address(0)`. This would effectively stall the ownership transfer process until the current `_human` initiates a new transfer with a valid address (7.2 Code Security).
IssueThe `transferHumanship` function does not validate the `newHuman` address, allowing it to be set to `address(0)`. If `_pendingHuman` is set to `address(0)`, the `acceptHumanship` function can never be successfully called, as `msg.sender` can never be `address(0)`. This would effectively stall the ownership transfer process until the current `_human` initiates a new transfer with a valid address (7.2 Code Security).
FixAdd a check in the `transferHumanship` function to ensure that `newHuman` is not the zero address. For example: `if (newHuman == address(0)) revert ZeroHuman();` (or a similar custom error).
StatusUnresolved
Info

Initial Token Supply Minted to Deployer

I-01In the `AgentToken` constructor, the entire `totalSupply_` is minted to `msg.sender` (the contract deployer). This design choice centralizes the initial distribution of all tokens to a single address (7.4 Economic).
IssueIn the `AgentToken` constructor, the entire `totalSupply_` is minted to `msg.sender` (the contract deployer). This design choice centralizes the initial distribution of all tokens to a single address (7.4 Economic).
FixThis is a design decision. Ensure that the implications of this centralized initial distribution are well-understood and align with the project's tokenomics and distribution strategy. If a more decentralized initial distribution is desired, consider alternative minting or distribution mechanisms.
StatusUnresolved
Info

`burnFrom` Function Explicitly Disabled

I-02The `burnFrom` function in `AgentToken` is explicitly implemented to always revert with `BurnFromDisabled()`. This means that tokens cannot be burned from an approved address, which deviates from the standard ERC20 behavior where `burnFrom` is typically available for approved amounts (7.1 Architecture, 7.4 Economic).
IssueThe `burnFrom` function in `AgentToken` is explicitly implemented to always revert with `BurnFromDisabled()`. This means that tokens cannot be burned from an approved address, which deviates from the standard ERC20 behavior where `burnFrom` is typically available for approved amounts (7.1 Architecture, 7.4 Economic).
FixThis is a deliberate design choice. Ensure that all potential integrations and users are aware that `burnFrom` functionality is not available. Document this deviation from standard ERC20 behavior clearly in project documentation to prevent unexpected issues with third-party protocols that might rely on this function.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical implementation of AgentToken is generally robust, utilizing battle-tested OpenZeppelin ERC20 and ERC20Permit libraries (7.2 Code Security). The custom `Humanship` contract provides a two-step ownership transfer mechanism, which is a good security practice (7.3 Access Control). However, a minor flaw exists where `transferHumanship` allows setting the pending human to the zero address, which can stall the transfer process (7.2 Code Security). The explicit disabling of `burnFrom` is a notable design choice (7.1 Architecture).

GovernanceHigh3/10

The `Humanship` pattern centralizes significant control in a single `_human` address, which acts as the contract owner (7.5 Governance). This address has the sole authority to initiate ownership transfers, creating a single point of failure (7.3 Access Control). The entire initial token supply is minted to the deployer, centralizing initial distribution (7.4 Economic). The explicit disabling of `burnFrom` might impact future economic integrations or expected token behaviors (7.4 Economic).

UpgradesLow7/10

The AgentToken contract is not implemented as an upgradeable proxy (7.7 Upgrades). This design choice eliminates risks associated with upgrade mechanisms, such as proxy initialization errors, storage collisions, or insecure upgrade paths. The contract is immutable once deployed, providing certainty regarding its functionality.

Security Checklist

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

Holder Composition

60.6% in top 10
9.3% in wallets51.2% in contracts
Effective Concentration29.8%

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

$176.8K across 4 pairs
Uniswap v4USDCanalysed$74.6K42.2%Uniswap v4NVDAc$50.8K28.8%Uniswap v4NVDAc$45.9K26.0%Uniswap v4USDC$5.5K3.1%

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
0x0147…57ff
Unlocked LP Held By
0xafaa…33df

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 — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (60.6% total → 29.8% effective; 9.3% in EOAs, 51.2% 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 = 42% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 42% of DEX liquidity)
  • Token age < 24h (brand new — bot activity, unproven)
  • 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

Related Audits

6 more on the record
Derive (DRV)Medium RiskVenice Deity (VVVEITY)Medium Risktokenbot (CLANKER)Medium RiskB3Medium RiskHandlPay (HANDL)Medium RiskLienFi (LFI)Medium Risk

Would You Like a More Detailed Audit of Kairence?

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

Get Detailed Audit