Is TRADOOR Safe? Smart Contract Security Analysis

Security Findings

1 Med1 Low2 Info

Medium

Centralization of Initial Token Supply

M-01The `Token` contract's constructor mints the entire `supply` to `msg.sender` (the deployer). This design choice results in 100% of the initial token supply being held by a single address. This concentration of tokens creates a significant centralization risk (7.4 Economic), as the deployer could potentially manipulate the market, dump tokens, or exert undue influence over the token's ecosystem.

IssueThe `Token` contract's constructor mints the entire `supply` to `msg.sender` (the deployer). This design choice results in 100% of the initial token supply being held by a single address. This concentration of tokens creates a significant centralization risk (7.4 Economic), as the deployer could potentially manipulate the market, dump tokens, or exert undue influence over the token's ecosystem.

FixIf the token is intended for a decentralized project or public distribution, consider implementing a more diversified initial distribution strategy. This could involve: 1) Minting to a multi-signature wallet for controlled distribution. 2) Allocating portions to various stakeholders (e.g., treasury, liquidity pools, community airdrops). 3) Implementing a vesting schedule for team or early investor allocations.

StatusUnresolved

Low

Lack of Emergency Controls

L-01The `Token` contract, being a basic ERC20, does not include any emergency control mechanisms such as `pause` or `blacklist` functionality. While this simplifies the contract and reduces complexity, the absence of these controls (7.8 Operations) means that in the event of a critical vulnerability, exploit, or regulatory requirement, there is no built-in mechanism to halt transfers or restrict malicious addresses, potentially leading to irreversible damage.

IssueThe `Token` contract, being a basic ERC20, does not include any emergency control mechanisms such as `pause` or `blacklist` functionality. While this simplifies the contract and reduces complexity, the absence of these controls (7.8 Operations) means that in the event of a critical vulnerability, exploit, or regulatory requirement, there is no built-in mechanism to halt transfers or restrict malicious addresses, potentially leading to irreversible damage.

FixAssess the project's risk tolerance and potential future needs. If the ability to react to emergencies is deemed important, consider integrating OpenZeppelin's `Pausable` or `Blacklist` modules. These should be controlled by a robust access control mechanism, such as a multi-signature wallet, to prevent single points of failure.

StatusUnresolved

Info

Reliance on OpenZeppelin Standards

I-01The `Token` contract heavily relies on the battle-tested and widely audited OpenZeppelin Contracts library (v4.9.0) for its ERC20 implementation. This significantly reduces the risk of common vulnerabilities (7.2 Code Security) such as reentrancy, integer overflows/underflows, and incorrect ERC20 behavior, as these libraries are maintained by a reputable team and have undergone extensive scrutiny.

IssueThe `Token` contract heavily relies on the battle-tested and widely audited OpenZeppelin Contracts library (v4.9.0) for its ERC20 implementation. This significantly reduces the risk of common vulnerabilities (7.2 Code Security) such as reentrancy, integer overflows/underflows, and incorrect ERC20 behavior, as these libraries are maintained by a reputable team and have undergone extensive scrutiny.

FixContinue to monitor OpenZeppelin's security advisories and updates. Ensure that any future custom logic or modifications are thoroughly reviewed to maintain the high security standard provided by the base library.

StatusUnresolved

Info

Immutability of Contract Logic

I-02The `Token` contract is deployed as a standard, non-upgradeable contract. This means its logic is immutable once deployed to the blockchain (7.7 Upgrades). This design provides certainty and eliminates risks associated with upgrade mechanisms (e.g., proxy vulnerabilities, upgrade key compromise). However, it also implies that any discovered bugs or desired feature enhancements cannot be implemented without deploying an entirely new contract and migrating existing token holders.

IssueThe `Token` contract is deployed as a standard, non-upgradeable contract. This means its logic is immutable once deployed to the blockchain (7.7 Upgrades). This design provides certainty and eliminates risks associated with upgrade mechanisms (e.g., proxy vulnerabilities, upgrade key compromise). However, it also implies that any discovered bugs or desired feature enhancements cannot be implemented without deploying an entirely new contract and migrating existing token holders.

FixAcknowledge the trade-offs of immutability. For a simple token, this is often an acceptable design. If future flexibility or bug-fixing capabilities are critical, consider an upgradeable proxy pattern for future contract deployments, ensuring proper implementation and robust access control for upgrade functions.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is straightforward, implementing a standard ERC20 token. Code security (7.2) is high due to the extensive use of OpenZeppelin's audited ERC20 library, which handles common vulnerabilities like reentrancy and integer overflows. The custom `Token` contract only adds a constructor for initial minting, which is a safe operation. Access control (7.3) is limited to standard ERC20 permissions, with no additional roles, which is appropriate for a basic token. External interactions (7.6) are confined to standard token transfers, minimizing attack surface. Operational risks (7.8) are low as the contract is self-contained.

GovernanceHigh2/10

The economic model (7.4) involves minting the entire initial token supply to the deployer, which presents a centralization risk. This concentration of tokens could allow the deployer to significantly influence market dynamics or control token distribution. There are no explicit governance mechanisms (7.5) implemented within the contract, meaning decisions regarding the token's future or ecosystem would rely on off-chain coordination or the deployer's discretion. For example, if the token is intended for broad public use, a more decentralized initial distribution strategy would mitigate this risk.

UpgradesMedium6/10

The contract is not designed with any upgradeability pattern (7.7), such as proxies. This means the contract is immutable once deployed, and its logic cannot be altered. While this provides certainty and eliminates upgrade-related risks like proxy misconfigurations or implementation bugs, it also means that any future feature enhancements or bug fixes would require a new contract deployment and migration of assets.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

89.7% in top 10

11.1% in wallets78.6% in contracts

Effective Concentration42.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

$803.8K across 3 pairs

Pancakeswap v3USDTanalysed$796.8K Pancakeswap v3USDT$6.9K

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 Holder97.1%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0x3c5d…25a7

Unlocked LP Held By

0xdd6c…5a1f0x265c…c3fd

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

What Raised This Score

7 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (89.7% total → 42.6% effective; 11.1% in EOAs, 78.6% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 97.1% (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 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

Final Recommendation

AI Copilot

For projects intending to launch a public token, consider implementing a more decentralized initial distribution strategy to mitigate the economic risks associated with a single entity holding the entire supply.…

Read the verdictHide

This could involve vesting schedules, airdrops, or liquidity pool provisions. Additionally, evaluate the need for emergency controls like pausing or blacklisting functions, which can be crucial for responding to unforeseen events or exploits, even for simple tokens. If such features are desired, they should be integrated with appropriate access control mechanisms.

Contract

TypeToken

Audit History

2 audits on record

Jul 2567Jul 2734

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Not Signed In

Is TRADOOR Safe?

Security Findings

Centralization of Initial Token Supply

Lack of Emergency Controls

Reliance on OpenZeppelin Standards

Immutability of Contract Logic

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of TRADOOR?