Quantum Audit Logo
Launch App

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

Is Hemi Safe?

HEMIBNB 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
SummaryAI Copilot

The audit of the BinanceHemiOFT contract, an extension of LayerZero's OFT, revealed a well-structured codebase with clear logic for its core functionality.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Volume/Liquidity > 15×
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 70% (92.0% total → 81.9% effective; 75.2% in EOAs, 16.8% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Volume/Liquidity > 15× (15.2× — wash-trading signal)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 1 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 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
16.8%Contracts75.2%Wallets8.0%
16.8%Contracts75.2%Wallets8.0%
ContractsWalletsEveryone elseBubble area = share of supply
92.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking16.8%
  • Walletsanonymous holders, free to sell75.2%
  • Everyone elsethe rest of the supply8.0%
Effective concentrationwhat the score reads81.9%
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$668.0K across 6 pairs
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$668.0KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x375f…9491

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control Over Token Transfers by Manager

The manager role possesses extensive control over token transfer functionality. The manager can enable/disable all transfers via isTransferEnabled, and selectively whitelist/blacklist accounts for sending (canSendToAnyone, canSendToWhitelisted) and receiving (canReceive). A compromised manager account could lead to a denial of service for all token holders by halting transfers, or selectively freeze funds by restricting specific accounts. This represents a significant centralization risk (7.3 Access Control, 7.4 Economic).H-01

Issue

The manager role possesses extensive control over token transfer functionality. The manager can enable/disable all transfers via isTransferEnabled, and selectively whitelist/blacklist accounts for sending (canSendToAnyone, canSendToWhitelisted) and receiving (canReceive). A compromised manager account could lead to a denial of service for all token holders by halting transfers, or selectively freeze funds by restricting specific accounts. This represents a significant centralization risk (7.3 Access Control, 7.4 Economic).

Fix

Assign the manager role to a robust multisignature wallet with a high transaction threshold to distribute control and reduce the risk of a single point of failure. Implement off-chain governance procedures for manager actions, ensuring transparency and community oversight.

Status

Unresolved

Medium

Irreversible Revocation of Management

The revokeManagement() function permanently sets the manager address to address(0) and, crucially, globally enables transfers by calling updateTransferEnabled(true). While this decentralizes control over transfer restrictions, it means that once revoked, the transfer restriction mechanism can never be re-established or modified. This design choice is irreversible and might limit future flexibility if unforeseen circumstances require re-enabling transfer controls (7.5 Governance, 7.8 Operations).M-01

Issue

The revokeManagement() function permanently sets the manager address to address(0) and, crucially, globally enables transfers by calling updateTransferEnabled(true). While this decentralizes control over transfer restrictions, it means that once revoked, the transfer restriction mechanism can never be re-established or modified. This design choice is irreversible and might limit future flexibility if unforeseen circumstances require re-enabling transfer controls (7.5 Governance, 7.8 Operations).

Fix

Ensure that the irreversible nature of revokeManagement is a deliberate design decision and is clearly communicated to all stakeholders. If future flexibility is desired, consider an alternative mechanism that allows for temporary suspension or a multi-step process for permanent revocation, possibly involving a governance vote.

Status

Unresolved

Low

Manager Role Not Enforced as Multisig On-Chain

The manager role, which holds significant power over token transfers, is defined as a single address. While the prefill indicates the owner (from Ownable) is a multisig, there is no on-chain enforcement or mechanism to ensure that the manager address itself is a multisig wallet. If the manager is an Externally Owned Account (EOA), it represents a single point of failure, increasing the risk of compromise (7.3 Access Control, 7.8 Operations).L-01

Issue

The manager role, which holds significant power over token transfers, is defined as a single address. While the prefill indicates the owner (from Ownable) is a multisig, there is no on-chain enforcement or mechanism to ensure that the manager address itself is a multisig wallet. If the manager is an Externally Owned Account (EOA), it represents a single point of failure, increasing the risk of compromise (7.3 Access Control, 7.8 Operations).

Fix

If the intention is for the manager to be a multisig, consider implementing a check in the constructor or updateManager function to verify if the new manager address is a known multisig contract, or explicitly document the off-chain policy requiring a multisig for this role.

Status

Unresolved

Info

Lack of Time-Locks for Critical Manager Operations

Critical operations performed by the manager, such as updateTransferEnabled, updateCanSendToAnyone, updateCanReceive, and updateManager, are executed immediately upon transaction. The absence of time-locks means that malicious or erroneous actions by a compromised manager could have immediate and irreversible consequences, leaving no window for community review or emergency intervention (7.8 Operations).I-01

Issue

Critical operations performed by the manager, such as updateTransferEnabled, updateCanSendToAnyone, updateCanReceive, and updateManager, are executed immediately upon transaction. The absence of time-locks means that malicious or erroneous actions by a compromised manager could have immediate and irreversible consequences, leaving no window for community review or emergency intervention (7.8 Operations).

Fix

Consider implementing a time-lock mechanism for critical manager functions. This would introduce a delay between the initiation and execution of sensitive changes, allowing for potential detection of malicious activity or correction of errors before they take full effect.

Status

Unresolved

Analysis

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

The audit of the BinanceHemiOFT contract, an extension of LayerZero's OFT, revealed a well-structured codebase with clear logic for its core functionality. The contract introduces a 'manager' role with significant control over token transfer restrictions, allowing for granular control over who can send and receive tokens. While the technical implementation is robust, the high degree of centralization around the manager role presents a significant operational and governance risk. The contract is not upgradeable, simplifying its lifecycle management.

Technical6/10Medium risk

The technical implementation of the BinanceHemiOFT contract is straightforward and adheres to common Solidity patterns. It correctly inherits from LayerZero's OFT and OpenZeppelin's Ownable, leveraging battle-tested libraries. The custom transfer restriction logic in _canTransfer and its integration into _update is clear and free from obvious reentrancy or integer overflow vulnerabilities (7.2 Code Security). Error handling for invalid manager addresses in the constructor is also well-implemented. No significant technical vulnerabilities were identified.

Governance1/10High risk

The contract design introduces a 'manager' role with extensive control over token transfers, including the ability to halt all transfers or selectively whitelist/blacklist accounts (7.3 Access Control). This centralization presents a high governance and economic risk (7.4 Economic, 7.5 Governance), as a compromised manager could freeze funds or disrupt the token's utility. While the revokeManagement function allows for permanent decentralization of transfer controls, its irreversible nature means these controls cannot be re-established if needed. The manager role is not enforced as a multisig on-chain, increasing the single point of failure risk (7.8 Operations).

Upgrades6/10Medium risk

The provided contract is not implemented as an upgradeable proxy (7.7 Upgrades). This simplifies the contract's lifecycle and removes the complexities and potential risks associated with upgrade mechanisms. Any changes to the contract's logic would require a new deployment and migration of assets, which is a standard approach for non-upgradeable contracts.

Final RecommendationWhat to do about this score

To enhance the security posture of the BinanceHemiOFT contract, it is strongly recommended to implement robust access control mechanisms for the 'manager' role, ideally by assigning it to a well-secured multisignature wallet with a high threshold.

Consider adding time-locks for critical manager operations to provide a window for review and intervention. Thoroughly document the intended long-term strategy for the revokeManagement function, ensuring all stakeholders understand its irreversible implications for transfer controls.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0x5ffd…fc5b
Deployer0xf5f5…fac1
Badge for your website
Hemi 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, 202668High
  2. Aug 30, 202660Medium

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

Would You Like a More Detailed Audit of Hemi?

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