Is Telcoin (TEL) Safe? Smart Contract Security Analysis

Security Findings

1 Med2 Low2 Info

Medium

ERC-20 `approve` Race Condition Vulnerability

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

IssueThe `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.

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

StatusUnresolved

Low

Outdated Solidity Compiler Version

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

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

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

StatusUnresolved

Low

SafeMath `div` Function Lacks Division-by-Zero Check

L-02The `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.

IssueThe `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.

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

StatusUnresolved

Info

Centralized Initial Token Distribution

I-01All `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.

IssueAll `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.

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

StatusUnresolved

Info

Use of `assert` in SafeMath Library

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow10/10

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.

GovernanceHigh3/10

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

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

52.8% in top 10

3.9% in wallets48.9% in contracts

Effective Concentration23.4%

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

$368.6K across 5 pairs

Uniswap v3WETHanalysed$194.7K Uniswap v4ETH$142.1K Uniswap v2WETH$31.4K SushiswapWETH$308 BalancerWETH$199

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 Holder99.9%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0x8cfc…6b65

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.

What Raised This Score

7 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

Is Telcoin Safe?

Security Findings

ERC-20 `approve` Race Condition Vulnerability

Outdated Solidity Compiler Version

SafeMath `div` Function Lacks Division-by-Zero Check

Centralized Initial Token Distribution

Use of `assert` in SafeMath Library

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Telcoin?