Smart Contract Wallets - ERC4337

Smart Contract Wallets - ERC4337

Jul 12, 2023·

7 min read

Improving UX for ETH wallets

If you have been watching the Ethereum news lately, by now you should have already heard about account abstraction and its myriad of possible use cases.

In this post, I will walk you through the main components your protocol needs to be able to support Account abstraction, a Smart Contract Wallet implementation example using the zkSync blockchain, the projects currently supporting it, and finally some more possible use cases according to interviews with founders and members of teams like Argent Wallet, Alchemy and ZkSync.


The hype on account abstraction is due to its potential to enhance the onboarding experience of new users and therefore increase mass adoption. Major cases include companies that could pay for your transaction fees, and you would be able to pay transactions in erc20s. And now with Argent, you are able to sign transactions with the iPhone biometrics or face recognition. You would be also able to customize your authentication logic using other addresses as guardians and make your transactions multi-signature in nature.

ERC overview

In the past, all Ethereum Request for Comments have been standards that involve specific routines in a single contract. The ERC4337 is the first request that involves more than a single contract, it is a set of on-chain and off-chain components that allows users to leverage the power of smart contracts as their primary account.

Currently, a transaction can only “start from” an externally owned account (EOA), which has one specific authorization policy: an ECDSA private key signature. With account abstraction, a transaction could start from accounts that have other kinds of authorization policies, including multi-sigs, other cryptographic algorithms, and more complex constructions such as ZK-SNARK verification.

ERC4337 will allow the innovation of Intent-based architectures.

ERC 4337 Components

  • UserOperation - a structure that describes a transaction to be sent on behalf of a user, is not allowed to access block data and it is not a regular transaction type.

  • Sender - the account contract sending a user operation.

  • EntryPoint - a singleton contract to execute bundles of UserOperations. Bundlers/Clients whitelist the supported entry point.

  • Bundler - a node (block builder) that bundles multiple UserOperations and creates an EntryPoint. handleOps() transaction. Note that not all block-builders on the network are required to be bundlers

  • Aggregator - a helper contract trusted by accounts to validate an aggregated signature. Bundlers/Clients whitelist the supported aggregators.

  • Paymaster - optional contract that will subsidize the transaction costs for the

Supporting smart contract wallets

Suppose you would like your protocol to support Account Abstraction and smart wallets. In that case, your project needs to stop using ECDSA recovery to validate signed transactions and start using EIP-1271 which is a standard way to verify a signature when the account is a smart contract, more specifically, start validating user operations with a library that supports both cases like the OpenZepelling "Signature checker" which supports EOA and EIP-1271 signatures.

This will improve your application user experience, allowing them to use regular EOA wallets or smart wallets, and your system to identify and register either option.

ZkSmart Wallet

The bootloader (yul contract) is a key component of the system that manages the execution of layer 2 transactions. It is specialized software that is not deployed like a regular contract but rather runs within a modified node as part of the execution environment. The validator modifies transactions and stores them in an array, which is then written to the bootloader memory and executed.

Follow ZkSync installation guide then

  • Deploy an Account Abstraction Factory contract

  • Using create2Address, precompute an address derived from two EOA addresses, this will be the address for the Multisignature Contract Wallet.

zkSync goerli contracts

  1. EOA owner1: 0x1d3Af21a1889A1262980Fb8021bF91B792584A88

  2. EOA owner2: 0x6C181A9892DDA85182B3b44ce2C2CFFe53278D5d

  3. Multisignature address: 0x77A77362c777a6314582b76B653ba3BAE3Db976B

    Deploy multi-sig Smart Wallet contract at Multisignature address

    Deploy a new AA via the Factory contract using the Multi-sig contract

  4. Using a paymaster extension

    • Deploy Paymaster contract capable of paying for user operations

    • Set the currency type to pay transactions with

    • Fund the paymaster to pay for user operations

    • Send user operations from the smart wallet

Security Considerations

The entry point contract must be heavily audited and formally verified because it will serve as a central trust point for all ERC-4337. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual accounts have to do becomes much smaller (they need only verify the validateUserOp function and its “check signature, increment nonce and pay fees” logic) and check that other functions are msg.sender == ENTRY_POINT gated (perhaps also allowing msg.sender == self), but it is nevertheless the case that this is done precisely by concentrating security risk in the entry point contract that needs to be verified to be very robust.

Argent Wallet, zKSync and Starknet

zkSync Era▫ Ecosystem. In our last two articles we introduced… | by MES  Protocol | Medium

Key new wallet features

  • Multicall bundle multiple tx's into one

  • Meta transactions & relayers, users sign intents to transit, relayers broadcast and pay gas.

  • Session keys Sessions can be defined in a variety of ways. The parameters could include: “a given duration, a max amount of gas, a max transaction volume of a certain token, or a particular function on a particular contract

  • Social Recovery - Trusted contacts or 3rd parties Guardians

  • Multi-factor auth, use off-chain services

  • Plugins to wallet

    • Pay fees in any token

    • Pay fees on behalf of users

    • Different signing schemes allow more than ECDSA

      • Phones as recovery wallets

The new, off-chain recovery method

The new process combines encryption and Cloud storage. As with recovery with guardians, we built it to protect you even if an attacker somehow seizes control of your device. Argent is the only wallet that offers this level of security. Here's how to use it.

This split gives you added protection. If anyone gets access to your iCloud or Google Drive, they can’t decrypt your keys without the KEK that Argent has. And if a malicious actor gets access to our infrastructure, they won’t be able to access your wallet as they won’t have your encrypted private keys.

1st level of security

A significant benefit of this level of security is that it would protect you even if your private key was somehow compromised. Nevertheless, to protect your private key, we also use all the available security features on iOS and Android, such as biometrics, keychain, and Secure Enclave, as well as a six-digit user pin code. The pin code helps to encrypt the private key (for those of you interested in cryptography: we use PBKDF2 and AES256 in Galois/Counter Mode).

2nd Level

Transaction protection for DeFi & Dapps To combine control and convenience, you can use Trust Lists and Trusted Sessions.

We've started with the "Argent Trust List". Key details:

  • The list includes the specific Dapps and functions integrated natively within Argent (e.g. Paraswap, Compound, Aave, Lido).

  • It's managed by us to stay in sync with those integrations. For security, it has a 1-week timelock for adding a Dapp, while removing a Dapp is instant. You can read more on this here.

  • You're always in control. The list will be active by default but you can disable it in a tap. In doing so you're making your Argent wallet a full multisig.

  • Sessions can last: 1 hour, 3 hours

    How do Sessions work?

    Through the app you'll create a new, temporary private key. Once authorized by your guardians, that key will be able to take any action without guardians for the duration of your session.

    At the end of the session the key becomes useless and is discarded. You can, of course, cancel a session at anytime if you change your mind.

    • Wallet locking

    • You can ask a guardian to lock your wallet. The wallet can’t then make transactions. This is useful in case your phone is lost or stolen and you want to protect it beyond the phone-layer security.

      When a guardian locks a wallet, a 5-day security period starts. This gives you time to get a new phone and recover your wallet. (Locking doesn’t prevent recovery, for precisely this reason).