Is Threshold Network Token (T) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Reentrancy Vulnerability in `approveAndCall`

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.

IssueThe `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.

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

StatusUnresolved

Medium

Front-running Risk in Signature-based Functions

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.

IssueThe `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.

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

StatusUnresolved

Low

Undefined `maxSupply()` Function

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.

IssueThe `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.

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

StatusUnresolved

Info

Dependency on Unaudited External Contracts

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.

IssueThe `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.

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh2/10

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

UpgradesMedium5/10

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

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

75.1% in top 10

52.9% in wallets22.2% in contracts

Effective Concentration61.8%

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

$480.6K across 7 pairs

CurveWETHanalysed$473.8K Balancer v3tBTC$3.0K Balancer v3rETH$1.5K Balancer v3WETH$1.5K Uniswap v3USDC$613 BalancerWETH$179

Show 1 more pairShow less

Uniswap v2WETH$5

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

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0x1236…4caf

Unlocked LP Held By

0xe6d6…e4bb

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

9 factors

Ownership NOT renounced — Timelock 48h delay (exit window)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 50% (75.1% total → 61.8% effective; 52.9% in EOAs, 22.2% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
1 High finding(s) from audit
1 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

Is Threshold Network Token Safe?

Security Findings

Reentrancy Vulnerability in `approveAndCall`

Front-running Risk in Signature-based Functions

Undefined `maxSupply()` Function

Dependency on Unaudited External Contracts

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Threshold Network Token?