JAM security record

In the design of the `JamAI` contract, a Uniswap V3 pool is intended to be created once a sufficient number of tickets have been sold, a process that may take some time. However, since the token can be predicted using the `predictToken()` function, a malicious attacker could create the pool before `JamAI` activates it, thereby obstructing the activation operation. Consequently, buyers might incur losses due to protocol fees required to participate, despite being able to sell their tickets. ```solidity function _createPool(AIAgentToken token) internal returns (address, uint256) { address pool = pancakeV3Factory.createPool(address(token), WETH, POOL_FEE); ... } ```

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

In the `startTrading()` function, users can provide a message and signature to initiate trading. The function decodes the message into relevant data and verifies its validity. ```solidity uint256 chainId; address contractAddress; uint256 aiAgentId; string memory name; string memory symbol; bytes32 salt; address creator; uint256 amount; (chainId, contractAddress, aiAgentId, name, symbol, salt, creator, amount) = abi.decode( message, (uint256, address, uint256, string, string, bytes32, address, uint256) ); ``` However, inconsistent data types during decoding won't cause the transaction to revert. If the data type during encoding is inconsistent with the data type during decoding, potentially resulting in unexpected data from message decoding. For example, decode a string type as a uint type.

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. ### External call(s) ```solidity=162 (bool success1, ) = msg.sender.call{value: price - protocolFee}(""); ```

In the `updateTokenInfo()` function, the owner can update the salt used during the deployment of the token contract and perform validity checks on the salt. ```solidity function updateTokenInfo( uint256 aiAgentId, string calldata newName, string calldata newSymbol, bytes32 newSalt ) external onlyOwner { if (pools[aiAgentId] != address(0)) revert PoolLaunched(); if (!jammer.deployDataValid(aiAgentId, newName, newSymbol, newSalt)) revert InvalidTokenInfo(); preTokenInfo[aiAgentId].salt = newSalt; } ``` However, after the check is completed, the token's name and symbol are not updated. This means that during the creation of the token contract, the outdated name and symbol are used, which might result in the token contract address not meeting the requirements and causing the creation to fail. ```solidity function activatePool(uint256 aiAgentId) external { if (pools[aiAgentId] != address(0)) revert PoolAlreadyCreated(); if (ticketsSupply[aiAgentId] < threshold) revert InsufficientTicketsForPool(); uint256 ethAmountIn = getPrice(0, ticketsSupply[aiAgentId]); TokenInfo memory tokenInfo = preTokenInfo[aiAgentId]; (address token, address pool) = jammer.deployTokenAndPool{value: ethAmountIn}( tokenInfo.name, tokenInfo.symbol, tokenInfo.salt, aiAgentId ); tokens[aiAgentId] = token; pools[aiAgentId] = pool; } ```

In the `AIAgentToken` contract, within the `_claimable()` function, we suspect that the following code is intended to handle precision loss issues that may arise during calculations, potentially preventing all tokens from being fully extracted from the contract. ```solidity if (balanceOf(address(this))-amount <= 1) { amount = balanceOf(address(this)); } ``` However, this approach might not cover all cases caused by precision loss, a very small amount of tokens may be left in the contract.