Is MineBean (BEAN) Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High3 Med1 Low

Critical

Incorrect `beanIsToken0` Assignment in `setPoolId`

C-01The `setPoolId` function, which configures the Uniswap V4 pool for TWAP calculations, unconditionally sets `beanIsToken0 = false`. This assumes that the Bean token will always be `token1` in any configured pool. If the actual pool created via `PoolManager.initialize()` has Bean as `token0`, the `getTWAPAmountOut` function will perform an inverted price calculation, leading to severe economic exploits, incorrect pricing, and potential loss of funds for users or protocols relying on this oracle.

IssueThe `setPoolId` function, which configures the Uniswap V4 pool for TWAP calculations, unconditionally sets `beanIsToken0 = false`. This assumes that the Bean token will always be `token1` in any configured pool. If the actual pool created via `PoolManager.initialize()` has Bean as `token0`, the `getTWAPAmountOut` function will perform an inverted price calculation, leading to severe economic exploits, incorrect pricing, and potential loss of funds for users or protocols relying on this oracle.

FixThe `beanIsToken0` flag must be correctly determined based on the actual `PoolKey` provided. Modify `setPoolId` to compare `address(this)` with `_poolId.token0` or `_poolId.token1` to accurately set `beanIsToken0`. For example: `beanIsToken0 = address(this) == _poolId.token0;`.

StatusUnresolved

High

High Centralization Risk via Owner Privileges

H-01The contract uses the `Ownable` pattern, granting the deployer (owner) exclusive control over critical functions such as `setMinter`, `freezeMinter`, `removeLimits`, and `setPoolId`. A compromised owner key or a malicious owner could lead to unauthorized minting (by setting a malicious minter), disabling essential transfer restrictions, or misconfiguring the core oracle, posing a single point of failure and significant trust risk.

IssueThe contract uses the `Ownable` pattern, granting the deployer (owner) exclusive control over critical functions such as `setMinter`, `freezeMinter`, `removeLimits`, and `setPoolId`. A compromised owner key or a malicious owner could lead to unauthorized minting (by setting a malicious minter), disabling essential transfer restrictions, or misconfiguring the core oracle, posing a single point of failure and significant trust risk.

FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) for the owner address to require multiple approvals for critical operations. For highly sensitive functions like `freezeMinter` or `removeLimits`, explore integrating a time-lock mechanism or a decentralized governance process to introduce a delay and community oversight.

StatusUnresolved

High

Short TWAP Window Susceptible to Manipulation

H-02The `getOracleTWAP` function calculates the Time-Weighted Average Price using a simple arithmetic mean of only 5 tick snapshots. While `MIN_SNAPSHOT_INTERVAL` (6 blocks) provides some delay between updates, a short window of 5 snapshots makes the TWAP more susceptible to manipulation. An attacker could potentially influence a significant portion of the snapshots within a relatively short period, leading to a manipulated TWAP price that could be exploited by dependent protocols.

IssueThe `getOracleTWAP` function calculates the Time-Weighted Average Price using a simple arithmetic mean of only 5 tick snapshots. While `MIN_SNAPSHOT_INTERVAL` (6 blocks) provides some delay between updates, a short window of 5 snapshots makes the TWAP more susceptible to manipulation. An attacker could potentially influence a significant portion of the snapshots within a relatively short period, leading to a manipulated TWAP price that could be exploited by dependent protocols.

FixIncrease the number of snapshots used for the TWAP calculation (e.g., 10-20 or more) to provide a longer averaging window, making manipulation more costly and difficult. Additionally, evaluate if a longer `MIN_SNAPSHOT_INTERVAL` or a more robust averaging method (e.g., weighted average, median) would enhance resilience against price attacks.

StatusUnresolved

Medium

Irreversible `removeLimits` Function

