Is BankrCoin (BNKR) Safe? Smart Contract Security Analysis

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2319

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: 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.

Category Ratings

TechnicalLow

9/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 ar

GovernanceMedium

6/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 parame

UpgradesLow

9/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.

LP Distribution

Top-1 Unlocked Holder98.1%

Top-3 Unlocked99.4%

What Raised This Score

7 factors

Top-10 concentration > 20% (32.2% total → 29.4% effective; 27.5% in EOAs, 4.7% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 98.1% (independent LP — depth risk, pool = 83% of DEX liquidity)
LP top3 unlocked holders = 99.4% (independent LP — depth risk, pool = 83% 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 Findings

6 total

1 High 1 Medium 3 Low 1 Info

H-01HighUnresolved

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.

Recommendation: 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.

M-01MediumUnresolved

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.

Recommendation: 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.

L-01LowUnresolved

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.

Recommendation: 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.

L-02LowUnresolved

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.

Recommendation: 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.

L-03LowUnresolved

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.

Recommendation: 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.

I-01InformationalUnresolved

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

Recommendation: 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.

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.

Is BankrCoin Safe? BNKR