Quantum Audit Logo

Is Bedrock Safe?

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

Is this your token? Publish your own audit on this page →

Bedrock BR
0xff7d…6b41
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The Bedrock token contract implements ERC20 with burnable functionality and robust access control. It features a centralized minting capability and a unique freezing mechanism allowing administrators to restrict user transfers to a designated recipient. While the code is well-structured, the extensive administrative powers introduce significant centralization risks, particularly concerning potential censorship or fund seizure.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$1.9K
Liquidity
$1.59M
Price
$0.3073
Token Age
1y
Top 10 Holders
84.3%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Centralized Control and Potential for Censorship/Seizure

C-01The `DEFAULT_ADMIN_ROLE` and `FREEZER_ROLE` possess extensive power, including the ability to freeze user accounts and dictate that frozen funds can only be transferred to a specific `freezeToRecipient` address. This introduces a high degree of centralization and potential for censorship or even seizure of funds if the `freezeToRecipient` is maliciously controlled or if the role holders act maliciously. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
IssueThe `DEFAULT_ADMIN_ROLE` and `FREEZER_ROLE` possess extensive power, including the ability to freeze user accounts and dictate that frozen funds can only be transferred to a specific `freezeToRecipient` address. This introduces a high degree of centralization and potential for censorship or even seizure of funds if the `freezeToRecipient` is maliciously controlled or if the role holders act maliciously. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
FixImplement multi-signature control for critical roles, especially `DEFAULT_ADMIN_ROLE` and `FREEZER_ROLE`. Consider a time-lock for sensitive operations like changing `freezeToRecipient`. Clearly communicate these powers and their implications to all users.
StatusUnresolved
High

Unlimited Minting Capability

H-01The `MINTER_ROLE` has the ability to mint an arbitrary amount of new tokens via the `mint` function. While this might be an intended feature for token supply management, it poses a significant economic risk as uncontrolled or malicious minting can lead to hyperinflation and devaluation of the token. (7.4 Economic)
IssueThe `MINTER_ROLE` has the ability to mint an arbitrary amount of new tokens via the `mint` function. While this might be an intended feature for token supply management, it poses a significant economic risk as uncontrolled or malicious minting can lead to hyperinflation and devaluation of the token. (7.4 Economic)
FixImplement a minting cap, a rate limit, or a multi-signature approval process for minting operations. Ensure the `MINTER_ROLE` is managed with the highest security standards, ideally by a multi-signature wallet or a robust governance mechanism.
StatusUnresolved
Medium

Gas Limit Concerns for Batch Operations

M-01The `batchTransfer`, `freezeUsers`, and `unfreezeUsers` functions iterate through arrays of recipients or users. If these arrays contain a very large number of elements, the transaction might exceed the block gas limit, causing the operation to fail. This can lead to denial of service for legitimate batch operations. (7.2 Code Security, 7.8 Operations)
IssueThe `batchTransfer`, `freezeUsers`, and `unfreezeUsers` functions iterate through arrays of recipients or users. If these arrays contain a very large number of elements, the transaction might exceed the block gas limit, causing the operation to fail. This can lead to denial of service for legitimate batch operations. (7.2 Code Security, 7.8 Operations)
FixImplement a maximum array size limit for these batch functions to prevent transactions from exceeding the block gas limit. Alternatively, provide alternative mechanisms for very large operations, such as pagination or Merkle tree-based claims, if such scale is anticipated.
StatusUnresolved
Low

Single Point of Failure for Critical Roles

L-01The constructor initially grants `DEFAULT_ADMIN_ROLE` and `FREEZER_ROLE` to a single `defaultAdmin` address. If this single address is compromised, an attacker gains full control over administrative functions, including minting, freezing, and role management, creating a single point of failure for the protocol's security. (7.3 Access Control, 7.8 Operations)
IssueThe constructor initially grants `DEFAULT_ADMIN_ROLE` and `FREEZER_ROLE` to a single `defaultAdmin` address. If this single address is compromised, an attacker gains full control over administrative functions, including minting, freezing, and role management, creating a single point of failure for the protocol's security. (7.3 Access Control, 7.8 Operations)
FixTransfer `DEFAULT_ADMIN_ROLE` to a multi-signature wallet immediately after deployment. Ensure robust security practices (e.g., hardware wallets, strong authentication) for all addresses holding critical roles.
StatusUnresolved
Info

