When a hook isn't wanted during the init of a Kernel, we still have to send an 0 address + empty array of bytes

Having another initialize method without this data could save up a bit of gas on L2, since less calldata sent (and this data is required to be sent during the contract creation, on arbitrum, it's approx 24k ArbGas that could be saved), smth like that:

function initialize(ValidationId _rootValidator, bytes calldata _validatorData) external {
  // ... Same as before
  // Hook setup would be: 
  ValidationConfig memory config = ValidationConfig({nonce: uint32(1), hook: address(0) });
  _installValidationWithoutNonceIncremental(_rootValidator, config, _validatorData, 0x);
}

Ooh and btw, the ValidationConfig fit on 32 bytes, so similarly to the custom ValidationId or ExecMode, type ValidationConfig could be a custom type on top of bytes32, saving up a bit on computation cost on L1 / alt L1

The returnData is always empty when excuting a delegate call (Refs: https://github.com/zerodevapp/kernel/blob/dev/src/utils/ExecLib.sol#L54). Is there a reason for that?

We've just come accross an issue that Kernel accounts revert with the AA21 didn't pay prefund error during the estimation phase - when calling simulateHandleOps method of EntryPoint - although the sender had enough funds.

I believe this is because Kernel.validateUserOp requires a signature to be valid before sending missingAccountFunds.

I'd suggest that Kernel.validateUserOp pays missingAccountFunds regardless of a signature otherwise it hurts UX (because we would be asking users for 2 signatures to send 1 userop)

Reference:
https://github.com/eth-infinitism/account-abstraction/blob/0a9d55ca73cd309f4ec1cda28284d2d039e552b9/contracts/core/BaseAccount.sol#L42-L48

lets say contract X wants to verify an eip712 signature.
Now contract X would already have his own typed_structure which he uses to contract the digest hash.
So when this contract would call the smartaccount isValidSignature(digest...)
The verification will fail because the kernel isValidSignature calculates a digest for the digest.
I believe isValidSignature is supposed to be used to verify requests from other contracts and not signatures designated to the smartaccount.

I have observed that every contract account created by KernelFactory utilizes low-level EVM code to instantiate a proxy instance. I am looking to verify each abstract account contract in my explorer, such as Blockcout. However, I am encountering difficulties due to the absence of proxy source code, with only EVM code available, making verification impossible.

I am interested in verifying contract accounts similar to this one: https://mumbai.polygonscan.com/address/0xc354BaCeB91E185dfeb4a1cA377F85CDE15b4097#code

Could anyone provide guidance on how to proceed with the verification of such contract accounts?

There are 3 Managers that are imported but they are absolutely not used anywhere.
From line:20 to line:22

When I run forge build, I get the error:

file cannot be resolved due to mismatch of file name case: "~/kernel/lib/forge-std/src/Console.sol": No such file or directory (os error 2)

Changing import {console} from "forge-std/Console.sol"; to lowercase import {console} from "forge-std/console.sol"; solves the above problem.

It would be nice if the contract code was commented to make it easier to follow. Consider using NatSpec format. I understand most people will treat these contracts as a black box and trust the code because it's audited, but some of us want to understand the code before committing to using Kernel. Comments would save a lot of time when reviewing the code.

• Reference to "threshold" is outdated

https://github.com/zerodevapp/zerodev-wallet-kernel/blob/acbc843ffbafa2eaf11bc6e93ed5e5d0438a24bd/src/Kernel.sol#L17

• I know the new entrypoint is not released yet, but would we want to validate & increment nonce here if it was sent directly by the owner?

https://github.com/zerodevapp/zerodev-wallet-kernel/blob/acbc843ffbafa2eaf11bc6e93ed5e5d0438a24bd/src/Kernel.sol#L66

As I typed out this comment, I realize that that would require us to pass in a nonce in this function, which is annoying.

• I wonder if it makes sense to check two signatures, once with toEthSignedMessageHash and one without. The reason is that some signers use the \x19Ethereum Signed Message:\n prefix and some don't, and we want to work with both kinds of signers. Does that make sense?

https://github.com/zerodevapp/zerodev-wallet-kernel/blob/acbc843ffbafa2eaf11bc6e93ed5e5d0438a24bd/src/Kernel.sol#L137

https://github.com/zerodevapp/zerodev-wallet-kernel/blob/acbc843ffbafa2eaf11bc6e93ed5e5d0438a24bd/src/Kernel.sol#L180

• Right now the AccountFactory is tied to MinimalAccount. Would it make sense to create an abstract contract with the initialize method, and have the AccountFactory tie to that instead? That way we can use the AccountFactory with the PluginAccount too.

Hi, team! Sorry for bothering you with issues, but I have one question.

It is not possible right now to make a delayed (valid only after a certain timestamp) user op with kernel signed via ECDSA validator, right? What would be the easiest approach to implement it?

node_modules/@zerodev/sdk/utils.ts:1
import { walletClientToCustomSigner } from "permissionless"

SyntaxError: The requested module 'permissionless' does not provide an export named 'walletClientToCustomSigner'

ZeroDev Kernel SC infrastructure is deployed on Linea Mainnet and was deployed on Linea Goerli before deprecation. Linea is a promising L2 with a growing number of community members.

Could you deploy Kernel SC to Linea Sepolia testnet too, please?

I'm testing Kernel Wallet and can't do a delegate call, I've tried these calldata:

1

abi.encodeWithSelector(
  IKernel.execute.selector,
  address(target),
  0,
  targetCallData,
  IKernel.Operation.DelegateCall
)

Result:

custom error `0x67ce7759` (couldn't figure out which error this is) 
was throw by 0x0DA6a956B9488eD4dd761E59f52FDc6c8068E6B5.execute()

2

abi.encodeWithSelector(
 IKernel.executeDelegateCall.selector,
 address(target),
 targetCallData,
)

Result:

    │   │   ├─ [5870] Wallet::executeDelegateCall(target, targetCalldata)
    │   │   │   ├─ [5561] 0x0DA6a956B9488eD4dd761E59f52FDc6c8068E6B5::executeDelegateCall(target, targetCalldata) [delegatecall]
    │   │   │   │   ├─ [0] 0x0000000000000000000000000000000000000000::executeDelegateCall(target, targetCalldata) [delegatecall]
    │   │   │   │   │   └─ ← ()
    │   │   │   │   └─ ← ()
    │   │   │   └─ ← ()

Am I missing something?
Thanks

only the factory seems to be verified, please verify others also

Good afternoon!
We are using Kernel SW and validators extensively, and are happy with updates frequency (v2.0, v2.1...).
The latest (v2.4) release has updated ECDSAValidator and SessionKeyValidator, however, their addresses (specified at the bottom of the README.md) were left unchanged.

Could you specify the addresses of updated validator modules in the readme, please?