Quantum Audit Logo
Launch App

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

Is BankrCoin Safe?

BNKRBase
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical9/10Governance5/10Upgrades9/10Checks passed4 of 5Findings1 High · 1 Medium · 3 Low · 1 Info6
SummaryAI Copilot

The Clanker protocol consists of a factory contract (Clanker) for deploying new ERC20 Token contracts, creating Uniswap V3 liquidity pools, and locking LP tokens.

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 = 94.7%
  • LP top3 unlocked holders = 97.7%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 3 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (37.1% total → 33.1% effective; 30.5% in EOAs, 6.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 94.7% (independent LP — depth risk, pool = 90% of DEX liquidity)
  • LP top3 unlocked holders = 97.7% (independent LP — depth risk, pool = 90% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 3 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 44 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
6.7%Contracts30.5%Wallets62.9%Everyone else
6.7%30.5%Wallets62.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
37.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking6.7%
  • Walletsanonymous holders, free to sell30.5%
  • Everyone elsethe rest of the supply62.9%
Effective concentrationwhat the score reads33.1%
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$2.07M across 24 pairs
Show 4 more pairs

The 14 remaining pairs hold $2.5K 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.86MShare of depth90.0%
Top-1 Unlocked Holder94.7%
Top-3 Unlocked97.7%
Unlocked LP held by
0x4f97…60230xc8c6…535a0x5581…06b10xbbd9…f1130x5ff7…7e5e0x3ce6…a2bc0xf197…ad5b0xde9f…1e7c0x7d27…fd550x72cd…2d93

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

Security Findings

1 High1 Medium3 Low1 Info
High

Centralized Control over Token Deployment

The deployToken function, which is responsible for creating new Token contracts, establishing Uniswap V3 liquidity pools, and locking LP tokens, is restricted to onlyOwner. This means that only the contract owner can initiate the creation of new tokens and their associated liquidity. This centralization introduces a single point of failure, limits the protocol's decentralization, and could lead to censorship or bottlenecks in token creation.H-01

Issue

The deployToken function, which is responsible for creating new Token contracts, establishing Uniswap V3 liquidity pools, and locking LP tokens, is restricted to onlyOwner. This means that only the contract owner can initiate the creation of new tokens and their associated liquidity. This centralization introduces a single point of failure, limits the protocol's decentralization, and could lead to censorship or bottlenecks in token creation.

Fix

Consider decentralizing the token deployment process. Options include: 1) Removing the onlyOwner modifier to allow anyone to deploy tokens (if appropriate for the protocol's design). 2) Implementing a multi-signature wallet or a decentralized autonomous organization (DAO) for approving token deployments. 3) Introducing a whitelisting mechanism for trusted deployers, managed by a multi-sig or DAO.

Status

Unresolved

Medium

Arbitrary weth Address Requirement for Token Deployment

The deployToken function includes a require(address(token) < weth, "Invalid salt"); condition. This forces the deployed token's address (determined by create2 with a user-provided _salt) to be numerically less than the weth address. This arbitrary requirement can significantly increase the computational burden and gas costs for users attempting to find a valid _salt that satisfies this condition. In some scenarios, it might even make it practically impossible to deploy a token if weth has a very low address, hindering legitimate token creation.M-01

Issue

The deployToken function includes a require(address(token) < weth, "Invalid salt"); condition. This forces the deployed token's address (determined by create2 with a user-provided _salt) to be numerically less than the weth address. This arbitrary requirement can significantly increase the computational burden and gas costs for users attempting to find a valid _salt that satisfies this condition. In some scenarios, it might even make it practically impossible to deploy a token if weth has a very low address, hindering legitimate token creation.

Fix

Re-evaluate the necessity of the address(token) < weth requirement. If it serves no critical security or functional purpose, it should be removed to improve usability and reduce deployment costs. If there is a specific architectural reason, consider alternative, less restrictive methods to achieve the desired consistency, or provide tools to assist users in generating valid salts efficiently.

Status

Unresolved

Low

Immutability of Key Economic Parameters

The defaultLockingPeriod and lpFeesCut variables are set during the constructor and are not provided with setter functions. This makes them immutable after deployment. While immutability can offer predictability, the lack of flexibility might become an issue if market conditions, regulatory requirements, or protocol strategies necessitate adjustments to these parameters in the future. This could lead to the protocol becoming rigid or requiring a full redeployment to adapt.L-01

Issue

The defaultLockingPeriod and lpFeesCut variables are set during the constructor and are not provided with setter functions. This makes them immutable after deployment. While immutability can offer predictability, the lack of flexibility might become an issue if market conditions, regulatory requirements, or protocol strategies necessitate adjustments to these parameters in the future. This could lead to the protocol becoming rigid or requiring a full redeployment to adapt.

Fix

Consider adding owner-controlled setter functions for defaultLockingPeriod and lpFeesCut. These setters should include appropriate access control (e.g., onlyOwner) and potentially a timelock or a multi-signature approval mechanism for sensitive changes to ensure security and provide a grace period for users to react.

Status

Unresolved

Low

Immutability of taxCollector and bundleFeeSwitch

The taxCollector address is set in the constructor and is immutable. If this address is initially set incorrectly (e.g., to a non-existent address, a contract that cannot receive ETH, or a malicious address), the fee collection mechanism (bundleFeeSwitch) could be permanently broken or funds could be misdirected. Similarly, the bundleFeeSwitch itself is a public variable without a setter, making its state (whether fees are collected or not) immutable after deployment. This lack of configurability for a critical economic parameter limits the protocol's adaptability.L-02

Issue

The taxCollector address is set in the constructor and is immutable. If this address is initially set incorrectly (e.g., to a non-existent address, a contract that cannot receive ETH, or a malicious address), the fee collection mechanism (bundleFeeSwitch) could be permanently broken or funds could be misdirected. Similarly, the bundleFeeSwitch itself is a public variable without a setter, making its state (whether fees are collected or not) immutable after deployment. This lack of configurability for a critical economic parameter limits the protocol's adaptability.

Fix

Implement owner-controlled setter functions for both taxCollector and bundleFeeSwitch. For taxCollector, ensure the setter includes input validation (e.g., require(newTaxCollector != address(0))). For both, consider adding a timelock or multi-signature approval for changes to enhance security and provide transparency.

Status

Unresolved

Low

Unchecked Return Values of External Calls

While the call to taxCollector explicitly checks its success, some other external calls to Uniswap V3 components (e.g., uniswapV3Factory.createPool, positionManager.mint, liquidityLocker.deploy, ILocker(lockerAddress).initializer) and ISwapRouter.exactInputSingle do not explicitly check their return values. Although these are typically interface calls that revert on failure, explicit checks or try/catch blocks can provide additional robustness and clearer error handling, especially for calls to external, potentially less trusted, contracts.L-03

Issue

While the call to taxCollector explicitly checks its success, some other external calls to Uniswap V3 components (e.g., uniswapV3Factory.createPool, positionManager.mint, liquidityLocker.deploy, ILocker(lockerAddress).initializer) and ISwapRouter.exactInputSingle do not explicitly check their return values. Although these are typically interface calls that revert on failure, explicit checks or try/catch blocks can provide additional robustness and clearer error handling, especially for calls to external, potentially less trusted, contracts.

Fix

For critical external calls, consider adding explicit checks for return values or wrapping them in try/catch blocks to handle potential failures gracefully. This can improve the contract's resilience against unexpected behavior from external dependencies.

Status

Unresolved

Info

deprecated Flag Lifecycle Management

The deprecated flag, controllable by the owner, prevents new token deployments when set to true. However, there is no mechanism to un-deprecate the contract. While this might be an intentional design choice for a final shutdown, it means that once deprecated, the factory cannot resume its primary function without a new deployment. The contract also does not specify how existing tokens or liquidity pools are affected or managed after deprecation.I-01

Issue

The deprecated flag, controllable by the owner, prevents new token deployments when set to true. However, there is no mechanism to un-deprecate the contract. While this might be an intentional design choice for a final shutdown, it means that once deprecated, the factory cannot resume its primary function without a new deployment. The contract also does not specify how existing tokens or liquidity pools are affected or managed after deprecation.

Fix

Clarify the intended lifecycle of the deprecated flag. If temporary deprecation is desired, implement a function to revert the flag. If permanent, ensure documentation clearly states this. Additionally, consider adding logic or documentation regarding the implications of deprecation on existing deployed tokens and their liquidity.

Status

Unresolved

Analysis

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

The Clanker protocol consists of a factory contract (Clanker) for deploying new ERC20 Token contracts, creating Uniswap V3 liquidity pools, and locking LP tokens. The audit identified a High-severity centralization risk due to the onlyOwner restriction on token deployment, a Medium-severity technical design flaw related to an arbitrary weth address requirement, and several Low-severity issues concerning parameter immutability and external call handling. The contract leverages established libraries like OpenZeppelin and Uniswap V3, contributing to its foundational security. Recommendations focus on decentralizing control, improving parameter flexibility, and enhancing robustness.

Technical9/10Low risk

The technical architecture (7.1) utilizes a factory pattern with create2 for predictable token addresses and integrates with Uniswap V3 for liquidity. Code security (7.2) benefits from Solidity 0.8+ overflow protection and OpenZeppelin libraries. However, a notable technical issue (M-01) is the arbitrary address(token) < weth requirement, which can complicate token deployment. External interactions (7.6) with Uniswap V3 and a liquidity locker are extensive, and while generally robust, some minor external call return values are not explicitly checked (L-03).

Governance5/10Medium risk

Access control (7.3) is heavily centralized, with the deployToken function restricted to onlyOwner (H-01), giving the contract owner sole control over new token creation and liquidity provisioning. This introduces a significant single point of failure and limits decentralization. Economic parameters (7.4) such as defaultLockingPeriod, lpFeesCut, and bundleFeeSwitch are immutable after deployment (L-01, L-02), lacking flexibility for future adjustments. The taxCollector address is also immutable, posing a risk if it's set incorrectly (L-02). Governance (7.5) is non-existent beyond the owner's control.

Upgrades9/10Low risk

The Clanker contract is not designed as an upgradeable proxy, meaning its logic is immutable once deployed. The Token contracts are deployed via create2 and are also immutable. Therefore, there are no upgrade safety issues (7.7) to consider for this specific implementation.

Final RecommendationWhat to do about this score

To enhance the security and decentralization of the Clanker protocol, it is strongly recommended to address the identified centralization risks.

Consider implementing a more decentralized token deployment mechanism, such as a permissionless factory or a multi-signature governance system for critical operations. Review and introduce flexibility for key economic parameters like defaultLockingPeriod and fee rates, allowing them to be adjusted through a secure, controlled process. Additionally, evaluate the necessity and implications of the address(token) < weth requirement, as it introduces unnecessary complexity and potential friction for users.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age1y
Contract0x22af…6f3b
Deployer0x7246…288f
Badge for your website
BankrCoin 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, 202625Low
  2. Jul 23, 202619Low

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

Frequently Asked Questions

Is BankrCoin a scam?

BankrCoin's status is not indicative of an outright scam based on available data. Its contract is verified, ownership is renounced, and no mint function exists, which are strong positive indicators against common scam tactics like malicious code or supply inflation. While liquidity is not locked, posing a risk, the low overall risk score of 18/100 suggests a generally positive security evaluation.

Is BankrCoin safe to buy?

Investing in BankrCoin involves inherent risks. The primary concern is that liquidity is not locked, meaning the substantial liquidity pool could potentially be removed, leading to a drastic price drop. Additionally, the concentration of 33.2% of the supply among the top 10 holders presents a risk of market manipulation. Investors should weigh these factors against the low risk score and conduct personal due diligence.

Has BankrCoin been audited?

BankrCoin's contract is verified, making its code publicly viewable for transparency. However, contract verification differs from a professional security audit, which involves a deep, independent review for vulnerabilities. The provided information does not confirm that BankrCoin has undergone such an audit. Investors should understand that verification alone does not guarantee security against all potential flaws.

Related Audits

6 more on the recordAll audits
o1.exchangeO · Base25LowSurplus IntelligenceSURPLUS · Base26LowRAWRBase26LowArcadiaAAA · Base24LowCLAWNCHBase23LowKittehCoinMEOW · Base23Low

Would You Like a More Detailed Audit of BankrCoin?

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