Quantum Audit Logo
Launch App

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

Is TokenFi Safe?

TOKENEthereum
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance4/10Upgrades7/10Checks passed6 of 7Findings1 Critical · 2 High · 2 Medium · 1 Low6
SummaryAI Copilot

The T1 token contract implements ERC-20 and governance delegation features.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 30%
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 46 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
64.1%Contracts14.2%Wallets21.7%Everyone else
64.1%Contracts14.2%21.7%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
78.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking64.1%
  • Walletsanonymous holders, free to sell14.2%
  • Everyone elsethe rest of the supply21.7%
Effective concentrationwhat the score reads39.9%
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$1.11M

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$1.11MShare of depth100.0%
LP Locked90.5% · Null Address, OnlyMoons Lock
Top-1 Unlocked Holder9.4%
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.

Security Findings

1 Critical2 High2 Medium1 Low
Critical

Missing _transfer Function Renders Token Non-Functional

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

Issue

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

Fix

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

Status

Unresolved

High

Incorrect ERC20 Withdrawal Logic in withdraw Function

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

Issue

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

Fix

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

Status

Unresolved

High

Potential uint224 Truncation in _moveDelegates

In 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.H-02

Issue

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

Fix

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

Status

Unresolved

Medium

Centralized Control by Owner

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

Issue

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

Fix

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

Status

Unresolved

Medium

Incomplete Code Snippet

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

Issue

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

Fix

Provide the complete and correct source code for the contract. Ensure all events are properly emitted and all functions are fully implemented as intended.

Status

Unresolved

Low

numCheckpoints uint32 Overflow Possibility

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical6/10Medium risk

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

Governance4/10Medium risk

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

Upgrades7/10Low risk

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.

Final RecommendationWhat to do about this score

Address the critical functional bugs immediately, particularly the missing _transfer function and the incorrect ERC20 withdraw logic.

Thoroughly review the governance delegation mechanism to prevent uint224 truncation and ensure accurate voting power representation. Consider implementing a multi-signature wallet for the owner address to mitigate centralized control risks and enhance operational security.

Contract & Record

1 audit on record
TypeVault, Token
NetworkEthereum
Token age2y
Contract0x4507…b528
Deployer0xa99c…5b9b
Badge for your website
TokenFi 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. Aug 30, 202661Medium

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

Related Audits

6 more on the recordAll audits
HarryPotterObamaSonic10InuBITCOIN · Ethereum61MediumLego PepeLEPE · Ethereum61MediumGraph TokenGRT · Ethereum61MediumGnosis TokenGNO · Ethereum61MediumInterfoldFOLD · Ethereum61MediumANyONe ProtocolANYONE · Ethereum61Medium

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 Is this your token? Publish your own audit on this page