Quantum Audit Logo

Is TokenFi Safe?

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

Is this your token? Publish your own audit on this page →

TokenFi TOKEN
0x4507…b528
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The T1 token contract implements ERC-20 and governance delegation features. A critical vulnerability was identified where the core `_transfer` function is missing, rendering the token non-functional for transfers. Additionally, the ERC-20 withdrawal mechanism is flawed, and a potential truncation issue exists in the governance delegation logic. The contract relies on an `Ownable` pattern, centralizing control over key parameters and fund withdrawals.

1 Critical2 High2 Medium1 Low
Volume 24h
$26.4K
Liquidity
$1.11M
Price
$0.002289
Token Age
2y
Top 10 Holders
78.3%

Security Findings

1 Crit2 High2 Med1 Low
Critical

Missing `_transfer` Function Renders Token Non-Functional

C-01The `transfer` and `transferFrom` functions, which are core to ERC-20 functionality, both call an internal `_transfer` function. However, the provided contract code for `T1` does not define a `_transfer` function. This critical omission means that token transfers will always revert, making the token completely non-functional as an ERC-20 asset.
IssueThe `transfer` and `transferFrom` functions, which are core to ERC-20 functionality, both call an internal `_transfer` function. However, the provided contract code for `T1` does not define a `_transfer` function. This critical omission means that token transfers will always revert, making the token completely non-functional as an ERC-20 asset.
FixImplement the `_transfer` function, which should handle the logic for updating `_balances` and emitting the `Transfer` event, similar to standard ERC-20 implementations. Ensure it includes necessary checks for sender/recipient validity and sufficient balance.
StatusUnresolved
High

Incorrect ERC20 Withdrawal Logic in `withdraw` Function

H-01The `withdraw` function, when handling ERC20 tokens, uses `IERC20(tokenAddress).transferFrom(address(this), address(treasuryHandler), amount);`. For `transferFrom` to succeed, the `T1` contract itself (as `address(this)`) would need to have approved itself to spend `tokenAddress` tokens, which is an incorrect and non-standard pattern. Typically, a contract holding ERC20 tokens would use `IERC20(tokenAddress).transfer(address(treasuryHandler), amount);` to send tokens it owns. As implemented, the ERC20 withdrawal functionality is non-functional.
IssueThe `withdraw` function, when handling ERC20 tokens, uses `IERC20(tokenAddress).transferFrom(address(this), address(treasuryHandler), amount);`. For `transferFrom` to succeed, the `T1` contract itself (as `address(this)`) would need to have approved itself to spend `tokenAddress` tokens, which is an incorrect and non-standard pattern. Typically, a contract holding ERC20 tokens would use `IERC20(tokenAddress).transfer(address(treasuryHandler), amount);` to send tokens it owns. As implemented, the ERC20 withdrawal functionality is non-functional.
FixChange the ERC20 withdrawal logic to `IERC20(tokenAddress).transfer(address(treasuryHandler), amount);` to correctly transfer tokens held by the contract to the treasury handler. Ensure the contract actually holds the tokens it intends to withdraw.
StatusUnresolved
High

Potential `uint224` Truncation in `_moveDelegates`

H-02In the `_delegate` function, `delegatorBalance` (a `uint256`) is cast to `uint224` before being passed as `amount` to `_moveDelegates`. If a delegator's balance exceeds `type(uint224).max` (approximately 2^224 - 1), the `amount` will be truncated. This truncation would lead to an incorrect representation of voting power for delegates, potentially undermining the integrity of the governance mechanism.
IssueIn the `_delegate` function, `delegatorBalance` (a `uint256`) is cast to `uint224` before being passed as `amount` to `_moveDelegates`. If a delegator's balance exceeds `type(uint224).max` (approximately 2^224 - 1), the `amount` will be truncated. This truncation would lead to an incorrect representation of voting power for delegates, potentially undermining the integrity of the governance mechanism.
FixConsider using `uint256` for `amount` in `_moveDelegates` and for `votes` in the `Checkpoint` struct to ensure that all possible token balances can be accurately represented as voting power. If `uint224` is strictly required for gas optimization or storage, implement a `require` check to prevent delegation of amounts exceeding `type(uint224).max`.
StatusUnresolved
Medium

Centralized Control by Owner

