Quantum Audit Logo
Launch App

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

Is BNI Safe?

BNB 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
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance10/10Upgrades10/10Checks passed5 of 5Findings1 Low · 4 Info5
SummaryAI Copilot

This audit covers the OpenZeppelin Address.sol library, a foundational component for secure address interactions in Solidity.

Read the full analysis
What raised the score
  • 1 Low finding(s) from audit
Exact factors
  • 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 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
36.6%Contracts4.9%Wallets58.5%Everyone else
36.6%Contracts4.9%58.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
41.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking36.6%
  • Walletsanonymous holders, free to sell4.9%
  • Everyone elsethe rest of the supply58.5%
Effective concentrationwhat the score reads19.5%
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$93.8K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$93.8KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 Low4 Info
Low

Reliance on Calling Contract for External Call Safety

The Address.sol library provides robust primitives for interacting with external addresses, including sending value and making arbitrary calls. However, the ultimate responsibility for ensuring the security of these interactions, such as preventing reentrancy or handling unexpected external contract behavior, lies with the contract that integrates and utilizes these library functions. A lack of proper implementation of the Checks-Effects-Interactions pattern or reentrancy guards in the calling contract can lead to vulnerabilities (7.2 Code Security, 7.6 External).L-01

Issue

The Address.sol library provides robust primitives for interacting with external addresses, including sending value and making arbitrary calls. However, the ultimate responsibility for ensuring the security of these interactions, such as preventing reentrancy or handling unexpected external contract behavior, lies with the contract that integrates and utilizes these library functions. A lack of proper implementation of the Checks-Effects-Interactions pattern or reentrancy guards in the calling contract can lead to vulnerabilities (7.2 Code Security, 7.6 External).

Fix

All contracts integrating Address.sol functions that perform external calls must implement the Checks-Effects-Interactions pattern. State changes should occur before any external calls. Additionally, consider using reentrancy guards for functions that transfer assets or modify critical state after an external call. Thoroughly test all external interactions.

Status

Unresolved

Info

Limitations of isContract Function

The isContract function, while correctly implemented, has inherent limitations as explicitly noted in its NatSpec documentation. It returns false for contracts in construction, externally-owned accounts (EOAs), addresses where a contract will be created, or where a contract was destroyed. It also returns true for contracts scheduled for SELFDESTRUCT within the same transaction. Relying on isContract alone for security, especially against flash loan attacks or to distinguish EOAs from contracts, is explicitly discouraged by OpenZeppelin (7.2 Code Security).I-01

Issue

The isContract function, while correctly implemented, has inherent limitations as explicitly noted in its NatSpec documentation. It returns false for contracts in construction, externally-owned accounts (EOAs), addresses where a contract will be created, or where a contract was destroyed. It also returns true for contracts scheduled for SELFDESTRUCT within the same transaction. Relying on isContract alone for security, especially against flash loan attacks or to distinguish EOAs from contracts, is explicitly discouraged by OpenZeppelin (7.2 Code Security).

Fix

Developers should be fully aware of the limitations of isContract and avoid using it as a primary security mechanism, particularly for preventing calls from contracts or protecting against flash loan attacks. Implement robust access control mechanisms and reentrancy guards instead of relying on isContract for such purposes.

Status

Unresolved

Info

sendValue Reentrancy Warning

The sendValue function, which replaces Solidity's transfer for sending ETH, explicitly warns about the potential for reentrancy vulnerabilities due to control being transferred to the recipient. While sendValue itself is a safe way to send ETH by forwarding all available gas, the calling contract must implement proper reentrancy protection (e.g., ReentrancyGuard or the Checks-Effects-Interactions pattern) to prevent malicious re-entry attacks (7.2 Code Security).I-02

Issue

The sendValue function, which replaces Solidity's transfer for sending ETH, explicitly warns about the potential for reentrancy vulnerabilities due to control being transferred to the recipient. While sendValue itself is a safe way to send ETH by forwarding all available gas, the calling contract must implement proper reentrancy protection (e.g., ReentrancyGuard or the Checks-Effects-Interactions pattern) to prevent malicious re-entry attacks (7.2 Code Security).

Fix

