Team and KYC Verification
The team has securely submitted their personal information to SolidProof.io for verification.
In the event of any fraudulent activities, this information will be promptly reported to the relevant authorities to ensure accountability and compliance.
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.
Security Assessments
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 Oraxel (ORAX) contract implements an ERC20 token with a fixed supply of one billion tokens, a public burn function, and an additional bookkeeping layer that records per-account buy and sell volume in daily, weekly and monthly buckets whenever tokens move to or from one of two PancakeSwap liquidity pools that the contract creates for itself at deployment. The token logic itself is a standard, well-established library implementation and was found to behave correctly. The volume bookkeeping is where the substantive findings of this review are concentrated. Because the contract sees only token transfers and never sees a trade, it cannot tell a genuine swap apart from a simple transfer into a pool. As a result the recorded volume figures can be inflated without limit and at no token cost by sending tokens to a pool and immediately retrieving them, and they are also inflated by ordinary liquidity provision and withdrawal, which are recorded as selling and buying respectively. A further defect was confirmed on the deployed contract: the function that produces the daily bucket divides time into fifteen minute windows rather than days, despite being named and documented as a daily figure, which means the daily metric effectively does not exist. None of these issues can move, freeze or take a user's tokens. They matter because the figures are clearly intended to feed something downstream, and in their present form they are not a trustworthy basis for allocating rewards, tiers or eligibility. One further point deserves attention before any mainnet launch: the mainnet USDT address kept in the source comments, ready to be swapped in, is not the USDT contract and has no code on BSC mainnet, and using it would silently create a pool that can never be funded or traded.
Ownership Privileges
The ownership of the contract has been eliminated entirely by design - the contract was deployed with no owner, no administrator and no role system of any kind, and because it is not upgradeable this cannot be changed later. This was confirmed both by reading the code and by calling the deployed contract directly. There is consequently no privileged party who can alter the token's behaviour. The points below therefore describe what the deploying account can do purely as the holder of the tokens and the liquidity, followed by the powers that are absent from the contract:
- The deploying account received one hundred percent of the supply at deployment and still holds just under 99.7 percent of it, giving it the ordinary ability of any large holder to sell into the market.
- The deploying account holds effectively all of the liquidity provider tokens for both pools; none have been burned and none are held in a locker, so the liquidity backing both pools can be withdrawn at will.
- The deploying account is an ordinary single-key wallet rather than a multi-signature wallet, so one compromised key would be sufficient to move both the token position and the liquidity.
- Any holder, including the deployer, may burn their own tokens or tokens they have been granted an allowance over, which permanently reduces the total supply.
- No party can create new tokens - the supply was minted once at deployment and there is no minting function anywhere in the contract.
- No party can pause, freeze, blacklist or otherwise restrict transfers, and no maximum transaction or maximum wallet limit exists on any path.
- No party can introduce a fee, tax or reflection - transfers move the full amount and no fee mechanism exists in the code at all.
- No party can upgrade or replace the contract - it is not a proxy, contains no delegated call, and its behaviour is fixed permanently.
Security Features
The contract implements several positive security features:
- The published source code matches the deployed bytecode exactly, so what is verified on the block explorer is what actually runs on chain.
- The token is built on a current, well-audited and widely used standard library release, with no modifications to the balance, allowance or supply logic, and no known advisory affects the parts of that library in use here.
- The contract makes no external calls at all once deployed, which removes the entire class of reentrancy and callback attacks by construction; the only two external calls happen during deployment and target fixed, well-known addresses.
- Arithmetic is fully checked throughout and the contract contains no unchecked blocks, no loops, no arrays and no assembly, so there is no path to overflow, to running out of gas through iteration, or to low-level memory errors.
- The complete absence of privileged roles means there is no administrator key to compromise and no governance process to capture, which is the strongest single property of this contract and was verified by static review, by symbolic analysis and by extended automated testing.
- Supply integrity was confirmed to hold across more than four hundred thousand randomised operations: the total supply never increased, always equalled the sum of all balances, and only ever decreased by exactly the amount burned.
Note - This Audit report consists of a security analysis of the Oraxel (ORAX) smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Oraxel (ORAX) team. Other contracts associated with the project were not audited by our team. The liquidity pools, the ownership of the liquidity provider tokens and any off-chain system that consumes the volume figures fall outside this scope. We recommend investors do their own research before investing.
Files and details
Findings and Audit result
high Issues | 1 findings
Pending
#1 high Issue
Buy and sell volume can be fabricated at zero token cost
The transfer hook increases a user's buy or sell counter whenever tokens move to or from one of the two liquidity pool addresses, without checking that a trade actually took place. A PancakeSwap pool exposes a skim function that pushes any balance above its recorded reserve to an address of the caller's choosing. Sending tokens to the pool is therefore recorded as a full sell, and calling skim immediately afterwards is recorded as a full buy while returning the very same tokens. The round trip costs nothing but gas and can be repeated without limit. Running twenty-five loops against the live deployment turned a 10,000 token position into 250,000 tokens of recorded buy volume and 250,000 tokens of recorded sell volume, with the balance unchanged at the end. Two independent fuzzers reached the same result in two calls each, driving recorded sell volume above the entire token supply. The practical consequence is that every figure the contract publishes can be set to any value by any holder without trading and without spending tokens, so anything built on top of these numbers can be gamed by someone who never took market risk.
medium Issues | 4 findings
Pending
#1 medium Issue
The daily bucket is fifteen minutes long, not a day
The helper that produces the key for the daily volume mappings divides the block timestamp by fifteen minutes rather than by one day, even though it is named getCurrentDay and its comment describes it as returning the current day. That produces ninety-six separate buckets per calendar day. Reading the deployed contract confirms it: at the time of review it returned 1986859, where a genuine day index would have been 20696. The effect is that the daily metric does not exist. Anyone computing a day index the normal way and reading the daily mapping will always get zero, and anyone calling the helper sees only the trailing fifteen minutes and loses the figure completely every quarter of an hour. There is a cost side too, because the contract writes to a fresh, previously untouched storage slot ninety-six times a day per active account instead of once, which is where most of the extra gas on pool-facing transfers comes from.
Pending
#2 medium Issue
The mainnet USDT address kept in the source comments is not the USDT contract
The router, USDT and wrapped BNB addresses are stored as constants holding testnet values, with the intended mainnet equivalents sitting next to them in comments to be swapped in by hand before a mainnet launch. Two of the three commented values are correct. The USDT one is not - it is a corrupted version of the real address and there is no contract at all at that location on BSC mainnet. Nothing is wrong with the contract as currently deployed, since the value sits in a comment and has no runtime effect. The risk is entirely at launch: creating a pool does not check that either side is a real token, so a mainnet deployment using that address would succeed quietly and produce a pool that can never hold liquidity or be traded. Because the pool addresses are fixed at construction with no setter, that outcome cannot be corrected afterwards.
Pending
#3 medium Issue
Adding and removing liquidity is recorded as selling and buying
Adding liquidity moves tokens from the provider into the pool, which matches the condition the contract uses to recognise a sell. Removing liquidity moves them back out, which matches the condition for a buy. Neither is a trade and neither puts any directional pressure on the price, yet both are recorded at their full amount. Tests against the live pools confirm it: adding 1,000 tokens of liquidity recorded 1,000 tokens of sell volume, and withdrawing the position afterwards recorded roughly the same amount as buy volume. A liquidity provider therefore builds up large phantom buy and sell figures simply by managing a position, and adding and withdrawing repeatedly generates volume for little more than gas. Any ranking or reward derived from these counters ends up favouring liquidity providers over actual traders, which is the opposite of what a buy and sell metric is normally meant to capture.
Pending
#4 medium Issue
Multi-hop trades credit the volume to a pool contract instead of the trader
When a swap is routed through more than one pool, the router settles each leg by sending the output straight to the next pool. If this token sits in the middle of such a route, both the sender and the receiver of its leg are pool contracts. The contract checks the sender first, so the whole amount is credited as a buy to the receiving pool, and the account that actually initiated and paid for the trade is credited with nothing at all. A test against the live pools, swapping tUSDT to ORAX to WBNB, recorded zero buy and zero sell volume for the trader and roughly 433 tokens of buy volume for the WBNB pool contract. Both pools needed for this route already exist, so the path is available today. As well as losing genuine volume, it gives a trader a way to trade without being recorded, and a way to push volume onto an address they do not control.
low Issues | 7 findings
Pending
#1 low Issue
Deployment can be blocked by creating either pool first
Creating a liquidity pool fails when that pool already exists, and the constructor does not handle that case. The address a contract will be deployed to can be worked out from the deployer's address and transaction count, both of which are visible while the transaction is still pending, so an observer can create either of the two pools first and make the whole deployment revert. Nothing is lost when this happens, because the deployment simply fails and can be retried from a different transaction count, which produces a different address. Someone willing to keep paying to create pools could keep doing this, though each attempt has to be front-run individually. The current deployment already succeeded, so this matters for a future deployment rather than for the contract that is live now.
Pending
#2 low Issue
Tracked pool addresses are fixed forever with no way to correct them
The two pool addresses are written once during deployment and there is no function to change them and no administrator who could ever add one. If liquidity later moves to a different venue, whether a newer pool type, a different quote asset or another exchange, the counters quietly stop reflecting what is happening in the market while continuing to return numbers that look perfectly plausible. There is no signal on-chain that the data has become incomplete, which makes this the kind of problem that is noticed long after it starts.
Pending
#3 low Issue
Volume accounting changes state without emitting any event
Six storage mappings are updated on qualifying transfers and none of those updates emits an event. The only log produced is the standard transfer event that every token emits. Indexers and analytics services therefore cannot observe the accounting directly and have to replay transfers and reimplement the classification logic themselves, which means any difference between the rule in the contract and the reimplementation goes unnoticed. It also makes the other problems in this area harder to spot in production monitoring, because there is nothing to alert on.
Pending
#4 low Issue
A movement between two pools is only ever counted as a buy
The two conditions that classify a movement are chained together, so when the sender and the receiver are both pool addresses the first condition matches and the second is never reached. The movement is recorded as a buy for the receiving pool and never as a sell for the sending pool. The result is that buy and sell totals become asymmetric for these movements, and aggregate buy volume can exceed aggregate sell volume even though exactly the same tokens crossed both boundaries. Any calculation of net flow built on the two counters is skewed as a result. This branch ordering is also the mechanism behind the multi-hop misattribution reported separately.
Pending
#5 low Issue
Volume is measured in tokens, so the two pools cannot be compared
Both pools write into the same counters, measured in this token's own units, with no record of which pool produced a given figure and no value attached. The number therefore answers how many tokens crossed a pool boundary, not how much was traded. Prices differ between the two pools and both change over time, so the figure cannot be converted into a value after the fact. The live pools illustrate the point clearly: one holds about 87,637 tokens against 2,011 tUSDT while the other holds 1,000,000 tokens against 0.001 WBNB, which are wildly different implied prices for the same quantity of tokens being added to the same counter.
Pending
#6 low Issue
Reporting period boundaries can be nudged by block producers
All three period keys are derived from the block timestamp, which a block producer can shift slightly within the tolerance the network allows. A transaction close to a boundary can therefore be pushed into the neighbouring period. With daily, weekly and monthly windows this would be negligible. With a fifteen minute window the boundaries occur ninety-six times more often, so the proportion of time that is close to a boundary is correspondingly larger and a well-timed sender or a block producer has more influence over which period a trade lands in. This only becomes material if the periods control a reward, which appears to be the intended use.
Pending
#7 low Issue
Month periods drift against the calendar and weeks start on a Thursday
The monthly period is a fixed thirty days, so twelve periods cover only 360 days and the boundaries drift five days each year, six after a leap year. Within a few years a monthly period bears no relation to any calendar month. The weekly period is seven days counted from the start of Unix time, which fell on a Thursday, so weeks run Thursday to Wednesday in UTC rather than Monday to Sunday. Neither has any security consequence, but reporting periods will not line up with what a user or an accountant expects, and the mismatch grows steadily over time.
optimization Issues | 8 findings
Pending
#1 optimization Issue
The compiler optimizer is switched off
The verified build has the optimizer disabled. Rebuilding with it enabled at two hundred runs reduces the deployed code from 7,104 bytes to 3,597 bytes, a reduction of just under half, and saves roughly 1,400 to 1,950 gas on every transfer. Deployment cost falls substantially as well, from the 5.72 million gas the live deployment consumed. This is the single highest value change available in this category.
Pending
#2 optimization Issue
Pool addresses should be immutable rather than stored in state
Both pool addresses are written once during deployment and then read on every single transfer for the life of the contract. Declaring them immutable turns those two storage reads into values baked directly into the code, saving roughly 4,200 gas on a transfer that touches them for the first time in a block and around 200 thereafter.
Pending
#3 optimization Issue
The timestamp is read three separate times per transfer
The transfer hook calls three separate helpers to obtain the daily, weekly and monthly period keys, and each one independently reads the block timestamp and performs its own division through an internal function call.
Pending
#4 optimization Issue
View functions are public but never called internally
The three volume getters are declared public even though no code inside the contract calls them, which means the compiler generates an unnecessary memory copy of their arguments on every external call.
Pending
#5 optimization Issue
The redundant guard can be removed from the transfer path
The condition guarding the volume accounting reads two storage slots on every transfer and can only ever be false during deployment, so for the entire operational life of the contract it is pure overhead on the hot path.
Pending
#6 optimization Issue
Buy and sell figures could share one storage slot, but not yet
The buy and sell figures for each period are held in separate mappings and therefore in separate storage slots. Packing the pair into a single slot using two smaller numbers would halve the number of previously untouched slots written for any account that both buys and sells within the same period. The saving is real, but it depends entirely on the volume figures first being bounded by actual trading activity.
Pending
#7 optimization Issue
The initial supply is computed at deployment instead of being a constant
The initial supply is expressed as a large literal multiplied by ten raised to the power returned by a virtual function call, all evaluated at deployment time, rather than being written directly as a compile-time constant.
Pending
#8 optimization Issue
The pool creation event carries a variable-length text field
The event announcing pool creation carries a variable-length text label describing which pool it refers to, which has to be encoded at runtime and cannot be filtered on efficiently by indexers.
informational Issues | 11 findings
Pending
#1 informational Issue
Compiler version is not pinned
The pragma accepts any compiler from 0.8.20 upward within the 0.8 series rather than naming a single version. The deployed contract was built with 0.8.20, so this has no effect on what is live today, but a rebuild on a different machine or at a later date can silently produce different bytecode and different behaviour without anything in the source changing.
Pending
#2 informational Issue
Documentation is missing and, where present, incorrect
The only substantive comment on a public function describes the daily helper as returning the current day, which is not what it does. Everything else is undocumented: the three volume getters, the two pool address variables, the six mappings and the event all have no description, and there is no contract level summary explaining the purpose of the tracking. A comment that is actively wrong is more damaging than no comment, because a reader will trust it.
Pending
#3 informational Issue
Explicit getters duplicate the automatically generated ones
The three convenience getters return exactly what the public mappings already expose, only bundled together as a pair of values. They add roughly seven hundred bytes of deployed code, which is a meaningful share of a contract of this size, and they give integrators two different ways to read the same underlying value with no guidance on which is intended.
Pending
#4 informational Issue
Parameter names do not follow the language style guide
Six parameters across the three volume getters are prefixed with an underscore, a convention the language style guide reserves for internal and private members rather than function arguments.
Pending
#5 informational Issue
The whole supply and effectively all liquidity sit with one ordinary account
The constructor creates the entire supply and assigns it to the deploying account in one step, with no vesting, no lock and no distribution logic. On-chain that account still holds just under 99.7 percent of the supply. It also holds effectively all of the liquidity provider tokens for both pools, none of which have been burned or placed in a locker. The deploying account is an ordinary externally owned account rather than a multi-signature wallet, so a single compromised key would be enough to move all of it. For a test deployment this is unremarkable, but it is the dominant economic consideration for anyone holding the token.
Pending
#6 informational Issue
Tokens sent to the contract address cannot be recovered
There is no rescue or sweep function, and no administrator who could ever add one, so any token mistakenly transferred to the contract address is permanently stuck. This applies to the contract's own token and to any other asset.
Pending
#7 informational Issue
Compiled for a newer instruction set than some chains support
The compiler defaults for this version target a newer instruction set, and the deployed code contains just over two hundred uses of an instruction introduced by that upgrade. The chain the contract is deployed on supports it, so there is no problem today, but the same source built with the same defaults would fail to deploy on a chain that has not adopted the upgrade.
Pending
#8 informational Issue
The guard on the volume tracking is dead code after deployment
The check that both pool addresses are set can only ever be false while the constructor is running, because both are assigned there and are never cleared afterwards. For the entire remaining life of the contract it costs two storage reads on every single transfer and always evaluates to true. It also unnecessarily couples the two pools, since if only one had been set the tracking would have been disabled for both.
Pending
#9 informational Issue
Burning tokens held by a pool creates phantom buy volume for the zero address
A burn is processed through the same internal hook as a transfer, with the recipient set to the zero address. Because the classification only looks at whether the sender is one of the two pool addresses, a burn of tokens held by a pool would credit the zero address with buy volume that corresponds to no purchase. On the deployed system this cannot actually happen. Entering that branch requires the pool contract itself to call the burn function, or a third party to hold an allowance granted by the pool, and a standard PancakeSwap V2 pool does neither - its compiled code contains no reference to either burn function, and it never grants an allowance on a paired token. The issue is recorded because the classification logic really does fail to exclude the zero address, and that would become a live problem if the token were ever paired on a non-standard venue.
Pending
#10 informational Issue
The address returned when creating a pool is not checked
The two addresses returned when the pools are created are stored without checking that they are not the zero address. With the fixed, trusted factory the contract actually uses, this cannot occur - the factory either reverts or returns a valid address, and it has no path that returns zero. The observation is therefore about defensive hardening rather than a live defect. It matters only if the factory address is ever turned into a constructor parameter, which is what we recommend elsewhere, because at that point an unexpected factory could leave both pool variables unset and quietly disable the tracking with no visible failure.
Pending
#11 informational Issue
Standard approval race condition
The approval function overwrites the existing allowance rather than adjusting it, so a spender watching pending transactions can spend the old allowance and then the new one. This is the standard behaviour of the ERC20 standard itself and is not specific to this project - the library used here deliberately removed the increase and decrease helpers in its current major version. It is recorded for completeness because a conformance check flags it, not because the contract does anything unusual.