Awesome

Light Account

A set of lightweight ERC-4337 compatible smart contract accounts with designated ownership. Account Kit is the easiest way to integrate Light Account.

Features

LightAccount

Like eth-infinitism's SimpleAccount, but with the following changes:

1. Instead of the default storage slots, uses namespaced storage to avoid clashes when switching implementations.

2. Ownership can be transferred via transferOwnership, similar to the behavior of an Ownable contract. This is a simple single-step operation, so care must be taken to ensure that the ownership is being transferred to the correct address.

3. Supports ERC-1271 signature validation for both validating the signature on user operations and in exposing its own isValidSignature method. This only works when the owner of LightAccount also support ERC-1271.

   ERC-4337's bundler validation rules limit the types of contracts that can be used as owners to validate user operation signatures. For example, the contract's isValidSignature function may not use any forbidden opcodes such as TIMESTAMP or NUMBER, and the contract may not be an ERC-1967 proxy as it accesses a constant implementation slot not associated with the account, violating storage access rules. This also means that the owner of a LightAccount may not be another LightAccount if you want to send user operations through a bundler.

4. Improves gas estimation by enabling switching between ecrecover and ERC-1271 signature validation by prepending a SignatureType byte to the user operation signature. Allowed SignatureType values:

   • SignatureType.EOA: For an EOA owner. Signature is validated using ecrecover.
   • SignatureType.CONTRACT: For a contract owner. Signature is validated using owner.isValidSignature.

5. The factory uses Solady's LibClone.createDeterministicERC1967 instead of OpenZeppelin's ERC1967Proxy.

6. The factory includes ownership and entry point staking capabilities to address mempool limitations for unstaked entities as defined in ERC-7562.

7. Event SimpleAccountInitialized renamed to LightAccountInitialized.

8. Uses custom errors.

MultiOwnerLightAccount

Like LightAccount, but with the following changes:

1. Multiple owners are supported. They can be specified at account deployment, or updated via updateOwners. This is a simple single-step operation, so care must be taken to ensure that the ownership is being updated to the correct address(es).

2. Allowed SignatureType values:

   • SignatureType.EOA: For EOA owners. Signature is validated using ecrecover.
   • SignatureType.CONTRACT_WITH_ADDR: For contract owners. Signature is validated using owner.isValidSignature. The contract owner address MUST be passed as part of the signature, following the format: SignatureType.CONTRACT_WITH_ADDR || contractOwnerAddress || signature, where || is the byte concatenation operator.

Deployments

See the current deployments by network under the deployments folder.

Build

forge build

Test

forge test -vvv

Deploy

The deploy script supports any wallet options provided by Foundry, including local private keys, mneumonics, hardware wallets, and remote signers. Append the chosen signing method's option to the field marked [WALLET_OPTION] in the following script command, and set the sender address in the field [SENDER_ADDRESS].

forge script script/Deploy_LightAccountFactory.s.sol [WALLET_OPTION] --sender [SENDER_ADDRESS] --rpc-url [RPC_URL] -vvvv --broadcast --verify
forge script script/Deploy_MultiOwnerLightAccountFactory.s.sol [WALLET_OPTION] --sender [SENDER_ADDRESS] --rpc-url [RPC_URL] -vvvv --broadcast --verify

Make sure the provided RPC_URL is set to an RPC for the chain you wish to deploy on.

Generate Inspections

bash utils/inspect.sh

Static Analysis

slither .

Dependencies

Light Account uses dependencies via git submodules, pinned to release branches. Dependencies that cannot be reliably pinned (or those that needed to be modified) have been copied directly into the repository. These are listed below: