Quantum Audit Logo
Launch App

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

Is tokenbot Safe?

CLANKERBase
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance4/10Upgrades8/10Checks passed6 of 7Findings2 High · 2 Medium · 2 Low · 1 Info7
SummaryAI Copilot

The SocialDexDeployer contract facilitates the creation of new ERC20 tokens, initializes Uniswap V3 liquidity pools, and manages associated fees.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 88.0%
  • LP top3 unlocked holders = 99.6%
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 46 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
25.5%Contracts34.5%Wallets40.0%Everyone else
25.5%Contracts34.5%Wallets40.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
60.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking25.5%
  • Walletsanonymous holders, free to sell34.5%
  • Everyone elsethe rest of the supply40.0%
Effective concentrationwhat the score reads44.7%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$1.54M across 13 pairs
Show 4 more pairs

The 3 remaining pairs hold $7 between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$1.43MShare of depth92.3%
Top-1 Unlocked Holder88.0%
Top-3 Unlocked99.6%
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.

Security Findings

2 High2 Medium2 Low1 Info
High

Inconsistent Fee Calculation and Unused Variable

The 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…H-01

Issue

The 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…

Fix

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

Status

Unresolved

High

Denial of Service via generateSalt Function

The 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.H-02

Issue

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

Fix

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

Status

Unresolved

Medium

Arbitrary token < weth Requirement for Token Deployment

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Medium

Potential Integer Overflow in protocolFees Calculation

The 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.M-02

Issue

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

Fix

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

Status

Unresolved

Low

Typo in Supply Validation

The 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.L-01

Issue

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

Fix

Change the validation to require(_supply > 0, "Supply must be greater than zero"); to ensure that tokens are deployed with a positive initial supply.

Status

Unresolved

Low

Centralized Control by Owner

The 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.L-02

Issue

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

Fix

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

Status

Unresolved

Info

Misleading Function Name

The 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.I-01

Issue

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

Fix

Rename the function to updateLpFeesCut(uint8 newFee) to accurately reflect its purpose and improve code clarity.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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.

Governance4/10Medium risk

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.

Upgrades8/10Low risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to address the high-severity issues related to inconsistent fee calculations and the denial-of-service vulnerability in generateSalt immediately.

The arbitrary token < weth requirement should be re-evaluated for its necessity and potential negative impacts. All identified medium and low-severity findings, including the theoretical integer overflow and the typo in supply validation, should be resolved to enhance the contract's robustness and security. Furthermore, consider implementing a multi-signature wallet for owner functions to mitigate centralization risks.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age1y
Contract0x1bc0…1bcb
Deployer0xc204…ab69
Badge for your website
tokenbot security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202641Medium
  2. Aug 31, 202639Medium

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

Frequently Asked Questions

What is the CLANKER contract address?

The tokenbot (CLANKER) contract on Base is 0x1bc0c42215582d5a085795f4badbac3ff36d1bcb. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is tokenbot a scam?

Quantum Audit's risk score for tokenbot is 41/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; 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.

Is CLANKER liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.54M.

Who holds CLANKER?

As of Sep 4, 2026, the 10 largest holders own 60.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
DeriveDRV · Base41MediumVenice DeityVVVEITY · Base41MediumKairenceKAI · Base41MediumSPIKEBase41MediumB3Base42MediumHandlPayHANDL · Base40Medium

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 Is this your token? Publish your own audit on this page