Quantum Audit Logo
Launch App

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

Is TokenFi Safe?

TOKENBNB Chain
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
SummaryAI Copilot

The T1 contract is an ERC-20 token implementation with Compound-style governance delegation features.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 30%
  • 3 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% (75.9% total → 35.6% effective; 8.8% in EOAs, 67.1% in contracts — moderate)
  • 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 44 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
67.1%Contracts8.8%24.1%Everyone else
67.1%Contracts8.8%24.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
75.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking67.1%
  • Walletsanonymous holders, free to sell8.8%
  • Everyone elsethe rest of the supply24.1%
Effective concentrationwhat the score reads35.6%
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.52M across 5 pairs
LP tokensLocked

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

Analysed pool$1.52MShare of depth100.0%
LP Locked90.6% · OnlyMoons Lock
Top-1 Unlocked Holder9.4%
Unlocked LP held by
0x17e9…4b940x0ed9…97060x97fa…d2e80xd634…cc730x95b8…70480xd388…67000x8bcd…07460x80d8…4ae90x28e2…e9df

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

Security Findings

3 Medium1 Low1 Info
Medium

Incorrect ERC-20 transferFrom usage in withdraw function

The withdraw function, intended for recovering ERC-20 tokens, uses `IERC20(tokenAddress).transferFrom(address(this), address(treasuryHandler), amount);. For a contract to send tokens it holds, it should use IERC20(tokenAddress).transfer(address(treasuryHandler), amount);. The current implementation requires the T1 contract itself to have approved the treasuryHandler` to spend its own tokens, which is an incorrect and impractical setup, effectively preventing the withdrawal of ERC-20 tokens from the contract.M-01

Issue

The withdraw function, intended for recovering ERC-20 tokens, uses `IERC20(tokenAddress).transferFrom(address(this), address(treasuryHandler), amount);. For a contract to send tokens it holds, it should use IERC20(tokenAddress).transfer(address(treasuryHandler), amount);. The current implementation requires the T1 contract itself to have approved the treasuryHandler` to spend its own tokens, which is an incorrect and impractical setup, effectively preventing the withdrawal of ERC-20 tokens from the contract.

Fix

Change the ERC-20 withdrawal logic in the withdraw function from `IERC20(tokenAddress).transferFrom(address(this), address(treasuryHandler), amount); to IERC20(tokenAddress).transfer(address(treasuryHandler), amount);`.

Status

Unresolved

Medium

Centralized Control over Critical Parameters and Funds

The onlyOwner role has significant control over critical functions, including setTaxHandler, setTreasuryHandler, and withdraw. This allows a single entity (or a multisig, as indicated by the prefill) to change core external dependencies and withdraw any tokens (including native currency) held by the contract. While the owner is a multisig, this level of centralized control still presents a single point of failure or potential for malicious action if the multisig is compromised.M-02

Issue

The onlyOwner role has significant control over critical functions, including setTaxHandler, setTreasuryHandler, and withdraw. This allows a single entity (or a multisig, as indicated by the prefill) to change core external dependencies and withdraw any tokens (including native currency) held by the contract. While the owner is a multisig, this level of centralized control still presents a single point of failure or potential for malicious action if the multisig is compromised.

Fix

Consider implementing a timelock for sensitive onlyOwner functions, such as setTaxHandler, setTreasuryHandler, and potentially withdraw. This would introduce a delay before changes take effect, allowing time for community review or intervention if a malicious action is detected. Alternatively, explore a more decentralized governance mechanism for these critical operations.

Status

Unresolved

Medium

Reliance on External Contract Security

The T1 contract heavily relies on external contracts, ITaxHandler and ITreasuryHandler, which are set by the owner. The security, correctness, and trustworthiness of these external contracts are paramount. A vulnerability or malicious design within ITaxHandler or ITreasuryHandler could directly impact the T1 token's functionality or economic model, potentially leading to unexpected behavior or loss of funds.M-03

Issue

The T1 contract heavily relies on external contracts, ITaxHandler and ITreasuryHandler, which are set by the owner. The security, correctness, and trustworthiness of these external contracts are paramount. A vulnerability or malicious design within ITaxHandler or ITreasuryHandler could directly impact the T1 token's functionality or economic model, potentially leading to unexpected behavior or loss of funds.

