Quantum Audit Logo

Is Milady Safe?

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

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

Milady LADYS
0x1297…46bf
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 LadysToken contract is an ERC20 token with custom features for blacklisting and holding limits. The audit identified a critical vulnerability related to unchecked arithmetic for token balances and total supply, which could lead to severe financial loss. High-risk issues include centralized control via blacklisting and potentially problematic `minHoldingAmount` logic.

1 Critical2 High1 Medium1 Low2 Informational
Volume 24h
$40.4K
Liquidity
$937.7K
Price
$0.0000000078
Token Age
3y
Top 10 Holders
73.9%

Security Findings

1 Crit2 High1 Med1 Low2 Info
Critical

Unchecked Arithmetic for Total Supply and Balances

C-01The `_mint`, `_burn`, and `_transfer` functions explicitly use `unchecked` blocks for additions to `_totalSupply` and `_balances`. In Solidity 0.8.0+, arithmetic operations default to checked, preventing overflows. By using `unchecked` for additions, if `_totalSupply` or any account's `_balances` were to exceed `type(uint256).max`, the value would wrap around to zero. This could lead to an incorrect total supply, token inflation, or users losing their tokens due to balance manipulation.
IssueThe `_mint`, `_burn`, and `_transfer` functions explicitly use `unchecked` blocks for additions to `_totalSupply` and `_balances`. In Solidity 0.8.0+, arithmetic operations default to checked, preventing overflows. By using `unchecked` for additions, if `_totalSupply` or any account's `_balances` were to exceed `type(uint256).max`, the value would wrap around to zero. This could lead to an incorrect total supply, token inflation, or users losing their tokens due to balance manipulation.
FixRemove the `unchecked` blocks around additions to `_totalSupply` and `_balances` in `_mint`, `_burn`, and `_transfer` functions. Allow Solidity's default checked arithmetic to prevent overflows, which is the safer behavior for token balances.
StatusUnresolved
High

Centralized Control and Blacklisting Risk

H-01The contract utilizes the `Ownable` pattern, granting the deployer (owner) exclusive control over critical functions. Specifically, the `blacklist` function allows the owner to prevent any address from sending or receiving tokens. This introduces a high level of centralization, enabling potential censorship, freezing of user funds, or manipulation of market dynamics by blacklisting liquidity pools or exchanges.
IssueThe contract utilizes the `Ownable` pattern, granting the deployer (owner) exclusive control over critical functions. Specifically, the `blacklist` function allows the owner to prevent any address from sending or receiving tokens. This introduces a high level of centralization, enabling potential censorship, freezing of user funds, or manipulation of market dynamics by blacklisting liquidity pools or exchanges.
FixConsider decentralizing control by implementing a multi-signature wallet or a time-locked contract for ownership. If blacklisting is deemed necessary, define clear, transparent criteria for its use and consider a community-governed mechanism or a timelock for such actions to reduce immediate impact.
StatusUnresolved
High

Ambiguous/Problematic `minHoldingAmount` Logic

H-02The `_beforeTokenTransfer` function includes a `minHoldingAmount` check (`super.balanceOf(to) + amount >= minHoldingAmount`) that applies only to transfers originating `from == uniswapV2Pair`. If `minHoldingAmount` is set to a non-zero value, it could prevent users from acquiring tokens from the LP if their resulting balance would be below this threshold. This could effectively lock out smaller investors or create unexpected barriers to entry for legitimate token acquisition.
IssueThe `_beforeTokenTransfer` function includes a `minHoldingAmount` check (`super.balanceOf(to) + amount >= minHoldingAmount`) that applies only to transfers originating `from == uniswapV2Pair`. If `minHoldingAmount` is set to a non-zero value, it could prevent users from acquiring tokens from the LP if their resulting balance would be below this threshold. This could effectively lock out smaller investors or create unexpected barriers to entry for legitimate token acquisition.
FixClarify the intended purpose of `minHoldingAmount`. If it's meant to ensure a minimum holding, consider if applying it only to transfers from the LP is the desired behavior. If the goal is to prevent users from holding less than a certain amount, the logic might need to be adjusted to cover all transfers or be removed if it creates unintended restrictions.
StatusUnresolved
Medium

Holding Limit Bypass for Direct Transfers

M-01The `limited` holding amount rules (`maxHoldingAmount`, `minHoldingAmount`) are only enforced when tokens are transferred `from == uniswapV2Pair`. This design allows users to bypass these limits by transferring tokens directly between wallets or by transferring tokens *to* the LP pair without restriction. While this might be an intentional design choice, it reduces the overall effectiveness of the holding limits if the goal is to restrict total holdings.
IssueThe `limited` holding amount rules (`maxHoldingAmount`, `minHoldingAmount`) are only enforced when tokens are transferred `from == uniswapV2Pair`. This design allows users to bypass these limits by transferring tokens directly between wallets or by transferring tokens *to* the LP pair without restriction. While this might be an intentional design choice, it reduces the overall effectiveness of the holding limits if the goal is to restrict total holdings.
FixIf the intention is to enforce holding limits universally, modify the `_beforeTokenTransfer` logic to apply `maxHoldingAmount` and `minHoldingAmount` checks to all transfers, regardless of the `from` address. If the current behavior is intentional, document this limitation clearly.
StatusUnresolved
Low

