On-chain security analysis — is it a scam or legit?
BNB ChainThe Bedrock token contract implements ERC20 with burnable functionality and robust access control.
Read the full analysisEach 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
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.
Holder balances as recorded by the audit of Sep 4, 2026
The 2 remaining pairs hold $8 between them and are not listed. The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x1aa4…579b0x2e05…d9dbNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
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)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)
Implement 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.
Unresolved
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)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)
Implement 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.
Unresolved
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)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)
Implement 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.
Unresolved
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)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)
Transfer 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.
Unresolved
setFreezeToRecipientsetFreezeToRecipient 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)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)
Emit 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.
Unresolved
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.
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).
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).
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.
It is strongly recommended to implement multi-signature wallets for all critical roles, especially the DEFAULT_ADMIN_ROLE, MINTER_ROLE, and FREEZER_ROLE, to mitigate single points of failure and enhance security.
Consider adding a time-lock mechanism for highly sensitive administrative actions, such as changing the freezeToRecipient or granting/revoking critical roles, to provide a window for community review and intervention. Additionally, clearly communicate the extent of centralized control and the implications of the freezing mechanism to all users to ensure transparency and informed participation.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Bedrock (BR) contract on BNB Chain is 0xff7d6a96ae471bbcd7713af9cb1feeb16cf56b41. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Bedrock is 77/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.60M.
As of Sep 4, 2026, the 10 largest holders own 84.3% of the supply. The Holders section on this page shows who they are by holder type.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
