Quantum Audit Logo

Is Topaz Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

Topaz TOPAZ
0xdf00…8abd
BNB Chain Not verifiedLast checked 1d ago 1 audit on record
Executive SummaryAI Copilot

The Topaz token contract is a basic ERC20 implementation leveraging OpenZeppelin libraries for standard token functionality and gasless approvals. The contract introduces a `minter` role with exclusive control over token supply and the ability to transfer this role. The primary security concern is the high centralization of minting authority, which poses significant economic risks. An `owner` state variable is present but unused, indicating a potential design oversight. The contract is not upgradeable.

1 High1 Medium1 Informational
Volume 24h
$34.6K
Liquidity
$89.5K
Price
$0.004411
Token Age
1y
Top 10 Holders
94.4%

Security Findings

High

Centralized Control of Token Supply

H-01The `Topaz` token contract grants the `minter` address exclusive and unlimited authority to mint new tokens. The `minter` can also transfer this powerful role to any other address without any checks or delays. This centralization poses a significant economic risk (7.4 Economic), as a compromised `minter` key or a malicious `minter` could lead to an arbitrary increase in token supply, severely devaluing existing tokens.
IssueThe `Topaz` token contract grants the `minter` address exclusive and unlimited authority to mint new tokens. The `minter` can also transfer this powerful role to any other address without any checks or delays. This centralization poses a significant economic risk (7.4 Economic), as a compromised `minter` key or a malicious `minter` could lead to an arbitrary increase in token supply, severely devaluing existing tokens.
FixImplement a multi-signature wallet for the `minter` role or introduce a time-locked delay for `setMinter` and `mint` operations, especially for large amounts. Consider a cap on total supply or a mechanism for community governance over minting (7.5 Governance).
StatusUnresolved
Medium

Unused State Variable `owner`

M-01The `owner` state variable is declared and initialized in the constructor to `msg.sender`, but it is never used in any function within the `Topaz` contract. This makes the variable redundant and potentially misleading (7.1 Architecture), as it suggests a role that does not exist or function, which could lead to confusion or future errors if someone assumes it has a purpose.
IssueThe `owner` state variable is declared and initialized in the constructor to `msg.sender`, but it is never used in any function within the `Topaz` contract. This makes the variable redundant and potentially misleading (7.1 Architecture), as it suggests a role that does not exist or function, which could lead to confusion or future errors if someone assumes it has a purpose.
FixRemove the `owner` variable if it serves no purpose. If an `owner` role is intended, implement functions that utilize this role for specific administrative tasks (e.g., pausing, emergency actions) and ensure proper access control mechanisms are in place for its management (7.3 Access Control).
StatusUnresolved
Info

Lack of Role Renouncement Mechanism

I-01The `minter` role can be transferred to a new address via `setMinter`, but there is no explicit function allowing the current `minter` to renounce or revoke their own role. While the `minter` can transfer the role to `address(0)` to effectively renounce it, an explicit `renounceMinter` function would improve clarity and reduce potential errors (7.3 Access Control).
IssueThe `minter` role can be transferred to a new address via `setMinter`, but there is no explicit function allowing the current `minter` to renounce or revoke their own role. While the `minter` can transfer the role to `address(0)` to effectively renounce it, an explicit `renounceMinter` function would improve clarity and reduce potential errors (7.3 Access Control).
FixConsider adding a `renounceMinter()` function that allows the current `minter` to voluntarily give up their role, potentially transferring it to `address(0)` or a designated null address, improving operational clarity (7.8 Operations).
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes well-audited OpenZeppelin ERC20 and ERC20Permit implementations, contributing to a solid technical foundation (7.2 Code Security). The custom logic for `minter` role management and token minting is straightforward. However, a notable technical issue is the presence of an unused `owner` state variable, which adds unnecessary complexity and could be misleading (7.1 Architecture). The custom error `NotMinter()` is used, but its definition is not provided in the given source, which could lead to compilation issues if not defined elsewhere.

GovernanceHigh2/10

The economic model of the Topaz token is highly centralized, with the `minter` address having absolute control over the token supply (7.4 Economic). This single point of failure introduces a significant risk of inflation and devaluation if the `minter` key is compromised or misused. There is no decentralized governance mechanism (7.5 Governance) to oversee minting operations or role transfers, placing full trust in a single entity. The `minter` can transfer its role without any time lock or multi-signature requirement, further exacerbating this centralization.

UpgradesMedium4/10

The Topaz contract is not designed to be upgradeable (7.7 Upgrades), meaning its logic cannot be modified after deployment. This eliminates upgrade-specific risks such as proxy misconfigurations or storage collisions. Any changes to the contract's functionality would require a new deployment and migration of assets.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

1.5% in wallets92.9% in contracts
Effective Concentration38.7%

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

Show 2 more pairsShow less

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

Deployer
0xd7e8…4aea
Unlocked LP Held By
0xef66…987e0x0ed9…9706

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

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (94.4% total → 38.7% effective; 1.5% in EOAs, 92.9% in contracts — moderate)
  • 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
  • 1 Medium 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

Related Audits

Infinity Ground AI (AIN)High RiskFinTech AI (FNA)High RiskSOCKHigh RiskAnoma (XAN)Critical RiskPlasma (XPL)Critical RiskMirex (MRX)Critical Risk

Would You Like a More Detailed Audit of Topaz?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit