Is Tako Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High1 Med1 Low1 Info

Critical

Incomplete Contract Code Provided

C-01The provided Solidity source code is incomplete. Specifically, the `_transfer` function is truncated at `_balances[address(this)]=_bala...`, and the `swapTokensForEth` and `sendETHToFee` functions, which are called within the `_transfer` function's automated swap logic, are entirely missing. This prevents a full and accurate security assessment of the contract's core token transfer, tax distribution, and liquidity management mechanisms.

IssueThe provided Solidity source code is incomplete. Specifically, the `_transfer` function is truncated at `_balances[address(this)]=_bala...`, and the `swapTokensForEth` and `sendETHToFee` functions, which are called within the `_transfer` function's automated swap logic, are entirely missing. This prevents a full and accurate security assessment of the contract's core token transfer, tax distribution, and liquidity management mechanisms.

FixProvide the complete and verified source code for all contract functions, including the full `_transfer` implementation and the definitions of `swapTokensForEth` and `sendETHToFee`. A full audit cannot be completed without this information.

StatusUnresolved

High

High Centralization of Control by Owner

H-01The `Ownable` contract grants the deployer (owner) extensive control over critical contract parameters and functionalities. The owner can modify tax rates (`setInitialBuyTax`, `setFinalBuyTax`, `setTransferTax`), transaction limits (`setMaxTxAmount`, `setMaxWalletSize`), trading status (`openTrading`, `setSwapEnabled`), bot lists (`setBots`, `delBots`), and even the Uniswap router address (`updateUniswapV2Router`). This high degree of centralization creates a single point of failure and a significant trust dependency on the owner, who could maliciously or inadvertently alter the contract's behavior.

IssueThe `Ownable` contract grants the deployer (owner) extensive control over critical contract parameters and functionalities. The owner can modify tax rates (`setInitialBuyTax`, `setFinalBuyTax`, `setTransferTax`), transaction limits (`setMaxTxAmount`, `setMaxWalletSize`), trading status (`openTrading`, `setSwapEnabled`), bot lists (`setBots`, `delBots`), and even the Uniswap router address (`updateUniswapV2Router`). This high degree of centralization creates a single point of failure and a significant trust dependency on the owner, who could maliciously or inadvertently alter the contract's behavior.

FixConsider implementing a multi-signature wallet for critical administrative functions or introducing time-locks for sensitive parameter changes. This would add a layer of security and decentralization, reducing the risk associated with a single point of control. Clearly document the owner's capabilities and the intended use of these powerful functions.

StatusUnresolved

High

Potential for Denial of Service in Sell Limiting Mechanism

H-02The `_transfer` function includes a mechanism (`sellCount` and `lastSellBlock`) that limits the number of sells to 3 per block (`require(sellCount < 3, "Only 3 sells per block!");`). While intended to prevent bot spam or manipulation, this hardcoded limit can lead to legitimate users being unable to sell their tokens if the block's sell quota is reached by other transactions. This effectively creates a temporary denial of service for subsequent sellers within the same block.

IssueThe `_transfer` function includes a mechanism (`sellCount` and `lastSellBlock`) that limits the number of sells to 3 per block (`require(sellCount < 3, "Only 3 sells per block!");`). While intended to prevent bot spam or manipulation, this hardcoded limit can lead to legitimate users being unable to sell their tokens if the block's sell quota is reached by other transactions. This effectively creates a temporary denial of service for subsequent sellers within the same block.

FixRe-evaluate the necessity and implementation of the sell limiting mechanism. If such a limit is critical, consider alternative approaches that are less prone to causing denial of service for legitimate users, such as dynamic limits based on volume or time-based cooldowns per address, rather than per block. If kept, clearly communicate this limitation to users.

StatusUnresolved

Medium

Owner's Ability to Manipulate Dynamic Tax and Swap Thresholds

M-01The contract features dynamic tax rates (`_initialBuyTax`, `_finalBuyTax`, `_reduceBuyTaxAt`, `_initialSellTax`, `_finalSellTax`, `_reduceSellTaxAt`) and a `_preventSwapBefore` threshold, all configurable by the owner. While providing flexibility, the owner's ability to change these parameters at any time without a time-lock or community vote can lead to unpredictable trading conditions, sudden changes in tokenomics, or even manipulation of the automated swap mechanism, potentially impacting user trust and token value.

IssueThe contract features dynamic tax rates (`_initialBuyTax`, `_finalBuyTax`, `_reduceBuyTaxAt`, `_initialSellTax`, `_finalSellTax`, `_reduceSellTaxAt`) and a `_preventSwapBefore` threshold, all configurable by the owner. While providing flexibility, the owner's ability to change these parameters at any time without a time-lock or community vote can lead to unpredictable trading conditions, sudden changes in tokenomics, or even manipulation of the automated swap mechanism, potentially impacting user trust and token value.

