Quantum Audit Logo

Is tokenbot Safe?

On-chain security analysis — is it a scam or legit?

tokenbot CLANKER
0x1bc0…1bcb
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The SocialDexDeployer contract facilitates the creation of new ERC20 tokens, initializes Uniswap V3 liquidity pools, and manages associated fees. The audit identified several high-severity issues, including inconsistent fee calculations and a denial-of-service vulnerability in the salt generation mechanism. Medium-severity findings include an arbitrary address requirement for token deployment and a theoretical integer overflow risk. The contract relies on external Uniswap V3 components and a custom locker factory, whose security is assumed. Centralized control by the owner is present for key parameters.

2 High2 Medium2 Low1 Informational
Volume 24h
$29.7K
Liquidity
$1.43M
Price
$12.5200
Token Age
1y
Top 10 Holders
60.0%

Security Findings

2 High2 Med2 Low1 Info
High

Inconsistent Fee Calculation and Unused Variable

H-01The contract exhibits inconsistent logic for calculating and applying fees. The `protocolCut` is used in the calculation `(msg.value * protocolCut) / 1000`, implying it's a permille (parts per thousand). In contrast, `lpFeesCut` is passed directly to `liquidityLocker.deploy` without scaling, suggesting it might be interpreted as a percentage (0-100) or another unit by the external locker contract. This inconsistency can lead to misconfiguration, incorrect fee distribution, and unexpected economic outcomes. Additionally, the `taxRate` variable is declared and has an owner-only update function (`updateTaxRate`) but is never utilized within the contract's logic, making it dead code and potenti…
IssueThe contract exhibits inconsistent logic for calculating and applying fees. The `protocolCut` is used in the calculation `(msg.value * protocolCut) / 1000`, implying it's a permille (parts per thousand). In contrast, `lpFeesCut` is passed directly to `liquidityLocker.deploy` without scaling, suggesting it might be interpreted as a percentage (0-100) or another unit by the external locker contract. This inconsistency can lead to misconfiguration, incorrect fee distribution, and unexpected economic outcomes. Additionally, the `taxRate` variable is declared and has an owner-only update function (`updateTaxRate`) but is never utilized within the contract's logic, making it dead code and potenti…
FixStandardize all fee parameters to use a consistent unit (e.g., basis points or permille) and ensure all calculations reflect this. Clearly document the expected units for all fee-related variables. Either implement the intended use for `taxRate` or remove it to avoid confusion and reduce contract complexity.
StatusUnresolved
High

Denial of Service via `generateSalt` Function

H-02The `generateSalt` function contains an infinite loop (`for (uint256 i; ; i++)`) designed to find a suitable `salt` value. This loop is constrained by two conditions: `token < weth` and `token.code.length == 0`. The `token < weth` condition is arbitrary and significantly restricts the address space for valid tokens. If a suitable salt that satisfies both conditions is difficult to find (e.g., if `weth` is a very low address, or if many addresses below `weth` are already occupied), the loop could iterate excessively, causing the transaction to run out of gas. This leads to a denial of service for users attempting to use this function to predict token addresses.
IssueThe `generateSalt` function contains an infinite loop (`for (uint256 i; ; i++)`) designed to find a suitable `salt` value. This loop is constrained by two conditions: `token < weth` and `token.code.length == 0`. The `token < weth` condition is arbitrary and significantly restricts the address space for valid tokens. If a suitable salt that satisfies both conditions is difficult to find (e.g., if `weth` is a very low address, or if many addresses below `weth` are already occupied), the loop could iterate excessively, causing the transaction to run out of gas. This leads to a denial of service for users attempting to use this function to predict token addresses.
FixRe-evaluate the necessity of the `token < weth` condition. If it's not critical, remove it. If it is, consider implementing a more efficient salt generation mechanism or providing a maximum iteration limit to prevent indefinite loops and potential gas exhaustion. Users should be aware of the potential for high gas costs when using this function.
StatusUnresolved
Medium

Arbitrary `token < weth` Requirement for Token Deployment

