Quantum Audit Logo
Launch App

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

Is TERAFAB Safe?

Ethereum
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance4/10Upgrades6/10Checks passed5 of 5Findings2 Critical · 2 High · 3 Medium · 1 Low8
SummaryAI Copilot

The audit of the TERAFAB (Tweet) token contract revealed critical issues, including undefined functions (min, sendETHToFee) that prevent core token swap and fee distribution mechanisms from functioning correctly.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity < $50k
  • 2 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 3 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
23.9%Contracts22.5%Wallets53.6%Everyone else
23.9%Contracts22.5%Wallets53.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
46.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking23.9%
  • Walletsanonymous holders, free to sell22.5%
  • Everyone elsethe rest of the supply53.6%
Effective concentrationwhat the score reads32.1%
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$15.4K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$15.4KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

2 Critical2 High3 Medium1 Low
Critical

Missing min Function Definition

The _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.C-01

Issue

The _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.

Fix

Define 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; } ```

Status

Unresolved

Critical

Missing sendETHToFee Function Definition

The _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.C-02

Issue

The _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.

Fix

Define 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); } ```

Status

Unresolved

High

High Centralization Risk / Extensive Owner Privileges

The 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).H-01

Issue

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

Fix

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

Status

Unresolved

High

Arbitrary _taxWallet Address Change

The 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).H-02

Issue

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

Fix

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

Status

Unresolved

Medium

renounceOwnership Transfers Contract ETH Balance

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

Issue

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

Fix

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

Status

Unresolved

Medium

Potential for Front-running/Sandwich Attacks on openTrading

The 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).M-02

Issue

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

Fix

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

Status

Unresolved

Medium

Restrictive _maxWalletSize Logic

The _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).M-03

Issue

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

Fix

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

Status

Unresolved

Low

Redundant SafeMath Library Usage

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

Issue

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

Fix

Remove 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+.

Status

Unresolved

Analysis

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

The audit of the TERAFAB (Tweet) token contract revealed critical issues, including undefined functions (min, sendETHToFee) that prevent core token swap and fee distribution mechanisms from functioning correctly. The contract also exhibits high centralization risks due to extensive owner privileges, allowing significant control over token parameters and tax wallet designation. Several medium and low-severity issues related to economic logic and redundant code were also identified.

Technical4/10Medium risk

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.

Governance4/10Medium risk

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

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

Address the critical issues by defining or correctly importing the min and sendETHToFee functions to ensure the contract's core functionality.

Review and mitigate the high centralization risks by considering multi-signature wallets for sensitive owner functions or implementing time-locks for critical parameter changes. Evaluate the economic implications of the _maxWalletSize logic and the renounceOwnership ETH transfer. Remove the redundant SafeMath library to optimize gas usage.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age4mo
Contract0xd833…59ab
Deployer0x7160…09ee
Badge for your website
TERAFAB 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 4, 202667High
  2. Aug 7, 202662Medium

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

Related Audits

6 more on the recordAll audits
DIATokenDIA · Ethereum67HighTrace TokenTRAC · Ethereum67HighPowerLedgerPOWR · Ethereum67HighStargate FinanceSTG · Ethereum66HighREEthereum68HighZamaEthereum68High

Would You Like a More Detailed Audit of TERAFAB?

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