M-01The `removeLimits` function, callable by the owner, permanently sets the `limited` flag to `false`. This action is irreversible and disables the `require(_isBean[to] || _isBean[from], "Not Allowed");` check within the `_update` function. This restriction is intended to control transfers involving AMM pools. Removing this limit permanently could have unintended consequences if the project's long-term strategy requires re-enabling such controls or if the initial restriction was critical for specific economic models.

IssueThe `removeLimits` function, callable by the owner, permanently sets the `limited` flag to `false`. This action is irreversible and disables the `require(_isBean[to] || _isBean[from], "Not Allowed");` check within the `_update` function. This restriction is intended to control transfers involving AMM pools. Removing this limit permanently could have unintended consequences if the project's long-term strategy requires re-enabling such controls or if the initial restriction was critical for specific economic models.

FixIf the `limited` flag is intended to be a configurable setting that might need to be toggled, consider making it reversible. If it is a one-time transition, ensure that the implications of permanently removing this restriction are fully understood, documented, and align with the project's long-term vision. Clearly communicate this irreversible action to users and stakeholders.

StatusUnresolved

Medium

Ambiguous `_isBean` Whitelist in `_update`

M-02The `_update` override includes a conditional `require(_isBean[to] || _isBean[from], "Not Allowed");` when `limited` is true and neither `from` nor `to` is excluded. The `_isBean` mapping is populated only once during the constructor with a fixed list of addresses. This design implies that only explicitly whitelisted 'Bean' addresses or excluded addresses can interact with AMM pools when `limited` is true. This could lead to unexpected transfer failures for legitimate users who are not on these lists, hindering liquidity provision, trading, or general token utility.

IssueThe `_update` override includes a conditional `require(_isBean[to] || _isBean[from], "Not Allowed");` when `limited` is true and neither `from` nor `to` is excluded. The `_isBean` mapping is populated only once during the constructor with a fixed list of addresses. This design implies that only explicitly whitelisted 'Bean' addresses or excluded addresses can interact with AMM pools when `limited` is true. This could lead to unexpected transfer failures for legitimate users who are not on these lists, hindering liquidity provision, trading, or general token utility.

FixClarify the exact purpose and scope of the `_isBean` whitelist. If it's intended to restrict AMM interactions, ensure that all legitimate participants (e.g., liquidity providers, traders) can be added to this list or that the restriction is clearly communicated. Consider if this restriction is truly necessary or if it introduces unnecessary friction and complexity for users.

StatusUnresolved

Medium

TWAP Not Ready for Extended Periods

M-03The `getOracleTWAP` function reverts with `TWAPNotReady` if fewer than 5 snapshots have been recorded. If AMM interactions (transfers to/from the pool) are infrequent or the `MIN_SNAPSHOT_INTERVAL` is too long, the TWAP oracle might not be ready for extended periods. This could prevent dependent protocols from functioning correctly, accessing a reliable price feed, or executing critical operations that rely on the TWAP.

IssueThe `getOracleTWAP` function reverts with `TWAPNotReady` if fewer than 5 snapshots have been recorded. If AMM interactions (transfers to/from the pool) are infrequent or the `MIN_SNAPSHOT_INTERVAL` is too long, the TWAP oracle might not be ready for extended periods. This could prevent dependent protocols from functioning correctly, accessing a reliable price feed, or executing critical operations that rely on the TWAP.

FixAssess the expected frequency of AMM interactions and adjust `MIN_SNAPSHOT_INTERVAL` and the number of required snapshots accordingly to ensure the TWAP is consistently available. Consider implementing a fallback mechanism or a grace period for protocols consuming the TWAP, or allow for a TWAP calculation with fewer than 5 snapshots (e.g., using the available average) if the staleness risk is acceptable for the use case.

StatusUnresolved

Low

Gas Inefficiency in `_updateTickSnapshot` Trigger

L-01The `_updateTickSnapshot` function is triggered on every transfer to or from an AMM pool via the `_update` override. While `MIN_SNAPSHOT_INTERVAL` prevents actual state updates frequently, the `block.number` check and the `extsload` call to `poolManager.getSlot0(poolId)` still execute on every such transfer. The `extsload` operation can be gas-intensive, potentially adding unnecessary gas costs to AMM-related transfers even when no snapshot update occurs.