Lack of Event for `setRule` Function

L-01The `setRule` function, which modifies critical parameters such as `limited`, `uniswapV2Pair`, `maxHoldingAmount`, and `minHoldingAmount`, does not emit an event. This makes it difficult for off-chain applications, block explorers, and users to track changes to these important contract configurations, hindering transparency and auditability.
IssueThe `setRule` function, which modifies critical parameters such as `limited`, `uniswapV2Pair`, `maxHoldingAmount`, and `minHoldingAmount`, does not emit an event. This makes it difficult for off-chain applications, block explorers, and users to track changes to these important contract configurations, hindering transparency and auditability.
FixEmit an event (e.g., `RuleSet(bool limited, address uniswapV2Pair, uint256 maxHoldingAmount, uint256 minHoldingAmount)`) whenever the `setRule` function is called. This will provide a clear, auditable history of parameter changes.
StatusUnresolved
Info

Fixed Decimals Value

I-01The `decimals()` function is hardcoded to return `18`. While 18 decimals is a common standard for ERC20 tokens, this value cannot be changed after deployment. This is an observation rather than a vulnerability.
IssueThe `decimals()` function is hardcoded to return `18`. While 18 decimals is a common standard for ERC20 tokens, this value cannot be changed after deployment. This is an observation rather than a vulnerability.
FixNo action required if 18 decimals is the intended and permanent configuration.
StatusUnresolved
Info

Initial Token Distribution to EOAs

I-02The constructor mints a significant portion of the total supply (94% to `_lpWallet`, 1% to `_airdropWallet`, 5% to `_ecoWallet`) to specific addresses. If these addresses are Externally Owned Accounts (EOAs), they represent single points of failure for the initial token distribution and control over a large supply.
IssueThe constructor mints a significant portion of the total supply (94% to `_lpWallet`, 1% to `_airdropWallet`, 5% to `_ecoWallet`) to specific addresses. If these addresses are Externally Owned Accounts (EOAs), they represent single points of failure for the initial token distribution and control over a large supply.
FixConsider using multi-signature wallets or timelock contracts for these critical distribution addresses to enhance security and reduce the risk associated with a single point of control.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract implements a standard ERC20 token with custom transfer hooks for blacklisting and holding limits. It leverages Solidity 0.8.0+ features. A critical vulnerability exists where `unchecked` blocks are used for additions to `_totalSupply` and `_balances`, which could lead to token supply manipulation or loss of funds if an overflow occurs (7.2 Code Security). Additionally, the `minHoldingAmount` logic for transfers from the LP pair is ambiguous and could restrict legitimate user interactions (7.2 Code Security).

GovernanceHigh1/10

The contract uses the Ownable pattern, granting the deployer significant centralized control over key parameters. The owner can blacklist any address, including users or the LP pair, posing a high censorship risk and potential for market manipulation (7.3 Access Control, 7.4 Economic). The `minHoldingAmount` rule, if set inappropriately, could create economic barriers for users acquiring tokens from the LP (7.4 Economic).

UpgradesMedium6/10

The contract is not designed to be upgradeable, which simplifies its architecture by avoiding proxy-related complexities. This eliminates risks associated with upgradeability patterns such as storage collisions or improper initialization. However, any future changes to the contract logic would require a new deployment and migration of assets (7.7 Upgrades).

Security Checklist

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

Holder Composition

73.9% in top 10
60.6% in wallets13.3% in contracts
Effective Concentration65.9%

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

$960.8K across 3 pairs
Uniswap v2WETHanalysed$937.7K97.6%Uniswap v3WETH$23.0K2.4%Uniswap v4USDC$1660.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

LP Burned99.8% · ≈ permanent lock
LP Locked99.8% · Null Address

Key Addresses

9 addresses
Deployer
0xcad5…b70c
Unlocked LP Held By
0x51e6…aca40xf385…5f850x0333…2ddf0x283b…a52d0xb3ac…68a00x826f…1e650x0000…8a900x1f2f…f387

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 NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 50% (73.9% total → 65.9% effective; 60.6% in EOAs, 13.3% in contracts — heavy)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 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
MorphoHigh RiskBeamHigh RiskSuperVerse (SUPER)High Risk00 Token (00)High RiskIxs Token (IXS)High RiskAlberich Token (ALBRH)High Risk

Would You Like a More Detailed Audit of Milady?

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

Get Detailed Audit