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.

On-chain security analysis — is it a scam or legit?
Is TokenFi Safe?
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 →The T1 contract is an ERC-20 token implementation with Compound-style governance delegation features.
Read the full analysis- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking67.1%
- Walletsanonymous holders, free to sell8.8%
- Everyone elsethe rest of the supply24.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- 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 LP tokens of the analysed pool are locked or burned.
0x17e9…4b940x0ed9…97060x97fa…d2e80xd634…cc730x95b8…70480xd388…67000x8bcd…07460x80d8…4ae90x28e2…e9dfA privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.
Security Findings
MediumIncorrect 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
transferFrom usage in withdraw functionIssue
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
MediumCentralized 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
MediumReliance 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
LowHardcoded 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
InfoInconsistent 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 4The 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).
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).
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- 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