Is True Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low2 Info

High

Centralized Minting Power

H-01The `mint` function is restricted to `onlyOwner`, allowing a single address to mint new tokens up to the `maxSupply`. If the owner's private key is compromised, or if the owner acts maliciously, they could mint a large number of tokens, devaluing existing tokens and potentially disrupting the protocol's economy. While `maxSupply` can be changed by `TIMELOCK_ROLE`, the owner still retains the power to mint up to the current limit.

IssueThe `mint` function is restricted to `onlyOwner`, allowing a single address to mint new tokens up to the `maxSupply`. If the owner's private key is compromised, or if the owner acts maliciously, they could mint a large number of tokens, devaluing existing tokens and potentially disrupting the protocol's economy. While `maxSupply` can be changed by `TIMELOCK_ROLE`, the owner still retains the power to mint up to the current limit.

FixTransfer the `owner` role to a multi-signature wallet or a Timelock contract with a sufficient delay. Consider implementing a more decentralized minting mechanism, such as a capped minting schedule or a governance-controlled minting function, if the project's long-term vision includes decentralization.

StatusUnresolved

Medium

Redundant Access Control Mechanisms

M-01The contract inherits both `Ownable` and `AccessControl`. While `Ownable` provides a simple `owner` role, `AccessControl` offers a more granular role-based system. The constructor grants `DEFAULT_ADMIN_ROLE` to `msg.sender`, who is also the initial `owner`. This dual access control can lead to confusion regarding responsibilities, potential misconfigurations, or unexpected interactions between the two systems if not managed carefully (7.3 Access Control).

IssueThe contract inherits both `Ownable` and `AccessControl`. While `Ownable` provides a simple `owner` role, `AccessControl` offers a more granular role-based system. The constructor grants `DEFAULT_ADMIN_ROLE` to `msg.sender`, who is also the initial `owner`. This dual access control can lead to confusion regarding responsibilities, potential misconfigurations, or unexpected interactions between the two systems if not managed carefully (7.3 Access Control).

FixConsolidate access control to use a single, robust mechanism (preferably `AccessControl` for its granularity). If both are deemed necessary, clearly document the responsibilities and interactions of each role and ensure that critical functions are protected by the most appropriate and secure mechanism. Ensure the `owner` and `DEFAULT_ADMIN_ROLE` are managed by secure entities (e.g., multi-sig, Timelock).

StatusUnresolved

Medium

Owner's Ability to Force Self-Delegation

M-02The `delegateByOwner(address to)` function, restricted to `onlyOwner`, calls `_delegate(to, to)`. This allows the contract owner to force any address `to` to self-delegate its voting power. While this doesn't allow the owner to directly control `to`'s votes or delegate `to`'s votes to a third party, it gives the owner centralized control over who can be an active voter by forcing self-delegation, potentially influencing governance participation or quorum (7.5 Governance).

IssueThe `delegateByOwner(address to)` function, restricted to `onlyOwner`, calls `_delegate(to, to)`. This allows the contract owner to force any address `to` to self-delegate its voting power. While this doesn't allow the owner to directly control `to`'s votes or delegate `to`'s votes to a third party, it gives the owner centralized control over who can be an active voter by forcing self-delegation, potentially influencing governance participation or quorum (7.5 Governance).

FixReview the intended purpose of `delegateByOwner`. If the goal is to allow the owner to delegate *their own* votes, the function should be `_delegate(msg.sender, to)`. If the goal is to enable delegation for others, consider if this centralized control is desirable. For truly decentralized governance, delegation should ideally be initiated by the delegator themselves.

StatusUnresolved

Low

`maxSupply` Modifiable by a Single Role

L-01The `setMaxSupply` function, which controls the maximum possible token supply, is protected by `onlyRole(Roles.TIMELOCK_ROLE)`. While using a `TIMELOCK_ROLE` is a good practice for critical parameters, it still relies on a single role to modify a fundamental economic constraint of the token (7.4 Economic). If the `TIMELOCK_ROLE` is compromised or mismanaged, the token's supply cap could be arbitrarily changed.

IssueThe `setMaxSupply` function, which controls the maximum possible token supply, is protected by `onlyRole(Roles.TIMELOCK_ROLE)`. While using a `TIMELOCK_ROLE` is a good practice for critical parameters, it still relies on a single role to modify a fundamental economic constraint of the token (7.4 Economic). If the `TIMELOCK_ROLE` is compromised or mismanaged, the token's supply cap could be arbitrarily changed.