FixImplement time-locks for changes to critical economic parameters to provide transparency and allow users to react to upcoming changes. Consider a more decentralized governance model for such sensitive parameters if the project aims for long-term community trust. Clearly document the intended values and adjustment policies for these parameters.

StatusUnresolved

Low

Redundant SafeMath Library Usage

L-01The contract utilizes the `SafeMath` library for arithmetic operations. However, the contract is compiled with Solidity version 0.8.23, which includes native overflow and underflow checks by default. This makes the explicit use of `SafeMath` redundant, as the compiler would already revert on such conditions. While not a vulnerability, it adds unnecessary code and slightly increases gas costs due to extra checks.

IssueThe contract utilizes the `SafeMath` library for arithmetic operations. However, the contract is compiled with Solidity version 0.8.23, which includes native overflow and underflow checks by default. This makes the explicit use of `SafeMath` redundant, as the compiler would already revert on such conditions. While not a vulnerability, it adds unnecessary code and slightly increases gas costs due to extra checks.

FixRemove the `SafeMath` library and its `using SafeMath for uint256;` directive. Rely on Solidity's native overflow/underflow protection for `uint256` operations. This will simplify the code and potentially reduce gas consumption slightly.

StatusUnresolved

Info

Lack of Event Emission for Critical Parameter Changes

I-01Several owner-controlled functions that modify critical contract parameters (e.g., `setTaxWallet`, `setInitialBuyTax`, `setInitialSellTax`, `setMaxTxAmount`, `setMaxWalletSize`, `setTaxSwapThreshold`, `setPreventSwapBefore`, `setBots`, `delBots`, `openTrading`, `setSwapEnabled`, `updateUniswapV2Router`) do not emit corresponding events. Without events, it is difficult for off-chain applications, block explorers, or users to monitor and track changes to the contract's configuration and behavior.

IssueSeveral owner-controlled functions that modify critical contract parameters (e.g., `setTaxWallet`, `setInitialBuyTax`, `setInitialSellTax`, `setMaxTxAmount`, `setMaxWalletSize`, `setTaxSwapThreshold`, `setPreventSwapBefore`, `setBots`, `delBots`, `openTrading`, `setSwapEnabled`, `updateUniswapV2Router`) do not emit corresponding events. Without events, it is difficult for off-chain applications, block explorers, or users to monitor and track changes to the contract's configuration and behavior.

FixEmit specific events whenever a critical contract parameter is changed by the owner. These events should include the old value, the new value, and the address of the caller. This enhances transparency and allows for better off-chain monitoring and auditing of administrative actions.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical architecture (7.1) includes standard ERC-20 functionality with custom tax and anti-bot logic. Code security (7.2) is severely impacted by the incomplete source code, making it impossible to verify the integrity of the `_transfer` function's balance updates and the `swapTokensForEth` and `sendETHToFee` implementations. The use of `SafeMath` is redundant in Solidity 0.8.23 but harmless. The `lockTheSwap` modifier is a good practice to prevent reentrancy during swaps, but its effectiveness cannot be fully assessed without the complete swap functions.

GovernanceMedium6/10

The contract's economic model (7.4) relies heavily on dynamic tax rates and automated liquidity provisions, which are highly configurable by the owner. Governance (7.5) is centralized, with the owner having extensive control over taxes, transaction limits, wallet sizes, bot lists, and trading status. This centralization (H-01) poses a significant trust risk. The `sellCount` and `lastSellBlock` mechanism (H-02) to limit sells per block could lead to denial of service for legitimate users. External interactions (7.6) with Uniswap V2 Router are critical for the token's functionality.

UpgradesLow9/10

The contract is not designed with an upgradeable proxy pattern (7.7), meaning its logic cannot be changed after deployment. This eliminates upgrade-related risks such as proxy misconfigurations or implementation vulnerabilities introduced during upgrades. Any changes to the contract's logic would require a new deployment and migration of assets.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

61.2% in top 10

18.9% in wallets42.3% in contracts

Effective Concentration35.8%

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

$50.2K

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

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

1 addresses

Deployer

0x716b…0a8d

What Raised This Score

5 factors

Top-10 concentration > 30% (61.2% total → 35.8% effective; 18.9% in EOAs, 42.3% in contracts — moderate)
1 Critical finding(s) from audit
2 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

Not Signed In

Is Tako Safe?

Security Findings

Incomplete Contract Code Provided

High Centralization of Control by Owner

Potential for Denial of Service in Sell Limiting Mechanism

Owner's Ability to Manipulate Dynamic Tax and Swap Thresholds

Redundant SafeMath Library Usage

Lack of Event Emission for Critical Parameter Changes

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 Tako?