Quantum Audit Logo

Is Milady Cult Coin Safe?

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

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

Milady Cult Coin CULT
0x0000…eca4
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? → High Risk
Executive SummaryAI Copilot

The Cult contract implements an ERC20 token with a linear vesting mechanism. It leverages well-audited Solady libraries for core functionalities and includes a reentrancy guard. The contract is owned by a multisig, which manages vesting schedules and treasury operations. No critical or high-severity vulnerabilities were identified. Minor issues include unused variables and a potential typo in an import path.

2 Low2 Informational
Volume 24h
$102.5K
Liquidity
$4.16M
Price
$0.0001407
Token Age
1y
Top 10 Holders
73.6%

Security Findings

2 Low2 Info
Low

Centralized Control over Vesting and Treasury

L-01The `Ownable` pattern grants the contract owner (a multisig) exclusive control over critical functions. The owner can set all vesting schedules via `setVest` and manage contract funds (ETH and other ERC20 tokens) via `transferEther` and `transferToken`. This centralization means the security of the protocol heavily relies on the integrity and operational security of the multisig owner. While a multisig mitigates single points of failure, it still represents a single administrative entity.
IssueThe `Ownable` pattern grants the contract owner (a multisig) exclusive control over critical functions. The owner can set all vesting schedules via `setVest` and manage contract funds (ETH and other ERC20 tokens) via `transferEther` and `transferToken`. This centralization means the security of the protocol heavily relies on the integrity and operational security of the multisig owner. While a multisig mitigates single points of failure, it still represents a single administrative entity.
FixEnsure the multisig owner's keys are managed with the highest security standards. Implement robust internal processes for transaction approval and consider transparent communication regarding owner actions, especially those affecting vesting schedules or treasury movements.
StatusUnresolved
Low

Potential Typo in ReentrancyGuard Import Path

L-02The import path for `ReentrancyGuard` is specified as `soledge/utils/ReentrancyGuard.sol`. Given that all other utility imports are from `solady/utils/`, this might be a typographical error and intended to be `solady/utils/ReentrancyGuard.sol`. If `soledge` refers to a different, potentially less-audited or custom library, it could introduce an unknown dependency risk. If it is indeed a typo and resolves to Solady's library, the risk is minimal.
IssueThe import path for `ReentrancyGuard` is specified as `soledge/utils/ReentrancyGuard.sol`. Given that all other utility imports are from `solady/utils/`, this might be a typographical error and intended to be `solady/utils/ReentrancyGuard.sol`. If `soledge` refers to a different, potentially less-audited or custom library, it could introduce an unknown dependency risk. If it is indeed a typo and resolves to Solady's library, the risk is minimal.
FixVerify the exact import path and ensure that `soledge/utils/ReentrancyGuard.sol` correctly points to the intended and audited `ReentrancyGuard` implementation, preferably Solady's. If it's a typo, correct the import statement to `solady/utils/ReentrancyGuard.sol` for clarity and consistency.
StatusUnresolved
Info

Unused `MESSAGE` Constant

I-01The `MESSAGE` constant is declared at the contract level but is not referenced or used anywhere within the contract's logic. Unused variables can increase bytecode size slightly and may indicate leftover code from previous development iterations.
IssueThe `MESSAGE` constant is declared at the contract level but is not referenced or used anywhere within the contract's logic. Unused variables can increase bytecode size slightly and may indicate leftover code from previous development iterations.
FixRemove the `MESSAGE` constant if it serves no current or planned purpose to optimize bytecode size and improve code clarity.
StatusUnresolved
Info

Unused `lastClaimTime` in Vesting Calculation

I-02The `lastClaimTime` field within the `Vest` struct is updated in the `pushVest` function to `block.timestamp`. However, this field is not utilized in the `FixedPointMathLib.lerp` calculation, which directly uses `block.timestamp` for determining the currently vested amount. This means `lastClaimTime` is purely informational in the current implementation and does not affect the vesting schedule or claimable amount.
IssueThe `lastClaimTime` field within the `Vest` struct is updated in the `pushVest` function to `block.timestamp`. However, this field is not utilized in the `FixedPointMathLib.lerp` calculation, which directly uses `block.timestamp` for determining the currently vested amount. This means `lastClaimTime` is purely informational in the current implementation and does not affect the vesting schedule or claimable amount.
FixClarify the intended purpose of `lastClaimTime`. If it's not meant to influence the vesting calculation, consider if it's truly necessary or if its name implies a function it doesn't perform. If it's for future functionality, document its purpose.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates strong technical security by utilizing battle-tested Solady libraries for ERC20, Ownable, FixedPointMathLib, and SafeTransferLib (7.2 Code Security). A ReentrancyGuard is correctly implemented in the `pushVest` function, mitigating reentrancy risks (7.2 Code Security). The linear vesting logic using `FixedPointMathLib.lerp` appears sound and correctly calculates vested amounts (7.1 Architecture). A minor concern is a potential typo in the `ReentrancyGuard` import path, which should be verified (7.6 External). Additionally, an unused constant and an unused field in the vesting struct were noted (7.2 Code Security).

GovernanceHigh1/10

The contract employs an `Ownable` access control pattern, with the owner being a multisig address (7.3 Access Control). This multisig has significant control, including the ability to set all vesting schedules via `setVest` and manage the contract's treasury (ETH and other ERC20 tokens) via `transferEther` and `transferToken` (7.4 Economic). While this centralization is inherent to the `Ownable` model, the use of a multisig enhances operational security by requiring multiple approvals for sensitive actions (7.5 Governance). The initial token supply of 100 billion CULT tokens is minted entirely to the owner in the constructor (7.4 Economic).

UpgradesMedium6/10

The Cult contract is not designed to be upgradeable. It is a standard, immutable contract deployed directly to the blockchain (7.7 Upgrades). This eliminates upgrade-related risks such as proxy implementation bugs or administrative key compromise for upgrades, but also means that any discovered vulnerabilities or desired feature changes would require a new deployment.

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

73.6% in top 10
3.4% in wallets70.2% in contracts
Effective Concentration31.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

$4.17M across 6 pairs
Uniswap v3WETHanalysed$4.16M99.7%Uniswap v3SPX$7.8K0.2%Uniswap v4ETH$2.5K0.1%Uniswap v4PC$1.5K0.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 Holder98.8%
Top-3 Unlocked99.5%

Key Addresses

11 addresses
Deployer
0x1ec7…6563
Unlocked LP Held By
0xd5cd…d7800x4258…c24e0x5670…8eb70x2da3…2d0c0x503d…b98e0x8e86…3ff10xbfbf…9b540x4744…4c0d0xb4c3…fd440x02c5…e114

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

6 factors
  • Ownership NOT renounced — Multisig (3-of-4)
  • Top-10 concentration > 30% (73.6% total → 31.5% effective; 3.4% in EOAs, 70.2% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • LP top1 unlocked holder = 98.8% (exit-liquidity risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 99.5% (exit-liquidity 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
Helix Token (HLX)High RiskEuler (EUL)High RiskQuant (QNT)High RiskNeuralAI (NEURAL)High RiskPepeCat (PCAT)High RiskMorphoHigh Risk

Would You Like a More Detailed Audit of Milady Cult Coin?

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

Get Detailed Audit