Last year, we pushed the web3 UX standards forward by releasing our path-breaking account abstraction SDK. By the end of 2023, the SDK had processed more than 2 million UserOps & was deploying a Smart Account every 17 seconds!

This year, we are doubling down to take our Account Abstraction solution to new heights. We have already started with a bang - In the first 40 days of 2024, we have already done more UserOps than we did in the entirety of 2023!!

Yep you read that right, good sers. AA seazon is here! And we are building & shipping with the same energy.

‍

Thrilled to introduce our SDK v4!

We’ve started the year by introducing a nice reduction in bundle size (~40%), and a host of simplified and improved ways to interact with our SDK.

Read on to learn about what’s new amongst our Biconauts 🧑‍🚀!

‍

Summary - what’s new in v4?

Wanna know the short and direct tldr? It’s now easier & faster than ever to integrate all the benefits of Account Abstraction / ERC4337 on your project.

‍

Here’s the main improvements:

1. Easier to configure the SDK & deploy Smart Accounts - Reduced the lines of code required by 40%!

2. Streamlined dev experience to import all ERC4337 services from one master-package: @Biconomy/Account

3. Simplified the dev efforts to build & send UserOps by merging BuildUserOp & SendUserOp into a single function

4. Support for Viem

‍

Let’s dive into the details.

An emphasis on usability

This recent iteration of the SDK underscores a commitment to enhancing the developer experience. Over the last few months, we have taken extensive feedback from our clients. Some of it resulted in new features and functionalities, while some of it helped us really pinpoint how to make their whole experience of integrating account abstraction easier and faster.

‍

And we have put all that feedback, learning & ideas into v4.

‍

1. Easier to configure the SDK & Deploy Smart Accounts

createSmartAccountClient

Creating a smart account should be a simple thing, and we have gone on a boilerplate-busting mission to make it happen. We have minimised the necessary code to its essential elements, ensuring that only the necessary fields are mandatory when instantiating the SDK, adding a host of defaults and abstractions which help to get you running transactions with as little configuration as possible:

The bundler and paymaster instance fields have been omitted in favour of using bundlerUrl and biconomyPaymasterApiKey. This change eliminates the need for users to delve into the inner workings of these packages initially. However, for those seeking additional customisation, explicit configuration options are also available to set paymaster or bundler instances aligning with v3.x documentation.

The chainId is no longer a required field (though you can still set it if you like) - it is inferred from the bundler, while the default entryPoint address which was previously required is assumed unless otherwise stated. Similarly, the active/default validation modules are defaulted to the ECDSA module, unless specifically set. Additionally, we now pluck out the relevant RPC URLl from the provided signer (both ethers and viem), so you need to worry no longer about being rate-limited by the publicly available RPCs.

‍

2. One Master Package to import them all

Until now, importing multiple packages was a requirement to carry out fundamental tasks with the SDK. However, with the introduction of v4, we present the master-package: @biconomy/account.

Easily import Smart account, Bundler, and Paymaster functionalities from just one master-package: @biconomy/account, ensuring a unified and streamlined development experience.

‍

This serves as a centralised hub, allowing all essential tools to be imported and re-exported from various sources, neatly encapsulated within a unified package. Advanced users can now access the beloved AA modules from this master package, complete with additional user-friendly aliases. The configuration for each module has also been simplified for ease of use.

• createBatchedSessionRouterModule
• createMultiChainValidationModule
• createECDSAOwnershipValidationModule
• createSessionKeyManagerModule
• createERC20SessionValidationModule

‍

3. Simpler method to build & send UserOps

smartAccount.sendTransaction

We've introduced a familiar syntax for executing userOps, streamlining two previously crucial calls (buildUserOp + sendUserOp) into a unified experience. This approach caters to developers less acquainted with erc4337 terminology, providing a more intuitive process. The function now accepts one or multiple transactions that will be batched and executed by the bundler, making it straightforward to initiate these calls.

Or, found an altruistic gas donor? Let’s have him sponsor you…

smartAccount.getTokenFees

Another area we have greatly simplified the dx around is when erc20 tokens are used to spend on gas. Let’s mint some NFTs and have the gas paid in an arc20 token. Hodling ETH > hodling USDC after all.

Actually, let’s offer the choice of a token to be spent on gas back to the user:

4. Introduced support for Viem

As per feedback from our builder community, we have introduced convenient support for the latest tool in our toolkit - viem (while maintaining backward compatibility for ethers users)!

‍

Simpler Documentation

We have simplified not just configuring & using the SDK, but also our docs.

In v4 we have added JSDoc-style documentation to the SDK which outlines the inner workings of our SDK. So even if you aren’t an expert in ERC4337 development, you will find you can easily understand and implement whatever your use case. Unsure about the purpose of a new alias, or some esoteric param or field that we offer? These SDK Modules will help you to look under the hood.

‍

Contributing to the SDK

Tests

As always we appreciate the community and love interest being shown in our work. For those of you with an eye for code we have set up unit tests, and end-to-end tests that have been configured to run against deployed infra on MUMBAI. Each PR will be subject to testing, or can also be configured locally setting appropriate environment variables so that you can submit PRs with confidence that your help is going to integrate nicely.

‍

What’s coming next?

Size matters.

While we significantly reduced our package size in v4, there are upcoming efforts to further minimise it substantially. In tandem with these bundle size improvements, we also have exciting speed optimizations in the pipeline, specifically interactions with our paymasters in particular.

‍

Additionally, one package we know will be increasing in size is our modules package - in the best possible way. We expect “Account recovery” and “Passkey” modules to be finalised in the coming weeks. Watch this space!

‍