Quantum Audit Logo

Is AXGT Safe?

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

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

AXGT AXGT
0x6112…274d
Ethereum Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This audit covers the provided Solidity source code, which primarily consists of OpenZeppelin's abstract ERC20, ERC20Burnable, and ERC20Permit contracts, along with related interfaces and libraries. A significant limitation of this audit is the absence of the concrete 'AXGT' token contract that would inherit from these abstract components and define its specific logic, initial supply, and access control mechanisms. Therefore, the assessment is based on the provided building blocks and potential implications for a derived token. The underlying OpenZeppelin components are well-audited and robust, but the overall risk is elevated due to the inability to review the final implementation.

1 High1 Medium1 Low1 Informational
Volume 24h
$89.0K
Liquidity
$326.6K
Price
$0.0262
Token Age
8mo
Top 10 Holders
75.6%

Security Findings

1 High1 Med1 Low1 Info
High

Missing Concrete Token Implementation

H-01The provided source code consists primarily of abstract contracts and interfaces (e.g., `ERC20`, `ERC20Burnable`, `ERC20Permit`, `ECDSA`). The actual concrete token contract, which would inherit from these abstract components and define its constructor, initial supply, and any custom logic, is not included. This prevents a complete security assessment of the token's specific behavior, initial state, and critical access control mechanisms.
IssueThe provided source code consists primarily of abstract contracts and interfaces (e.g., `ERC20`, `ERC20Burnable`, `ERC20Permit`, `ECDSA`). The actual concrete token contract, which would inherit from these abstract components and define its constructor, initial supply, and any custom logic, is not included. This prevents a complete security assessment of the token's specific behavior, initial state, and critical access control mechanisms.
FixProvide the full source code for the concrete AXGT token contract. This is essential for a comprehensive audit to evaluate its specific implementation details, initial minting, any additional custom logic, and access control for sensitive functions.
StatusUnresolved
Medium

Centralized Minting Capability (Potential)

M-01The `_mint` function, which increases the total supply, is internal to the `ERC20` contract. If the concrete AXGT token contract exposes a public or external function that calls `_mint` and this function is protected by an `onlyOwner` or similar access control, it introduces a centralized point of control over the token supply. A compromise of the owner's private key could lead to arbitrary token inflation, devaluing existing tokens.
IssueThe `_mint` function, which increases the total supply, is internal to the `ERC20` contract. If the concrete AXGT token contract exposes a public or external function that calls `_mint` and this function is protected by an `onlyOwner` or similar access control, it introduces a centralized point of control over the token supply. A compromise of the owner's private key could lead to arbitrary token inflation, devaluing existing tokens.
FixIf centralized minting is intended, ensure robust access control (e.g., a multi-signature wallet or a timelock) for the owner address. Consider a mechanism to renounce minting capabilities after initial supply distribution if a fixed supply is desired long-term. Clearly document the minting policy and its implications.
StatusUnresolved
Low

Multiple Solidity Pragma Directives

L-01The codebase uses multiple `pragma solidity` directives across different files/sections (e.g., `>=0.4.16`, `>=0.6.2`, `^0.8.20`, `>=0.8.4`). While the compiler typically resolves this by using the highest compatible version, it can lead to confusion and potential inconsistencies in compiler behavior or linting tools.
IssueThe codebase uses multiple `pragma solidity` directives across different files/sections (e.g., `>=0.4.16`, `>=0.6.2`, `^0.8.20`, `>=0.8.4`). While the compiler typically resolves this by using the highest compatible version, it can lead to confusion and potential inconsistencies in compiler behavior or linting tools.
FixIt is best practice to use a single, explicit `pragma solidity` directive (e.g., `pragma solidity 0.8.20;` or `pragma solidity ^0.8.20;`) consistently across all contract files within the project. This improves clarity and ensures consistent compilation behavior.
StatusUnresolved
Info

Standard OpenZeppelin Implementation

I-01The core ERC20, ERC20Burnable, and ERC20Permit functionalities are implemented using well-audited and widely adopted OpenZeppelin contracts. This significantly reduces the likelihood of common vulnerabilities such as reentrancy, integer overflows/underflows (outside of explicitly `unchecked` blocks where safety is guaranteed by preceding logic), and standard ERC20 compliance issues. The `permit` function correctly utilizes `nonces` to prevent replay attacks.
IssueThe core ERC20, ERC20Burnable, and ERC20Permit functionalities are implemented using well-audited and widely adopted OpenZeppelin contracts. This significantly reduces the likelihood of common vulnerabilities such as reentrancy, integer overflows/underflows (outside of explicitly `unchecked` blocks where safety is guaranteed by preceding logic), and standard ERC20 compliance issues. The `permit` function correctly utilizes `nonces` to prevent replay attacks.
FixContinue to leverage battle-tested libraries like OpenZeppelin for core functionalities. Ensure that any custom logic added in the concrete token contract adheres to similar security standards and best practices.
StatusResolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is based on standard, well-vetted OpenZeppelin ERC20 components, which is a significant strength, ensuring robust code security (7.2) against common vulnerabilities like reentrancy and integer issues. The use of `unchecked` blocks is appropriate for Solidity 0.8+ after necessary checks. However, the absence of the concrete token contract (AXGT) prevents a full assessment of its specific implementation details, including how internal functions like `_mint` are exposed and protected, which directly impacts access control (7.3). The reliance on the ECDSA library (7.6) for permit functionality is standard and secure. No complex operational roles (7.8) are defined in the provided abstract contracts.

GovernanceHigh1/10

The economic model (7.4) is that of a standard ERC20 token with burn functionality. The `_mint` function is internal, meaning its exposure in the concrete token contract could introduce centralized control over token supply. If a privileged role can mint new tokens, this presents a potential economic risk of inflation if that role is compromised. No explicit governance mechanisms (7.5) are present in the provided abstract contracts, implying that any governance would be off-chain or implemented in the concrete token contract. The `ERC20Burnable` contract allows public burning of owned tokens or approved tokens, which is standard.

UpgradesLow8/10

Based on the provided information, the contract is not identified as a proxy (`is_proxy: false`) and has no associated implementation contract. Therefore, the contract is not upgradeable (7.7). This eliminates upgrade-related risks such as proxy misconfigurations or logic inconsistencies between proxy and implementation.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

75.6% in top 10
2.4% in wallets73.2% in contracts
Effective Concentration31.7%

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

$329.4K across 6 pairs
Uniswap v3WETHanalysed$326.6K99.1%Uniswap v4USDT$1.5K0.4%Uniswap v4ETH$8600.3%Uniswap v3USDC$3790.1%Uniswap v3USDC$1020.0%Uniswap v4ETH$130.0%

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

LP Locked11.7% · UNCX Locker
Top-1 Unlocked Holder88.0%
Top-3 Unlocked88.3%

Key Addresses

3 addresses
Deployer
0xffe5…e588
Unlocked LP Held By
0x4426…1ca20xa85c…83c3

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

7 factors
  • Ownership NOT renounced — Multisig (2-of-4)
  • Top-10 concentration > 30% (75.6% total → 31.7% effective; 2.4% in EOAs, 73.2% in contracts — moderate)
  • LP top1 unlocked holder = 88.0% (exit-liquidity risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 88.3% (exit-liquidity risk, pool = 99% of DEX liquidity)
  • 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
Espresso (ESP)High RiskPRDCTR (PRD)High RiskSPACE ID (ID)High RiskWrapped Pulse from PulseChain (WPLS)High RiskUSDS Stablecoin (USDS)High RiskMarlin POND (POND)High Risk

Would You Like a More Detailed Audit of AXGT?

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

Get Detailed Audit