M-01The `deployToken` function includes a `require(address(token) < weth, "Invalid salt");` check. This condition forces the newly deployed token's address (determined by `create2` with a salt) to be numerically smaller than the `weth` address. The purpose of this arbitrary restriction is unclear and introduces an unnecessary constraint on token deployment. It can significantly limit the available `create2` salts, making it harder and potentially more gas-intensive to find a valid salt, especially if `weth` is a low address or if the address space below `weth` becomes crowded.
IssueThe `deployToken` function includes a `require(address(token) < weth, "Invalid salt");` check. This condition forces the newly deployed token's address (determined by `create2` with a salt) to be numerically smaller than the `weth` address. The purpose of this arbitrary restriction is unclear and introduces an unnecessary constraint on token deployment. It can significantly limit the available `create2` salts, making it harder and potentially more gas-intensive to find a valid salt, especially if `weth` is a low address or if the address space below `weth` becomes crowded.
FixClarify the rationale behind the `token < weth` requirement. If it serves no critical security or functional purpose, it should be removed to allow for more flexible token deployment and reduce potential friction for users. If it is deemed necessary, document its purpose and consider alternative, less restrictive mechanisms.
StatusUnresolved
Medium

Potential Integer Overflow in `protocolFees` Calculation

M-02The calculation `uint256 protocolFees = (msg.value * protocolCut) / 1000;` could theoretically lead to an integer overflow. While Solidity 0.8.0+ prevents overflows by default, the intermediate product `msg.value * protocolCut` could exceed `type(uint256).max` if `msg.value` is extremely large (e.g., close to `type(uint256).max / protocolCut`). Although `protocolCut` is a `uint8` (max 255) and `msg.value` is typically limited by the amount of ETH sent in a transaction, this remains a theoretical vulnerability for extremely high `msg.value` scenarios.
IssueThe calculation `uint256 protocolFees = (msg.value * protocolCut) / 1000;` could theoretically lead to an integer overflow. While Solidity 0.8.0+ prevents overflows by default, the intermediate product `msg.value * protocolCut` could exceed `type(uint256).max` if `msg.value` is extremely large (e.g., close to `type(uint256).max / protocolCut`). Although `protocolCut` is a `uint8` (max 255) and `msg.value` is typically limited by the amount of ETH sent in a transaction, this remains a theoretical vulnerability for extremely high `msg.value` scenarios.
FixWhile the practical likelihood is low, consider reordering the multiplication and division to reduce the chance of overflow, for example, `(msg.value / 1000) * protocolCut` if `msg.value` is guaranteed to be a multiple of 1000, or use a safe math library if `protocolCut` could be larger. Alternatively, ensure `protocolCut` is always small enough that `type(uint256).max / protocolCut` is greater than any practically expected `msg.value`.
StatusUnresolved
Low

Typo in Supply Validation

L-01The `deployToken` function includes the validation `require(_supply >= _supply, "Invalid supply amount");`. This condition will always evaluate to `true` and therefore does not effectively validate the `_supply` parameter. It fails to prevent the deployment of tokens with a zero supply, which could lead to unexpected behavior or issues with subsequent liquidity provisioning.
IssueThe `deployToken` function includes the validation `require(_supply >= _supply, "Invalid supply amount");`. This condition will always evaluate to `true` and therefore does not effectively validate the `_supply` parameter. It fails to prevent the deployment of tokens with a zero supply, which could lead to unexpected behavior or issues with subsequent liquidity provisioning.
FixChange the validation to `require(_supply > 0, "Supply must be greater than zero");` to ensure that tokens are deployed with a positive initial supply.
StatusUnresolved
Low

Centralized Control by Owner

L-02The `SocialDexDeployer` contract inherits `Ownable`, granting the deployer (owner) significant control over critical parameters. The owner can update `taxCollector`, `liquidityLocker`, `defaultLockingPeriod`, `lpFeesCut`, and `taxRate`. This centralization introduces a single point of failure and a high degree of trust in the owner's actions, which could pose a risk if the owner's key is compromised or acts maliciously.
IssueThe `SocialDexDeployer` contract inherits `Ownable`, granting the deployer (owner) significant control over critical parameters. The owner can update `taxCollector`, `liquidityLocker`, `defaultLockingPeriod`, `lpFeesCut`, and `taxRate`. This centralization introduces a single point of failure and a high degree of trust in the owner's actions, which could pose a risk if the owner's key is compromised or acts maliciously.
FixFor enhanced security and decentralization, consider implementing a multi-signature wallet for ownership, or introducing a time-lock mechanism for sensitive parameter updates. This would add a layer of security and transparency to critical administrative actions.
StatusUnresolved
Info

