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
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

3 Medium1 Low1 Informational
Volume 24h
$63.1K
Liquidity
$1.52M
Price
$0.002287
Token Age
2y
Top 10 Holders
75.9%

Security Findings

3 Med1 Low1 Info
Medium

Incorrect ERC-20 `transferFrom` usage in `withdraw` function

M-01The `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.
IssueThe `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.
FixChange 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);`.
StatusUnresolved
Medium

Centralized Control over Critical Parameters and Funds

M-02The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Medium

Reliance on External Contract Security

M-03The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Low

Hardcoded Token Parameters

L-01The `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.
IssueThe `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.
FixIf 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.
StatusUnresolved
Info

Inconsistent Visibility for ERC-20 Metadata Functions

I-01The `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.
IssueThe `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.
FixFor consistency and adherence to common ERC-20 patterns, consider declaring `name()` as `external view` to match `symbol()` and `decimals()`.
StatusUnresolved

Category Ratings

TechnicalLow10/10

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

GovernanceLow7/10

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

UpgradesLow8/10

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.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

75.9% in top 10
8.8% in wallets67.1% in contracts
Effective Concentration35.6%

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.52M across 5 pairs
Pancakeswap v2WBNBanalysed$1.52M100.0%Squadswap v2WBNB$5600.0%Pancakeswap v2USDT$660.0%0x6fB6…cbE5USDT$150.0%Sushiswap v3WBNB$00.0%

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.6% · OnlyMoons Lock
Top-1 Unlocked Holder9.4%

Key Addresses

10 addresses
Deployer
0xa99c…5b9b
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.

What Raised This Score

4 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

Related Audits

6 more on the record
MatthewCoinMedium RiskBillion Zone Xchange (ZBX)Medium RiskElonCoinMedium RiskBaby Asteroid (BABYASTEROID)Medium RiskDecentrawood (DEOD)Medium Riskast.fun (AST)Medium 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