Using Plugins
ZeroDev is built on Kernel, a modular smart account that can be extended with plugins (sometimes also called modules).
While there are many types of plugins, we will focus on validators, which modify the logic for validating UserOps. Validators are used for most of the major use cases of AA, including:
- Alternative signature schemes, such as passkeys and multisig.
- Dynamic access control, such as guardians and session keys.
Sudo vs regular validators
For any given Kernel account, it will have one sudo validator and any number of regular validators.
- The sudo validator is the "owner" of the account. It's the only validator that can enable other validators.
- A regular validator represents an alternative form of access to the smart account. For example, a session key or a guardian would be a regular validator. Regular validators cannot enable other validators.
When you set up a Kernel account object with the SDK, you must specify a sudo validator, a regular validator, or both. Let's walk through the three cases:
Using only a sudo validator
In the most common case, you set up a Kernel account that is powered by a single sudo validator. For example, to set up an account owned by a ECDSA key:
const account = await createKernelAccount(publicClient, {
plugins: {
sudo: ecdsaValidator,
},
entryPoint,
kernelVersion
})
Here, when you send a UserOp, the ECDSA key will be used for signing the UserOp, and the ECDSA key has sudo access to the smart account (meaning it can do anything).
Enabling a regular validator
If you have access to the sudo validator, you can enable a regular validator. For example, to enable a session key:
const account = await createKernelAccount(publicClient, {
plugins: {
sudo: ecdsaValidator,
regular: sessionKeyValidator,
},
entryPoint,
kernelVersion
})
Now, when you send a UserOp with this account
, the regular validator will be enabled, and the regular validator (in this case the session key) will be used for signing the UserOp.
Note that Kernel plugins are enabled "lazily" -- you don't have to explicitly enable them. That is, whenever you send the first UserOp with an account
object with a regular
plugin, the plugin will be enabled as a part of that UserOp. The UserOp itself can do whatever it needs to do.
Using only a regular validator
If a regular validator has already been enabled, you can use it without access to the sudo validator.
For example, continuing the session key example above, if the session key has already been enabled, you can simply do:
const account = await createKernelAccount(publicClient, {
plugins: {
regular: sessionKeyValidator,
},
entryPoint,
kernelVersion
})
Next Steps
Learn more about plugins such as passkeys and permissions.