Quantum Audit Logo

Is Lido DAO Safe?

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

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

Lido DAO LDO
0x5a98…1b32
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High2 Medium1 Low1 Informational
Volume 24h
$1.28M
Liquidity
$686.5K
Price
$0.3908
Token Age
5y
Top 10 Holders
50.6%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control by Controller

H-01The `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.
IssueThe `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.
FixEvaluate 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.
StatusUnresolved
Medium

Old Solidity Compiler Version and Lack of SafeMath

M-01The 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.
IssueThe 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.
FixUpgrade 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.
StatusUnresolved
Medium

ERC20 `approve` Front-Running Vulnerability

M-02The 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.
IssueThe 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.
FixAdvise 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.
StatusUnresolved
Low

Non-Standard `transferFrom` Return Behavior

L-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Info

Lack of Event Emission for Critical Actions

I-01Critical 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.
IssueCritical 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.
FixEmit 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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).

GovernanceHigh1/10

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.

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

50.6% in top 10
16.7% in wallets33.9% in contracts
Effective Concentration30.3%

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

$1.69M across 20 pairs
Uniswap v3WETHanalysed$686.5K40.7%Uniswap v3WETH$517.1K30.7%Uniswap v4CRV$164.1K9.7%Uniswap v4ETH$132.0K7.8%Uniswap v3USDC$61.4K3.6%SushiswapWETH$30.9K1.8%
Show 4 more pairsShow less
CurveWETH$28.9K1.7%Uniswap v2WETH$19.5K1.2%BalancerwstETH$15.6K0.9%Uniswap v3AAVE$15.5K0.9%

The 10 remaining pairs hold $14.3K between them and are not listed.

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 Holder91.2%
Top-3 Unlocked97.5%

Key Addresses

11 addresses
Deployer
0x909d…47ec
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.

What Raised This Score

8 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

Related Audits

6 more on the record
Virtuals Protocol (VIRTUAL)High RiskDerive (DRV)High RiskEthena (ENA)High RiskUniswap (UNI)High RiskEigenCloud (prev. EigenLayer) (EIGEN)High RiskRelicsHigh Risk

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