Fix

Ensure that ITaxHandler and ITreasuryHandler contracts undergo rigorous security audits. Implement robust validation checks for new handler addresses (e.g., checking if the address is a contract, or if it implements expected interfaces). Consider a community-driven or timelocked process for updating these critical external dependencies.

Status

Unresolved

Low

Hardcoded Token Parameters

The totalSupply() and decimals() functions return hardcoded values (5e9 * 1e9 and 9, respectively). While this provides predictability and is common for many tokens, it means these parameters cannot be adjusted in the future without deploying a new contract. This limits flexibility for potential future economic model adjustments.L-01

Issue

The totalSupply() and decimals() functions return hardcoded values (5e9 * 1e9 and 9, respectively). While this provides predictability and is common for many tokens, it means these parameters cannot be adjusted in the future without deploying a new contract. This limits flexibility for potential future economic model adjustments.

Fix

If future flexibility is desired, consider making totalSupply or decimals configurable during deployment or through a governance mechanism. However, for a standard fixed-supply token, this is often an acceptable design choice.

Status

Unresolved

Info

Inconsistent Visibility for ERC-20 Metadata Functions

The name() function is declared as public view, while symbol() and decimals() are declared as external view or external pure. While this does not pose a security vulnerability, it represents a minor inconsistency in function visibility for standard ERC-20 metadata getters.I-01

Issue

The name() function is declared as public view, while symbol() and decimals() are declared as external view or external pure. While this does not pose a security vulnerability, it represents a minor inconsistency in function visibility for standard ERC-20 metadata getters.

Fix

For consistency and adherence to common ERC-20 patterns, consider declaring name() as external view to match symbol() and decimals().

Status

Unresolved

Analysis

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

The T1 contract is an ERC-20 token implementation with Compound-style governance delegation features. It utilizes OpenZeppelin's Ownable pattern for administrative functions and integrates with external Tax and Treasury handlers. The contract exhibits good adherence to ERC-20 standards for core transfer logic, including safe handling of integer arithmetic. Key findings include an incorrect usage of transferFrom in the withdraw function, significant centralized control by the owner, and inherent risks associated with critical external dependencies. The owner is a multisig, which partially mitigates centralization risks.

Technical10/10Low risk

The contract demonstrates a solid foundation, leveraging OpenZeppelin libraries and implementing standard ERC-20 and governance patterns (7.1 Architecture, 7.2 Code Security). Integer arithmetic is handled safely with unchecked blocks appropriately guarded by require statements. The delegateBySig function correctly uses nonces to prevent replay attacks. However, a functional bug exists in the withdraw function where transferFrom is used instead of transfer for ERC-20 tokens, preventing the contract from withdrawing its own ERC-20 holdings (7.2 Code Security).

Governance7/10Low risk

The contract implements a Compound-style delegation system for governance, allowing token holders to delegate their voting power, which is a robust and widely adopted model (7.5 Governance). The token's total supply and decimals are hardcoded, providing a predictable economic model (7.4 Economic). However, the onlyOwner role has significant power, including the ability to change the taxHandler and treasuryHandler addresses and to initiate token withdrawals (7.3 Access Control). The security and trustworthiness of these external ITaxHandler and ITreasuryHandler contracts are critical to the overall system's integrity (7.6 External). The use of a multisig for the owner address partially mitigates the centralization risk (7.8 Operations).

Upgrades8/10Low risk

The T1 contract is not designed with an upgrade mechanism (e.g., proxy pattern). This means the contract's logic cannot be modified post-deployment. While this eliminates upgrade-related risks, any discovered vulnerabilities would require a new contract deployment and migration.

Final RecommendationWhat to do about this score

It is recommended to address the identified functional bug in the withdraw function to ensure proper ERC-20 token recovery.

A thorough review of the ITaxHandler and ITreasuryHandler contracts is crucial, as their security directly impacts the T1 token system. Consider implementing a timelock for critical owner-controlled functions to introduce a delay for sensitive operations, enhancing security and transparency.

Contract & Record

1 audit on record
TypeVault, Token
NetworkBNB Chain
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 20, 202628Low

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

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