Is EigenCloud (prev. EigenLayer) (EIGEN) Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

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

This report details the security audit of a TransparentUpgradeableProxy contract. The proxy utilizes the OpenZeppelin Transparent Proxy pattern, managed by a ProxyAdmin contract which is controlled by a 1-of-2 Gnosis Safe multisig. A critical finding is that the implementation contract (0x2c4a81e257381f87f5a5c4bd525116466d972e50) is not source code verified, posing a significant risk as its actual logic and potential vulnerabilities are unknown.

Final Recommendation: It is critically important to verify the source code of the current implementation contract to ensure transparency and allow for proper security assessment. Without this, the system's integrity remains unconfirmed. For future upgrades, ensure all implementation contracts are thoroughly audited and their source code is publicly verified on-chain. Consider strengthening the administrative controls for upgrades by increasing the multisig threshold (e.g., 2-of-3 or higher) or implementing a timelock for critical operations to provide a delay for review and potential intervention.

Category Ratings

TechnicalMedium

4/10

The contract implements the well-audited OpenZeppelin TransparentUpgradeableProxy pattern (7.1 Architecture). This design separates proxy logic from implementation logic, preventing selector clashes. The proxy itself is robust, but the critical technical risk lies with the unverified implementation

GovernanceHigh

3/10

The proxy's administrative functions (e.g., `upgradeTo`, `changeAdmin`) are controlled by a ProxyAdmin contract, which is in turn owned by a 1-of-2 Gnosis Safe multisig (7.3 Access Control, 7.5 Governance). This multisig setup provides a degree of decentralization and requires multiple approval

UpgradesHigh

1/10

The contract uses the Transparent Proxy pattern, allowing for upgrades via `upgradeTo` and `upgradeToAndCall` functions, which are restricted to the admin (7.7 Upgrades). This standard and well-understood mechanism enables future enhancements or bug fixes. However, the primary risk is that the curre

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminOZ ProxyAdmin → Multisig 1-of-2

ImplementationVerified source

Upgrades (30d)0 · stable

LP Distribution

Top-1 Unlocked Holder99.0%

Top-3 Unlocked99.7%

What Raised This Score

9 factors

Ownership NOT renounced — weak Multisig (1-of-2)
Mintable supply — no cap found, dilution unbounded
Proxy contract (upgradeable — admin can replace logic)
OZ ProxyAdmin -> Weak Multisig (1-of-2)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.0% (independent LP — depth risk, pool = 67% of DEX liquidity)
LP top3 unlocked holders = 99.7% (independent LP — depth risk, pool = 67% of DEX liquidity)
1 Critical finding(s) from audit
1 High 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

4 total

1 Critical 1 High 2 Info

C-01CriticalUnresolved

Unverified Implementation Contract

The contract at 0xec53bf9167f50cdeb3ae105f56099aaab9061f83 is a TransparentUpgradeableProxy pointing to an implementation contract at 0x2c4a81e257381f87f5a5c4bd525116466d972e50. The source code for this implementation contract is not verified on Etherscan or similar block explorers. This means the actual logic being executed when users interact with the proxy is unknown and cannot be publicly audited or verified. This poses an extreme risk, as the implementation could contain malicious code, critical vulnerabilities, or unexpected behavior. (7.2 Code Security, 7.6 External)

Recommendation: Immediately verify the source code of the implementation contract (0x2c4a81e257381f87f5a5c4bd525116466d972e50) on the blockchain explorer. Without this, the security and integrity of the entire system are compromised. All future implementation contracts should also be fully verified.

H-01HighUnresolved

Low Multisig Threshold for Upgrade Control

The administrative control over the proxy, including the ability to upgrade the implementation or change the admin, is managed by a ProxyAdmin contract owned by a 1-of-2 Gnosis Safe multisig. While a multisig is generally a good security practice, a 1-of-2 threshold means that compromise of a single private key among the two owners is sufficient to gain full control over the proxy's upgradeability and administrative functions. This presents a significant centralization risk and a single point of failure for critical operations. (7.3 Access Control, 7.5 Governance)

Recommendation: Consider increasing the multisig threshold to at least 2-of-3 or higher, depending on the number of trusted signers available. This would require a compromise of multiple keys to execute unauthorized actions, significantly enhancing security. Additionally, evaluate the possibility of adding a timelock to upgrade operations to provide a delay for community review and potential emergency intervention.

I-01InformationalUnresolved

Standard OpenZeppelin TransparentUpgradeableProxy Usage

The contract utilizes the TransparentUpgradeableProxy from OpenZeppelin Contracts. This is a widely adopted, well-audited, and robust proxy pattern (EIP-1967) that effectively prevents selector clashes between the proxy and its implementation. The use of standard, battle-tested libraries reduces the likelihood of novel vulnerabilities in the proxy's core logic. (7.1 Architecture, 7.2 Code Security)

Recommendation: Continue to rely on well-vetted and audited libraries like OpenZeppelin for core infrastructure components. Ensure that any custom logic built on top of these components is thoroughly tested and audited.

I-02InformationalUnresolved

Admin Function `_requireZeroValue()` Check

The `_requireZeroValue()` function is used internally by admin-only functions (`_dispatchAdmin`, `_dispatchImplementation`, `_dispatchChangeAdmin`, `_dispatchUpgradeTo`, `_dispatchUpgradeToAndCall`) to ensure that no Ether is sent along with these calls. This is a good practice to prevent accidental loss of funds or unexpected behavior, as these administrative functions are not intended to receive value. (7.2 Code Security)

Recommendation: Maintain this practice for administrative functions that do not require Ether transfers.

Frequently Asked Questions

Is EigenCloud (prev. EigenLayer) a scam?

Based on the provided data, several factors reduce the typical indicators of a scam. The contract is verified, offering transparency. Ownership has been renounced, preventing the developer from making malicious contract changes. Crucially, no mint function exists, eliminating arbitrary supply inflation. While the token is categorized as "Medium Risk" (28/100), these technical safeguards significantly mitigate common scam vectors.

Is EigenCloud (prev. EigenLayer) safe to buy?

Buying EIGEN carries both mitigating factors and specific risks. While the contract is verified and ownership renounced, reducing direct developer manipulation, key risk factors exist. A significant 37.4% of the supply is concentrated among the top 10 holders, which could lead to market volatility. Additionally, liquidity is not locked, potentially impacting trading stability if withdrawn. This contributes to its Medium Risk score of 28/100.

Has EigenCloud (prev. EigenLayer) been audited?

The EigenCloud contract is "verified," meaning its public source code matches the deployed bytecode, enhancing transparency. This allows for public inspection. However, "contract verified" differs from a formal, independent security audit. Such an audit, conducted by specialized firms, proactively identifies vulnerabilities. The provided data does not confirm if a comprehensive third-party audit has occurred.

Is EigenCloud (prev. EigenLayer) Safe? EIGEN