Quantum Audit Logo
Launch App

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

Is AXGT Safe?

Ethereum
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance1/10Upgrades8/10Checks passed6 of 7Findings1 High · 1 Medium · 1 Low · 1 Info4
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.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Top-10 concentration > 30%
  • LP top1 unlocked holder = 88.0%
  • LP top3 unlocked holders = 88.3%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 46 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
73.2%Contracts2.4%24.4%Everyone else
73.2%Contracts24.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
75.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking73.2%
  • Walletsanonymous holders, free to sell2.4%
  • Everyone elsethe rest of the supply24.4%
Effective concentrationwhat the score reads31.7%
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$329.4K across 6 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$326.6KShare of depth99.1%
LP Locked11.7% · UNCX Locker
Top-1 Unlocked Holder88.0%
Top-3 Unlocked88.3%
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.

Security Findings

1 High1 Medium1 Low1 Info
High

Missing Concrete Token Implementation

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

Issue

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

Fix

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

Status

Unresolved

Medium

Centralized Minting Capability (Potential)

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

Issue

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

Fix

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

Status

Unresolved

Low

Multiple Solidity Pragma Directives

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

Issue

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

Fix

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

Status

Unresolved

Info

Standard OpenZeppelin Implementation

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

Issue

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

Fix

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

Status

Resolved

Analysis

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

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.

Technical8/10Low risk

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.

Governance1/10High risk

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.

Upgrades8/10Low risk

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.

Final RecommendationWhat to do about this score

To enhance the security posture, it is crucial to provide the full source code for the concrete AXGT token contract for a comprehensive audit.

This would allow for a thorough review of its constructor, initial supply, any custom logic, and critically, the access control mechanisms around sensitive functions like _mint. If a centralized minting capability is intended, consider implementing a timelock or multi-signature wallet for the owner address to mitigate single points of failure. Additionally, consolidate Solidity pragma directives for improved code clarity and consistency.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age8mo
Contract0x6112…274d
Deployer0xffe5…e588
Badge for your website
AXGT 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. Sep 4, 202664Medium
  2. Sep 4, 202652Medium
  3. Sep 1, 202664Medium

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

Frequently Asked Questions

What is the AXGT contract address?

The AXGT contract on Ethereum is 0x6112c3509a8a787df576028450febb3786a2274d. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is AXGT a scam?

Quantum Audit's risk score for AXGT is 64/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is AXGT liquidity locked?

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

Who holds AXGT?

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

Related Audits

6 more on the recordAll audits
EspressoESP · Ethereum64MediumPRDCTRPRD · Ethereum64MediumNumeraireNMR · Ethereum64MediumVertical AIVERTAI · Ethereum64MediumWrapped REACTREACT · Ethereum64MediumSPACE IDID · Ethereum63Medium

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