Quantum Audit Logo

Is Bankr Kat a Scam?

Early-stage security check — honeypot & rug-pull analysis

Bankr Kat BANKAT
0x3351…8ba3
Base
Not verifiedThis 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.
Last checked today 1 audit on record New Launch · 18h old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DopplerERC20V1 contract serves as an upgradeable ERC20 token with integrated vesting functionalities and a temporary balance limit mechanism. The audit identified a High-severity issue related to centralized control, two Medium-severity issues concerning token distribution concentration and potential gas inefficiencies, one Low-severity issue regarding event logging, and one Informational finding about initialization complexity. The contract generally demonstrates good code quality, leveraging battle-tested Solady libraries, but critical roles and initial token distribution parameters warrant careful review and potential mitigation strategies.

1 High2 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (18h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$402.3K
Liquidity
$50.1K
Price
$0.0000008055
Token Age
18h
Top 10 Holders
0.0%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control and Single Points of Failure

H-01The `owner` and `controller` roles in the DopplerERC20V1 contract possess significant power, creating single points of failure. The `owner` can `lockPool`, `unlockPool`, and `updateTokenURI`, which directly impacts token distribution and the balance limit mechanism. The `controller` can `disableBalanceLimit` entirely. If these accounts are compromised, an attacker could manipulate token distribution, bypass balance limits, or alter token metadata, leading to severe financial and reputational damage to the protocol. This directly impacts 7.3 Access Control and 7.5 Governance.
IssueThe `owner` and `controller` roles in the DopplerERC20V1 contract possess significant power, creating single points of failure. The `owner` can `lockPool`, `unlockPool`, and `updateTokenURI`, which directly impacts token distribution and the balance limit mechanism. The `controller` can `disableBalanceLimit` entirely. If these accounts are compromised, an attacker could manipulate token distribution, bypass balance limits, or alter token metadata, leading to severe financial and reputational damage to the protocol. This directly impacts 7.3 Access Control and 7.5 Governance.
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for both the `owner` and `controller` roles to require multiple approvals for critical operations. Consider introducing a time-lock mechanism for highly sensitive functions (e.g., `disableBalanceLimit`, `lockPool`) to provide a window for community review or emergency intervention before changes take effect.
StatusUnresolved
Medium

High Pre-Mint Limits Leading to Concentration Risk

M-01The constants `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are both set to `0.8 ether`. When used in the `initialize` function's calculations (e.g., `initialSupply * MAX_PRE_MINT_PER_ADDRESS_WAD / WAD`), this effectively allows a single beneficiary to receive up to 80% of the total initial supply as pre-minted tokens, and the total pre-minted amount can also be up to 80% of the initial supply. This high percentage could lead to a highly concentrated token distribution among a few addresses, potentially impacting decentralization, market liquidity, and susceptibility to manipulation. This impacts 7.4 Economic.
IssueThe constants `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are both set to `0.8 ether`. When used in the `initialize` function's calculations (e.g., `initialSupply * MAX_PRE_MINT_PER_ADDRESS_WAD / WAD`), this effectively allows a single beneficiary to receive up to 80% of the total initial supply as pre-minted tokens, and the total pre-minted amount can also be up to 80% of the initial supply. This high percentage could lead to a highly concentrated token distribution among a few addresses, potentially impacting decentralization, market liquidity, and susceptibility to manipulation. This impacts 7.4 Economic.
FixReview these pre-mint limits to ensure they align with the project's desired token distribution model. If a more decentralized distribution is intended, consider significantly reducing these percentages. Clearly document the rationale if this high concentration is an intentional design choice.
StatusUnresolved
Medium

Potential Gas Inefficiency in `_releaseAllFor` and `getScheduleIdsOf`

M-02The `_scheduleIdsOf` mapping stores an array of `scheduleId`s for each beneficiary. The `_releaseAllFor` function iterates through this array to compute and release tokens for all associated vesting schedules. If a beneficiary accumulates a very large number of individual vesting schedules, this iteration could become gas-intensive, potentially leading to transaction failures or high gas costs for the beneficiary when attempting to claim all their vested tokens. Similarly, the `getScheduleIdsOf` view function could also be expensive to call off-chain if the array is large. This impacts 7.2 Code Security and 7.8 Operations.
IssueThe `_scheduleIdsOf` mapping stores an array of `scheduleId`s for each beneficiary. The `_releaseAllFor` function iterates through this array to compute and release tokens for all associated vesting schedules. If a beneficiary accumulates a very large number of individual vesting schedules, this iteration could become gas-intensive, potentially leading to transaction failures or high gas costs for the beneficiary when attempting to claim all their vested tokens. Similarly, the `getScheduleIdsOf` view function could also be expensive to call off-chain if the array is large. This impacts 7.2 Code Security and 7.8 Operations.
FixConsider imposing a reasonable maximum limit on the number of vesting schedules that can be assigned to a single beneficiary. Alternatively, for `_releaseAllFor`, provide an option for beneficiaries to release tokens for specific schedule IDs rather than requiring an iteration over all schedules. For `getScheduleIdsOf`, if it's primarily for off-chain display, ensure front-end applications handle potential gas costs or implement pagination if feasible.
StatusUnresolved
Low

Incomplete Event Logging for Balance Limit Disablement

L-01The `BalanceLimitDisabled` event, emitted when the balance limit is deactivated by the `controller`, only includes a boolean value (`false`) indicating that it's disabled. It does not log the `maxBalanceLimit` or `balanceLimitEnd` values that were active prior to disablement. This omission makes it more challenging for off-chain monitoring and historical analysis to track the exact parameters of the balance limit when it was active and subsequently disabled. This impacts 7.8 Operations.
IssueThe `BalanceLimitDisabled` event, emitted when the balance limit is deactivated by the `controller`, only includes a boolean value (`false`) indicating that it's disabled. It does not log the `maxBalanceLimit` or `balanceLimitEnd` values that were active prior to disablement. This omission makes it more challenging for off-chain monitoring and historical analysis to track the exact parameters of the balance limit when it was active and subsequently disabled. This impacts 7.8 Operations.
FixEnhance the `BalanceLimitDisabled` event to include the `maxBalanceLimit` and `balanceLimitEnd` values that were in effect when the balance limit was disabled. This provides a more complete audit trail for the state changes.
StatusUnresolved
Info

Complex Initialization Function

I-01The `initialize` function takes a large number of parameters, including multiple arrays for vesting schedules and beneficiaries. While necessary for comprehensive initial setup, this complexity increases the risk of human error during deployment, where incorrect parameter ordering or values could lead to unintended configurations. This impacts 7.8 Operations.
IssueThe `initialize` function takes a large number of parameters, including multiple arrays for vesting schedules and beneficiaries. While necessary for comprehensive initial setup, this complexity increases the risk of human error during deployment, where incorrect parameter ordering or values could lead to unintended configurations. This impacts 7.8 Operations.
FixEnsure thorough testing and multiple independent reviews of the deployment script and all initialization parameters. Consider creating a dedicated deployment script that clearly labels and validates each parameter to minimize the chance of errors. If feasible, for future versions, explore breaking down the initialization into smaller, more focused functions, though this might not be practical for a single `initializer` call.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes Solady libraries (ERC20, Ownable, ERC20Votes, Initializable), which generally contribute to robust code security and gas efficiency. The vesting logic appears sound, calculating available amounts correctly and preventing reentrancy by updating state before transfers. However, the `_releaseAllFor` function, which iterates through a beneficiary's vesting schedules, could become gas-intensive if a beneficiary accumulates a very large number of schedules (7.2 Code Security). Additionally, the `owner` and `controller` roles hold significant power over critical functions like pool locking and balance limit disabling, representing a centralized control risk (7.3 Access Control).

GovernanceHigh2/10

The contract's economic model allows for a highly concentrated initial token distribution. The `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` constants are set to 80% of the initial supply, enabling a single address to receive up to 80% of the total pre-minted tokens, and the total pre-minted amount to be up to 80% of the initial supply (7.4 Economic). This could lead to significant centralization of token ownership. Furthermore, the `owner` and `controller` roles possess substantial governance power, including the ability to disable the balance limit and manage the token pool, creating single points of failure (7.5 Governance).

UpgradesLow7/10

The contract is designed as an upgradeable implementation, correctly using Solady's `Initializable` and calling `_disableInitializers()` in its constructor. This adheres to the standard proxy pattern for upgrade safety (7.7 Upgrades). However, the contract's storage layout includes dynamic arrays (`vestingSchedules`) and complex mappings (`vestingOf`, `_scheduleIdsOf`). While the current implementation is sound, future upgrades must carefully manage storage slot allocation to avoid collisions or data corruption, especially if new state variables are introduced before these complex structures.

Security Checklist

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

Liquidity Depth

$50.1K across 7 pairs
Uniswap v4BNKRanalysed$50.1K99.9%Uniswap v4USDC$350.1%Uniswap v4USDC$230.0%Uniswap v4ETH$80.0%

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 Holder54.0%
Top-3 Unlocked92.1%

Key Addresses

7 addresses
Deployer
0x2fbf…ec65
Unlocked LP Held By
0xa6f3…e1680x0dad…d24e0x3e44…b36c0xc43a…d5160x2fce…75ae0x30be…3118

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

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 54.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 92.1% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 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
Coinbase Wrapped XRP (CBXRP)High RiskZestHigh RiskOMI Token (OMI)High RiskSilencio (SLC)High RiskRibbita by Virtuals (TIBBIR)High RiskPromptHigh Risk

Would You Like a More Detailed Audit of Bankr Kat?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit