Quantum Audit Logo

Is BankrCoin Safe?

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

BankrCoin BNKR
0x22af…6f3b
Base Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive 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. 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.

1 High1 Medium3 Low1 Informational
Volume 24h
$175.4K
Liquidity
$1.86M
Price
$0.0002513
Token Age
1y
Top 10 Holders
37.1%

Security Findings

1 High1 Med3 Low1 Info
High

Centralized Control over Token Deployment

H-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Medium

Arbitrary `weth` Address Requirement for Token Deployment

M-01The `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.
IssueThe `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.
FixRe-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.
StatusUnresolved
Low

Immutability of Key Economic Parameters

L-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Low

Immutability of `taxCollector` and `bundleFeeSwitch`

L-02The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Low

Unchecked Return Values of External Calls

L-03While 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.
IssueWhile 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.
FixFor 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.
StatusUnresolved
Info

`deprecated` Flag Lifecycle Management

I-01The `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.
IssueThe `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.
FixClarify 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.
StatusUnresolved

Category Ratings

TechnicalLow9/10

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

GovernanceMedium5/10

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.

UpgradesLow9/10

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.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

37.1% in top 10
30.5% in wallets6.7% in contracts
Effective Concentration33.1%

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

$2.07M across 24 pairs
Uniswap v3WETHanalysed$1.86M90.0%AerodromeWETH$86.0K4.2%Hydrex CLAMMWETH$63.7K3.1%Uniswap v4ETH$28.1K1.4%Uniswap v4USDC$15.3K0.7%Uniswap v4AIOCTO$3.8K0.2%
Show 4 more pairsShow less
Uniswap v3WETH$3.4K0.2%AerodromewBLT$1.7K0.1%AerodromeDRB$1.3K0.1%AerodromeEVRGROW$1.1K0.1%

The 14 remaining pairs hold $2.5K 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 Holder94.7%
Top-3 Unlocked97.7%

Key Addresses

11 addresses
Deployer
0x7246…288f
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.

What Raised This Score

7 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

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 record
o1.exchange (O)Medium RiskSurplus Intelligence (SURPLUS)Medium RiskRAWRMedium RiskCLAWNCHMedium RiskKittehCoin (MEOW)Medium RiskAlphabet Inc. (GOOGLC)Medium Risk

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