Quantum Audit Logo

Is Pons Safe?

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

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

Pons PONS
0x07f5…2241
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low1 Informational
Volume 24h
$8.3K
Liquidity
$26.11M
Price
$0.05222
Token Age
18d
Top 10 Holders
100.2%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control of Token Supply (Minting Capability)

H-01The 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.
IssueThe 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.
FixEvaluate 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.
StatusUnresolved
Medium

Redundant Address Validation Check

M-01The `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.
IssueThe `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.
FixRemove 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.
StatusUnresolved
Low

Older Solidity Compiler Version

L-01The 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).
IssueThe 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).
FixConsider 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.
StatusUnresolved
Info

Immutability and Lack of Upgradeability

I-01The 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).
IssueThe 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).
FixUnderstand 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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.

GovernanceHigh1/10

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.

UpgradesHigh2/10

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

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

100.2% in top 10
50.0% in wallets50.2% in contracts
Effective Concentration70.1%

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

$26.11M

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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x2f0f…946a
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.

What Raised This Score

10 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

Related Audits

6 more on the record
SpaceX xStock (SPCXX)Critical RiskBananaCritical RiskGoldfish (GGBR)Critical RiskAUSDCritical RiskHumanity (H)Critical RiskVision (VSN)Critical Risk

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