NetMind XYZ

In the contract `AgentFactory`, the role `_bonding` has authority over the functions shown in the diagram below. Any compromise to the `_bonding` account may allow the hacker to take advantage of this authority and register a new application, graduate a token with specified dex pair.  In the contract `AgentFactory`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the bonding address, set the agent NFT address, and set the vault address.  In the contract `NetmindAgentNFT`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and mint new tokens safely.  In the contract `AgentToken`, the role `_ownerorbonding` has authority over the functions shown in the diagram below. Any compromise to the `_ownerorbonding` account may allow the hacker to take advantage of this authority and set the swap threshold basis points, set project tax rates, set the token status, add a new liquidity pool address, remove a liquidity pool, withdraw ETH to a specified address, set the project tax recipient, and withdraw specified ERC20 tokens to a given address.  In the contract `AgentVault`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and safely transfer token ownership.  In the contract `StakeVault`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the lock period, withdraw tokens after the lock period ends, and burn tokens by transferring to address zero.  In the contract `Bonding`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the agent token implementation address, set the stake vault implementation address, set token admin address, set the grad threshold, set token parameters, set the initial supply, set the fee and fee recipient address, and set the asset rate and set the token information.  In the contract `FFactory`, the role `ADMIN_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `ADMIN_ROLE` account may allow the hacker to take advantage of this authority and set tax parameters or set the router address.  In the contract `FFactory`, the role `CREATOR_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `CREATOR_ROLE` account may allow the hacker to take advantage of this authority and create a token pair.  In the contract `FRouter`, the role `EXECUTOR_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `EXECUTOR_ROLE` account may allow the hacker to take advantage of this authority and transfer tokens and assets from a specified token address, sell tokens and transfer assets with fees, add initial liquidity to a token pair, approve asset spending for a given pair and spender, and perform a token purchase with a specified amount and address.  In the contract `FPair`, the role `router` has authority over the functions shown in the diagram below. Any compromise to the `router`

In the contract `Bonding`, `FFactory`, `FRouter`, `AgentFactory`, `AgentToken` and `StakeVault`, the role `admin` has the authority to update the implementation contract behind the contract. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.

All of the `AgentToken` tokens are sent to the contract deployer. This is a centralization risk because the deployer can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

The function `_swapTax` is designed to exchange a certain amount of the contract's tokens for USDC using the PancakeSwap/Uniswap protocol `uniswapRouter` function. This function specifies the `projectTaxRecipient` address as the recipient of the swapped tokens. The `projectTaxRecipient` address is a critical parameter within this function, as it determines the destination of the output tokens. It has been identified that the admin has the ability to alter the `projectTaxRecipient` address at any given time. This poses a security risk, as a compromised admin account could lead to unauthorized modification of the recipient address, resulting in the misdirection of funds to an attacker-controlled address. ```solidity=664 function _swapTax(uint256 tokenAmount, address pool) private { // ... (other code) uniswapRouter .swapExactTokensForTokensSupportingFeeOnTransferTokens( swapBalance_, 0, path, projectTaxRecipient, block.timestamp + 600 ) // ... (other code) } ```

The `_addInitialLiquidity()` function transfers LP tokens to a newly created `stakeVault` contract. Since the `stakeVault` contract's `initialize()` function is called by the `Bonding` contract, the owner of the `stakeVault` contract is set to the `Bonding` contract. As a result, only the `Bonding` contract can call owner-restricted functions in the `stakeVault`. However, the `Bonding` contract does not invoke these functions, leading to the LP tokens being locked in the `stakeVault`. **contracts/fun/Bonding.sol** ```solidity=305 function _addInitialLiquidity(IAgentToken token_, IERC20 _assetToken) internal returns(address){ ... (, , uint256 lpTokens) = uniswapRouter .addLiquidity( address(token_), address(_assetToken), token_.balanceOf(address(this)), _assetToken.balanceOf(address(this)), 0, 0, address(this), block.timestamp ); IStakeVault stakeVault = IStakeVault(Clones.clone(stakeVaultImpl)); tokenStake[address(token_)] = address(stakeVault); IERC20(uniswapV2Pair_).approve(address(stakeVault), lpTokens); stakeVault.initialize(uniswapV2Pair_, lpTokens); return uniswapV2Pair_; } ``` **contracts/StakeVault.sol** ```solidity=21 function initialize(address assetToken_, uint256 amount) external initializer { __Ownable_init(_msgSender()); assetToken = IERC20(assetToken_); assetToken.transferFrom(_msgSender(), address(this), amount); lockAmount = amount; lockTime = block.timestamp; lockPeriod = 10 * 365 * 1 days; } ```

When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee),, only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f

In the Uniswap AMM system, a deadline is typically set for token swaps to prevent transactions from being executed after a certain amount of time, which could result in unfavorable price slippage. However, in the current contract, when conducting transactions using the Uniswap function, the deadline is set to `block.timestamp` or more than `block.timstamp`, meaning "the deadline check will pass whatever block the transaction is in" due to the check of deadline `require(deadline >= block.timestamp, 'UniswapV2Router: EXPIRED')` which will always pass. If bots and maximal extractable value (MEV) strategies are widely used, it could affect many transactions. A malicious miner can hold the transaction as he wants to incur the maximum loss is reached. Therefore, the absence or incorrect usage of a deadline could make transactions more susceptible to front-running / MEV attacks, leading to greater price slippage losses.

HTTP/HTTPS should not be used for token metadata because the server owner can change token metadata at will, which can dramatically affect the token value. ```solidity=17 function _baseURI() internal pure override returns (string memory) { return "http://xyz.netmind.ai/agentNFT/"; } ```

A sandwich attack can occur when an attacker notices a transaction involving token swaps or liquidity additions that lacks slippage restrictions or minimum output amount settings. The attacker can exploit this by frontrunning the transaction to purchase one of the assets, thereby manipulating the exchange rate, and then backrunning the transaction to sell the asset for a profit. The referenced functions are invoked without setting slippage restrictions or minimum output amounts, making transactions that trigger these functions particularly vulnerable to sandwich attacks, especially when large input amounts are involved.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=53 IUniswapV2Router public uniswapRouter; ``` - The contract `AgentToken` interacts with third party contract with `IUniswapV2Router` interface via `uniswapRouter`. ```solidity=11 IERC20 public assetToken; ``` - The contract `StakeVault` interacts with third party contract with `IERC20` interface via `assetToken`. ```solidity=24 address public assetToken; ``` - The contract `FRouter` interacts with third party contract with `IERC20` interface via `assetToken`. ```solidity=37 IUniswapV2Router public uniswapRouter; ``` - The contract `Bonding` interacts with third party contract with `IUniswapV2Router` interface via `uniswapRouter`. ```solidity=4 interface IProxyAdmin { function changeProxyAdmin(address proxy, address newAdmin) external; function upgrade(address proxy, address implementation) external; function transferOwnership(address newOwner) external; } ``` - The contract `Management` interacts with third party contract with `IProxyAdmin` interface via `proxyAdmin`.