FixEnsure the `TIMELOCK_ROLE` is assigned to a highly secure entity, such as a multi-signature wallet with a significant number of signers and a substantial time delay. Consider if a more decentralized governance mechanism (e.g., a DAO vote) should be required to alter `maxSupply` for long-term protocol stability.

StatusUnresolved

Info

Lack of Pause Mechanism

I-01The contract does not include a pause mechanism (e.g., `Pausable` from OpenZeppelin). In the event of an emergency, such as a critical vulnerability discovery or a major market exploit, the contract owner or administrators would not have the ability to temporarily halt token transfers or other critical operations (7.8 Operations).

IssueThe contract does not include a pause mechanism (e.g., `Pausable` from OpenZeppelin). In the event of an emergency, such as a critical vulnerability discovery or a major market exploit, the contract owner or administrators would not have the ability to temporarily halt token transfers or other critical operations (7.8 Operations).

FixConsider integrating OpenZeppelin's `Pausable` contract to provide an emergency stop functionality. This mechanism should be controlled by a multi-signature wallet or a Timelock to prevent arbitrary pausing.

StatusUnresolved

Info

External Dependency on `Roles.sol`

I-02The contract imports `./libraries/Roles.sol` and uses `Roles.TIMELOCK_ROLE`. While this is a common pattern for defining constants, the content of `Roles.sol` was not provided for review. Assuming it defines `bytes32` constants, its absence in the audit scope means its specific implementation details and potential implications could not be fully assessed (7.6 External).

IssueThe contract imports `./libraries/Roles.sol` and uses `Roles.TIMELOCK_ROLE`. While this is a common pattern for defining constants, the content of `Roles.sol` was not provided for review. Assuming it defines `bytes32` constants, its absence in the audit scope means its specific implementation details and potential implications could not be fully assessed (7.6 External).

FixEnsure all external dependencies, including simple libraries like `Roles.sol`, are included in the audit scope for a comprehensive review. Verify that `Roles.sol` only contains constant definitions and does not introduce any unexpected logic or vulnerabilities.

StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract is built upon battle-tested OpenZeppelin libraries (ERC-20, ERC20Votes, AccessControl, Ownable), which significantly reduces the risk of common vulnerabilities (7.2 Code Security). Standard ERC-20 functionalities are correctly overridden. However, the coexistence of `Ownable` and `AccessControl` patterns introduces potential complexity and redundancy in access control (7.3 Access Control). The `delegateByOwner` function's logic, allowing the owner to force self-delegation for any address, is an unusual design choice that centralizes control over voting participation (7.3 Access Control).

GovernanceMedium4/10

The contract's economic model allows the contract owner to mint tokens up to a `maxSupply` (7.4 Economic), which represents a significant centralization of power. While the `maxSupply` itself can only be adjusted by a `TIMELOCK_ROLE`, the owner's minting capability remains potent. The `delegateByOwner` function grants the owner the ability to influence governance participation by forcing self-delegation for any address (7.5 Governance). This level of centralized control over token supply and voting mechanisms introduces substantial economic and governance risks.

UpgradesMedium5/10

The TrueToken contract is not designed as an upgradeable proxy (7.7 Upgrades). This eliminates risks associated with upgrade mechanisms, such as proxy implementation mismatches or insecure upgrade paths. Any changes to the contract logic would require a new deployment and migration of assets.

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

60.4% in top 10

0.0% in wallets60.4% in contracts

Effective Concentration24.2%

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

$817.4K across 8 pairs

Uniswap v2WETHanalysed$755.5K Uniswap v3WETH$60.8K Uniswap v4ETH$745 Uniswap v4USDC$261 Uniswap v4USDC$124 Uniswap v4ETH$29

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 Holder99.0%

Top-3 Unlocked100.0%

Key Addresses

11 addresses

Deployer

0xa9d1…4a57

Unlocked LP Held By

0x688f…f0140x7ddb…3e280x2db6…704c0x5040…2e5e0xfbb5…20870xe28d…a94d0x1f6b…867b0xce83…93ae0xe8ce…57ad0x20f9…d991

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 1080h delay (exit window)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 20% (60.4% total → 24.2% effective; 0.0% in EOAs, 60.4% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
1 High finding(s) from audit
2 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

Not Signed In

Is True Safe?

Security Findings

Centralized Minting Power

Redundant Access Control Mechanisms

Owner's Ability to Force Self-Delegation

`maxSupply` Modifiable by a Single Role

Lack of Pause Mechanism

External Dependency on `Roles.sol`

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 True?