Kontos security record

The creation of new SmartAccount (in the form of a `BeaconProxy`) uses the `create` opcode instead of the `create2` opcode. This deviates from a key design goal of account abstraction. According to EIP4337 (https://eips.ethereum.org/EIPS/eip-4337#first-time-account-creation): "The factory is expected to use CREATE2 (not CREATE) to create the wallet, so that the order of creation of wallets doesn’t interfere with the generated addresses." Also, the `createSmartAccount()` function should return the wallet account address even if it has already been created, so the use of the `require` statement in line 51 is incompatible with EIP4337. Separately, according to EIP4337, signature verification should take place at the account level instead of in the `EntryPoint` contract. Based on https://eips.ethereum.org/EIPS/eip-4337#specification: The account MUST validate the caller is a trusted EntryPoint. If the account does not support signature aggregation, it MUST validate the signature is a valid signature of the userOpHash, and SHOULD return SIG_VALIDATION_FAILED (and not revert) on signature mismatch. Any other error should revert. An account that works with aggregated signature, should return its signature aggregator address in the “sigAuthorizer” return value of validateUserOp.

In the `SmartAccountFactory` contract, the `initialize()`, `initBeacon()`, and `initEntryPoint()` functions can be called by anyone. A malicious user could potentially front run the call to these functions and set malicious `beacon`, `entryPoint`, and `kontosLightNode` addresses. In the `EntryPoint` contract, the `initGenesisBrokerAccount()` function can be called by anyone. A malicious user could potentially front run the call to this function and set malicious `broker` addresses.

The `isValidSignature()` function does not perform any signature verification and returns the truthy value for any input value. This deviates from a key goal of account abstraction, which is to allow users to use smart contract wallets containing arbitrary verification logic (reference: https://eips.ethereum.org/EIPS/eip-4337#motivation).

The `updatePubKey()` function updates the SmartAccount's public keys. There's no check that the new `_pk` is valid and corresponds to a point on the chosen elliptical curve. The lack of validation could result in invalid public keys being set for the SmartAccount, which means no signature validation can be successful afterwards.

The account abstraction workflow includes the prepayment of gas and the refund of unused gas fee. The prepayment of gas fee should be from the user/user's smart account (or user directed PayMaster in the original EIP4337 design) to the bundler which calls the `handleOps()` function and incurs gas cost. However, in line 177 of the `EntryPoint` contract, the prepayment workflow transfers the asset from the `payer`, which is the `broker` in line 128, to the `accountProxy` which is the user's smart account address. This is not consistent with the EIP4337 design. If the intention here is that the `broker` will subsidize users to execute their transactions, then there should be economic incentive for the broker to do so, and such logic is not included in the in-scope smart contracts. Furthermore, while the `actualGasCost` is measured in line 189, there is no actual gas refund mechanism. In EIP4337, the intended design is that the difference between the prepayment amount and the `actualGasCost` will be refunded to the user or user designated paymaster in the form of increased deposit.

The `SmartAccount` contract contains several variables with unclear usage. The existence of several variables and the lack of usage indicate that certain important functions are missing in the contract, such as replay protection. The `_kontosAddress` and `_kontosLightNode` variables are initialized or contain a default value, but is not used within the contract. The `_eoaOwner` is never initialized, which makes the `require` statement in line 98 always fail. THe `_slot` and `_usedProofs` variables are never used. The `_nonce` variable is updated in line 115 but there is no check that the `_nonce` has not bee used previously. The lack of usage of `_usedProofs` and `_nonce` indicate missing replay protection. In the `EntryPoint` contract, the `strandedAssets` variable in line 22 is declared but never used.

The variable `_eoaOwner` is never set and defaults to the zero address. This makes the `executeBatchByEOAOwner()` function uncallable due to the `require` statement in line 98, and breaks a key functionality of the `SmartAccount` contract.

In the `SmartAccountBeacon` contract, the value of `target` always equals `implementation()`, and is therefore duplicative.

The `startUpgrade()` function takes in an array of `_indexes`, and the `cancelUpgrade()` function takes in a single `_index`. However, even if a single `_index` is cancelled, the global `upgradeStatus` is set to `Idle` in line 81, which would cause the `startPreparation()` function to revert due to the check in line 90. In other words, canceling one `_index` essentially prevents all `_indexes` from being upgraded.

The contract has payable functions, making it able to receive native tokens. However, it does not have a function to withdraw the funds, which can lead to permanently locked tokens within the contract.