On-chain security analysis — is it a scam or legit?
EthereumThe audit of the T token contract reveals a well-structured ERC20 implementation with EIP-2612 permit and delegation features.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xe6d6…e4bbNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
approveAndCallapproveAndCall function performs an external call to spender.receiveApproval after modifying the allowance state. If the spender contract is malicious or compromised, it could re-enter the token contract and perform unauthorized actions before the approve state change is fully committed, potentially leading to unexpected behavior or loss of funds. This violates the Checks-Effects-Interactions pattern.H-01The approveAndCall function performs an external call to spender.receiveApproval after modifying the allowance state. If the spender contract is malicious or compromised, it could re-enter the token contract and perform unauthorized actions before the approve state change is fully committed, potentially leading to unexpected behavior or loss of funds. This violates the Checks-Effects-Interactions pattern.
Implement a reentrancy guard on the approveAndCall function or ensure that the external call is the last operation after all state changes. Alternatively, consider removing the approveAndCall function if its utility does not justify the inherent reentrancy risk.
Unresolved
permit and delegateBySig functions rely on off-chain signed messages. While nonces and deadlines are used to prevent replay attacks, these transactions can still be front-run. A malicious actor could observe a pending transaction, submit their own transaction with a higher gas price, and potentially execute the action before the legitimate user, leading to a denial of service for the original signer or unexpected state changes, especially if the deadline is set far in the future.M-01The permit and delegateBySig functions rely on off-chain signed messages. While nonces and deadlines are used to prevent replay attacks, these transactions can still be front-run. A malicious actor could observe a pending transaction, submit their own transaction with a higher gas price, and potentially execute the action before the legitimate user, leading to a denial of service for the original signer or unexpected state changes, especially if the deadline is set far in the future.
Educate users about the risks of front-running for signature-based transactions and advise them to use short, reasonable deadlines. While not fully preventable, clear communication can mitigate user impact. Consider implementing a commit-reveal scheme for highly sensitive operations if applicable, though this adds complexity.
Unresolved
maxSupply() Functionmint function in T.sol includes a require statement checking totalSupply + amount <= maxSupply(). However, the maxSupply() function is not defined within the provided T.sol or ERC20WithPermit.sol code. This implies a dependency on an external or inherited contract (e.g., MisfundRecovery or Checkpoints) for a critical economic constraint. Without its definition, the actual maximum supply limit and its enforceability cannot be fully assessed, posing an architectural dependency risk.L-01The mint function in T.sol includes a require statement checking totalSupply + amount <= maxSupply(). However, the maxSupply() function is not defined within the provided T.sol or ERC20WithPermit.sol code. This implies a dependency on an external or inherited contract (e.g., MisfundRecovery or Checkpoints) for a critical economic constraint. Without its definition, the actual maximum supply limit and its enforceability cannot be fully assessed, posing an architectural dependency risk.
Ensure that the maxSupply() function is clearly defined and its logic is robust and immutable, or controlled by a secure governance mechanism. Document its location and behavior thoroughly. If it's intended to be a fixed value, consider making it a constant or immutable variable.
Unresolved
T contract inherits from MisfundRecovery and Checkpoints, whose source code was not provided for this audit. The security and correctness of the T token heavily rely on the proper functioning and security of these external contracts, particularly Checkpoints for voting power mechanics and MisfundRecovery for potential token recovery. Any vulnerabilities in these dependencies could directly impact the T token.I-01The T contract inherits from MisfundRecovery and Checkpoints, whose source code was not provided for this audit. The security and correctness of the T token heavily rely on the proper functioning and security of these external contracts, particularly Checkpoints for voting power mechanics and MisfundRecovery for potential token recovery. Any vulnerabilities in these dependencies could directly impact the T token.
Conduct a comprehensive security audit of all external and inherited contracts (MisfundRecovery, Checkpoints) to ensure their robustness, correctness, and absence of vulnerabilities. Ensure that these dependencies are from reputable sources and have undergone prior security reviews.
Unresolved
The audit of the T token contract reveals a well-structured ERC20 implementation with EIP-2612 permit and delegation features. Key security considerations include a reentrancy vulnerability in approveAndCall and front-running risks for signature-based operations. Dependencies on external, unaudited contracts also introduce potential risks, particularly concerning the maxSupply and voting power mechanisms.
The contract demonstrates strong technical foundations, utilizing Solidity 0.8.9 for automatic overflow/underflow protection and inheriting from battle-tested OpenZeppelin and Thesis libraries. The implementation of EIP-2612 permit and delegation features is generally robust, employing nonces and deadlines to mitigate replay attacks. However, a significant reentrancy vulnerability exists in the approveAndCall function (7.2 Code Security), which could allow malicious spender contracts to re-enter the token contract. Additionally, signature-based functions like permit and delegateBySig are susceptible to front-running (7.2 Code Security).
The economic model benefits from a maxSupply check during minting, preventing uncontrolled inflation (7.4 Economic). The mint function is appropriately restricted to the contract owner, which is controlled by a Timelock, enhancing governance security (7.3 Access Control, 7.5 Governance). The MisfundRecovery mechanism (7.4 Economic) suggests a safety net for accidental token transfers. However, the integrity of the voting power system relies heavily on the Checkpoints contract, whose specific implementation and security were not part of this audit (7.6 External).
The contract is not deployed as an upgradeable proxy, meaning direct in-place upgrades are not possible (7.7 Upgrades). Any significant changes to the token logic would necessitate a new deployment and a migration strategy, which can be complex and disruptive. While this avoids proxy-specific upgrade risks, it introduces operational challenges for future enhancements (7.8 Operations).
Address the identified reentrancy vulnerability in approveAndCall by implementing a Checks-Effects-Interactions pattern or using a reentrancy guard.
Evaluate the necessity of approveAndCall and consider removing it if its risks outweigh its benefits. Review the maxSupply() implementation in the inherited contracts to ensure its robustness. Conduct a comprehensive audit of all external dependencies, specifically MisfundRecovery and Checkpoints, to ensure their security and proper integration with the token contract.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Threshold Network Token (T) contract on Ethereum is 0xcdf7028ceab81fa0c6971208e83fa7872994bee5. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Threshold Network Token is 71/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $480.6K.
As of Sep 4, 2026, the 10 largest holders own 75.1% of the supply. The Holders section on this page shows who they are by holder type.
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
