Quantum Audit Logo

Is BNI Safe?

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

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

BNI BNI
0x209e…ffff
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

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.

1 Low4 Informational
Volume 24h
$35.1K
Liquidity
$93.8K
Price
$0.0007801
Token Age
1mo
Top 10 Holders
41.5%

Security Findings

1 Low4 Info
Low

Reliance on Calling Contract for External Call Safety

L-01The `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).
IssueThe `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).
FixAll 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.
StatusUnresolved
Info

Limitations of `isContract` Function

I-01The `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).
IssueThe `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).
FixDevelopers 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.
StatusUnresolved
Info

`sendValue` Reentrancy Warning

I-02The `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).
IssueThe `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).
FixWhen 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.
StatusUnresolved
Info

Usage of Low-Level Call Functions

I-03The 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).
IssueThe 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).
FixDevelopers 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.
StatusUnresolved
Info

Library Nature and Integration Risk

I-04As 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).
IssueAs 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).
FixDevelopers 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.
StatusUnresolved

Category Ratings

TechnicalLow10/10

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.

GovernanceLow10/10

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.

UpgradesLow10/10

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.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

41.5% in top 10
4.9% in wallets36.6% in contracts
Effective Concentration19.5%

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

$93.8K

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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

1 addresses
Deployer
0x9467…0a70

What Raised This Score

1 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

Related Audits

6 more on the record
TCryptochicks (TCC)Low Risk币安人生Low RiskSKYAILow RiskBLow RiskDOYRLow RiskCREPELow Risk

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