Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

AgentBNB Info

agentbnb.xyz

A non-custodial AI agent that works from the user's own wallet inside a plain-language mandate, enforced by a contract and recorded in a verifiable on-chain log.

AgentBNB Logo
Onboarded date 17/10/2026

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

79.71
Poor Excellent

Real-Time Threat Detection

Real-time threat detection, powered by Cyvers.io, is currently not activated for this project.

This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks. For more information, click here.

Security Assessments

"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
0xFe86...d4Ba
Network
BNB Smart Chain - Mainnet
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2026/10/17
Revision date 2026/10/17

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Contract owner cannot mint

It is not possible to mint new tokens.

Contract owner cannot blacklist addresses.

It is not possible to lock user funds by blacklisting addresses.

Contract owner cannot set high fees

The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.

Contract cannot be locked

Owner cannot lock any user funds.

Token cannot be burned

There is no burning within the contract without any allowances

Ownership is not renounced

The owner retains significant control, which could potentially be used to modify key contract parameters.

Contract is not upgradeable

The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

Smart Contract Analysis Statement

Contract Analysis

The AgentBNB contract implements an ERC20 token with a fixed supply of 1,000,000,000 AGNT and 18 decimals, holder-initiated burning through burn and burnFrom, and gasless approvals through EIP-2612 permit signatures. The contract consists of a single constructor on top of unmodified OpenZeppelin Contracts 5.6.1 components and is deployed on BNB Smart Chain at 0xFe864a73571D9836b293d7fC5bD7F89777fDd4Ba, where its verified source code matches the deployed bytecode exactly. It contains no minting function after deployment, no fees or taxes, no transfer restrictions, no blacklist, no pause mechanism and no upgrade path.

Ownership Privileges

The ownership of the contract has been left out by design - AgentBNB does not implement an owner, an administrator or any role-based access control, so no address can change its behavior after deployment. The only party with outsized influence is the deployer wallet 0xb6C03B4E9674De78C97f6Be3e8E1F940dF6f4272, a single externally owned account that received the entire supply at deployment and still held all of it at the time of the audit. In the absence of a contract owner, this wallet is referred to as the owner below. Its powers are purely economic and come from holding the tokens, not from any special contract function. The owner retains full privileges including:

  • Full control over 100% of the token supply through one private key, without multisig protection
  • Free decision over when and how tokens are distributed, sold or provided as liquidity, since no vesting or lock is in place
  • Burning any amount of its own tokens, which permanently reduces the total supply
  • Granting allowances to other addresses through approve or gasless permit signatures
  • The owner cannot mint new tokens - the supply was fixed in the constructor and no mint function exists
  • The owner cannot pause transfers, blacklist addresses or freeze the balances of other holders
  • The owner cannot introduce or change fees, taxes, or transaction and wallet limits, as none exist in the contract
  • The owner cannot upgrade, replace or destroy the contract - it is not a proxy and contains no self-destruct or delegatecall

Security Features

The contract implements several positive security features:

  • It relies exclusively on unmodified OpenZeppelin Contracts 5.6.1 code, confirmed file by file against the official release, with no known security advisories for this version
  • The verified source code matches the deployed bytecode exactly, and no function can increase the fixed supply or move tokens without the holder's consent
  • Permit signatures are protected against replay and manipulation through per-owner nonces, deadlines, an EIP-712 domain bound to chain id 56 and to the contract address, and the rejection of malleable signatures
  • Solidity 0.8 checked arithmetic, custom errors, zero-address validation and the absence of external calls apart from signature recovery leave no room for overflow or reentrancy issues

Auditor Comments

We did not identify any critical, high or medium severity issues. The contract is a minimal, standards-compliant token whose behavior is fully determined by well-reviewed library code, and its claimed properties were confirmed both in the source code and on-chain. The only low severity finding concerns the concentration of the entire supply in one externally owned account, which is an operational and economic risk rather than a code defect, but it is the most relevant point for holders: until the supply is distributed transparently, the value of the token depends on the security and the intentions of a single key holder.

The informational findings describe behaviors that every standard ERC-20 token with permit shares - the approval race, permit front-running against careless integrations, zero-value transfers that can be abused for address poisoning, tokens accidentally sent to the contract address, and allowance updates that emit no event - together with minor code quality points such as the floating pragma, an outdated library version comment, an unnamed supply literal and missing documentation. Because the contract is immutable, these points are best handled through user education, careful integrations and, where relevant, future deployments. We recommend that the team moves the supply into a multisig wallet, places allocations into audited vesting contracts, locks liquidity once a trading pair exists and publishes its distribution plan before trading begins.

Note - This Audit report consists of a security analysis of the AgentBNB smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the AgentBNB team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.

Files and details

Findings and Audit result

Critical
High
Medium
1
Low
1
Optimization
9
Informational
low Issues | 1 findings

Pending

#1 low Issue
Entire token supply is controlled by a single externally owned account
AgentBNB.sol
L14
Description

The constructor mints the complete fixed supply of 1,000,000,000 AGNT to the recipient argument, and the deployment transaction passed the deployer's own address 0xb6C03B4E9674De78C97f6Be3e8E1F940dF6f4272. On-chain checks show that this address is a plain externally owned account with no contract code and no EIP-7702 delegation, and at the time of the audit it still held 100% of the supply. No multisig, vesting contract, timelock or liquidity lock is involved, so the safety and the distribution of every token depend on a single private key and on the conduct of its holder. A compromised or lost key would expose or freeze the entire supply. Because the contract has no owner functions, this risk cannot be reduced on the contract level after deployment and has to be addressed operationally.

Comments

We recommend moving the treasury to a multisig wallet, for example a Safe with at least three independent signers using hardware keys, placing team, investor and ecosystem allocations into audited vesting or timelock contracts, and locking liquidity once a trading pair is created. The project should publish the intended distribution together with the wallet addresses so that holders can verify it on-chain. For any future deployment, the constructor should mint directly into the multisig or the vesting contracts instead of an individual wallet.

optimization Issues | 1 findings

Pending

#1 optimization Issue
Low optimizer runs setting for a frequently used token
AgentBNB.sol
LN/A (compiler settings)
Description

The contract was compiled with the optimizer set to 200 runs, which favours a cheaper deployment over cheaper function calls. Our measurements with 10,000 runs show savings of about 120 gas per transfer, 182 gas per transferFrom, 72 gas per approve and 105 gas per permit, at the cost of roughly 202,000 additional gas once at deployment. For an actively traded token the extra deployment cost would be recovered after about 1,700 transfers. The absolute saving on BNB Smart Chain is small, so this is a minor efficiency point.

Comments

The deployed contract cannot be changed, so this only applies to future deployments of this or similar tokens. For high-volume tokens we recommend a higher optimizer runs value, such as 10,000 or more, after confirming the trade-off for the expected usage.

informational Issues | 9 findings

Pending

#1 informational Issue
Approve front-running race condition
ERC20.sol
L120-124
Description

The inherited approve function overwrites the existing allowance in a single step. If a holder changes a non-zero allowance to a different non-zero value, the current spender can watch the pending transaction, spend the old allowance first and then also spend the new one once the change is mined. In the worst case the spender moves the sum of both allowances instead of the intended new amount. This is the well-known ERC-20 approval race and applies to every standard ERC-20 token, it is not specific to AgentBNB.

Comments

Since the contract is immutable, this has to be handled by users and integrators. Wallets and dApps should reduce an allowance to zero and wait for confirmation before setting a new non-zero value, or verify the current allowance immediately before replacing it. Holders should prefer exact-amount approvals over unlimited ones and revoke allowances that are no longer needed.

Pending

#2 informational Issue
Permit signatures can be front-run to break integrating contracts
ERC20Permit.sol
L42-65
Description

The permit function can be executed by any account that knows a valid signature. When a user calls an integrating contract that first calls permit and then transferFrom, the signature is visible in the public mempool. A third party can copy it and submit permit directly before the user's transaction is mined. The allowance is then set exactly as the user intended, but the integrator's own permit call fails because the nonce has already been used, and the whole user transaction reverts. No tokens are lost, yet the user flow breaks and the griefing can be repeated cheaply. Off-chain permit signatures are also a common phishing vector, because a single signed message grants an allowance without any transaction from the holder.

Comments

Integrating contracts should wrap the permit call in a try/catch block and continue when the allowance is already sufficient, instead of relying on permit to succeed. Front-ends should present permit requests as clearly readable typed data with short deadlines and exact amounts, and users should only sign permit messages for applications they trust.

Pending

#3 informational Issue
Zero-value transferFrom can be used to spoof transfer history
ERC20.sol
L142-147
Description

The allowance check in transferFrom passes whenever the requested amount is zero, so any account can call transferFrom with a value of zero from an arbitrary holder to an arbitrary recipient without having any allowance. The call succeeds and emits a Transfer event that appears to originate from the victim. Attackers use this behavior for address poisoning, where look-alike addresses are planted into a victim's history in explorers and wallets in the hope that the victim later copies the wrong address. The same applies to burnFrom with a value of zero. The behavior is compliant with ERC-20, which requires zero-value transfers to be treated as normal transfers, so it is a user-safety concern rather than a defect in the token logic.

