On-chain security analysis — is it a scam or legit?
BNB ChainThe OLY token contract implements a custom ERC20 token with a fee mechanism on trades involving a main liquidity pair.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x8c87…5b1f0x0e42…38e20xdcbf…48250x80d8…4ae90x28e2…e9dfNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
feeReceiver_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.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.
Implement 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.
Unresolved
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.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.
Implement 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.
Unresolved
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.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.
Consider 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.
Unresolved
feeReceiver, or a compromised mainPair, the absence of a pause function could lead to irreversible losses, continued exploitation, or prolonged protocol disruption.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.
Implement 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.
Unresolved
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.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.
Implement 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.
Unresolved
INTERN_SYSTEM Role Misconfiguration RiskINTERN_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.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.
Clearly 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.
Unresolved
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.
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).
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).
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).
Implement a multi-signature wallet or time-lock for the DEFAULT_ADMIN_ROLE to manage critical functions and parameters, enhancing security and decentralization.
Introduce a robust error handling mechanism or a pull-based system for external calls to the feeReceiver to mitigate Denial of Service risks. Consider adopting battle-tested OpenZeppelin ERC20 contracts for improved security and maintainability.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Based on automated analysis, OLY scores 68/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.
Our scanner flagged a risk score of 68/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.
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.
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