Misleading Function Name

I-01The function `updateProtocolFees(uint8 newFee)` is named in a way that suggests it updates a general 'protocol fees' variable. However, its implementation `lpFeesCut = newFee;` reveals that it specifically updates the `lpFeesCut` variable. This naming inconsistency can lead to confusion for auditors, developers, and users, potentially resulting in misconfiguration.
IssueThe function `updateProtocolFees(uint8 newFee)` is named in a way that suggests it updates a general 'protocol fees' variable. However, its implementation `lpFeesCut = newFee;` reveals that it specifically updates the `lpFeesCut` variable. This naming inconsistency can lead to confusion for auditors, developers, and users, potentially resulting in misconfiguration.
FixRename the function to `updateLpFeesCut(uint8 newFee)` to accurately reflect its purpose and improve code clarity.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates a clear architecture for token deployment and liquidity management (7.1 Architecture), leveraging standard ERC20 and Uniswap V3 interfaces. However, several technical vulnerabilities were identified (7.2 Code Security). A significant concern is the potential for denial of service in the `generateSalt` function due to an infinite loop and a restrictive condition. Additionally, a theoretical integer overflow exists in the `protocolFees` calculation, though its practical exploitability is low. The contract's reliance on external Uniswap V3 components and a custom locker factory introduces dependencies (7.6 External) whose security is external to this audit.

GovernanceMedium4/10

The economic model presents a high risk due to inconsistent fee calculations (7.4 Economic). The `protocolCut` is applied as a permille, while `lpFeesCut` is passed directly, creating potential for misconfiguration and incorrect fee distribution. An arbitrary requirement that deployed token addresses be numerically less than the WETH address (7.4 Economic) introduces an unnecessary constraint, potentially hindering token creation. The contract utilizes an `Ownable` pattern, granting the owner centralized control over critical parameters (7.3 Access Control, 7.5 Governance), which is a single point of failure. An unused `taxRate` variable also contributes to economic ambiguity.

UpgradesLow8/10

The SocialDexDeployer contract is not designed as an upgradeable proxy (7.7 Upgrades). It is deployed as a standard, immutable contract. Therefore, there are no upgrade-specific vulnerabilities or risks associated with proxy patterns.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

60.0% in top 10
34.5% in wallets25.5% in contracts
Effective Concentration44.7%

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

$1.54M across 13 pairs
Uniswap v3WETHanalysed$1.43M92.3%AerodromeWETH$90.5K5.9%Uniswap v3WETH$21.2K1.4%Uniswap v4TRINI$4.8K0.3%Uniswap v4ETH$1.4K0.1%Hydrex CLAMMWETH$4320.0%
Show 4 more pairsShow less
Uniswap v4USDC$4190.0%Uniswap v4ARBME$480.0%AerodromeVIRTUAL$310.0%Uniswap v4CLAWNCH$130.0%

The 3 remaining pairs hold $7 between them and are not listed.

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 Holder88.0%
Top-3 Unlocked99.6%

Key Addresses

11 addresses
Deployer
0xc204…ab69
Unlocked LP Held By
0xce0b…62cc0x2994…38df0xa5a7…333a0x5d2a…ded70x1952…568c0x0068…9da00x7204…86fc0xc873…88a60x50d3…56500xed79…6636

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

What Raised This Score

7 factors
  • Top-10 concentration > 30% (60.0% total → 44.7% effective; 34.5% in EOAs, 25.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 88.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
  • LP top3 unlocked holders = 99.6% (independent LP — depth risk, pool = 92% of DEX liquidity)
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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

Related Audits

6 more on the record
Derive (DRV)Medium RiskVenice Deity (VVVEITY)Medium RiskB3Medium RiskHandlPay (HANDL)Medium RiskLienFi (LFI)Medium RiskMey Network (MEY)Medium Risk

Would You Like a More Detailed Audit of tokenbot?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit