Quantum Audit Logo
Launch App

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

Is Orizon Safe?

ORIBNB Chain
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
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance2/10Upgrades4/10Checks passed3 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

This audit covers an abstract ERC20 token implementation, including SafeMath and ERC20Permit functionalities.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 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
Exact 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
96.7%Contracts3.1%
96.7%Contracts
ContractsWalletsEveryone elseBubble area = share of supply
96.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking96.7%
  • Walletsanonymous holders, free to sell0.1%
  • Everyone elsethe rest of the supply3.1%
Effective concentrationwhat the score reads38.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$2.21M

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$2.21MShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x5795…e1dc

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

Security Findings

1 High1 Medium1 Low1 Info
High

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

The _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.H-01

Issue

The _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.

Fix

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

Status

Unresolved

Medium

Custom SafeMath sqrrt Function Complexity and Potential Precision Issues

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Low

Unused OpenZeppelin AccessControl Import

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Use of Older Solidity Version (0.7.5)

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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

Governance2/10High risk

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.

Upgrades4/10Medium risk

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.

Final RecommendationWhat to do about this score

It is crucial for any contract inheriting this abstract ERC20 implementation to implement robust access control mechanisms for functions that call _mint or _burn.

This will prevent unauthorized token supply manipulation. Additionally, thoroughly review and test any custom mathematical functions, such as sqrrt, for precision and edge cases before deployment, or consider using battle-tested libraries for such operations.

Contract & Record

1 audit on record
TypeERC20TokenX
NetworkBNB Chain
Token age1y
Contract0xda03…092e
Deployer0x9c61…4cb3
Badge for your website
Orizon 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. Aug 14, 202666High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the ORI contract address?

The Orizon (ORI) contract on BNB Chain is 0xda033999bb6165e64db01bd9be14b40f5653092e. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Orizon a scam?

Quantum Audit's risk score for Orizon is 66/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is ORI liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $2.21M.

Who holds ORI?

As of Sep 4, 2026, the 10 largest holders own 96.9% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
XPULSBNB Chain66HighHana TokenHANA · BNB Chain66HighUpstartyUPY · BNB Chain66High牛来NIULAI · BNB Chain66HighRandyBNB Chain66HighShopinX TokenSPX · BNB Chain66High

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 Is this your token? Publish your own audit on this page