Quantum Audit Logo

Is OLY Safe?

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

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

OLY OLY
0x5440…61b0
BNB Chain Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The OLY token contract implements a custom ERC20 token with a fee mechanism on trades involving a main liquidity pair. It utilizes OpenZeppelin's AccessControl for role-based permissions. The contract exhibits a high degree of centralization, with critical functions controlled by a single admin role, and introduces a potential Denial of Service vector through an external call to the fee receiver.

2 High3 Medium1 Low
Volume 24h
$534.8K
Liquidity
$7.21M
Price
$1.1700
Token Age
12mo
Top 10 Holders
97.7%

Security Findings

2 High3 Med1 Low
High

Denial of Service via Malicious or Faulty `feeReceiver`

H-01The `_transfer` function makes an external call to `IFeeReceiver(feeReceiver).triggerSwapFeeForLottery()` when tokens are sold to `mainPair` and fees are taken. If the `feeReceiver` contract is malicious and reverts, or if it is a buggy contract that runs out of gas, all such token transfers will fail. This effectively creates a Denial of Service (DoS) vulnerability for a significant portion of token trades, blocking users from selling their tokens.
IssueThe `_transfer` function makes an external call to `IFeeReceiver(feeReceiver).triggerSwapFeeForLottery()` when tokens are sold to `mainPair` and fees are taken. If the `feeReceiver` contract is malicious and reverts, or if it is a buggy contract that runs out of gas, all such token transfers will fail. This effectively creates a Denial of Service (DoS) vulnerability for a significant portion of token trades, blocking users from selling their tokens.
FixImplement a robust error handling mechanism for the external call, such as a `try/catch` block to gracefully handle reverts without blocking transfers. Alternatively, consider a pull-based system where the `feeReceiver` initiates the call, or implement an emergency mechanism to disable the external call or change the `feeReceiver` address if it becomes problematic.
StatusUnresolved
High

Centralized Control and Single Point of Failure

H-02The `DEFAULT_ADMIN_ROLE`, initially assigned to the contract deployer, possesses extensive control over critical contract parameters and roles. This includes the ability to set `mainPair`, adjust `feeRatio` and `buyFeeRatio`, and grant/revoke `MINT` and `INTERN_SYSTEM` roles. A compromise of this single administrative address would allow an attacker to manipulate fees, disable minting/burning controls, or block trades, leading to severe financial and operational risks.
IssueThe `DEFAULT_ADMIN_ROLE`, initially assigned to the contract deployer, possesses extensive control over critical contract parameters and roles. This includes the ability to set `mainPair`, adjust `feeRatio` and `buyFeeRatio`, and grant/revoke `MINT` and `INTERN_SYSTEM` roles. A compromise of this single administrative address would allow an attacker to manipulate fees, disable minting/burning controls, or block trades, leading to severe financial and operational risks.
FixImplement a multi-signature wallet (e.g., Gnosis Safe) or a time-lock contract to manage the `DEFAULT_ADMIN_ROLE`. This adds a layer of security by requiring multiple approvals for critical operations and provides a delay for users to react to proposed changes.
StatusUnresolved
Medium

Custom ERC20 Implementation Risk

M-01The contract utilizes a custom implementation of the ERC20 standard rather than leveraging battle-tested and widely audited libraries like OpenZeppelin's `ERC20`. While `SafeMath` is used, custom implementations are more prone to subtle bugs, edge-case vulnerabilities, or non-compliance issues that might be overlooked during development and testing, potentially leading to unexpected behavior or exploits.
IssueThe contract utilizes a custom implementation of the ERC20 standard rather than leveraging battle-tested and widely audited libraries like OpenZeppelin's `ERC20`. While `SafeMath` is used, custom implementations are more prone to subtle bugs, edge-case vulnerabilities, or non-compliance issues that might be overlooked during development and testing, potentially leading to unexpected behavior or exploits.
FixConsider refactoring the token contract to inherit from OpenZeppelin's `ERC20` contract. If a custom implementation is strictly necessary, ensure comprehensive unit and integration tests are developed and executed to cover all ERC20 functionalities and potential edge cases thoroughly.
StatusUnresolved
Medium

Lack of Emergency Pause Mechanism

M-02The contract lacks a mechanism to pause critical operations (such as transfers or fee collection) in the event of an emergency. In scenarios like a discovered vulnerability, a malicious `feeReceiver`, or a compromised `mainPair`, the absence of a pause function could lead to irreversible losses, continued exploitation, or prolonged protocol disruption.
IssueThe contract lacks a mechanism to pause critical operations (such as transfers or fee collection) in the event of an emergency. In scenarios like a discovered vulnerability, a malicious `feeReceiver`, or a compromised `mainPair`, the absence of a pause function could lead to irreversible losses, continued exploitation, or prolonged protocol disruption.
FixImplement a pause mechanism, for example, by inheriting from OpenZeppelin's `Pausable` contract. This mechanism should be controllable by a trusted entity (e.g., the `DEFAULT_ADMIN_ROLE` or a multi-sig) to temporarily halt operations during emergencies, allowing time for remediation.
StatusUnresolved
Medium

