Bridge security record

In the contract `StakePoolV2` the role `_owner` has authority over the function shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and modify the maximum deposit amount. If the maximum deposit amount is set to 0, then any deposit request will be blocked. 

In the contract `[Ownable]`, the role `[owner]` has authority over the following functions: - transferOwnership() - renounceOwnership() Any compromise to the `[owner]` account may allow a hacker to take advantage of this authority and become a malicious owner to potentially steal funds. In the contract `[Pauseable]`, the role `[owner]` has authority over the following functions: - halt() - start() Any compromise to the `[owner]` account may allow a hacker to take advantage of this authority and make the contract malfunction.

All of the [BridgeToken] tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute [BridgeToken] tokens without obtaining the consensus of the community.

In the contract `[StandardToken]`, the role `[owner]` has authority over the following functions: - mint() - burn() Any compromise to the `[owner]` account may allow a hacker to take advantage of this authority and mint unlimited tokens to arbitrary accounts and burn owner's tokens.

In the contract `[BridgeToken]`, the role `[owner]` has authority over the following functions: - freeze() - melt() - transferAnyBEP20() - withdrawBNB() Any compromise to the `[owner]` account may allow a hacker to take advantage of this authority and steal ERC20 tokens and BNB from the contract.

The `callOptionalReturn()` function is being used to transfer tokens, and if the token address is found in the mapping `bugERC20s`, the result of the function call is not checked to determine if the transfer was successful. ```solidity=110 function callOptionalReturn(IERC20 token, bytes memory data, mapping(address => uint8) storage bugERC20s) private { // We need to perform a low level call here, to bypass Solidity's return data size checking mechanism, since // we're implementing it ourselves. // A Solidity high level call has three parts: // 1. The target address is checked to verify it contains contract code // 2. The call itself is made, and success asserted // 3. The return value is decoded, which in turn checks the size of the returned data. // solhint-disable-next-line max-line-length require(address(token).isContract(), "SafeERC20: call to non-contract"); // solhint-disable-next-line avoid-low-level-calls (bool success, bytes memory returndata) = address(token).call(data); require(success, "SafeERC20: low-level call failed"); if (bugERC20s[address(token)] != 0) { return; } if (returndata.length > 0) { // Return data is optional // solhint-disable-next-line max-line-length require(abi.decode(returndata, (bool)), "SafeERC20: ERC20 operation did not succeed"); } } ``` This function is called internally in the `createOrSignWithdraw()` function, which means that if the token transfer fails, then the user will not receive the assets. This function is called internally in the `crossOut()` or `crossOutII()` functions, which means that if the tokens transfer fails, then the user may get the assets without having to transfer out the assets.

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 ```solidity=645 token.safeTransferFrom(address(msg.sender), address(this), _amount); ``` - Transferring tokens by `_amount`. But the actual token amount received by the recipient might not equal to `_amount`. ```solidity=646 addressTotalAmount[msg.sender] = myTotal.add(_amount); totalAmount = totalAmount.add(_amount); ``` - The `addressTotalAmount` and `totalAmount` used for bookkeeping purposes without compensating the potential transfer fees.

It is possible that after `burn()` is called, the message sender's frozen amount > balance, which will result in the token transfer from the message sender always fails.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur and the transaction may fail due to the validation checks. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee) to the target contract, only 90 tokens actually arrive to the contract.

The function `stopReward()` can be called by the owner to stop the accumulation of rewards. However, if `bonusEndBlock` is already less than `block.number`, then the user may still receive some additional rewards even after `stopReward()` is called. Therefore, it's important to check the current value of `bonusEndBlock` before calling `stopReward()`.