Quantum Audit Logo
Launch App

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

Is Pons Safe?

PONSEthereum
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
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades2/10Checks passed4 of 7Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The provided source code for the TeamToken contract is truncated, limiting a full review of its custom logic.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70%
  • Liquidity not locked
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70% (100.2% total → 70.1% effective; 50.0% in EOAs, 50.2% in contracts — extreme)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • LP top1 unlocked holder = 100.0% (exit-liquidity risk)
  • LP top3 unlocked holders = 100.0% (exit-liquidity risk)
  • Token age < 30 days (still settling)
  • 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 44 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
50.2%Contracts50.0%Wallets
50.2%Contracts50.0%Wallets
ContractsWalletsBubble area = share of supply
100.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking50.2%
  • Walletsanonymous holders, free to sell50.0%
Effective concentrationwhat the score reads70.1%
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$26.11M

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$26.11MShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x2f0f…946a

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

Centralized Control of Token Supply (Minting Capability)

The contract likely includes a minting function (indicated by the TeamFinanceTokenMint event) that is controlled by the contract owner. This allows the owner to arbitrarily increase the token supply. While a common design choice for some tokens, it introduces a significant centralization risk (7.3 Access Control, 7.4 Economic, 7.5 Governance) as the owner has unilateral power to devalue existing tokens, impacting the token's economy and trust in the system.H-01

Issue

The contract likely includes a minting function (indicated by the TeamFinanceTokenMint event) that is controlled by the contract owner. This allows the owner to arbitrarily increase the token supply. While a common design choice for some tokens, it introduces a significant centralization risk (7.3 Access Control, 7.4 Economic, 7.5 Governance) as the owner has unilateral power to devalue existing tokens, impacting the token's economy and trust in the system.

Fix

Evaluate whether such centralized control over token supply aligns with the project's long-term vision. If decentralization is a goal, consider implementing mechanisms such as a fixed supply, a capped minting limit, a multi-signature wallet for minting operations, or a time-locked minting schedule. Clearly communicate the minting policy to token holders.

Status

Unresolved

Medium

Redundant Address Validation Check

The checkIsAddressValid modifier includes the check `require(ethAddress == address(ethAddress), '[Validation] invalid address');. This condition is always true for a valid address` type, making the check redundant (7.2 Code Security). It adds unnecessary gas cost to transactions that use this modifier without providing any additional security benefit.M-01

Issue

The checkIsAddressValid modifier includes the check `require(ethAddress == address(ethAddress), '[Validation] invalid address');. This condition is always true for a valid address` type, making the check redundant (7.2 Code Security). It adds unnecessary gas cost to transactions that use this modifier without providing any additional security benefit.

Fix

Remove the redundant `require(ethAddress == address(ethAddress), '[Validation] invalid address'); line from the checkIsAddressValid modifier. The require(ethAddress != address(0), '[Validation] invalid address');` check is sufficient for validating non-zero addresses.

Status

Unresolved

Low

Older Solidity Compiler Version

The contract uses pragma solidity >=0.6.0 <0.8.0; (specifically compiled with 0.6.12). While SafeMath is used to mitigate integer overflow/underflow, using an older compiler version means missing out on security improvements, bug fixes, and gas optimizations introduced in newer Solidity versions (e.g., 0.8.x which includes built-in overflow checks by default) (7.2 Code Security).L-01

Issue

The contract uses pragma solidity >=0.6.0 <0.8.0; (specifically compiled with 0.6.12). While SafeMath is used to mitigate integer overflow/underflow, using an older compiler version means missing out on security improvements, bug fixes, and gas optimizations introduced in newer Solidity versions (e.g., 0.8.x which includes built-in overflow checks by default) (7.2 Code Security).

Fix

Consider upgrading the Solidity compiler version to a more recent stable release (e.g., 0.8.x). This would allow the contract to benefit from the latest security enhancements and optimizations. Ensure thorough testing if upgrading, as syntax changes or new features might require minor code adjustments.

Status

Unresolved

Info

