Is Lido DAO (LDO) Safe? Smart Contract Security Analysis

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2342

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: 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.

Category Ratings

TechnicalLow

8/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

GovernanceMedium

4/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

UpgradesMedium

6/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&#

LP Distribution

Top-1 Unlocked Holder24.9%

Top-3 Unlocked53.1%

What Raised This Score

6 factors

Ownership NOT renounced (admin/mint authority retained)
Top-10 concentration > 20% (49.5% total → 29.3% effective; 15.9% in EOAs, 33.7% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
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 Findings

5 total

1 High 2 Medium 1 Low 1 Info

H-01HighUnresolved

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.

Recommendation: 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.

M-01MediumUnresolved

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.

Recommendation: 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.

M-02MediumUnresolved

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.

Recommendation: 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.

L-01LowUnresolved

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.

Recommendation: 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.

I-01InformationalUnresolved

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.

Recommendation: 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.

Is Lido DAO Safe? LDO