Is Beam Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low2 Info

High

Centralized Minting and Burning Capabilities

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).

IssueThe `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).

FixTransfer 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.

StatusUnresolved

Medium

Centralized Administrative 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).

IssueThe `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).

FixImmediately 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.

StatusUnresolved

Low

Custom `onlyHasRole` Modifier

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).

IssueThe 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).

FixReplace 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.

StatusUnresolved

Info

No Explicit Total Supply Cap

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).

IssueThe `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).

FixConsider 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.

StatusUnresolved

Info

Non-Upgradeable Contract Design

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).

IssueThe `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).

FixAcknowledge 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.

StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceHigh2/10

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).

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

56.8% in top 10

26.7% in wallets30.0% in contracts

Effective Concentration38.8%

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

$3.59M across 3 pairs

Uniswap v2WETHanalysed$3.06M Uniswap v4ETH$520.8K Uniswap v3WETH$12.4K

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 Holder42.1%

Top-3 Unlocked85.3%

Key Addresses

11 addresses

Deployer

0xf4fb…62ef

Unlocked LP Held By

0xa99f…bb430x8aa0…a95f0x1ef1…210d0xd023…cf050x29fc…f1000xee38…86470x7e30…fc3e0xbed1…11f60xc69c…9d6b0xfbab…4aa8

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 status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (56.8% total → 38.8% effective; 26.7% in EOAs, 30.0% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top3 unlocked holders = 85.3% (independent LP — depth risk, pool = 85% of DEX liquidity)
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

Final Recommendation

AI Copilot

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.…

Read the verdictHide

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.

Contract

TypeBeamToken

Audit History

2 audits on record

Jul 2568Jul 2754

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Is Beam Safe?

Security Findings

Centralized Minting and Burning Capabilities

Centralized Administrative Control

Custom `onlyHasRole` Modifier

No Explicit Total Supply Cap

Non-Upgradeable Contract Design

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of Beam?