Quantum Audit Logo

Is Olympus Safe?

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

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

Olympus OHM
0x64aa…f1d5
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This audit covers foundational components of the Olympus protocol, including an access control mechanism, ECDSA signature recovery, EIP-712 typed data hashing, and ERC-20 interfaces with mint/burn capabilities. The provided code snippets demonstrate robust security patterns and adherence to best practices for libraries and access control. However, the centralized nature of the `IOlympusAuthority` introduces significant governance and operational risks, which are further amplified by the powerful functions implied by the `IOHM` interface. A comprehensive security posture depends heavily on the full implementation of the `OlympusERC20Token` and the secure management of privileged roles.

1 Medium1 Low1 Informational
Volume 24h
$83.7K
Liquidity
$4.93M
Price
$20.1900
Token Age
4y
Top 10 Holders
99.2%

Security Findings

1 Med1 Low1 Info
Medium

Centralized Control via OlympusAuthority

M-01The `OlympusAccessControlled` pattern relies on a single `IOlympusAuthority` contract to manage all critical roles (governor, guardian, policy, vault). The `governor` role has the power to change the `authority` contract itself via `setAuthority`. If the `governor` address is compromised, it could lead to a complete takeover of the protocol's access control, potentially enabling unauthorized minting, burning, or other critical operations if the `OlympusERC20Token` implements `IOHM` and uses these roles. This introduces significant governance and operational risk (7.3 Access Control, 7.5 Governance, 7.8 Operations).
IssueThe `OlympusAccessControlled` pattern relies on a single `IOlympusAuthority` contract to manage all critical roles (governor, guardian, policy, vault). The `governor` role has the power to change the `authority` contract itself via `setAuthority`. If the `governor` address is compromised, it could lead to a complete takeover of the protocol's access control, potentially enabling unauthorized minting, burning, or other critical operations if the `OlympusERC20Token` implements `IOHM` and uses these roles. This introduces significant governance and operational risk (7.3 Access Control, 7.5 Governance, 7.8 Operations).
FixImplement robust multi-signature (e.g., Gnosis Safe) for the `governor` address and other critical roles. Ensure clear operational procedures and key management for these privileged accounts. Consider time-locks for critical administrative actions like `setAuthority` to allow for community review and emergency response.
StatusUnresolved
Low

Use of Solidity 0.7.x

L-01The contracts are compiled with Solidity `0.7.5` and `^0.7.5`. While `SafeMath` is used to prevent integer overflows/underflows, newer Solidity versions (e.g., `0.8.x`) include default checked arithmetic, which provides an additional layer of safety and reduces the reliance on external libraries for basic arithmetic. Migrating to a newer compiler version could simplify the code and leverage these built-in safety features (7.2 Code Security).
IssueThe contracts are compiled with Solidity `0.7.5` and `^0.7.5`. While `SafeMath` is used to prevent integer overflows/underflows, newer Solidity versions (e.g., `0.8.x`) include default checked arithmetic, which provides an additional layer of safety and reduces the reliance on external libraries for basic arithmetic. Migrating to a newer compiler version could simplify the code and leverage these built-in safety features (7.2 Code Security).
FixConsider upgrading to Solidity `0.8.x` to benefit from default checked arithmetic and other compiler improvements. Thoroughly test all contracts after any compiler upgrade to ensure compatibility and prevent unexpected behavior.
StatusUnresolved
Info

Powerful `IOHM` Interface Functions

I-01The `IOHM` interface defines `mint`, `burn`, and `burnFrom` functions, which are highly privileged operations for an ERC-20 token. While the `OlympusAccessControlled` abstract contract provides modifiers (`onlyPolicy`, `onlyVault`, etc.) to restrict access, the specific roles assigned to these functions in the actual `OlympusERC20Token` implementation are not visible in the provided snippets. Misconfiguration or overly broad permissions for these functions could lead to uncontrolled supply manipulation, impacting the token's economic stability (7.1 Architecture, 7.3 Access Control, 7.4 Economic).
IssueThe `IOHM` interface defines `mint`, `burn`, and `burnFrom` functions, which are highly privileged operations for an ERC-20 token. While the `OlympusAccessControlled` abstract contract provides modifiers (`onlyPolicy`, `onlyVault`, etc.) to restrict access, the specific roles assigned to these functions in the actual `OlympusERC20Token` implementation are not visible in the provided snippets. Misconfiguration or overly broad permissions for these functions could lead to uncontrolled supply manipulation, impacting the token's economic stability (7.1 Architecture, 7.3 Access Control, 7.4 Economic).
FixEnsure that `mint`, `burn`, and `burnFrom` functions in the `OlympusERC20Token` are strictly controlled by appropriate, multi-sig-protected roles (e.g., `onlyPolicy` or `onlyVault` with strong governance). Document the exact permissions and their implications clearly to maintain transparency and accountability.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical implementation demonstrates strong security practices. The `OlympusAccessControlled` contract provides a clear role-based access control system (7.3 Access Control). Libraries like `ECDSA` and `EIP712` are well-implemented, handling signature recovery and typed data hashing robustly, including checks for signature validity and chain ID changes (7.2 Code Security). The use of `SafeMath` mitigates integer overflow/underflow risks. A minor point is the use of Solidity 0.7.x, which lacks default checked arithmetic (7.2 Code Security).

GovernanceHigh2/10

The protocol's governance and economic model, as implied by the `IOlympusAuthority` pattern, presents a high risk due to its centralized control (7.5 Governance). The `governor` role holds significant power, including the ability to change the `authority` contract itself via `setAuthority` (7.3 Access Control). The `IOHM` interface suggests powerful `mint` and `burn` functions, which, if controlled by these centralized roles, introduce substantial economic risk if compromised or misused (7.4 Economic). Secure management of these privileged addresses is paramount (7.8 Operations).

UpgradesHigh3/10

Based on the provided code snippets and prefilled information, the contracts are not designed as upgradeable proxies (`is_proxy: false`). Therefore, direct upgradeability is not a concern, and no specific upgrade safety issues were identified (7.7 Upgrades). Any future changes would require redeployment and migration of state, or the introduction of a new upgrade mechanism.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

99.2% in top 10
0.2% in wallets99.0% in contracts
Effective Concentration39.8%

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

$5.42M across 12 pairs
Uniswap v3WETHanalysed$4.93M91.0%Uniswap v3USDC$321.2K5.9%Uniswap v3WETH$93.2K1.7%CurveWETH$34.9K0.6%BalancerwstETH$17.0K0.3%BalancerWETH$6.8K0.1%
Show 4 more pairsShow less
BalancerDAI$6.7K0.1%SushiswapDAI$4.0K0.1%SushiswapWETH$2.2K0.0%BalancerWETH$4390.0%

The 2 remaining pairs hold $435 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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0x5dfa…4b8f
Unlocked LP Held By
0x245c…988b0x2515…fbc0

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 status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (99.2% total → 39.8% effective; 0.2% in EOAs, 99.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 91% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 91% of DEX liquidity)
  • 1 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
Ethena (ENA)High RiskEigenCloud (prev. EigenLayer) (EIGEN)High RiskYield Basis (YB)High RiskFabric Protocol (ROBO)High RiskUSDeHigh RiskVirtuals Protocol (VIRTUAL)High Risk

Would You Like a More Detailed Audit of Olympus?

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

Get Detailed Audit