Potential for Fee Manipulation by Admin

M-03The `DEFAULT_ADMIN_ROLE` has the authority to change `feeRatio` and `buyFeeRatio` at any time via the `setRatio` function. While this provides flexibility, it also allows an administrator to arbitrarily increase fees up to `PRECISION` (100%) without prior notice or community consensus. Such sudden changes could negatively impact user trust, token utility, and overall protocol stability.
IssueThe `DEFAULT_ADMIN_ROLE` has the authority to change `feeRatio` and `buyFeeRatio` at any time via the `setRatio` function. While this provides flexibility, it also allows an administrator to arbitrarily increase fees up to `PRECISION` (100%) without prior notice or community consensus. Such sudden changes could negatively impact user trust, token utility, and overall protocol stability.
FixImplement a time-lock for changes to critical parameters like `feeRatio` and `buyFeeRatio`. This would introduce a delay between the proposal and activation of a change, providing transparency and allowing users to react or voice concerns. Alternatively, integrate these parameter changes into a broader governance mechanism.
StatusUnresolved
Low

`INTERN_SYSTEM` Role Misconfiguration Risk

L-01The `INTERN_SYSTEM` role is designed to exempt addresses from trading fees when interacting with the `mainPair`. While the constructor correctly grants this role to the deployer and `_feeReceiver`, accidental granting of this role to the `mainPair` address itself could lead to unintended fee bypasses for all trades involving that pair. Although the current `_isTradeAndNotInSystem` logic appears robust against this specific scenario, careful management of roles is crucial to prevent future misconfigurations.
IssueThe `INTERN_SYSTEM` role is designed to exempt addresses from trading fees when interacting with the `mainPair`. While the constructor correctly grants this role to the deployer and `_feeReceiver`, accidental granting of this role to the `mainPair` address itself could lead to unintended fee bypasses for all trades involving that pair. Although the current `_isTradeAndNotInSystem` logic appears robust against this specific scenario, careful management of roles is crucial to prevent future misconfigurations.
FixClearly document the intended use and implications of the `INTERN_SYSTEM` role. Implement additional checks or safeguards within the `grantRole` function to prevent `mainPair` from being assigned this role if it is not intended to be fee-exempt. Regular audits of role assignments are also recommended.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract implements a custom ERC20 token with `SafeMath` for arithmetic safety. A complex fee mechanism is integrated into the `_transfer` function, applying different ratios for buy and sell operations involving a designated `mainPair`. A significant technical risk is the potential for Denial of Service (DoS) due to an external call to the `feeReceiver` contract, which could revert and block token transfers (7.2 Code Security). Additionally, using a custom ERC20 implementation introduces a higher risk of subtle bugs compared to battle-tested libraries (7.2 Code Security).

GovernanceHigh3/10

The protocol exhibits high centralization, with the `DEFAULT_ADMIN_ROLE` possessing extensive control over critical parameters such as `mainPair`, `feeRatio`, and `buyFeeRatio`, as well as role management (7.3 Access Control, 7.5 Governance). This single point of failure poses a significant risk if the admin key is compromised. The fee mechanism allows the admin to adjust fees up to 100% without a time-lock or governance, potentially impacting token economics and user trust (7.4 Economic).

UpgradesMedium4/10

The contract is not designed with an upgradeability pattern (e.g., proxy). Any future changes to the contract logic would require a complete redeployment and a potentially complex token migration process, which can be costly and introduce significant risks (7.7 Upgrades).

Security Checklist

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

Holder Composition

97.7% in top 10
3.8% in wallets93.9% in contracts
Effective Concentration41.3%

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

$7.21M across 2 pairs
Pancakeswap v2USDTanalysed$7.21M100.0%Pancakeswap v2WBNB$50.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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

6 addresses
Deployer
0x592c…3130
Unlocked LP Held By
0x8c87…5b1f0x0e42…38e20xdcbf…48250x80d8…4ae90x28e2…e9df

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

What Raised This Score

6 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (97.7% total → 41.3% effective; 3.8% in EOAs, 93.9% in contracts — moderate)
  • 2 High finding(s) from audit
  • 3 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

Frequently Asked Questions

Is OLY a scam?

Based on automated analysis, OLY scores 68/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is OLY safe to buy?

Our scanner flagged a risk score of 68/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has OLY been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the record
STABLEHigh RiskUnibase (UB)High RiskCapHigh RiskVELOHigh RiskBicatHigh Riskb-moneyHigh Risk

Would You Like a More Detailed Audit of OLY?

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

Get Detailed Audit