M-01The contract utilizes the `Ownable` pattern, granting the deployer (owner) exclusive control over critical functions. The owner can unilaterally change the `taxHandler` and `treasuryHandler` addresses, and has the ability to withdraw any ETH or ERC20 tokens from the contract via the `withdraw` function. This centralization introduces a single point of failure and relies heavily on the trustworthiness of the owner.
IssueThe contract utilizes the `Ownable` pattern, granting the deployer (owner) exclusive control over critical functions. The owner can unilaterally change the `taxHandler` and `treasuryHandler` addresses, and has the ability to withdraw any ETH or ERC20 tokens from the contract via the `withdraw` function. This centralization introduces a single point of failure and relies heavily on the trustworthiness of the owner.
FixConsider implementing a multi-signature wallet for the owner address to distribute control and require multiple approvals for sensitive operations. Alternatively, introduce a timelock mechanism for critical changes (e.g., changing handlers) to provide a window for community review or intervention.
StatusUnresolved
Medium

Incomplete Code Snippet

M-02The contract code ends abruptly with `emit DelegateVotesCh...`, indicating that the provided source code is incomplete or truncated. This suggests potential issues with the development process, code quality, or a copy-paste error, and raises concerns about the full functionality and security of the missing parts.
IssueThe contract code ends abruptly with `emit DelegateVotesCh...`, indicating that the provided source code is incomplete or truncated. This suggests potential issues with the development process, code quality, or a copy-paste error, and raises concerns about the full functionality and security of the missing parts.
FixProvide the complete and correct source code for the contract. Ensure all events are properly emitted and all functions are fully implemented as intended.
StatusUnresolved
Low

`numCheckpoints` `uint32` Overflow Possibility

L-01The `numCheckpoints` variable, which tracks the number of checkpoints for a delegatee, is a `uint32`. In the `_writeCheckpoint` function, `numCheckpoints[delegatee]` is incremented. While highly unlikely in practical scenarios, if a delegatee accumulates `2^32 - 1` (approx. 4.2 billion) checkpoints, the next increment would cause an overflow, potentially leading to incorrect checkpoint indexing or state corruption.
IssueThe `numCheckpoints` variable, which tracks the number of checkpoints for a delegatee, is a `uint32`. In the `_writeCheckpoint` function, `numCheckpoints[delegatee]` is incremented. While highly unlikely in practical scenarios, if a delegatee accumulates `2^32 - 1` (approx. 4.2 billion) checkpoints, the next increment would cause an overflow, potentially leading to incorrect checkpoint indexing or state corruption.
FixWhile the likelihood is extremely low, consider adding a `require` check before incrementing `numCheckpoints` to ensure it does not exceed `type(uint32).max`. Alternatively, if the number of checkpoints is expected to be very large, use `uint256` for `numCheckpoints`.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical implementation attempts to combine ERC-20 functionality with governance delegation. Strengths include the use of OpenZeppelin's Ownable for access control and EIP-712 for `delegateBySig`. However, critical functional flaws were found, such as the missing `_transfer` function (7.2 Code Security), which prevents any token transfers. The `withdraw` function for ERC20 tokens is also incorrectly implemented, using `transferFrom` instead of `transfer` (7.2 Code Security). A potential `uint224` truncation issue in `_moveDelegates` could lead to incorrect voting power calculations (7.2 Code Security).

GovernanceMedium4/10

The contract incorporates a standard governance delegation mechanism, allowing token holders to delegate their voting power and retrieve historical vote counts (7.5 Governance). This promotes decentralized decision-making. However, the `Ownable` pattern grants the deployer significant centralized control over critical parameters like `taxHandler` and `treasuryHandler` addresses, and the ability to withdraw all contract funds (7.3 Access Control, 7.4 Economic). The potential `uint224` truncation issue could also lead to inaccurate voting power, undermining governance integrity (7.5 Governance).

UpgradesLow7/10

The T1 contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, no upgrade-specific risks are present. Any changes to the contract's logic would require a new deployment and migration of assets, which is a standard practice for non-upgradeable contracts.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

78.3% in top 10
14.2% in wallets64.1% in contracts
Effective Concentration39.9%

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

$1.11M

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 Locked90.5% · Null Address, OnlyMoons Lock
Top-1 Unlocked Holder9.4%

Key Addresses

8 addresses
Deployer
0xa99c…5b9b
Unlocked LP Held By
0x2b9d…0ab00x5a07…2a180x0333…2ddf0xb3ac…68a00x826f…1e650x0000…8a900x1f2f…f387

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

6 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 30% (78.3% total → 39.9% effective; 14.2% in EOAs, 64.1% in contracts — moderate)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 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

Related Audits

6 more on the record
HarryPotterObamaSonic10Inu (BITCOIN)High RiskLego Pepe (LEPE)High RiskGraph Token (GRT)High RiskGnosis Token (GNO)High RiskInterfold (FOLD)High RiskANyONe Protocol (ANYONE)High Risk

Would You Like a More Detailed Audit of TokenFi?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit