Quantum Audit Logo
Launch App

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

Is Olympus Safe?

OHMEthereum
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 →
Last checked Sep 4, 2026 · 1 audit on record
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.

Read the full analysis
What raised the score
  • 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
99.0%Contracts
99.0%Contracts
ContractsWalletsEveryone elseBubble area = share of supply
99.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking99.0%
  • Walletsanonymous holders, free to sell0.2%
  • Everyone elsethe rest of the supply0.8%
Effective concentrationwhat the score reads39.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$5.42M across 12 pairs
LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$4.93MShare of depth91.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
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.

Security Findings

1 Medium1 Low1 Info
Medium

Centralized 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

Low

Use 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

Info

Powerful 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

Issue

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 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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).

Governance2/10High risk

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).

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

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

1 audit on record
TypeOlympusERC20Token
NetworkEthereum
Token age4y
Contract0x64aa…f1d5
Deployer0x5dfa…4b8f
Badge for your website
Olympus security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202650Medium
  2. 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