Quantum Audit Logo
Launch App

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

Is Bless Token Safe?

BLESSBNB Chain
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The DeBridgeToken contract serves as an upgradeable ERC-20 token implementation, utilizing OpenZeppelin's upgradeable contracts and access control.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 70% (92.3% total → 80.1% effective; 72.0% in EOAs, 20.3% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • 1 High finding(s) from audit
  • 2 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
20.3%Contracts72.0%Wallets7.7%
20.3%Contracts72.0%Wallets7.7%
ContractsWalletsEveryone elseBubble area = share of supply
92.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking20.3%
  • Walletsanonymous holders, free to sell72.0%
  • Everyone elsethe rest of the supply7.7%
Effective concentrationwhat the score reads80.1%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$234.8K across 5 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$224.4KShare of depth95.6%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xcb2b…d20f0x6458…2df5

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

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Control of Critical Functions (Minting, Pausing, Admin)

The contract grants extensive power to specific roles: DEFAULT_ADMIN_ROLE can manage all other roles, MINTER_ROLE can arbitrarily increase token supply via mint, and PAUSER_ROLE can halt all token transfers via pause/unpause. This high degree of centralization means that a compromise or malicious action by an address holding these roles could severely impact the token's integrity, value, and usability. The DEFAULT_ADMIN_ROLE effectively controls the entire token's lifecycle and economic parameters.H-01

Issue

The contract grants extensive power to specific roles: DEFAULT_ADMIN_ROLE can manage all other roles, MINTER_ROLE can arbitrarily increase token supply via mint, and PAUSER_ROLE can halt all token transfers via pause/unpause. This high degree of centralization means that a compromise or malicious action by an address holding these roles could severely impact the token's integrity, value, and usability. The DEFAULT_ADMIN_ROLE effectively controls the entire token's lifecycle and economic parameters.

Fix

Implement a robust multi-signature wallet or a decentralized governance mechanism for the DEFAULT_ADMIN_ROLE, MINTER_ROLE, and PAUSER_ROLE. This distributes control and requires multiple approvals for critical operations, significantly reducing the risk of a single point of failure or malicious insider actions. Clearly document the responsibilities and operational procedures for each role.

Status

Unresolved

Medium

updateName Function Allows Token Identity Change

The updateName function, callable only by the DEFAULT_ADMIN_ROLE, allows the token's name and symbol to be changed post-deployment. While the DOMAIN_SEPARATOR is correctly re-calculated, this capability could lead to user confusion, misrepresentation on exchanges, or potential trust issues if not managed with extreme transparency and community consensus. Frequent or unannounced changes to a token's identity can erode user confidence.M-01

Issue

The updateName function, callable only by the DEFAULT_ADMIN_ROLE, allows the token's name and symbol to be changed post-deployment. While the DOMAIN_SEPARATOR is correctly re-calculated, this capability could lead to user confusion, misrepresentation on exchanges, or potential trust issues if not managed with extreme transparency and community consensus. Frequent or unannounced changes to a token's identity can erode user confidence.

Fix

Consider if the ability to change the token's name and symbol is truly necessary post-deployment. If it is, ensure that any changes are communicated transparently and well in advance to all stakeholders, including exchanges and users. Implement a time-lock or a governance vote for such critical changes to provide a window for review and prevent immediate, unilateral alterations.

Status

Unresolved

Medium

Unusual burn Function Implementation

The burn function is restricted to onlyMinter and allows the minter to burn msg.sender's (i.e., their own) tokens. This deviates from the common ERC-20 burn pattern, where any token holder can burn their own tokens without requiring a special role. This design choice limits the utility of the burn function and might lead to confusion or unmet expectations for users accustomed to standard ERC-20 token behavior.M-02

Issue

The burn function is restricted to onlyMinter and allows the minter to burn msg.sender's (i.e., their own) tokens. This deviates from the common ERC-20 burn pattern, where any token holder can burn their own tokens without requiring a special role. This design choice limits the utility of the burn function and might lead to confusion or unmet expectations for users accustomed to standard ERC-20 token behavior.

Fix

Clarify the intended purpose of the burn function. If the goal is to allow any token holder to burn their own tokens, remove the onlyMinter modifier. If the intent is specifically for minters to manage their own token holdings through burning, document this behavior clearly to avoid user confusion. Consider adding a separate burnFrom function if minters are intended to burn tokens from other addresses.

Status

Unresolved

Low

Single Point of Failure for Privileged Roles

If the addresses assigned to DEFAULT_ADMIN_ROLE, MINTER_ROLE, or PAUSER_ROLE are single Externally Owned Accounts (EOAs), they represent single points of failure. A compromise of any of these EOAs (e.g., private key theft) would grant an attacker full control over the respective privileged functions, potentially leading to severe consequences for the token and its holders.L-01

Issue

