Is Hemi Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Control Over Token Transfers by Manager

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

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

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

StatusUnresolved

Medium

Irreversible Revocation of Management

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

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

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

StatusUnresolved

Low

Manager Role Not Enforced as Multisig On-Chain

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

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

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

StatusUnresolved

Info

Lack of Time-Locks for Critical Manager Operations

I-01Critical 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).

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

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh1/10

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

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

92.0% in top 10

75.2% in wallets16.8% in contracts

Effective Concentration81.9%

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

$668.0K across 6 pairs

Pancakeswap v3USDTanalysed$668.0K Pancakeswap v2WBNB$23 Pancakeswap v3USDT$10 Pancakeswap v2Subject 3$4 Pancakeswap v2USDT$2

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

2 addresses

Deployer

0xf5f5…fac1

Unlocked LP Held By

0x375f…9491

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

What Raised This Score

9 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

Is Hemi Safe?

Security Findings

Centralized Control Over Token Transfers by Manager

Irreversible Revocation of Management

Manager Role Not Enforced as Multisig On-Chain

Lack of Time-Locks for Critical Manager Operations

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Hemi?