On-chain security analysis — is it a scam or legit?
EthereumThe BeamToken contract implements an ERC20 token with voting capabilities and role-based access control for minting and burning.
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 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.
0xa99f…bb430x8aa0…a95f0x1ef1…210d0xd023…cf050x29fc…f1000xee38…86470x7e30…fc3e0xbed1…11f60xc69c…9d6b0xfbab…4aa8No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
BeamToken contract includes mint and burn functions, controlled by MINTER_ROLE and BURNER_ROLE respectively. These roles, along with the DEFAULT_ADMIN_ROLE, are initially assigned to the contract deployer. This centralization allows the role holders to arbitrarily increase or decrease the total supply of tokens without any on-chain checks or community consensus. This poses a significant economic risk as it can lead to token dilution or manipulation of supply (7.4 Economic, 7.3 Access Control).H-01The BeamToken contract includes mint and burn functions, controlled by MINTER_ROLE and BURNER_ROLE respectively. These roles, along with the DEFAULT_ADMIN_ROLE, are initially assigned to the contract deployer. This centralization allows the role holders to arbitrarily increase or decrease the total supply of tokens without any on-chain checks or community consensus. This poses a significant economic risk as it can lead to token dilution or manipulation of supply (7.4 Economic, 7.3 Access Control).
Transfer the MINTER_ROLE and BURNER_ROLE to a multi-signature wallet or a robust DAO governance contract. Implement a transparent minting policy, potentially with a maximum supply cap or a time-locked minting schedule, to limit the potential for abuse and provide predictability to token holders. Consider removing the burn functionality if not strictly necessary, or restrict it to specific, auditable scenarios.
Unresolved
DEFAULT_ADMIN_ROLE is granted to the contract deployer in the constructor. This role has the power to grant and revoke all other roles, including itself, MINTER_ROLE, and BURNER_ROLE. This creates a single point of failure where a compromised or malicious admin account could gain full control over the token's critical functions, including the ability to assign minting and burning privileges to any address (7.5 Governance, 7.3 Access Control).M-01The DEFAULT_ADMIN_ROLE is granted to the contract deployer in the constructor. This role has the power to grant and revoke all other roles, including itself, MINTER_ROLE, and BURNER_ROLE. This creates a single point of failure where a compromised or malicious admin account could gain full control over the token's critical functions, including the ability to assign minting and burning privileges to any address (7.5 Governance, 7.3 Access Control).
Immediately transfer the DEFAULT_ADMIN_ROLE to a secure multi-signature wallet or a well-established DAO governance system. Ensure that the multi-signature wallet has a sufficient number of signers and a robust operational security policy. Regularly review and audit the addresses holding administrative roles.
Unresolved
onlyHasRole ModifieronlyHasRole(bytes32 _role) which duplicates the functionality of the onlyRole(bytes32 role) modifier provided by the inherited OpenZeppelin AccessControl contract. While functionally equivalent, using a custom modifier introduces an unnecessary deviation from standard library usage and could potentially lead to subtle inconsistencies or errors if not maintained carefully (7.2 Code Security).L-01The contract defines a custom modifier onlyHasRole(bytes32 _role) which duplicates the functionality of the onlyRole(bytes32 role) modifier provided by the inherited OpenZeppelin AccessControl contract. While functionally equivalent, using a custom modifier introduces an unnecessary deviation from standard library usage and could potentially lead to subtle inconsistencies or errors if not maintained carefully (7.2 Code Security).
Replace the custom onlyHasRole modifier with the standard onlyRole modifier provided by OpenZeppelin's AccessControl contract for consistency and to leverage battle-tested code. For example, modifier onlyHasRole(bytes32 _role) can be replaced with onlyRole(_role) directly.
Unresolved
BeamToken contract does not implement an explicit maximum total supply (hard cap) for the token. While the MINTER_ROLE controls the minting process, there is no inherent limit enforced by the contract itself on how many tokens can be minted over time. This design choice means the total supply is entirely dependent on the discretion and policy of the MINTER_ROLE holder (7.4 Economic).I-01The BeamToken contract does not implement an explicit maximum total supply (hard cap) for the token. While the MINTER_ROLE controls the minting process, there is no inherent limit enforced by the contract itself on how many tokens can be minted over time. This design choice means the total supply is entirely dependent on the discretion and policy of the MINTER_ROLE holder (7.4 Economic).
Consider implementing a maximum total supply (hard cap) in the contract if the project intends for the token to have a finite supply. Alternatively, if an elastic supply is desired, clearly document the minting policy and mechanisms to ensure transparency and predictability for token holders. If a hard cap is implemented, ensure the mint function checks against this cap.
Unresolved
BeamToken contract is deployed as a standard, non-upgradeable contract. This means that its logic cannot be modified or updated after deployment. While this eliminates risks associated with upgrade mechanisms (e.g., proxy vulnerabilities), it also means that any discovered bugs, necessary feature enhancements, or changes in economic parameters would require a complete redeployment of a new contract and a migration of existing tokens, which can be a complex and disruptive process for users (7.7 Upgrades, 7.1 Architecture).I-02The BeamToken contract is deployed as a standard, non-upgradeable contract. This means that its logic cannot be modified or updated after deployment. While this eliminates risks associated with upgrade mechanisms (e.g., proxy vulnerabilities), it also means that any discovered bugs, necessary feature enhancements, or changes in economic parameters would require a complete redeployment of a new contract and a migration of existing tokens, which can be a complex and disruptive process for users (7.7 Upgrades, 7.1 Architecture).
Acknowledge the implications of a non-upgradeable design. For future contracts or if flexibility is desired, consider implementing an upgradeable proxy pattern (e.g., UUPS or Transparent Proxy) from OpenZeppelin. If remaining non-upgradeable, ensure thorough testing and auditing to minimize the likelihood of needing future changes.
Unresolved
The BeamToken contract implements an ERC20 token with voting capabilities and role-based access control for minting and burning. The contract leverages battle-tested OpenZeppelin libraries, contributing to a solid technical foundation. However, significant centralization exists in the control over token supply and administrative roles, posing a high economic and governance risk.
The BeamToken contract demonstrates strong technical foundations by utilizing well-audited OpenZeppelin libraries for its core ERC20, voting, and access control functionalities (7.2 Code Security). The Solidity version 0.8.6 mitigates common integer overflow/underflow vulnerabilities. Custom logic includes restrictions on transferring and minting to the contract address itself, which is a specific design choice (7.1 Architecture). A minor observation is the use of a custom onlyHasRole modifier instead of the standard onlyRole from AccessControl, which could be unified for consistency.
The contract design presents a high economic and governance risk due to significant centralization (7.4 Economic, 7.5 Governance). The DEFAULT_ADMIN_ROLE is assigned to the deployer, granting full control over all other roles, including MINTER_ROLE and BURNER_ROLE. This means a single entity or a small group of entities can arbitrarily mint new tokens, dilute existing holders, or burn tokens, directly impacting the token's supply and value. There is no on-chain governance mechanism to decentralize these critical powers, making the system highly dependent on the integrity of the role holders (7.3 Access Control).
The BeamToken contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). This design choice eliminates upgrade-related risks such as proxy misconfigurations or logic errors during upgrades. However, it also means that any future changes or bug fixes to the contract logic would require a new deployment and migration of tokens, which can be a complex and costly process.
To enhance the security and decentralization of the BeamToken, it is strongly recommended to transition critical roles such as DEFAULT_ADMIN_ROLE, MINTER_ROLE, and BURNER_ROLE to a robust multi-signature wallet or a decentralized autonomous organization (DAO) governance system.
This would distribute control and reduce the risk associated with a single point of failure or malicious intent. Additionally, consider implementing a maximum total supply or a transparent minting schedule to provide greater predictability and trust in the token's economic model.
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.
Based on automated analysis, Beam scores 68/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.
Our scanner flagged a risk score of 68/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.
The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.
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
