Blog/Case Study
BNB Smart ChainERC-20 Token with GovernanceJuly 2026380 lines

Case Study: BSC Governance Token Audit — 100% Tax Enabled and Unlimited Mint Authority

78/100
Risk Score (B)
14
Total Findings
4
Critical + High
Severity Distribution

Executive Summary

This contract is an ERC-20 token with built-in governance and fee mechanisms. At deployment, a single externally owned account already holds every administrative privilege: fee rates, tax rates, authorized minters, and contract ownership can all be changed instantly by one wallet with zero delays or approvals required. The contract already ships with a 99.99% buy tax configured, and the validation logic allows this value to be set to exactly 100%.

The mint function has no supply cap and can be invoked by any address on a mutable authorized list. Ownership can be transferred to any address — including a zero address that would permanently lock all admin functions — with a single call and no confirmation step.

Three medium-severity issues add compounding risk: fee-on-transfer interactions may break integrations with third-party DeFi protocols, there is no mechanism to recover mistakenly sent tokens, and role management lacks event emissions that would let external monitors detect permission changes.

Risk Assessment

This contract places total control in a single unprotected key with no safeguards, and ships pre-configured with a near-100% tax rate. It poses substantial financial risk to any holder who does not control that key.

Key Findings

high

Severe Centralization Risk — Single Governance EOA Controls All Protocol Parameters

What We Found

One single person controls every important setting with no delays, no second approvals, and no safety checks. If that person's account is ever hacked, they can immediately redirect all fees, set taxes to 100%, and effectively steal from every user.

Why It Matters

A single compromised or malicious key can immediately alter all fee rates, tax rates, minter lists, and ownership, causing total loss of funds for all token holders.

What Should Be Done

Migrate all admin functions behind a multisig wallet and implement timelocks — a minimum 48-hour delay — on all parameter changes so that token holders can detect and react to malicious actions before they take effect.

high

100% Tax Rate Possible — Tautological Rate Validation Allows Full Fund Confiscation

What We Found

The administrator can set the transaction tax to 100%, meaning anyone buying or selling would have their entire transaction amount taken as a fee. The contract already starts with a 99.99% buy tax.

Why It Matters

Any buy or sell transaction can be taxed at 100%, transferring the full transaction value to the fee recipient and leaving the trader with nothing.

What Should Be Done

Implement a hard-coded maximum tax rate — for example 10% — using a constant rather than a configurable parameter, and add a require statement that prevents any rate from being set above that ceiling.

high

Unrestricted Mint Function — No Supply Cap and Mutable Mint-Authorized Addresses

What We Found

Two specific external accounts have the permanent ability to create unlimited new tokens at any time, with no maximum limit.

Why It Matters

Authorized minters can inflate the token supply without bound, diluting all existing holders to near-zero value instantly.

What Should Be Done

Define an immutable maximum supply constant, enforce it inside the mint function, and require multisig approval before adding new addresses to the authorized minters list.

high

Single-Step Governance Transfer — No Zero-Address Check, No Two-Step Pattern

What We Found

The person who controls this contract can accidentally hand over permanent control to a wrong address with a single mistaken action, and there is no way to undo it.

Why It Matters

Ownership can be permanently transferred to an invalid or attacker-controlled address in a single transaction, locking all administrative functions or handing control to an adversary.

What Should Be Done

Implement a two-step ownership transfer pattern — propose a new owner, then require the new owner to accept — and add an explicit check that rejects the zero address as a transfer target.

What a Secure Contract Should Have

All administrative functions gated behind a multisig wallet with at least 2-of-3 signers
Timelocked parameter changes with a minimum 48-hour delay so holders can respond to unexpected changes
Hard-coded maximum tax and fee rates enforced as immutable constants in the contract code
An immutable total supply cap checked inside every mint call
Two-step ownership transfer with an explicit zero-address rejection
On-chain events emitted for every role and permission change to enable real-time monitoring

Disclaimer: This case study is published for educational purposes only. It reflects the state of the analyzed contract at the time of audit and does not constitute investment advice, an endorsement, or a guarantee of security. Smart contracts may be modified after an audit. HyperAudit is not liable for losses arising from interaction with any contract referenced in this report. Project names and addresses have been removed to protect ongoing remediation efforts. For a full audit of your own contracts, visit hyperaudit.io.

Building a project?

Get the same depth of analysis on your own contracts before you deploy. Reports delivered in hours, not weeks.

Audit Your Contract

Thinking about buying a token?

Before you buy, find out if the contract is safe. We can audit any token on any EVM chain and tell you exactly what risks you're taking — in plain language you can act on.

Check a Token Before You Buy