IssueThe `_updateTickSnapshot` function is triggered on every transfer to or from an AMM pool via the `_update` override. While `MIN_SNAPSHOT_INTERVAL` prevents actual state updates frequently, the `block.number` check and the `extsload` call to `poolManager.getSlot0(poolId)` still execute on every such transfer. The `extsload` operation can be gas-intensive, potentially adding unnecessary gas costs to AMM-related transfers even when no snapshot update occurs.

FixEvaluate the gas cost impact of the `extsload` call on every AMM interaction. If significant, consider optimizing the trigger condition for `_updateTickSnapshot` to only call `getSlot0` when a snapshot update is actually due, or explore alternative mechanisms for updating snapshots, such as a dedicated keeper bot, to offload this cost from user transactions.

StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract utilizes robust OpenZeppelin ERC20 and Uniswap V4 libraries for core functionalities (7.2 Code Security). The TWAP oracle mechanism incorporates a `MIN_SNAPSHOT_INTERVAL` to prevent rapid updates (7.4 Economic). However, a critical flaw exists in the `setPoolId` function where `beanIsToken0` is unconditionally set to `false`, potentially leading to inverted price calculations if BEAN is `token0` in the actual pool (7.6 External). The TWAP relies on a short 5-snapshot window, making it susceptible to manipulation (7.4 Economic). Additionally, the `_update` override's `_isBean` whitelist could cause unexpected transfer failures for users interacting with AMM pools (7.3 Access Control).

GovernanceMedium4/10

The contract implements a `MAX_SUPPLY` and a `minter` role, providing a controlled token issuance mechanism (7.4 Economic). The owner can `freezeMinter` and `removeLimits`, which are one-way actions, enhancing predictability once executed (7.8 Operations). However, the `Ownable` pattern grants the deployer extensive control over critical parameters, including the minter, transfer limits, and pool configuration, posing a high centralization risk (7.3 Access Control). The `removeLimits` function permanently disables a transfer restriction, which could have unintended long-term consequences (7.5 Governance).

UpgradesMedium4/10

The contract is not designed as an upgradeable proxy. Therefore, it does not introduce any upgrade-specific risks (7.7 Upgrades). Any changes to the contract's logic would require a new deployment and migration of assets.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionFail

Liquidity LockedPass

Not a ProxyPass

Holder Composition

88.2% in top 10

1.6% in wallets86.6% in contracts

Effective Concentration36.3%

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

$30.5K across 4 pairs

Uniswap v4ETHanalysed$30.4K Uniswap v3USDC$50 Uniswap v4USDC$38 Uniswap v4ETH$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

LP Locked96.0% · GoPlus SafeToken Locker

Top-1 Unlocked Holder2.9%

Key Addresses

10 addresses

Deployer

0x837c…7c21

Unlocked LP Held By

0xeb5c…8be50x7a66…d2720x2bb3…bff60xd1c7…4a280x0eab…73f20xb525…ae5e0xf5d2…23970x8876…74e90xb270…9f6f

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

What Raised This Score

7 factors

Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (88.2% total → 36.3% effective; 1.6% in EOAs, 86.6% in contracts — moderate)
Liquidity < $50k ($30,472 across 4 pairs — thin market)
1 Critical finding(s) from audit
2 High finding(s) from audit
3 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

Not Signed In

Is MineBean Safe?

Security Findings

Incorrect `beanIsToken0` Assignment in `setPoolId`

High Centralization Risk via Owner Privileges

Short TWAP Window Susceptible to Manipulation

Irreversible `removeLimits` Function

Ambiguous `_isBean` Whitelist in `_update`

TWAP Not Ready for Extended Periods

Gas Inefficiency in `_updateTickSnapshot` Trigger

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of MineBean?