Quantum Audit Logo

Is Orizon Safe?

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

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

Orizon ORI
0xda03…092e
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This audit covers an abstract ERC20 token implementation, including SafeMath and ERC20Permit functionalities. The core ERC20 logic is generally sound, utilizing SafeMath for arithmetic safety. However, a significant design concern is the lack of explicit access control for internal minting and burning functions, which could lead to critical vulnerabilities if not properly secured by inheriting contracts. Additionally, a custom square root function in SafeMath introduces potential complexity and precision risks.

1 High1 Medium1 Low1 Informational
Volume 24h
$133.6K
Liquidity
$2.21M
Price
$52.5700
Token Age
1y
Top 10 Holders
96.9%

Security Findings

1 High1 Med1 Low1 Info
High

Missing Access Control for Mint/Burn Functions (Design Flaw for Implementers)

H-01The `_mint` and `_burn` functions are declared as `internal virtual` within the abstract ERC20 contract. While internal, any concrete contract inheriting this ERC20 would likely expose these functionalities via public or external functions to manage token supply. The current design does not enforce any access control (e.g., `onlyOwner` or `onlyRole`) on these internal functions, making it a critical design flaw for implementers. If an inheriting contract exposes these functions without proper access control, it could allow any caller to mint or burn tokens, leading to arbitrary supply manipulation and severe economic damage.
IssueThe `_mint` and `_burn` functions are declared as `internal virtual` within the abstract ERC20 contract. While internal, any concrete contract inheriting this ERC20 would likely expose these functionalities via public or external functions to manage token supply. The current design does not enforce any access control (e.g., `onlyOwner` or `onlyRole`) on these internal functions, making it a critical design flaw for implementers. If an inheriting contract exposes these functions without proper access control, it could allow any caller to mint or burn tokens, leading to arbitrary supply manipulation and severe economic damage.
FixImplementers of this abstract ERC20 contract MUST ensure that any public or external functions that call `_mint` or `_burn` are protected by strong access control mechanisms. For example, integrate `AccessControl` (which is imported but unused) or `Ownable` to restrict these operations to authorized roles or addresses.
StatusUnresolved
Medium

Custom SafeMath `sqrrt` Function Complexity and Potential Precision Issues

M-01The `SafeMath` library includes a custom implementation of an integer square root function (`sqrrt`). Custom mathematical functions, especially for complex operations like square root, are prone to subtle bugs, edge case failures, or precision issues when dealing with integer arithmetic. While not directly used in the core ERC20 logic, its presence in a foundational library means it could be utilized by other parts of the system, introducing potential vulnerabilities or unexpected behavior.
IssueThe `SafeMath` library includes a custom implementation of an integer square root function (`sqrrt`). Custom mathematical functions, especially for complex operations like square root, are prone to subtle bugs, edge case failures, or precision issues when dealing with integer arithmetic. While not directly used in the core ERC20 logic, its presence in a foundational library means it could be utilized by other parts of the system, introducing potential vulnerabilities or unexpected behavior.
FixThoroughly test the `sqrrt` function with a comprehensive suite of test cases, including edge cases (0, 1, large numbers, numbers just above/below perfect squares). Consider using a battle-tested library for complex mathematical operations if high precision and robustness are critical, or simplify the logic if possible.
StatusUnresolved
Low

Unused OpenZeppelin `AccessControl` Import

L-01The `AccessControl` contract from OpenZeppelin is imported at the top of `ERC20.sol` but is not utilized within the provided `ERC20` or `ERC20Permit` abstract contracts. This indicates either an incomplete design where access control was planned but not implemented, or an unnecessary import.
IssueThe `AccessControl` contract from OpenZeppelin is imported at the top of `ERC20.sol` but is not utilized within the provided `ERC20` or `ERC20Permit` abstract contracts. This indicates either an incomplete design where access control was planned but not implemented, or an unnecessary import.
FixRemove unused imports to reduce contract bytecode size, improve readability, and avoid potential confusion. If access control is intended for future implementations, ensure it is properly integrated.
StatusUnresolved
Info

Use of Older Solidity Version (0.7.5)

I-01The contract is compiled with Solidity version 0.7.5. While functional, newer Solidity versions (e.g., 0.8.x and above) introduce native overflow/underflow checks for `uint256` arithmetic operations, removing the explicit need for `SafeMath` for basic operations and simplifying code. Newer versions also include various optimizations, bug fixes, and language features.
IssueThe contract is compiled with Solidity version 0.7.5. While functional, newer Solidity versions (e.g., 0.8.x and above) introduce native overflow/underflow checks for `uint256` arithmetic operations, removing the explicit need for `SafeMath` for basic operations and simplifying code. Newer versions also include various optimizations, bug fixes, and language features.
FixConsider upgrading to a more recent Solidity compiler version (e.g., 0.8.x) to benefit from native overflow checks, improved security features, and language enhancements. This would also allow for removal of `SafeMath` for basic arithmetic, making the code cleaner.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical architecture provides a standard ERC20 token implementation, leveraging the SafeMath library for robust arithmetic operations, which is a strong security practice (7.2 Code Security). The ERC20Permit extension is correctly implemented following EIP-2612. However, a critical design flaw exists in the abstract ERC20 contract regarding the `_mint` and `_burn` functions, which lack inherent access control (7.3 Access Control). If exposed by inheriting contracts without proper restrictions, this could allow unauthorized supply manipulation. Furthermore, the custom `sqrrt` function in SafeMath introduces potential precision and complexity risks (7.2 Code Security).

GovernanceHigh2/10

The provided abstract ERC20 contract defines a standard token without specific governance or complex economic mechanisms (7.4 Economic, 7.5 Governance). Its economic behavior is limited to basic transfer, approval, minting, and burning functionalities. There are no inherent economic vulnerabilities in the base contract itself, assuming proper access control is implemented by inheriting contracts for supply-altering functions.

UpgradesMedium4/10

The provided contracts are not designed with upgradeability patterns (e.g., proxy contracts) (7.7 Upgrades). Therefore, there are no upgrade-specific risks associated with this codebase. Any future upgradeability would require a separate proxy implementation and careful consideration of storage layout and initialization.

Security Checklist

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

Holder Composition

96.9% in top 10
0.1% in wallets96.7% in contracts
Effective Concentration38.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

$2.21M

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

2 addresses
Deployer
0x9c61…4cb3
Unlocked LP Held By
0x5795…e1dc

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (96.9% total → 38.8% effective; 0.1% in EOAs, 96.7% in contracts — moderate)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • LP claimed locked but only 0.0% actually locked
  • 1 High finding(s) from audit
  • 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
XPULSHigh RiskHana Token (HANA)High RiskUpstarty (UPY)High Risk牛来 (NIULAI)High RiskRandyHigh RiskShopinX Token (SPX)High Risk

Would You Like a More Detailed Audit of Orizon?

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

Get Detailed Audit