Arxia Info
Every blockchain dies when the internet goes dark. Every chain. Every protocol. Every network. One conflict, one severed cable, one order from above — and 3 trillion dollars in digital assets become unreachable. ARXIA doesn’t die. The first Layer 1 built to operate when infrastructure fails — mesh-networked, radio-propagated, unstoppable.
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 renounced
The contract does not include owner functions that allow post-deployment modifications.
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 Arxia (ARX) contract implements an ERC20 token with burning and EIP-2612 permit support, a fixed supply of 1,000,000,000 tokens minted once at deployment, and a deliberate absence of any administrative controls. While the overall design follows common patterns on Ethereum, a few areas need attention:
- The token uses 6 decimals instead of the usual 18, which keeps it aligned with USDC on Base but can mislead wallets, explorers and integrations that assume 18 decimals.
- Permit signatures use the EIP-712 domain version "1", which is separate from the human-readable VERSION value of "1.0.0"; tooling that signs permits must use the correct value.
Ownership Privileges
The ownership of the contract has been removed entirely by design - there is no owner, no admin role, and no privileged address of any kind. Rather than listing powers the owner holds, the more accurate picture is the set of things no one can do:
- Holders can transfer, approve, and grant allowances through signed permits on their own balances.
- Holders can burn their own tokens, or tokens they have been approved to spend, reducing the total supply.
- No address can mint new tokens after deployment - the supply can only stay the same or decrease.
- No address can pause transfers or trigger an emergency stop.
- No address can blacklist, freeze, or seize tokens from any holder.
- No address can set or change transfer fees - transfers always move the exact amount.
- No address can upgrade or replace the contract code - the bytecode is immutable.
- No address can redirect or recover the initial allocations once they are minted.
Security Features
The contract implements several positive security features:
- A zero administrative surface, which removes the most common source of token risk - a compromised owner or admin key has no powers to abuse because none exist.
- A fixed, hard-capped supply enforced at deployment with a defensive consistency check, and no minting path that could inflate it later.
- Reliance on widely used, externally audited OpenZeppelin v5 building blocks for the ERC20, burn, and permit logic, with no custom accounting that could introduce errors.
- EIP-2612 permit support with chain-bound, single-use signatures that resist cross-chain and post-fork replay, complemented by an extensive test suite, symbolic proofs, and coverage-guided fuzzing that all confirm the core supply and transfer invariants.
Note - This Audit report consists of a security analysis of the Arxia (ARX) smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Arxia (ARX) 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
Findings and Audit result
optimization Issues | 1 findings
Pending
#1 optimization Issue
Defensive constructor invariant adds minor deployment gas
The constructor performs a final consistency check comparing the minted total against the declared maximum supply. The branch is unreachable in the current code because the six allocation constants already sum to the maximum supply, so it adds a small, deployment-only gas cost and shows up as an uncovered branch in coverage tools. Removing it would save a trivial amount of gas but would also remove a useful guard against a future change to one of the constants, so retaining it is the better trade-off.
informational Issues | 6 findings
Pending
#1 informational Issue
Permit front-running griefing and the classic approve race condition
Because the token implements EIP-2612 permit, a signed permit sitting in the mempool can be picked up and submitted by anyone. The allowance ends up set correctly, but the original sender's own permit transaction then reverts because the nonce has already been consumed, which can grief a poorly written integration. Separately, the standard approve function carries the well-known race condition where changing a non-zero allowance can let a spender use both the old and new values if they front-run the change. Neither leads to loss of funds in this token and both are standard behaviour, but integrators should handle them.
Pending
#2 informational Issue
MAX_SUPPLY is the initial supply and only an effective ceiling because no mint exists
The public constant named MAX_SUPPLY equals the exact amount minted at deployment. Because the contract has no post-deployment mint, total supply starts at this value and can only decrease through burning. The name may suggest a ceiling that supply could approach over time, when in fact it is the fixed starting supply. This is purely a naming and clarity observation; the value and behaviour are correct.
Pending
#3 informational Issue
EIP-712 signing version differs from the public VERSION string
The contract exposes a public VERSION constant of "1.0.0" for human reference. The EIP-712 domain separator used by permit, however, uses the version string "1" inherited from the permit framework. These two values serve different purposes and are not interchangeable. A developer who assumes the domain version is "1.0.0" when constructing a permit signature off-chain would produce an invalid signature. There is no security impact, only a potential integration pitfall.
Pending
#4 informational Issue
Initial token distribution is concentrated across six holders
At deployment the entire supply is held by six addresses representing node operators, ecosystem, team vesting, IDO, treasury and seed vesting. The contract grants none of these addresses any special power over other holders; they are ordinary balances. However, the concentration means a small number of parties control most of the circulating supply at launch, which is a market and governance concern that holders should understand. Any lock-up is enforced by external tooling such as vesting streams, not by this contract.
Pending
#5 informational Issue
Permit deadline check relies on block timestamp
The permit function compares the supplied deadline against the current block timestamp to decide whether a signature is still valid. Automated analysis flags any use of the block timestamp in control flow. In this case the dependency is required by the permit standard and the timestamp is only used to enforce an expiry, where the few seconds of leeway a block producer might have is irrelevant. There is no randomness or value decision tied to the timestamp, so the flag is a by-design pattern and not a weakness.
Pending
#6 informational Issue
Non-standard token decimals may cause integration and display issues
The token overrides decimals() to return 6 instead of the de-facto ERC-20 default of 18. This is an intentional choice to align with USDC on Base and is documented, but it is a frequent source of integration mistakes. Wallets, explorers, dashboards, presale tools and DeFi integrations that hard-code 18 decimals will display and compute amounts that are off by a factor of 10^12. The contract itself is correct and conformant, so the risk is entirely on the integration and presentation side, where a wrong assumption can mislead users about how many tokens they are sending or receiving.