Quantum Audit Logo

Is EigenCloud (prev. EigenLayer) Safe?

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

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

EigenCloud (prev. EigenLayer) EIGEN
0xec53…1f83
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 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Critical1 High2 Informational
Volume 24h
$3.2K
Liquidity
$1.11M
Price
$0.2032
Token Age
2y
Top 10 Holders
37.3%

Security Findings

1 Crit1 High2 Info
Critical

Unverified Implementation Contract

C-01The contract at 0xec53…1f83 is a TransparentUpgradeableProxy pointing to an implementation contract at 0x2c4a…2e50. 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)
IssueThe contract at is a TransparentUpgradeableProxy pointing to an implementation contract at . 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)
FixImmediately verify the source code of the implementation contract () 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.
StatusUnresolved
High

Low Multisig Threshold for Upgrade Control

H-01The 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)
IssueThe 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)
FixConsider 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.
StatusUnresolved
Info

Standard OpenZeppelin TransparentUpgradeableProxy Usage

I-01The 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)
IssueThe 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)
FixContinue 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.
StatusUnresolved
Info

Admin Function `_requireZeroValue()` Check

I-02The `_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)
IssueThe `_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)
FixMaintain this practice for administrative functions that do not require Ether transfers.
StatusUnresolved

Category Ratings

TechnicalMedium4/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 contract () (7.2 Code Security, 7.6 External). Without verified source, the actual functionality and security posture of the underlying logic cannot be assessed, making it a black box.

GovernanceHigh3/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 approvals for critical operations, mitigating single points of failure. However, a 1-of-2 threshold is relatively low, meaning compromise of a single key could still enable unauthorized upgrades or admin changes (7.4 Economic).

UpgradesHigh1/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 current implementation contract is unverified, meaning any upgrade would be from an unknown state to a potentially unknown new state, making it impossible to verify the safety or intent of upgrades (7.7 Upgrades, 7.8 Operations).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 1-of-2
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

37.3% in top 10
8.7% in wallets28.6% in contracts
Effective Concentration20.2%

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 10 pairs
Uniswap v3USDCanalysed$1.11M65.6%Curve twoWETH$250.7K14.8%Uniswap v3WETH$153.8K9.1%Balancer v3WETH$129.8K7.7%Uniswap v4USDC$33.1K2.0%Uniswap v4ETH$7.0K0.4%
Show 4 more pairsShow less
Uniswap v3WETH$6.6K0.4%Uniswap v4USDC$2.1K0.1%Balancer v3WETH$00.0%Balancer v3WETH$00.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

Top-1 Unlocked Holder99.8%
Top-3 Unlocked99.9%

Key Addresses

7 addresses
Deployer
0x45f9…5b52
Unlocked LP Held By
0x4e48…32d30xbb1b…46ce0xef6a…a7db0x5caa…bb0a0x463a…6b610x67c3…7bad

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

What Raised This Score

10 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)
  • Top-10 concentration > 20% (37.3% total → 20.2% effective; 8.7% in EOAs, 28.6% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.8% (independent LP — depth risk, pool = 66% of DEX liquidity)
  • LP top3 unlocked holders = 99.9% (independent LP — depth risk, pool = 66% 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

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.

Related Audits

6 more on the record
Ethena (ENA)High RiskYield Basis (YB)High RiskOlympus (OHM)High RiskFabric Protocol (ROBO)High RiskUSDeHigh RiskVirtuals Protocol (VIRTUAL)High Risk

Would You Like a More Detailed Audit of EigenCloud (prev. EigenLayer)?

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

Get Detailed Audit