Quantum Audit Logo
Launch App

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

Is Telcoin Safe?

TELEthereum
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance3/10Upgrades6/10Checks passed5 of 7Findings1 Medium · 2 Low · 2 Info5
SummaryAI Copilot

The Telcoin contract is an ERC-20 compliant token implemented in Solidity 0.4.18. It utilizes the SafeMath library to prevent integer overflows/underflows.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9%
  • LP top3 unlocked holders = 100.0%
  • 1 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (52.8% total → 23.4% effective; 3.9% in EOAs, 48.9% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 53% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 53% of DEX liquidity)
  • 1 Medium finding(s) from audit
  • 2 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 45 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
48.9%Contracts3.9%47.2%Everyone else
48.9%Contracts3.9%47.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
52.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking48.9%
  • Walletsanonymous holders, free to sell3.9%
  • Everyone elsethe rest of the supply47.2%
Effective concentrationwhat the score reads23.4%
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$368.6K across 5 pairs

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$194.7KShare of depth52.8%
Top-1 Unlocked Holder99.9%
Top-3 Unlocked100.0%
Unlocked LP held by
0xe6a5…e20a0x9e08…d7c8

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

Security Findings

1 Medium2 Low2 Info
Medium

ERC-20 approve Race Condition Vulnerability

The approve function in the ERC-20 standard is susceptible to a race condition. If a user approves an amount for a spender, and then attempts to change that approved amount to a different value, a malicious actor could front-run the second transaction. This could result in the spender being able to spend both the original and the new approved amounts, leading to an unintended transfer of funds. While increaseApproval and decreaseApproval functions are provided to mitigate this, the base approve function remains vulnerable.M-01

Issue

The approve function in the ERC-20 standard is susceptible to a race condition. If a user approves an amount for a spender, and then attempts to change that approved amount to a different value, a malicious actor could front-run the second transaction. This could result in the spender being able to spend both the original and the new approved amounts, leading to an unintended transfer of funds. While increaseApproval and decreaseApproval functions are provided to mitigate this, the base approve function remains vulnerable.

Fix

Educate users to exclusively use increaseApproval and decreaseApproval functions when modifying allowances. If approve must be used, advise users to first set the allowance to zero before setting a new non-zero allowance, though this still involves two transactions and potential race conditions.

Status

Unresolved

Low

Outdated Solidity Compiler Version

The contract is compiled with Solidity version 0.4.18. This version is significantly outdated and lacks numerous security improvements, bug fixes, and gas optimizations introduced in later compiler versions (e.g., 0.5.x, 0.6.x, 0.8.x). While the contract is simple and uses SafeMath, relying on an old compiler can expose the contract to known compiler-level bugs or make it harder to integrate with modern tooling.L-01

Issue

The contract is compiled with Solidity version 0.4.18. This version is significantly outdated and lacks numerous security improvements, bug fixes, and gas optimizations introduced in later compiler versions (e.g., 0.5.x, 0.6.x, 0.8.x). While the contract is simple and uses SafeMath, relying on an old compiler can expose the contract to known compiler-level bugs or make it harder to integrate with modern tooling.

Fix

For any new deployments or significant updates, consider migrating the contract to a more recent and actively supported Solidity compiler version (e.g., 0.8.x) to leverage enhanced security features, better error handling, and gas efficiency.

Status

Unresolved

Low

SafeMath div Function Lacks Division-by-Zero Check

The div function in the SafeMath library, as implemented, does not explicitly check for division by zero. While Solidity's default behavior for division by zero would revert the transaction, an explicit require(b != 0) check would provide clearer error messages and prevent potential unexpected behavior or gas consumption in certain edge cases. In this specific contract, the div function is not used, mitigating its direct impact.L-02

Issue

The div function in the SafeMath library, as implemented, does not explicitly check for division by zero. While Solidity's default behavior for division by zero would revert the transaction, an explicit require(b != 0) check would provide clearer error messages and prevent potential unexpected behavior or gas consumption in certain edge cases. In this specific contract, the div function is not used, mitigating its direct impact.

Fix

If the div function were to be used in the future, consider adding an explicit require(b != 0, "SafeMath: division by zero") check at the beginning of the function for robustness and clarity.

Status

Unresolved

Info

Centralized Initial Token Distribution