If the addresses assigned to DEFAULT_ADMIN_ROLE, MINTER_ROLE, or PAUSER_ROLE are single Externally Owned Accounts (EOAs), they represent single points of failure. A compromise of any of these EOAs (e.g., private key theft) would grant an attacker full control over the respective privileged functions, potentially leading to severe consequences for the token and its holders.

Fix

Ensure that all privileged roles (DEFAULT_ADMIN_ROLE, MINTER_ROLE, PAUSER_ROLE) are assigned to multi-signature wallets (e.g., Gnosis Safe) rather than single EOAs. This significantly enhances security by requiring multiple approvals for any action, making it much harder for an attacker to gain full control.

Status

Unresolved

Info

EIP-712 permit Function Susceptible to Front-running

The permit function, while correctly implemented with deadline and nonces to prevent replay attacks, is inherently susceptible to front-running. A malicious actor observing a signed permit message off-chain could submit the transaction with a higher gas price before the legitimate spender, effectively 'stealing' the approval. This is a general characteristic of EIP-712 permit and not a flaw in this specific implementation.I-01

Issue

The permit function, while correctly implemented with deadline and nonces to prevent replay attacks, is inherently susceptible to front-running. A malicious actor observing a signed permit message off-chain could submit the transaction with a higher gas price before the legitimate spender, effectively 'stealing' the approval. This is a general characteristic of EIP-712 permit and not a flaw in this specific implementation.

Fix

Educate users about the potential for front-running when using the permit function. Advise them to be cautious when sharing signed messages and to consider using transaction privacy services if available and necessary for highly sensitive approvals. This risk is generally mitigated by the deadline parameter, but users should be aware.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The DeBridgeToken contract serves as an upgradeable ERC-20 token implementation, utilizing OpenZeppelin's upgradeable contracts and access control. The contract features centralized minting, pausing, and administrative control, which introduces significant economic and governance risks. While the code adheres to OpenZeppelin best practices for upgradeability and ERC-20 functionality, the extensive power vested in specific roles (Admin, Minter, Pauser) represents a high degree of centralization. Key management for these roles is critical to prevent single points of failure and potential misuse of power, which could impact token supply, transferability, and identity.

Technical4/10Medium risk

The DeBridgeToken contract is built upon battle-tested OpenZeppelin upgradeable libraries, ensuring a solid foundation for ERC-20 functionality, access control, and pausability (7.2 Code Security). The implementation of EIP-2612 permit functionality includes standard nonce and deadline checks, mitigating replay attacks. However, the burn function's restriction to onlyMinter and its behavior of burning msg.sender's tokens is an unusual design choice that deviates from standard ERC-20 expectations (7.1 Architecture).

Governance1/10High risk

The contract exhibits a high degree of centralization, with the DEFAULT_ADMIN_ROLE having the power to grant/revoke MINTER_ROLE and PAUSER_ROLE, effectively controlling token supply and transferability (7.3 Access Control, 7.5 Governance). The MINTER_ROLE allows for arbitrary token creation, posing a significant economic risk through potential inflation (7.4 Economic). Additionally, the updateName function, callable by the admin, allows for changes to the token's name and symbol, which could lead to confusion if not managed transparently (7.5 Governance).

Upgrades1/10High risk

The contract utilizes OpenZeppelin's Initializable and upgradeable patterns, correctly managing storage slots and initialization to prevent common upgrade-related issues (7.7 Upgrades). As a beacon proxy implementation, upgrades affect all proxies pointing to the same beacon, centralizing the upgrade mechanism. While the technical implementation is robust, the control over the beacon's owner (which dictates upgrades) represents a single point of failure and a potential vector for malicious upgrades if compromised (7.8 Operations).

Final RecommendationWhat to do about this score

It is strongly recommended to implement robust multi-signature governance for all critical roles, especially DEFAULT_ADMIN_ROLE, MINTER_ROLE, and PAUSER_ROLE, to mitigate the risks associated with centralized control and single points of failure.

Clear documentation and communication regarding the unusual behavior of the burn function and the implications of the updateName function should be provided to users and integrators. Regular security reviews and monitoring of privileged addresses are essential to maintain the integrity and security of the DeBridgeToken.

Contract & Record

1 audit on record
TypeDeBridgeTokenProxy
NetworkBNB Chain
Token age10mo
Contract0x7c82…e11f
Deployer0x3f88…c9af
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Badge for your website
Bless Token security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202697Critical
  2. Aug 13, 202693Critical

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

Related Audits

6 more on the recordAll audits
Tesla, Inc. TSLAB · BNB Chain96CriticalACETokenACE · BNB Chain98CriticalWebKey DAO 2.0WKEYDAO2 · BNB Chain100CriticalPieverse TokenPIEVERSE · BNB Chain100CriticalETHGasGWEI · BNB Chain94CriticalSnapCoinBNB Chain100Critical

Would You Like a More Detailed Audit of Bless Token?

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