Is TERAFAB Safe? Smart Contract Security Analysis

Security Findings

2 Crit2 High3 Med1 Low

Critical

Missing `min` Function Definition

C-01The `_transfer` function attempts to call a `min` function within `swapTokensForEth(min(amount, min(contractTokenBalance, _maxTaxSwap)))`. However, the `min` function is not defined within the contract, inherited, or imported. This will cause a compilation error or a runtime error if the contract was deployed with a placeholder, preventing the core token swap mechanism from functioning.

IssueThe `_transfer` function attempts to call a `min` function within `swapTokensForEth(min(amount, min(contractTokenBalance, _maxTaxSwap)))`. However, the `min` function is not defined within the contract, inherited, or imported. This will cause a compilation error or a runtime error if the contract was deployed with a placeholder, preventing the core token swap mechanism from functioning.

FixDefine a `min` utility function within the contract or import a library that provides it. For example: ```solidity function min(uint256 a, uint256 b) internal pure returns (uint256) { return a < b ? a : b; } ```

StatusUnresolved

Critical

Missing `sendETHToFee` Function Definition

C-02The `_transfer` function attempts to call `sendETHToFee(address(this).balance)` after a swap. However, the `sendETHToFee` function is not defined within the contract, inherited, or imported. This will cause a compilation error or a runtime error, preventing the collected ETH from being sent to the `_taxWallet` and potentially locking ETH in the contract.

IssueThe `_transfer` function attempts to call `sendETHToFee(address(this).balance)` after a swap. However, the `sendETHToFee` function is not defined within the contract, inherited, or imported. This will cause a compilation error or a runtime error, preventing the collected ETH from being sent to the `_taxWallet` and potentially locking ETH in the contract.

FixDefine the `sendETHToFee` function. It should typically send the specified ETH amount to the `_taxWallet`. For example: ```solidity function sendETHToFee(uint256 amount) private { _taxWallet.transfer(amount); } ```

StatusUnresolved

High

High Centralization Risk / Extensive Owner Privileges

H-01The `owner` address has extensive control over critical contract parameters, including tax rates (`setInitialBuyTax`, `setFinalSellTax`), transaction limits (`setMaxTxAmount`, `setMaxWalletSize`), swap enablement (`setSwapEnabled`), and the ability to add/remove bot addresses (`addBot`, `removeBot`). This high degree of centralization means a compromised owner key or a malicious owner could significantly alter the token's behavior, potentially leading to rug pulls or unfair market conditions (7.3 Access Control, 7.8 Operations).

IssueThe `owner` address has extensive control over critical contract parameters, including tax rates (`setInitialBuyTax`, `setFinalSellTax`), transaction limits (`setMaxTxAmount`, `setMaxWalletSize`), swap enablement (`setSwapEnabled`), and the ability to add/remove bot addresses (`addBot`, `removeBot`). This high degree of centralization means a compromised owner key or a malicious owner could significantly alter the token's behavior, potentially leading to rug pulls or unfair market conditions (7.3 Access Control, 7.8 Operations).

FixConsider implementing a multi-signature wallet for the owner address or for critical functions. For highly sensitive parameters, implement time-locks or a governance mechanism to allow community review before changes take effect. Clearly document the owner's capabilities and their impact on the token's economy.

StatusUnresolved

High

Arbitrary `_taxWallet` Address Change

H-02The `setTaxWallet` function allows the owner to change the `_taxWallet` to any arbitrary address. This means that if the owner's private key is compromised, or if the owner acts maliciously, they could redirect all collected taxes to an address they control, effectively draining the fee revenue (7.3 Access Control, 7.4 Economic).

IssueThe `setTaxWallet` function allows the owner to change the `_taxWallet` to any arbitrary address. This means that if the owner's private key is compromised, or if the owner acts maliciously, they could redirect all collected taxes to an address they control, effectively draining the fee revenue (7.3 Access Control, 7.4 Economic).

FixImplement a timelock for changing the `_taxWallet` address, allowing a grace period for users to react. Alternatively, consider a multi-signature wallet for the `_taxWallet` itself or for the function that changes it. Ensure the `_taxWallet` is a secure, controlled address.

StatusUnresolved

Medium

`renounceOwnership` Transfers Contract ETH Balance

M-01The `renounceOwnership` function, before setting the owner to `address(0)`, transfers the entire ETH balance of the contract to the current owner (`payable(owner()).transfer(address(this).balance)`). This is an unusual behavior for renouncing ownership and could lead to unexpected ETH transfers if the contract accumulates ETH for reasons other than intended fee collection (e.g., accidental sends, failed transactions) (7.5 Governance).

IssueThe `renounceOwnership` function, before setting the owner to `address(0)`, transfers the entire ETH balance of the contract to the current owner (`payable(owner()).transfer(address(this).balance)`). This is an unusual behavior for renouncing ownership and could lead to unexpected ETH transfers if the contract accumulates ETH for reasons other than intended fee collection (e.g., accidental sends, failed transactions) (7.5 Governance).

FixReview the necessity of transferring the entire contract ETH balance upon renunciation. If the intent is only to transfer collected fees, ensure that only those specific funds are transferred. Otherwise, remove this line to prevent unintended ETH transfers when ownership is renounced.

StatusUnresolved

Medium

Potential for Front-running/Sandwich Attacks on `openTrading`

