NetMind security record

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) } ```

In the contract `Ownable` 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. - transfer ownership of the contract to a new account - renounce ownership will leave the contract without an owner  In the contract `AccountManage` the role `_auth` has authority over the functions shown in the diagram below. Any compromise to the `_auth` account may allow the hacker to take advantage of this authority. - freeze user's tokens for the job - deduct assets from user's account  In the contract `AccountManage` the role `_executor` has authority over the functions shown in the diagram below. Any compromise to the `_executor` account may allow the hacker to take advantage of this authority. - init user’s information - update user‘s address  In the contract `AccountManage` 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. - set `signNum`, `authSta`  In the contract `CommunityFund` 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. - set `LockTime`, `votingPeriod` - add node information - delete node information  In the contract `Conf` the role `wards` has authority over the functions shown in the diagram below. Any compromise to the `wards` account may allow the hacker to take advantage of this authority. - grant/revoke `wards` role. - update state values of `Conf` contract. - update accountant addresses. In the contract `Crosschain` 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. - set `trader`, `exector`, `threshold`, `signNum`, `pause`, `chargeRate`, `tokenSta` - withdraw the fee - add node information - delete node information  In the contract `Crosschain` the role `exector` has authority over the functions shown in the diagram below. Any compromise to the `exector` account may allow the hacker to take advantage of this authority. - pause the contract  In the contract `Crosschain` the role `trader` has authority over the functions shown in the diagram below. Any compromise to the `trader` account may allow the hacker to take advantage of this authority. - transfer the token for the user  In the contract `Ledger` the role `accountant` has authority over the functions shown in the diagram below. Any compromise to the `accountant` account may allow the hacker to take advantage of this authority. - update ledger. In the contract `Pledge` the role `_nodeaddr` has authority over the functions shown in the diagram below. Any compromise to the `_nodeaddr` account may allow the hacker to take advantage of this authority. - stake NMT or ERC20 token assets.  In the contract `Pledge` 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. - set `guarder`, `tokenSta` - update node information - add node information - delete node information  In the contract `Pledge` the role `guarder` has authority over the functions shown in the diagram below. Any compromise to the `guarder` account may allow the hacker to take advantage of this

All contracts in the project inherits upgradeable contracts, indicating that it is part of an upgradeable system. Upgradeable contracts often pair with a proxy contract that is responsible for managing contract upgrades. The `privileged roles` of the proxy often have the authority to update the implementation contract. Any compromise of the privileged account could allow a hacker to exploit this authority, potentially altering the implementation contract pointed to by the proxy and thus executing malicious functionality within the implementation contract.

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

There is no storage gap preserved in the logic contract. The storage gap is essentially reserved space within a contract's storage layout. It's a placeholder for future variables that might be added in upgraded versions of the contract. The storage gap ensures that new variables added during upgrade do not overwrite existing storage variables, preserving the integrity of the contract's state. Any logic contract that acts as a base contract and which is inherited by other upgradeable contracts should have a reasonably sized storage gap preserved. In the audit scope, all contracts are upgradeable and derive from either the `Initializable`, `Ownable`, or `ERC20` super contract.

The `refund()` function is designed to be called to return contract assets to users. when the function is invoked with an `amt` parameter less than the `paymentId`'s token amount, the remaining tokens are irretrievably locked in the contract because the function is callable only once with a specific `paymentId`. ```solidity=166 require(R.amount >= amt, "invalid amt"); ```