Kontos security record

The `EntryPoint` contract contains multiple low level calls with no reentrancy protection and unclear replay protection. As such, reentrancy could be possible. As an example, the `distributeRewards()` performs a low level call in line 278, which could result in malicious actors receiving more rewards than what they are eligible for if reentrancy occurs.

In the `handleProofTask()` function, proof types of `NEW_REGULAR_ACCOUNT`, `NEW_MULTI_SIG_ACCOUNT`, and `OPERATION_TASK` are no-ops, indicating incompleteness of function logic.

One or more parameters with `memory` data location are never modified in their functions and those functions are never called internally within the contract. Thus, their data location can be changed to `calldata` to avoid the gas consumption copying from calldata to memory. ```solidity=47 function getManagedContractsByString(string memory index) public view returns (address){ ``` `getManagedContractsByString` has memory location parameters: `index`.

The `handleProofTask()` function does not check if there is a valid account for the `proof.payer`. If the account does not exist, then the `EntryPoint` contract could end up being the payer for reward distribution instead. Additionally, there is no requirement that the `proof.payer` account has sufficient asset balance for the reward distribution.

The `preValidateUserOp()` function does not check that the user account has enough `requiredAssets` balance for prepayment. Without enough balance, the user should not be able to trigger the execution of its UserOp. Additionally, the `fundInfo` in the `UserOperation` is never used or checked in the `EntryPoint` contract.

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities.

The `supportsInterface()` function always returns `false`, indicating a lack of support of any interface. However, the contract does support multiple interfaces, including but is not limited to IERC721Receiver, IERC1155Receiver, IProxy, etc.

The `SafeMath` library is used unnecessarily. With Solidity compiler versions 0.8.0 or newer, arithmetic operations will automatically revert in case of integer overflow or underflow.

The following code does not increment `versionIds[index]`. ```solidity=111 versionIds[index] = versionIds[index]++; ``` Based on Solidity documentation (https://docs.soliditylang.org/en/latest/types.html#compound-and-increment-decrement-operators), a++ and a-- are equivalent to a += 1 / a -= 1 but the expression itself still has the previous value of a. In contrast, --a and ++a have the same effect on a but return the value after the change.