When using sendValue or any function that performs external calls, ensure that the calling contract strictly adheres to the Checks-Effects-Interactions pattern. Integrate a reentrancy guard mechanism (e.g., OpenZeppelin's ReentrancyGuard) in functions that modify state before making external calls to untrusted addresses.

Status

Unresolved

Info

Usage of Low-Level Call Functions

The library provides several functionCall variants for performing low-level call, staticcall, and delegatecall operations. These functions are correctly implemented with error handling and revert bubbling. However, low-level calls inherently carry risks if the target contract is untrusted, malicious, or buggy. Misuse of these functions, especially delegatecall, can lead to critical vulnerabilities in the calling contract if not handled with extreme care (7.2 Code Security).I-03

Issue

The library provides several functionCall variants for performing low-level call, staticcall, and delegatecall operations. These functions are correctly implemented with error handling and revert bubbling. However, low-level calls inherently carry risks if the target contract is untrusted, malicious, or buggy. Misuse of these functions, especially delegatecall, can lead to critical vulnerabilities in the calling contract if not handled with extreme care (7.2 Code Security).

Fix

Developers should use low-level call functions only when absolutely necessary and with a thorough understanding of their implications. Always validate the target address and the data payload. For delegatecall, ensure the target contract is fully trusted and compatible with the calling contract's storage layout to prevent storage collisions or unexpected behavior.

Status

Unresolved

Info

Library Nature and Integration Risk

As a utility library, Address.sol is designed to be imported and used by other contracts. While the library itself is highly secure and well-audited, its security posture within a larger system is dependent on the correct and secure integration by consuming contracts. Flaws in the application logic of contracts using Address.sol could inadvertently introduce vulnerabilities, even if the library functions are used as intended (7.1 Architecture, 7.6 External).I-04

Issue

As a utility library, Address.sol is designed to be imported and used by other contracts. While the library itself is highly secure and well-audited, its security posture within a larger system is dependent on the correct and secure integration by consuming contracts. Flaws in the application logic of contracts using Address.sol could inadvertently introduce vulnerabilities, even if the library functions are used as intended (7.1 Architecture, 7.6 External).

Fix

Developers should treat the integration of Address.sol (and any external library) as a critical security boundary. Comprehensive unit and integration testing should be performed on all functions that utilize Address.sol utilities. A holistic security review of the entire system, including how Address.sol is used, is recommended.

Status

Unresolved

Analysis

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

This audit covers the OpenZeppelin Address.sol library, a foundational component for secure address interactions in Solidity. The library itself is highly robust, well-tested, and adheres to best practices, providing essential utilities like safe value transfers and low-level call wrappers. While the library is secure, its functions require careful integration and understanding by consuming contracts to prevent common vulnerabilities such as reentrancy or incorrect handling of external calls. The audit identifies several informational points regarding the intended use and limitations of its functions.

Technical10/10Low risk

The Address.sol library demonstrates high technical quality, adhering to secure coding standards and providing robust utilities for EVM interactions (7.2 Code Security). Functions like sendValue and functionCallWithValue correctly handle external calls with proper error checking and gas forwarding. The library includes explicit warnings within its NatSpec documentation regarding potential pitfalls, such as the limitations of isContract and reentrancy risks with sendValue. The architecture (7.1 Architecture) is modular and follows established patterns for utility libraries, ensuring reusability and clarity. No direct access control issues (7.3 Access Control) are present as it's a stateless library.

Governance10/10Low risk

As a foundational utility library, Address.sol does not implement any economic mechanisms (7.4 Economic) or governance structures (7.5 Governance). Therefore, there are no inherent economic or governance risks within this specific contract. The risk level is considered Low due to the absence of these components.

Upgrades10/10Low risk

The Address.sol contract is a library and is not designed to be upgradeable via proxy patterns (7.7 Upgrades). It is typically deployed as an immutable component or included directly in other contracts. Consequently, there are no upgrade-related risks associated with this specific contract. The risk level is considered Low due to the absence of upgradeability features.

Final RecommendationWhat to do about this score

While the OpenZeppelin Address.sol library is inherently secure and well-audited, consuming contracts must exercise diligence in its integration.

Developers should thoroughly review the NatSpec documentation for each function, paying particular attention to warnings regarding reentrancy, external call safety, and the limitations of isContract. Implement the Checks-Effects-Interactions pattern consistently when using functions that perform external calls, and consider using reentrancy guards where appropriate. Ensure that any contract interacting with Address.sol adheres to secure development best practices to mitigate risks arising from misuse.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1mo
Contract0x209e…ffff
Deployer0x9467…0a70
Badge for your website
BNI 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, 20260Low
  2. Aug 14, 20264Low

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

Related Audits

6 more on the recordAll audits
TCryptochicksTCC · BNB Chain0Low币安人生BNB Chain0LowSKYAIBNB Chain0LowBBNB Chain0LowDOYRBNB Chain0LowCREPEBNB Chain0Low

Would You Like a More Detailed Audit of BNI?

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