Immutability and Lack of Upgradeability

The contract is not designed with an upgrade mechanism (e.g., proxy pattern), meaning its logic is immutable once deployed (7.7 Upgrades). While this ensures that the contract's behavior cannot be changed post-deployment, it also means that any discovered bugs or desired feature enhancements would necessitate a new deployment and migration of assets, which can be a costly and disruptive operational challenge (7.8 Operations).I-01

Issue

The contract is not designed with an upgrade mechanism (e.g., proxy pattern), meaning its logic is immutable once deployed (7.7 Upgrades). While this ensures that the contract's behavior cannot be changed post-deployment, it also means that any discovered bugs or desired feature enhancements would necessitate a new deployment and migration of assets, which can be a costly and disruptive operational challenge (7.8 Operations).

Fix

Understand the implications of immutability. For simple, well-audited contracts, immutability can be a strength. For complex protocols or those expecting future feature development, consider a well-tested upgradeable proxy pattern in future iterations, understanding the associated risks and operational overhead.

Status

Unresolved

Analysis

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

The provided source code for the TeamToken contract is truncated, limiting a full review of its custom logic. Based on the available code, the contract implements a standard ERC20 token with Ownable access control and SafeMath for arithmetic operations. Key findings include centralized control over token supply via minting, a redundant address validation check, and the use of an older Solidity compiler version. The contract is not upgradeable, ensuring immutability but lacking flexibility for future enhancements or bug fixes.

Technical4/10Medium risk

The contract leverages standard OpenZeppelin patterns for ERC20 and Ownable, enhancing code security (7.2 Code Security). The use of SafeMath effectively mitigates integer overflow/underflow vulnerabilities. However, the checkIsAddressValid modifier contains a redundant check (ethAddress == address(ethAddress)), adding unnecessary gas cost. The contract also uses an older Solidity compiler version (0.6.12), which means it misses out on some security features and optimizations present in newer versions.

Governance1/10High risk

The contract implements a centralized ownership model via the Ownable pattern (7.3 Access Control, 7.5 Governance). A significant economic risk (7.4 Economic) is the centralized control over token supply through the owner's ability to mint new tokens (implied by the TeamFinanceTokenMint event). This allows the owner to arbitrarily increase the token supply, potentially devaluing existing tokens and impacting the token's economy. There are no decentralized governance mechanisms.

Upgrades2/10High risk

The contract is not designed with an upgrade mechanism (7.7 Upgrades), meaning its logic is immutable once deployed. This eliminates upgrade-specific risks such as proxy misconfigurations or logic bugs introduced during upgrades. However, it also means that any discovered vulnerabilities or desired feature enhancements would require a new deployment and migration of assets, which can be a costly and disruptive operational challenge (7.8 Operations).

Final RecommendationWhat to do about this score

It is recommended to carefully consider the implications of centralized token minting and, if possible, implement a more decentralized or time-locked approach to supply management.

Address the identified redundant code to optimize gas usage and consider upgrading to a more recent Solidity compiler version for enhanced security features. For future projects, evaluate the trade-offs between immutability and upgradeability based on the project's long-term vision and risk tolerance.

Contract & Record

1 audit on record
TypeMintBurnTeamToken
NetworkEthereum
Token age18d
Contract0x07f5…2241
Deployer0x2f0f…946a
Badge for your website
Pons 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. Aug 30, 2026100Critical

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

Frequently Asked Questions

What is the PONS contract address?

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

Is Pons a scam?

Quantum Audit's risk score for Pons is 100/100 (Critical risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not 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 PONS liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $26.11M.

Who holds PONS?

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

Related Audits

6 more on the recordAll audits
SpaceX xStockSPCXX · Ethereum100CriticalBananaEthereum100CriticalGoldfishGGBR · Ethereum100CriticalAUSDEthereum100CriticalNVIDIA (Ondo Tokenized)NVDAON · Ethereum100CriticalRollbit CoinRLB · Ethereum100Critical

Would You Like a More Detailed Audit of Pons?

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