Quantum Audit Logo
Launch App

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

Is Lido DAO Safe?

LDOEthereum
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance1/10Upgrades6/10Checks passed3 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The MiniMeToken contract implements an ERC20-like token with a unique cloning mechanism and a controller pattern.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 91.2%
  • LP top3 unlocked holders = 97.5%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Top-10 concentration > 30% (50.6% total → 30.3% effective; 16.7% in EOAs, 33.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 91.2% (independent LP — depth risk, pool = 41% of DEX liquidity)
  • LP top3 unlocked holders = 97.5% (independent LP — depth risk, pool = 41% of DEX liquidity)
  • 1 High finding(s) from audit
  • 2 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
33.9%Contracts16.7%Wallets49.4%Everyone else
33.9%Contracts16.7%Wallets49.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
50.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking33.9%
  • Walletsanonymous holders, free to sell16.7%
  • Everyone elsethe rest of the supply49.4%
Effective concentrationwhat the score reads30.3%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$1.69M across 20 pairs
Show 4 more pairs

The 10 remaining pairs hold $14.3K between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$686.5KShare of depth40.7%
Top-1 Unlocked Holder91.2%
Top-3 Unlocked97.5%
Unlocked LP held by
0xd4f8…489c0xe0f8…803d0x33d2…b0cc0x9d5c…0c280x2db7…8a370xf8d0…dd0c0xe348…dd090xfc4b…e4c10x2afa…53c70x72c3…c102

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

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Control by Controller

The controller address, initially the contract deployer, possesses extensive power over the token contract. This includes the ability to change the controller, enable/disable transfers, and bypass standard transferFrom allowance checks to move tokens arbitrarily. This represents a significant centralization risk and a single point of failure. If the controller's private key is compromised, all token holders could be at risk.H-01

Issue

The controller address, initially the contract deployer, possesses extensive power over the token contract. This includes the ability to change the controller, enable/disable transfers, and bypass standard transferFrom allowance checks to move tokens arbitrarily. This represents a significant centralization risk and a single point of failure. If the controller's private key is compromised, all token holders could be at risk.

Fix

Evaluate if such a high degree of centralization is necessary. If not, consider implementing a multi-signature wallet for the controller address or transitioning control to a decentralized autonomous organization (DAO) for critical functions like changeController and enableTransfers/disableTransfers. Ensure robust security measures are in place for the controller's private key.

Status

Unresolved

Medium

Old Solidity Compiler Version and Lack of SafeMath

The contract uses pragma solidity ^0.4.24, an outdated compiler version. This version lacks built-in overflow/underflow protection (like SafeMath in newer versions) and may contain known compiler bugs. While some checks are present (e.g., previousBalanceFrom >= _amount), other arithmetic operations, especially with uint128 values in Checkpoint structs or in the truncated generateTokens/destroyTokens functions, could be vulnerable if not explicitly guarded. This increases the risk of unexpected behavior or exploits.M-01

Issue

The contract uses pragma solidity ^0.4.24, an outdated compiler version. This version lacks built-in overflow/underflow protection (like SafeMath in newer versions) and may contain known compiler bugs. While some checks are present (e.g., previousBalanceFrom >= _amount), other arithmetic operations, especially with uint128 values in Checkpoint structs or in the truncated generateTokens/destroyTokens functions, could be vulnerable if not explicitly guarded. This increases the risk of unexpected behavior or exploits.

Fix

Upgrade the contract to a modern Solidity compiler version (e.g., 0.8.x) which includes default overflow/underflow checks. If upgrading is not feasible, thoroughly audit all arithmetic operations, especially those involving uint128 and uint256 types, and explicitly implement SafeMath checks for all additions, subtractions, and multiplications to prevent overflows and underflows.

Status

Unresolved

Medium

ERC20 approve Front-Running Vulnerability

The standard ERC20 approve function is susceptible to a known front-running attack. If a user approves an amount, then attempts to approve a different amount, a malicious actor can front-run the second transaction. This allows the malicious actor to spend the original approved amount, and then the new approval is set, potentially leading to a double-spend of the approved amount if the user intended to reduce the allowance.M-02

Issue

The standard ERC20 approve function is susceptible to a known front-running attack. If a user approves an amount, then attempts to approve a different amount, a malicious actor can front-run the second transaction. This allows the malicious actor to spend the original approved amount, and then the new approval is set, potentially leading to a double-spend of the approved amount if the user intended to reduce the allowance.

Fix

Advise users to set the allowance to zero (approve(spender, 0)) before setting a new non-zero allowance. Alternatively, consider implementing an increaseAllowance and decreaseAllowance pattern, as seen in modern ERC20 implementations, which mitigates this specific front-running vector.

Status

Unresolved

Low

Non-Standard transferFrom Return Behavior

The transferFrom function returns false on insufficient allowance rather than reverting. While technically compliant with the original ERC20 specification, modern Solidity best practices and many integrations expect a revert on failure. Returning false can lead to unexpected behavior or silent failures in consuming contracts that do not explicitly check the return value.L-01

Issue

The transferFrom function returns false on insufficient allowance rather than reverting. While technically compliant with the original ERC20 specification, modern Solidity best practices and many integrations expect a revert on failure. Returning false can lead to unexpected behavior or silent failures in consuming contracts that do not explicitly check the return value.

Fix

Consider modifying the transferFrom function to revert (using require() or revert()) instead of returning false when the allowance is insufficient. This aligns with current best practices and improves compatibility with modern DeFi protocols and tools.

Status

Unresolved

Info

Lack of Event Emission for Critical Actions

Critical state-changing actions, such as changeController, enableTransfers, disableTransfers, and potentially token minting/burning (if present in the truncated code), do not emit corresponding events. This hinders off-chain monitoring, transparency, and makes it difficult to track significant administrative changes or token supply adjustments.I-01

Issue

Critical state-changing actions, such as changeController, enableTransfers, disableTransfers, and potentially token minting/burning (if present in the truncated code), do not emit corresponding events. This hinders off-chain monitoring, transparency, and makes it difficult to track significant administrative changes or token supply adjustments.

Fix

Emit events for all critical state-changing functions. For example, `event ControllerChanged(address indexed oldController, address indexed newController); or event TransfersEnabled(bool enabled);`. This enhances transparency and allows for easier integration with off-chain monitoring systems.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The MiniMeToken contract implements an ERC20-like token with a unique cloning mechanism and a controller pattern. The audit identified significant centralization risks due to the extensive powers of the controller address. Additionally, the use of an outdated Solidity compiler version (0.4.24) introduces potential vulnerabilities related to integer arithmetic and known compiler bugs. While the contract provides core token functionality, several aspects deviate from modern security best practices, warranting careful review and potential upgrades.

Technical8/10Low risk

The contract implements a custom ERC20-like token with a historical balance tracking mechanism. Strengths include a clear separation of concerns with the Controlled base contract and an ITokenController interface for external control. However, the use of Solidity 0.4.24 is a major technical risk, as it lacks modern security features like built-in overflow/underflow checks (e.g., SafeMath) and may contain known compiler bugs (7.2 Code Security). The transferFrom function's non-standard return behavior (returning false instead of reverting) can lead to integration issues (7.2 Code Security). The approve function is also susceptible to front-running attacks (7.2 Code Security).

Governance1/10High risk

The economic and governance model is highly centralized around the controller address. This address, initially the contract deployer, has extensive power, including the ability to change the controller, enable/disable all token transfers, and bypass standard transferFrom allowance checks to move tokens arbitrarily (7.3 Access Control). This level of control presents a significant single point of failure and a high governance risk (7.5 Governance). While this design might be intentional for specific use cases (e.g., a DAO's initial token), it requires absolute trust in the controller.

Upgrades6/10Medium risk

The MiniMeToken contract is not designed as an upgradeable proxy contract. It is a standard, immutable contract deployed directly to the blockchain. Therefore, there are no upgrade-specific risks such as proxy implementation mismatches or storage collisions (7.7 Upgrades). Any changes to the token's logic would require deploying a new contract and migrating users, which is a known characteristic of this design.

Final RecommendationWhat to do about this score

It is strongly recommended to migrate to a more modern Solidity compiler version (e.g., 0.8.x) and incorporate robust security libraries like OpenZeppelin Contracts, especially for arithmetic operations (SafeMath).

The extensive centralized control by the controller should be carefully evaluated; if decentralization is a goal, consider implementing a multi-signature wallet or a robust governance mechanism for critical functions. Additionally, ensure all critical state-changing actions emit events for transparency and off-chain monitoring.

Contract & Record

1 audit on record
TypeMiniMeToken
NetworkEthereum
Token age5y
Contract0x5a98…1b32
Deployer0x909d…47ec
Badge for your website
Lido DAO security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202651Medium
  2. Jul 23, 202642Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the LDO contract address?

The Lido DAO (LDO) contract on Ethereum is 0x5a98fcbea516cf06857215779fd812ca3bef1b32. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Lido DAO a scam?

Quantum Audit's risk score for Lido DAO is 51/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is LDO liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.69M.

Who holds LDO?

As of Sep 4, 2026, the 10 largest holders own 50.6% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Virtuals ProtocolVIRTUAL · Ethereum51MediumDeriveDRV · Ethereum51MediumFXN TokenFXN · Ethereum51MediumFuse CatFUSECAT · Ethereum51MediumCreditStrategyCREDITSTR · Ethereum51MediumEthenaENA · Ethereum50Medium

Would You Like a More Detailed Audit of Lido DAO?

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

Get Detailed Audit Is this your token? Publish your own audit on this page