Orex Info
Edenorex Is A Next-Generation RWA-NFT And Utility Token Ecosystem That Bridges Real-World Asset Value Into Blockchain Infrastructure.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The OREX (ORX) contract implements a fixed-supply BEP-20 / ERC-20 token with a controlled DEX launch gate, a public self-burn function, and a minimal administrative surface. The design is intentionally lean: no minting, no fees, no blacklist, no rescue, no proxy. While the overall structure follows common patterns and passes both static analyzers without high or medium findings, a few areas need attention:
- The setDexPair function sets the trading exclusion flag unconditionally, regardless of the status argument, which can permanently whitelist addresses that were meant to be removed and broadens the owner's pre-launch powers beyond the function's stated purpose.
- The burn function sends tokens to the zero address but never decrements totalSupply, since the supply variable is immutable. This breaks the widely used convention that burning reduces the reported supply, and can mislead wallets, explorers and listing pipelines that read totalSupply() directly.
- The freezeTrading function emits an event and flips a flag that no other part of the contract ever reads. Holders and exchanges may reasonably interpret the name and the event as an irrevocable lock of admin or trading powers, but admin functions remain fully callable after it is invoked.
Ownership Privileges
The ownership of the contract has been assigned to the deployer at construction and is held in an externally owned account; it can be transferred at any time to a multisig or to a renouncement address. The initial token holder and the owner are deliberately separate roles. The owner retains full privileges including:
- Enabling trading once, via enableTrading, which is monotonic and cannot be disabled again.
- Registering and deregistering DEX pairs through setDexPair, which also writes the trading exclusion mapping.
- Signalling an irrevocable trading state through freezeTrading, which is advisory only in the current implementation.
- Transferring ownership to another address through a single-step transferOwnership.
- The owner cannot mint new tokens, as the total supply is set once at deployment to an immutable variable.
- The owner cannot blacklist, freeze or confiscate any holder's balance.
- The owner cannot charge fees, taxes or otherwise modify the amounts transferred between users.
- The owner cannot upgrade the contract, rescue tokens held by other users, or change the token metadata, since the contract is a plain non-upgradeable deployment with no delegatecall, no proxy pattern and no admin-controlled metadata setters.
Security Features
The contract implements several positive security features:
- Fixed total supply of 50,000,000 ORX enforced through an immutable variable, removing any hidden inflation path.
- A one-shot, monotonic trading gate (enableTrading) that gives the team a clean launch phase while preventing the gate from being toggled back off.
- A complete event surface covering transfers, approvals, burns, ownership changes, trading activation, trading freeze and DEX pair registration, which makes the contract fully observable to indexers, explorers and monitoring tools.
- A minimal attack surface with no external calls, no assembly, no delegatecall and no selfdestruct, which eliminates reentrancy, proxy upgrade and self-destruct risks entirely, and is reflected in the clean static-analysis results.
Note - This Audit report consists of a security analysis of the OREX (ORX) smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the OREX (ORX) team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
medium Issues | 3 findings
Pending
#1 medium Issue
setDexPair ignores the status flag on the trading allow-list
setDexPair updates isDexPair[pair] with the supplied status, but then unconditionally writes isExcludedFromTrading[pair] = true regardless of whether the caller intended to register (status true) or unregister (status false) the pair. Calling setDexPair(oldPair, false) only clears the pair flag; the old pair address remains trading-whitelisted forever. During the pre-launch phase the owner can also abuse this to whitelist any arbitrary address and bypass the global trading gate, which is broader than the function's stated purpose.
Pending
#2 medium Issue
Burn does not reduce totalSupply and inflates balanceOf(address(0))
The burn function transfers tokens to address(0) but keeps _totalSupply at its initial 50,000,000 ORX value because the variable is declared immutable. The balance of the zero address therefore grows indefinitely while totalSupply() never changes. This breaks the common ERC-20 convention that burning reduces totalSupply and causes wallets, explorers, data aggregators and listing pipelines that read totalSupply() directly to over-report circulating supply. The @notice says burn is permanent while the @dev says totalSupply is unchanged, creating an internal contradiction.
Pending
#3 medium Issue
freezeTrading is a no-op that misleads integrators
The tradingFrozen flag is set to true by freezeTrading and emitted via the TradingFrozen event, but no other part of the contract ever reads tradingFrozen. After freezeTrading is called, setDexPair, transferOwnership and every other owner-only function remain fully callable. A CEX reviewer or token holder inspecting the contract is likely to conclude from the function name, the comment and the event that trading or admin powers are permanently locked, which is not the case. This is a semantic / marketing bug rather than a direct exploit.
low Issues | 5 findings
Pending
#1 low Issue
Single-step ownership transfer can lock admin control
The transferOwnership function overwrites the owner immediately, without any confirmation step from the proposed new owner. A mistyped address, a frontend bug, or an address whose private key is not held by any party permanently removes the ability to call enableTrading, setDexPair, freezeTrading and transferOwnership. Although the zero-address check prevents the most obvious mistake, it does not protect against any other wrong address.
Pending
#2 low Issue
ERC-20 approve race condition
The approve function writes the allowance unconditionally. A spender who sees a pending transaction that changes an existing non-zero allowance to a new non-zero value can front-run it, spend the old allowance first, and then spend the new allowance as well, effectively withdrawing the sum of both. This is a well-known ERC-20 weakness that affects user UX rather than the contract itself.
Pending
#3 low Issue
Contract does not explicitly implement the IERC20 interface
The contract implements the full ERC-20 function set but does not inherit from an IERC20 / IERC20Metadata interface. Wallets, DEXs and CEXs work correctly because the ABI matches, but some integrations, linters and on-chain type checks rely on interface inheritance for discovery. The absence of the inheritance declaration is a minor compatibility issue.
Pending
#4 low Issue
Floating Solidity pragma
The source uses `pragma solidity ^0.8.26;`, which allows compilation with any 0.8.x release greater than or equal to 0.8.26. The currently deployed bytecode was compiled with 0.8.26, but re-deployments on test networks, forks or partner chains could land on a different compiler version with subtle behavioural differences or bug-fix profiles.
Pending
#5 low Issue
setDexPair lacks an idempotency guard
Calling setDexPair with the same (pair, status) combination repeatedly succeeds each time and re-emits DexPairUpdated. Indexers can double count pair registrations or mis-order the lifecycle of a pair. The behaviour interacts with the side-effect issue on the exclusion mapping reported separately.
optimization Issues | 3 findings
Pending
#1 optimization Issue
No infinite-allowance shortcut in transferFrom
The transferFrom implementation decrements the allowance on every call, even when the current allowance is type(uint256).max. Users who grant an effectively unlimited allowance to routers or aggregators still pay for allowance bookkeeping on each transfer. This is a pure gas optimization with no security impact.
Pending
#2 optimization Issue
Large numeric literal can be expressed with scientific notation
The constructor computes the initial supply as `50_000_000 * 10 ** decimals`. While readable, large multiples of ten are conventionally written using scientific notation, which also improves consistency with the rest of the Solidity ecosystem.
Pending
#3 optimization Issue
Compiler optimizer disabled for the deployed contract
The verified source on BscScan shows the compiler optimizer was disabled at deployment time. Enabling the optimizer reduces gas cost for every ERC-20 operation performed by end users and has no effect on the contract's behaviour or security.
informational Issues | 5 findings
Pending
#1 informational Issue
No explicit renounceOwnership path despite the comment
The transferOwnership natspec mentions renouncement ("multisig / renounce later") as a future option, but the require check on the new owner rejects address(0). There is no alternative code path that allows the owner to permanently give up control, so the documentation and the implementation disagree.
Pending
#2 informational Issue
No EIP-2612 permit support
The contract does not implement EIP-2612 permit. Users must perform a separate on-chain approve before every new spender. Many modern DEX aggregators and paymasters expect permit support for optimal UX, so its absence limits integration quality, though it is not a security issue.
Pending
#3 informational Issue
Loss of the initial holder key is unrecoverable
The entire 50,000,000 ORX supply is minted to a single externally owned account at construction. There is intentionally no mint, no rescue and no sweep function, so if the initial holder key is lost or compromised the full supply is either frozen or drained. This is a deliberate design choice but needs to be managed operationally.
Pending
#4 informational Issue
Burn is callable before trading is enabled
A holder can call burn even while tradingEnabled is false, at a time when ordinary transfers are still blocked by the trading gate. Before launch the only holder is the initial holder, so the practical risk is limited, but the asymmetry between burn and transfer is worth documenting or removing so the pre-launch state is fully locked.
Pending
#5 informational Issue
Centralization risk inherent to the admin role
The owner can enable trading, freeze trading, register DEX pairs and transfer ownership. None of these functions can drain user funds, mint new supply or blacklist holders, but they do grant meaningful launch-phase control. This is the standard centralization profile for a controlled-launch ERC-20 and should be mitigated operationally through a multisig and clear communication.