M-02The `openTrading` function, which enables token trading, is called by the owner. This creates a window of opportunity for sophisticated attackers to front-run the transaction. Attackers can monitor the mempool for the `openTrading` transaction, then place buy orders immediately before it and sell orders immediately after, profiting from the initial price surge caused by legitimate buyers (7.4 Economic).

IssueThe `openTrading` function, which enables token trading, is called by the owner. This creates a window of opportunity for sophisticated attackers to front-run the transaction. Attackers can monitor the mempool for the `openTrading` transaction, then place buy orders immediately before it and sell orders immediately after, profiting from the initial price surge caused by legitimate buyers (7.4 Economic).

FixWhile common in meme tokens, this risk can be mitigated by using a commit-reveal scheme or by adding a small, random delay to the `openTrading` function, though this adds complexity. Alternatively, accept this as an inherent risk of the token launch model and ensure users are aware.

StatusUnresolved

Medium

Restrictive `_maxWalletSize` Logic

M-03The `_maxWalletSize` check `require(balanceOf(to) + amount <= _maxWalletSize, "Exceeds the maxWalletSize.")` prevents a recipient from holding more than `_maxWalletSize` tokens *after* a buy from the Uniswap pair. However, if a user already holds `_maxWalletSize` tokens, any subsequent buy, even for a small amount, will fail. This can lead to a denial of service for legitimate users trying to acquire more tokens, even if they are below the `_maxTxAmount` (7.4 Economic).

IssueThe `_maxWalletSize` check `require(balanceOf(to) + amount <= _maxWalletSize, "Exceeds the maxWalletSize.")` prevents a recipient from holding more than `_maxWalletSize` tokens *after* a buy from the Uniswap pair. However, if a user already holds `_maxWalletSize` tokens, any subsequent buy, even for a small amount, will fail. This can lead to a denial of service for legitimate users trying to acquire more tokens, even if they are below the `_maxTxAmount` (7.4 Economic).

FixRe-evaluate the `_maxWalletSize` logic. Consider if it should apply only to initial buys or if there should be a mechanism for users to consolidate tokens without being blocked by this limit. Ensure the intent of the anti-whale mechanism is clearly defined and implemented without unintended side effects.

StatusUnresolved

Low

Redundant SafeMath Library Usage

L-01The contract uses the `SafeMath` library for arithmetic operations. However, the contract is compiled with Solidity version 0.8.24, which includes native overflow and underflow checks by default. The explicit use of `SafeMath` is therefore redundant and adds unnecessary gas overhead to transactions (7.2 Code Security).

IssueThe contract uses the `SafeMath` library for arithmetic operations. However, the contract is compiled with Solidity version 0.8.24, which includes native overflow and underflow checks by default. The explicit use of `SafeMath` is therefore redundant and adds unnecessary gas overhead to transactions (7.2 Code Security).

FixRemove the `SafeMath` library and directly use standard arithmetic operators (`+`, `-`, `*`, `/`). This will reduce gas costs without compromising security against integer overflows/underflows in Solidity 0.8.0+.

StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract's technical architecture is based on a standard ERC-20 implementation with added tax and anti-bot mechanisms (7.1 Architecture). However, critical code security flaws were identified, specifically the use of undefined `min` and `sendETHToFee` functions, which will cause compilation/runtime errors and prevent essential operations like tax collection and liquidity swaps (7.2 Code Security). The use of `SafeMath` is redundant given Solidity 0.8.24's native overflow checks, adding unnecessary gas overhead.

GovernanceMedium4/10

The contract exhibits a high degree of centralization, with the owner possessing extensive control over critical parameters such as tax rates, maximum transaction amounts, and the ability to add/remove bot addresses (7.3 Access Control). The `_taxWallet` can be arbitrarily changed by the owner, posing a significant risk if the owner's key is compromised (7.4 Economic). The `openTrading` function, controlled by the owner, creates a front-running opportunity for malicious actors (7.4 Economic). The `renounceOwnership` function also transfers the contract's ETH balance to the owner before renouncing, which is an unusual and potentially risky behavior (7.5 Governance).

UpgradesMedium6/10

The contract is not designed to be upgradeable, as it does not implement any proxy pattern (7.7 Upgrades). This eliminates upgrade-specific risks such as storage collisions or proxy misconfigurations. Any changes to the contract logic would require a new deployment and migration of assets, which is a standard practice for non-upgradeable contracts.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

46.4% in top 10

22.5% in wallets23.9% in contracts

Effective Concentration32.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

$15.4K

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

0x7160…09ee

What Raised This Score

6 factors

Top-10 concentration > 30% (46.4% total → 32.1% effective; 22.5% in EOAs, 23.9% in contracts — moderate)
Liquidity < $50k ($15,446 across 1 pairs — thin market)
2 Critical finding(s) from audit
2 High finding(s) from audit
3 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

Is TERAFAB Safe?

Security Findings

Missing `min` Function Definition

Missing `sendETHToFee` Function Definition

High Centralization Risk / Extensive Owner Privileges

Arbitrary `_taxWallet` Address Change

`renounceOwnership` Transfers Contract ETH Balance

Potential for Front-running/Sandwich Attacks on `openTrading`

Restrictive `_maxWalletSize` Logic

Redundant SafeMath Library Usage

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