Is BitgetToken (BGB) Safe? Smart Contract Security Analysis

Security Findings

1 High2 Info

High

Centralization of Token Supply to a Single Address

H-01The `BitgetToken` contract's constructor mints the entire `totalSupply` (2e9 * 1e18 tokens) to a single `vault` address. This design choice centralizes control over the entire token supply to this one address. If the `vault` address is compromised (e.g., private key theft) or mismanaged, the entire token supply could be at risk of loss or unauthorized movement, posing a significant economic and operational risk to the project and its users.

IssueThe `BitgetToken` contract's constructor mints the entire `totalSupply` (2e9 * 1e18 tokens) to a single `vault` address. This design choice centralizes control over the entire token supply to this one address. If the `vault` address is compromised (e.g., private key theft) or mismanaged, the entire token supply could be at risk of loss or unauthorized movement, posing a significant economic and operational risk to the project and its users.

FixImplement robust security measures for the `vault` address. This should include, at a minimum, a multi-signature wallet with a sufficient number of signers. For enhanced security and transparency, consider integrating a timelock contract to introduce a delay for critical operations, allowing time for review and potential intervention. Explore options for gradual distribution or vesting schedules if the intention is to release tokens over time, rather than holding the entire supply in one hot wa…

StatusUnresolved

Info

Lack of Advanced Token Features

I-01The `BitgetToken` contract is a basic ERC20 implementation, inheriting directly from OpenZeppelin's standard `ERC20` contract. It does not include additional features commonly found in more complex token designs, such as pausing transfers (`ERC20Pausable`), blacklisting malicious addresses, or role-based access control (`AccessControl`) for specific functions (e.g., minting/burning beyond the initial supply). While this simplicity reduces attack surface, it also limits operational flexibility.

IssueThe `BitgetToken` contract is a basic ERC20 implementation, inheriting directly from OpenZeppelin's standard `ERC20` contract. It does not include additional features commonly found in more complex token designs, such as pausing transfers (`ERC20Pausable`), blacklisting malicious addresses, or role-based access control (`AccessControl`) for specific functions (e.g., minting/burning beyond the initial supply). While this simplicity reduces attack surface, it also limits operational flexibility.

FixEvaluate if these advanced features are necessary for the project's long-term vision, regulatory compliance, or operational needs. If features like pausing or blacklisting are deemed important for emergency situations or mitigating specific risks, consider extending the ERC20 contract with appropriate OpenZeppelin modules or custom implementations in future iterations. Acknowledge that adding such features also introduces additional complexity and potential attack vectors.

StatusUnresolved

Info

Non-Upgradeable Contract Design

I-02The `BitgetToken` contract is deployed as a standard, non-upgradeable contract. This means that once deployed, its code cannot be modified. Any future bug fixes, feature enhancements, or changes to the token's logic would necessitate deploying a new contract and migrating existing token holders. This process can be complex, costly, and disruptive for the community.

IssueThe `BitgetToken` contract is deployed as a standard, non-upgradeable contract. This means that once deployed, its code cannot be modified. Any future bug fixes, feature enhancements, or changes to the token's logic would necessitate deploying a new contract and migrating existing token holders. This process can be complex, costly, and disruptive for the community.

FixAcknowledge the implications of non-upgradeability. For a simple, immutable token, this can be a desired feature. However, if future flexibility or the ability to fix potential bugs post-deployment is critical, consider implementing an upgradeable proxy pattern (e.g., UUPS or Transparent Proxy) for future deployments. Note that upgradeability introduces its own set of complexities and security considerations that would require careful design and auditing.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract (7.1 Architecture) is a straightforward ERC20 token, inheriting directly from OpenZeppelin's well-audited `ERC20` implementation. This minimizes custom logic, enhancing code security (7.2 Code Security). The only custom logic is the constructor's initial mint of the entire supply to a specified vault address. Standard ERC20 access control (7.3 Access Control) is in place, with no additional roles or permissions defined within the token contract itself.

GovernanceHigh1/10

The primary economic risk (7.4 Economic) is the complete centralization of the token's total supply to a single 'vault' address during deployment. This design choice means the security and control of all 2 billion tokens are entirely dependent on the security of this single address. There are no governance mechanisms (7.5 Governance) within the token contract itself to manage or distribute this supply, nor are there any external interactions (7.6 External) defined.

UpgradesLow7/10

The BitgetToken contract is deployed as a standard, non-upgradeable contract (7.7 Upgrades). This design choice means that any future modifications, bug fixes, or feature additions would necessitate a new contract deployment and a potentially complex token migration process. There are no operational roles (7.8 Operations) or upgrade-specific risks.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

87.0% in top 10

68.8% in wallets18.3% in contracts

Effective Concentration76.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

$512.3K across 5 pairs

Uniswap v2WETHanalysed$500.3K Uniswap v4ZIK$4.8K Uniswap v4ZIK$3.5K Uniswap v3ZIK$3.3K Uniswap v4ZIK$489

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

4 addresses

Deployer

0x0d6e…71eb

Unlocked LP Held By

0xf833…13330x826f…1e650x1f2f…f387

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

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 70% (87.0% total → 76.1% effective; 68.8% in EOAs, 18.3% in contracts — extreme)
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
LP claimed locked but only 0.0% actually locked
1 High 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 BitgetToken Safe?

Security Findings

Centralization of Token Supply to a Single Address

Lack of Advanced Token Features

Non-Upgradeable Contract Design

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 BitgetToken?