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.

On-chain security analysis — is it a scam or legit?
Is Hemi Safe?
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 →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- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking16.8%
- Walletsanonymous holders, free to sell75.2%
- Everyone elsethe rest of the supply8.0%
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- Pancakeswap v3USDTAnalysed$668.0K100.0%
- Pancakeswap v2WBNB$230.0%
- Pancakeswap v3USDT$100.0%
- Pancakeswap v2Subject 3$40.0%
- Pancakeswap v2USDT$20.0%
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x375f…9491No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighCentralized 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
MediumIrreversible 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
LowManager 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
InfoLack 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 4The 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.
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).
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202668High
- 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