Lack of Event Emission for `setFreezeToRecipient`

I-01The `setFreezeToRecipient` function allows the `DEFAULT_ADMIN_ROLE` to change the critical `freezeToRecipient` address. However, this function does not emit an event upon successful execution. This lack of an event makes it difficult to track changes to this address on-chain, impacting transparency and off-chain monitoring for users and auditors. (7.2 Code Security, 7.8 Operations)
IssueThe `setFreezeToRecipient` function allows the `DEFAULT_ADMIN_ROLE` to change the critical `freezeToRecipient` address. However, this function does not emit an event upon successful execution. This lack of an event makes it difficult to track changes to this address on-chain, impacting transparency and off-chain monitoring for users and auditors. (7.2 Code Security, 7.8 Operations)
FixEmit an event, such as `FreezeToRecipientChanged(address indexed oldRecipient, address indexed newRecipient)`, whenever `freezeToRecipient` is updated. This enhances transparency and allows for easier monitoring of critical parameter changes.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract leverages OpenZeppelin's battle-tested ERC20Burnable and AccessControl libraries, enhancing code security and adherence to established standards (7.2 Code Security). The implementation of `_transfer` to enforce freezing logic is clear and correctly overrides the parent function. However, batch operations like `batchTransfer`, `freezeUsers`, and `unfreezeUsers` could face gas limit issues with very large input arrays, potentially leading to operational failures (7.2 Code Security, 7.8 Operations).

GovernanceHigh1/10

The protocol employs a robust `AccessControl` system to manage roles for minting and freezing, ensuring only authorized entities can perform these actions (7.3 Access Control). However, the `MINTER_ROLE` allows for unlimited token minting, posing a significant inflation risk if misused (7.4 Economic). Furthermore, the `FREEZER_ROLE` grants the ability to freeze user accounts, forcing transfers to a specific `freezeToRecipient`, which introduces a high degree of centralization and potential for censorship or fund seizure (7.4 Economic, 7.5 Governance).

UpgradesHigh2/10

The Bedrock contract is not designed as an upgradeable proxy, which simplifies its architecture by avoiding upgrade-specific complexities and potential vulnerabilities (7.7 Upgrades). This design choice means the contract's logic is immutable once deployed. Consequently, any future feature additions or bug fixes would require a new contract deployment and migration of assets.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

84.3% in top 10
12.3% in wallets71.9% in contracts
Effective Concentration41.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

$1.60M across 12 pairs
Pancakeswap v3USDTanalysed$1.59M98.8%Pancakeswap v3WBNB$12.4K0.8%Pancakeswap v3USDT$4.0K0.3%Pancakeswap v3WBNB$1.6K0.1%UniswapUSDT$9460.1%UniswapUSDC$1180.0%
Show 4 more pairsShow less
UniswapUSDT$1010.0%Pancakeswap v3USDC$850.0%UniswapUSDT$90.0%Pancakeswap v2WBNB$80.0%

The 2 remaining pairs hold $8 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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0xe100…a4bf
Unlocked LP Held By
0x1aa4…579b0x2e05…d9db

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

What Raised This Score

10 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (84.3% total → 41.1% effective; 12.3% in EOAs, 71.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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
SpaceX (SPCXB)Critical RiskLorenzo Governance Token (BANK)Critical RiskVenusCoinCritical RiskCysic Token (CYS)Critical RiskBased Token (BASED)Critical RiskZypher Token (POP)Critical Risk

Would You Like a More Detailed Audit of Bedrock?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit