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.

On-chain security analysis — is it a scam or legit?
Is Olympus Safe?
Not verified
This 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 →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.
Read the full analysis- Ownership status UNKNOWN
- Mintable supply — no cap found, dilution unbounded
- Top-10 concentration > 30%
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- LP top1 unlocked holder = 100.0%
- LP top3 unlocked holders = 100.0%
- 1 Medium finding(s) from audit
- 1 Low finding(s) from audit
Exact 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking99.0%
- Walletsanonymous holders, free to sell0.2%
- Everyone elsethe rest of the supply0.8%
How holder types affect the score
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.
Holder balances as recorded by the audit of Sep 4, 2026
Liquidity
as of audit · Sep 4- 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 pairs
The 2 remaining pairs hold $435 between them and are not listed. The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x245c…988b0x2515…fbc0No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
MediumCentralized Control via OlympusAuthority
The 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).M-01
Issue
The 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).
Fix
Implement 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.
Status
Unresolved
LowUse of Solidity 0.7.x
The 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).L-01
Issue
The 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).
Fix
Consider 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.
Status
Unresolved
InfoPowerful IOHM Interface Functions
The 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).I-01
IOHM Interface FunctionsIssue
The 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).
Fix
Ensure 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.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The 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).
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).
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.
Prioritize the secure management of all privileged roles defined within the IOlympusAuthority, especially the governor.
Implement multi-signature wallets (e.g., Gnosis Safe) for these addresses and establish clear operational procedures for key management and transaction execution. For critical administrative actions, consider implementing time-locks to provide a window for community review and emergency intervention. Additionally, ensure that the specific roles assigned to powerful functions like mint and burn in the OlympusERC20Token are strictly defined and adhere to the principle of least privilege.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202650Medium
- Aug 11, 202649Medium
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the OHM contract address?
The Olympus (OHM) contract on Ethereum is 0x64aa3364f17a4d01c6f1751fd97c2bd3d7e7f1d5. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is Olympus a scam?
Quantum Audit's risk score for Olympus is 50/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Is OHM liquidity locked?
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $5.42M.
Who holds OHM?
As of Sep 4, 2026, the 10 largest holders own 99.2% of the supply. The Holders section on this page shows who they are by holder type.
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 Is this your token? Publish your own audit on this page