X314 - Audit

**Important Note: Certain identification and KYC procedures were attempted to be applied to the project team in order to better understand the centralization situation and potential risks of the project. Based on the collected information and further conducted investigation, the project failed to pass the criteria with a certain amount of negative signals. Thus the case analysis concluded that there is potential high risk to the project. We strongly advise end users to conduct further research and exercise due diligence before engaging with the project. It is crucial for end users to independently verify and assess all available information to make informed decisions.** In the `X314` protocol, only the owner can add liquidity as a liquidity provider, and it can be done only once. The owner can set an LP unlock time, after which the liquidity provider can withdraw all native tokens ('BNB') from the contract and close swap trading. Once this action is performed, the contract will no longer have any liquidity to support transactions. This results in the `X314` token holders being unable to sell their tokens, effectively rendering the contract non-functional and causing losses to token holders. Additionally, all other `X314` tokens for liquidity will be locked in the contract. ```solidity function removeLiquidity() public onlyLiquidityProvider { require(block.number > blockToUnlockLiquidity, "Liquidity locked"); tradingEnable = false; payable(msg.sender).transfer(address(this).balance); emit RemoveLiquidity(address(this).balance); } ```

**Important Note: Certain identification and KYC procedures were attempted to be applied to the project team in order to better understand the centralization situation and potential risks of the project. Based on the collected information and further conducted investigation, the project failed to pass the criteria with a certain amount of negative signals. Thus the case analysis concluded that there is potential high risk to the project. We strongly advise end users to conduct further research and exercise due diligence before engaging with the project. It is crucial for end users to independently verify and assess all available information to make informed decisions.** 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 and renounce ownership of the contract or transfer the contract ownership.  In the contract `X314`, 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 enable or disable wallet maximum holding limit, set the buy fee, set trading open time, set maximum wallet amount, send tokens to multiple addresses without cooldown limitation, set the cooldown seconds, set the sell fee, add liquidity and enable trading, initialize the liquidity amount, and set exclude cooling status for accounts.  In the contract `X314`, the role `excludeCoolingOf` has authority over the functions shown in the diagram below. Any compromise to the `excludeCoolingOf` account may allow the hacker to take advantage of this authority and execute a buy or sell transaction without fees and conditions when trading is not open.  In the contract `X314`, the role `liquidityProvider` has authority over the functions shown in the diagram below. Any compromise to the `liquidityProvider` account may allow the hacker to take advantage of this authority and extend the liquidity lock duration, removing liquidity if unlocked. All native tokens (`BNB`) in the contract will be claimed when removing liquidity, and users cannot buy or sell tokens through the contract.  In the contract `X314`, the role `mkt_314` has authority over the functions shown in the diagram below. Any compromise to the `mkt_314` account may allow the hacker to take advantage of this authority and withdraw any ERC20 token from the contract except the `X314` token. 

**Important Note: Certain identification and KYC procedures were attempted to be applied to the project team in order to better understand the centralization situation and potential risks of the project. Based on the collected information and further conducted investigation, the project failed to pass the criteria with a certain amount of negative signals. Thus the case analysis concluded that there is potential high risk to the project. We strongly advise end users to conduct further research and exercise due diligence before engaging with the project. It is crucial for end users to independently verify and assess all available information to make informed decisions.** All of the `X314` tokens are sent to the contract and an externally-owned account (EOA) address, and the owner of the EOA address can withdraw `X314` tokens before adding liquidity. This is a centralization risk because the deployer or the owner(s) of the EOAs 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 `X314` protocol has designed a transaction fee that is charged to users during actual swap transactions. ```solidity function getAmountOut(uint256 value, bool _buy) public view returns (uint256) { (uint256 reserveETH, uint256 reserveToken) = getReserves(); if (_buy) { return (value * reserveToken) / (reserveETH + value); } else { return (value * reserveETH) / (reserveToken + value); } } ``` However, the `getAmountOut()` function does not incorporate transaction fees in the calculations. The outcomes may not meet users expectations if they rely on the function's return result as a reference.

When a user purchases `X314` tokens, they are subject to the maximum holding limit if they are not in the `excludeCoolingOf` list. ```solidity function buy() internal { ... if ( maxWalletEnable && _maxWallet != 0 && !excludeCoolingOf[msg.sender] ) { require(balanceOf(msg.sender) <= _maxWallet, "Max wallet exceeded"); } emit Swap(msg.sender, swapValue, 0, 0, user_amount); } ``` However, this limit is only enforced during purchases and not during regular transactions. This means a user could potentially receive X314 tokens from multiple accounts, exceeding the maximum holding limit.

In the `_basicTransfer()` function, relevant parameters lack sanity checks. If the transaction addresses are zero addresses, it may lead to potential losses. Additionally, a transaction amount of zero is meaningless. For instance, when the transaction amount is calculated as zero during purchase operations due to rounding issues, users will not receive any `X314` tokens and will lose the native tokens they paid.

When users perform token swaps without a minimum output amount or slippage parameter, transactions execute without safeguards. This not only exposes users to the risk of receiving fewer tokens than expected due to price slippage but also makes them susceptible to sandwich attacks. In a sandwich attack, a malicious actor inserts their transactions before and after the user's transaction, manipulating the price for profit, causing the user to complete the trade at an unfavorable price and incur financial losses. Despite the cooldown limitation and same block limitation, accounts listed in `excludeCoolingOf` do not face these restrictions and can easily execute sandwich attacks.

The `transferFrom()` function contains different restrictions compared to the `transfer` function, resulting in inconsistent behavior between these two core ERC-20 functions. This inconsistency can lead to a situation where a transfer to the `X314` contract (Sell transaction) might fail when using `transferFrom()`, but the same transfer could succeed using `transfer()`. Such discrepancies can create confusion for users and may lead to potential incompatibilities with other contracts. ```solidity function transferFrom( address from, address to, uint256 amount ) public virtual returns (bool) { ... if (to == address(this)) { require(false,"reject self"); // sell(from, amount); } else { _transfer(from, to, amount); } ... } ```

A local variable is shadowing another component defined elsewhere. This means that when the contract accesses the variable by its name, it will use the one defined locally, not the one defined in the other place. The use of the variable may lead to unexpected results and unintended behavior. ```solidity=191 address _owner, ``` - Local variable `_owner` in `X314.allowance` shadows the variable `_owner` in `Ownable`. ```solidity=226 address _owner, ``` - Local variable `_owner` in `X314._approve` shadows the variable `_owner` in `Ownable`. ```solidity=201 address _owner = msg.sender; ``` - Local variable `_owner` in `X314.approve` shadows the variable `_owner` in `Ownable`. ```solidity=238 address _owner, ``` - Local variable `_owner` in `X314._spendAllowance` shadows the variable `_owner` in `Ownable`.

The smart contract contains low-level call (`.call()`) to send ether to the account `mkt_314`.If the account `mkt_314` is a contract that manages to receive ether with customized logic, it may introduce vulnerabilities such as reentrancy, unexpected gas consumption, or unexpected revert. ```solidity=469 (bool success,) = address(mkt_314).call{value: fundValue}(""); ```