All totalSupply tokens are minted and assigned to a single _distributor address during contract deployment. This design choice centralizes the initial distribution of tokens to one entity. While common for initial token launches, it means the entire supply is controlled by a single address at genesis.I-01

Issue

All totalSupply tokens are minted and assigned to a single _distributor address during contract deployment. This design choice centralizes the initial distribution of tokens to one entity. While common for initial token launches, it means the entire supply is controlled by a single address at genesis.

Fix

This is a design decision. Ensure the _distributor address is secured with robust multi-signature or hardware wallet solutions to prevent unauthorized access and control over the initial token supply.

Status

Unresolved

Info

Use of assert in SafeMath Library

The SafeMath library uses assert statements for overflow/underflow checks. In Solidity versions 0.8.0 and later, assert failures consume all remaining gas, which can be costly. While this behavior is standard for Solidity 0.4.18 and assert is typically used for internal invariants, it's a pattern that has evolved towards require for input validation and revert for internal errors in newer Solidity versions.I-02

Issue

The SafeMath library uses assert statements for overflow/underflow checks. In Solidity versions 0.8.0 and later, assert failures consume all remaining gas, which can be costly. While this behavior is standard for Solidity 0.4.18 and assert is typically used for internal invariants, it's a pattern that has evolved towards require for input validation and revert for internal errors in newer Solidity versions.

Fix

For future contracts or if migrating to newer Solidity versions, consider using require statements for all validation checks, including arithmetic safety, as they refund unused gas on failure. For this contract, the current implementation is standard for its Solidity version.

Status

Unresolved

Analysis

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

The Telcoin contract is an ERC-20 compliant token implemented in Solidity 0.4.18. It utilizes the SafeMath library to prevent integer overflows/underflows. The contract includes standard ERC-20 functionalities along with increaseApproval and decreaseApproval to mitigate the common approve race condition. While the core logic is sound, the use of an older Solidity compiler version and the inherent approve race condition in the base ERC-20 standard present some medium and low-level risks.

Technical10/10Low risk

The Telcoin contract demonstrates a solid foundation for an ERC-20 token (7.1 Architecture). It correctly implements standard token functionalities and uses the SafeMath library to prevent common integer overflow/underflow vulnerabilities (7.2 Code Security). The contract includes increaseApproval and decreaseApproval functions, which are good practices to mitigate the ERC-20 approve race condition. However, the base approve function remains susceptible to this issue, and the contract is compiled with an older Solidity version (0.4.18), which lacks modern security features and optimizations.

Governance3/10High risk

The economic model is straightforward: a fixed supply ERC-20 token (7.4 Economic). All tokens are initially minted to a single distributor address, which represents a point of centralization for initial distribution but does not confer ongoing special governance powers (7.5 Governance). There are no complex economic mechanisms or external dependencies that could introduce oracle manipulation or flash loan risks (7.6 External).

Upgrades6/10Medium risk

The Telcoin contract is not designed to be upgradeable (7.7 Upgrades). This simplifies its architecture by removing the complexities and potential risks associated with proxy patterns. Consequently, there are no upgrade-specific vulnerabilities to address, but also no flexibility for future feature enhancements or bug fixes without a redeployment.

Final RecommendationWhat to do about this score

It is recommended to consider deploying new contracts with a more recent and supported Solidity compiler version to benefit from the latest security features and optimizations.

For the existing contract, users should be strongly advised to utilize the increaseApproval and decreaseApproval functions instead of the standard approve function to prevent potential front-running attacks related to allowance changes. Regular security reviews and adherence to best practices for user interaction with ERC-20 tokens are also advised.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age5y
Contract0x467b…790f
Deployer0x8cfc…6b65
Badge for your website
Telcoin 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 1, 202626Low

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

Frequently Asked Questions

What is the TEL contract address?

The Telcoin (TEL) contract on Ethereum is 0x467bccd9d29f223bce8043b84e8c8b282827790f. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Telcoin a scam?

Quantum Audit's risk score for Telcoin is 26/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; 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 TEL liquidity locked?

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

Who holds TEL?

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

Related Audits

6 more on the recordAll audits
Shiba InuSHIB · Ethereum26LowGrand Theft Auto VIGTAVI · Ethereum26LowUnipegUPEG · Ethereum26LowMog CoinMOG · Ethereum26LowWrapped TAOWTAO · Ethereum26LowStockereum.funSTOCKER · Ethereum26Low

Would You Like a More Detailed Audit of Telcoin?

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