Comments

No change is possible in the deployed contract without breaking ERC-20 compatibility. We recommend that the project informs its community about address poisoning, that integrated wallets and explorers hide zero-value transfers by default, and that users always verify the complete recipient address. A future token version could reject zero-value transferFrom calls from spenders without any allowance, after weighing the compatibility impact.

Pending

#4 informational Issue
Tokens sent to the token contract address are permanently locked
ERC20.sol
L159-167
Description

The internal transfer logic only rejects the zero address as a recipient. Tokens sent to the AgentBNB contract address itself, a frequent user mistake when the token address is pasted as the destination, are credited to the contract. The contract never approves or transfers tokens on its own behalf and offers no recovery function, so such balances can never be moved again. The same holds for any other ERC-20 token sent to this address by mistake. At the time of the audit the contract address held no tokens.

Comments

For future deployments we recommend rejecting transfers whose recipient is the token contract itself by overriding the internal update hook. For the current deployment, wallets and front-ends should warn or block when the recipient equals the token address. We do not recommend adding a rescue function, since that would introduce a privileged role into an otherwise ownerless design.

Pending

#5 informational Issue
Allowance changes during transferFrom and burnFrom emit no Approval event
ERC20.sol
L294-304
Description

When a spender uses an allowance through transferFrom or burnFrom, the remaining allowance is reduced without an Approval event being emitted. This follows the gas-saving design of the underlying library and is permitted by ERC-20, but it means that the allowance state changes silently. Dashboards, allowance revocation tools and indexers that rebuild allowances purely from Approval events will show outdated values to users.

Comments

Off-chain services should always read the current allowance from contract state instead of rebuilding it from events. If complete event coverage is required for a future version, the internal approve function can be overridden so that it always emits the Approval event.

Pending

#6 informational Issue
Floating compiler pragma
AgentBNB.sol
L3
Description

The contract declares pragma solidity ^0.8.27, which accepts any 0.8 compiler from version 0.8.27 onwards. The deployed bytecode was produced with version 0.8.34, but the source file alone does not enforce this. Some compiler versions inside the accepted range contain known bugs, for example a high-severity transient storage clearing issue in versions 0.8.28 to 0.8.33 that affects the IR pipeline. None of these bugs is reachable in this contract, yet a floating pragma makes rebuilding and verifying the exact deployed bytecode less reliable.

Comments

Pin the pragma to the compiler that was actually used, for example pragma solidity 0.8.34, and keep the full compiler configuration, the optimizer enabled with 200 runs and the osaka EVM target, in the project build configuration so that the deployment can always be reproduced.

Pending

#7 informational Issue
Library version comment does not match the dependency used
AgentBNB.sol
L2
Description

The header comment states that the contract is compatible with OpenZeppelin Contracts ^5.7.0, while the verified deployment was compiled against version 5.6.1, whose files are identical to the official release. Rebuilding with version 5.7.0, as the comment suggests, produces different bytecode because the EIP-712 module changed between these releases. The token behavior is equivalent, but the comment misleads reviewers and makes independent verification of the deployment harder.

Comments

Update the comment to the version that was actually used and pin the dependency to exactly 5.6.1 in the package manifest and lockfile, so that reviewers and verification services can reproduce the deployed bytecode.

Pending

#8 informational Issue
Initial supply is defined with an unnamed hard-to-read literal
AgentBNB.sol
L14
Description

The constructor mints 1000000000 * 10 ** decimals() tokens. The ten-digit literal has no digit separators and is not defined as a named constant, which makes it easy to misread by a factor of ten during reviews or future changes and hides the intended supply from anyone reading the public interface.

Comments

Define the value as a public constant, for example uint256 public constant INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18, and mint that constant in the constructor. This improves readability, exposes the intended supply on-chain and removes the exponentiation at construction time.

Pending

#9 informational Issue
Missing NatSpec documentation
AgentBNB.sol
L9-15
Description

The contract and its constructor have no NatSpec comments. Important properties such as the fixed supply, the absence of any owner or administrative functions, the burn capability, the permit domain and the meaning of the recipient parameter are not documented in the source code, even though explorers and wallets display this documentation to users.

Comments

Add @title, @notice and @dev tags to the contract and a @param tag for the recipient argument, describing the fixed supply, the ownerless design and the supported extensions.