Is Bless Token (BLESS) Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low1 Info

High

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

H-01The 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.

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

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

StatusUnresolved

Medium

`updateName` Function Allows Token Identity Change

M-01The `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.

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

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

StatusUnresolved

Medium

Unusual `burn` Function Implementation

M-02The `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.

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

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

StatusUnresolved

Low

Single Point of Failure for Privileged Roles

L-01If 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.

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

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

StatusUnresolved

Info

EIP-712 `permit` Function Susceptible to Front-running

I-01The `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.

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

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

StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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

UpgradesHigh1/10

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

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeBeacon

ImplementationVerified source

Holder Composition

92.3% in top 10

72.0% in wallets20.3% in contracts

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

$234.8K across 5 pairs

Pancakeswap v3WBNBanalysed$224.4K UniswapUSDT$9.5K Pancakeswap v3USDT$909 Pancakeswap v2Subject 3$6 Pancakeswap v2WBNB$5

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

3 addresses

Deployer

0x3f88…c9af

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.

What Raised This Score

11 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypeDeBridgeTokenProxy

Audit History

1 audit on record

Aug 1393Sep 497

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

Is Bless Token Safe?

Security Findings

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

`updateName` Function Allows Token Identity Change

Unusual `burn` Function Implementation

Single Point of Failure for Privileged Roles

EIP-712 `permit` Function Susceptible to Front-running

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Bless Token?