Quantum Audit Logo

Is Huma Finance Safe?

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

Is this your token? Publish your own audit on this page →

Huma Finance HUMA
0x9251…a8e6
BNB Chain
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The BNBOFT contract is an Omni-Fungible Token (OFT) implementation built on LayerZero V2, inheriting from LayerZero's OFT and OpenZeppelin's Ownable contracts. It provides cross-chain transfer capabilities for a token with 6 decimals. The contract itself is minimal, primarily relying on well-audited external libraries. Key risks identified relate to the extensive control held by the contract owner and the inherent dependency on the LayerZero protocol's security and operational integrity.

1 High1 Low2 Informational
Volume 24h
$2.68M
Liquidity
$3.15M
Price
$0.02713
Token Age
1y
Top 10 Holders
98.6%

Security Findings

1 High1 Low2 Info
High

Extensive Owner Privileges

H-01The `Ownable` pattern grants the owner (a 2/2 multisig) extensive control over critical LayerZero OFT configurations, including setting trusted remotes, message libraries, and fee settings. These privileges allow the owner to significantly influence the cross-chain functionality and security of the token. A compromise of the multisig or malicious action by its signers could lead to severe consequences such as halting cross-chain transfers, redirecting funds, or imposing arbitrary fees (7.3 Access Control, 7.5 Governance).
IssueThe `Ownable` pattern grants the owner (a 2/2 multisig) extensive control over critical LayerZero OFT configurations, including setting trusted remotes, message libraries, and fee settings. These privileges allow the owner to significantly influence the cross-chain functionality and security of the token. A compromise of the multisig or malicious action by its signers could lead to severe consequences such as halting cross-chain transfers, redirecting funds, or imposing arbitrary fees (7.3 Access Control, 7.5 Governance).
FixWhile the `Ownable` pattern is standard, consider implementing a more decentralized governance model for critical parameters, such as time-locked changes or a higher multisig threshold (e.g., 3/5). Ensure the multisig signers are highly trusted individuals and follow best practices for key management. Implement robust monitoring for any changes made by the owner.
StatusUnresolved
Low

External Dependency Risk (LayerZero Protocol)

L-01The contract's core functionality, specifically its cross-chain capabilities, relies entirely on the security and operational integrity of the LayerZero protocol and its endpoint. Any vulnerabilities, exploits, or failures within the LayerZero infrastructure could directly affect the BNBOFT token's ability to perform cross-chain transfers, potentially leading to loss of funds or service disruption (7.6 External).
IssueThe contract's core functionality, specifically its cross-chain capabilities, relies entirely on the security and operational integrity of the LayerZero protocol and its endpoint. Any vulnerabilities, exploits, or failures within the LayerZero infrastructure could directly affect the BNBOFT token's ability to perform cross-chain transfers, potentially leading to loss of funds or service disruption (7.6 External).
FixMaintain continuous awareness of LayerZero protocol updates, security audits, and community announcements. Implement monitoring for LayerZero endpoint status and any reported incidents. Diversify cross-chain solutions if feasible, or ensure robust contingency plans are in place for LayerZero-related disruptions.
StatusUnresolved
Info

Immutability of Contract

I-01The BNBOFT contract is deployed as a standard implementation and is not designed with an upgrade proxy pattern. This means that once deployed, its code cannot be modified. Any future bug fixes, feature enhancements, or changes to the token's logic would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex, costly, and disruptive process (7.7 Upgrades).
IssueThe BNBOFT contract is deployed as a standard implementation and is not designed with an upgrade proxy pattern. This means that once deployed, its code cannot be modified. Any future bug fixes, feature enhancements, or changes to the token's logic would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex, costly, and disruptive process (7.7 Upgrades).
FixThis is a design choice. If future upgradeability is desired, consider implementing a proxy pattern (e.g., UUPS) for future deployments. For the current contract, ensure thorough testing and auditing before deployment to minimize the need for future changes.
StatusUnresolved
Info

Hardcoded Decimals Value

I-02The `decimals()` function in the BNBOFT contract is hardcoded to return `6`. While this is an intentional design choice for the token's precision, it means that the decimal precision cannot be altered post-deployment. This immutability might limit future flexibility if a different decimal precision becomes desirable for ecosystem compatibility or other reasons (7.1 Architecture).
IssueThe `decimals()` function in the BNBOFT contract is hardcoded to return `6`. While this is an intentional design choice for the token's precision, it means that the decimal precision cannot be altered post-deployment. This immutability might limit future flexibility if a different decimal precision becomes desirable for ecosystem compatibility or other reasons (7.1 Architecture).
FixThis is a design decision. Ensure that the chosen decimal precision of 6 is suitable for all current and anticipated future use cases of the token. If flexibility was a concern, a configurable decimal value could have been implemented, though it adds complexity.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The BNBOFT contract is minimal, inheriting core functionality from well-audited OpenZeppelin `Ownable` and LayerZero `OFT` libraries (7.2 Code Security). It only overrides the `decimals()` function, reducing the attack surface significantly. The code adheres to standard Solidity practices and is straightforward to understand. No direct technical vulnerabilities were identified within the custom logic of BNBOFT. The primary technical risks stem from the security of the underlying LayerZero protocol, which is an external dependency (7.6 External).

GovernanceHigh1/10

The contract utilizes the `Ownable` pattern, with ownership held by a 2/2 multisig, which provides a layer of security against single points of failure for administrative actions (7.5 Governance). This allows for controlled management of critical cross-chain parameters. However, the owner (multisig) possesses extensive privileges (7.3 Access Control), including setting trusted remotes, message libraries, and fee configurations for the LayerZero OFT. This centralization of control (7.5 Governance) means a compromise of the multisig or malicious intent could lead to significant disruption of cross-chain transfers or denial of service.

UpgradesLow7/10

The contract is deployed as a standard implementation, avoiding the complexities and potential risks associated with proxy upgrade patterns. This ensures the contract's logic is immutable once deployed. However, the contract is not upgradeable via a proxy (7.7 Upgrades). Any future bug fixes, feature additions, or changes to the token's logic would require deploying an entirely new contract and migrating token holders, which can be a costly and disruptive process.

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

98.6% in top 10
73.8% in wallets24.8% in contracts
Effective Concentration83.7%

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

$3.15M

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

4 addresses
Deployer
0xc171…ab61
Unlocked LP Held By
0xf781…5d6f0x8f84…b6b60x4125…df6c

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

What Raised This Score

7 factors
  • Ownership NOT renounced — weak Multisig (2-of-2)
  • Top-10 concentration > 70% (98.6% total → 83.7% effective; 73.8% in EOAs, 24.8% 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High 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

Related Audits

6 more on the record
Slap Cat (SLAP)High RiskUnitas (UP)High RiskniulaiHigh RiskRICE AI (RICE)High RiskPrometeus (PROM)High RiskDAPPOS (DOS)High Risk

Would You Like a More Detailed Audit of Huma Finance?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit