Earlier this week, Bicononmy and Rhinestone announced the Module Store with a planned launch in Q1 2024. This post dives into the motivation and provides a high-level technical overview of what’s powering the Module Store.

Prefer to jump ahead? Join the waitlist!

Introduction

Since the finalized audit of ERC-4337, there has been a surge in activity and interest surrounding account abstraction. ERC-4337 standardized the execution flow of smart accounts and provides a solution for decentralizing the traditional relay services required to initiate transactions from smart accounts. 

Account abstraction is one of the most important innovations for the Ethereum community. Wallets today are plagued with a trilemma – improving user security or the user experience can only come with compromises. Smart accounts are the answer. 

However, ERC-4337 has little to say about the implementation of smart accounts. Biconomy and Rhinestone are excited by an emerging concept known as modular smart accounts, which introduces the idea of modularising the account contract. At its core, this allows developers to build self-contained components that extend the functionality of the user’s account, making it far easier for developers to offer new features without expensive audits or gas-intensive upgrades. It also means that developers don’t need to have full knowledge of ERC-4337 or any other smart account complexities just to build a wallet feature.

Modularizing the account not only improves the developer experience, it turns smart accounts into a platform for any third-party developer. Modules can be built by a third party and easily installed on a modular account by the end user. However, there are some obstacles to achieving this.

First, module interfaces, their functionality and execution flow should be standardized to promote interoperability. ERC-6900 is the ecosystem’s first attempt at this. Second, users need assurance that the module being installed is not malicious. And finally, users and module developers need a space to discover and distribute these modules.

Infrastructure for the module ecosystem

The module ecosystem starts with the modular smart account. Biconomy, which has been enhancing web3 UX via gas abstraction since 2019, recently launched its modular account implementation, and with it, enabled dapps to access a module ecosystem.   

To unlock the module ecosystem, Rhinestone has built an open and permissionless Module Registry. This registry provides a destination for developers to deploy modules and for security entities to make onchain assertions about those modules. These assertions are called attestations and can be queried by an account before installing or executing a module. One example would be determining what storage slots a specific module can write to. This assertion is infeasible to verify onchain but can be verified off-chain. Thus, an attester could check off-chain and publish the findings onchain as an attestation.

The Module Registry and Rhinestone’s infrastructure are leveraged to create a seamless translation layer between modules and the Biconomy smart account (as seen above). This enables the secure distribution of third-party modules to dapp developers but still leaves open the question of how dapps can easily discover and install these modules. 

Enter the Module Store

Rhinestone and Biconomy are excited to announce the next evolution for embedded wallets. A simple “app store-like” marketplace where dapps can discover modules and customize their wallet solution to meet their product needs. At launch, the Module Store will support all dapps and wallets utilizing Biconomy’s latest smart account, with more account integrations to come.

At launch, the Module Store will be equipped with all the basic account abstraction features; social login, passkeys, session keys, pull payments, multi-sig, 2FA, social recovery, etc. However, you’ll also see some novel module concepts such as flashloans, token-bound account integrations (ERC-6551), stealth addresses, DeFi automation and advanced security modules. 

The Module Store will be compatible with the Biconomy smart account to start with, but soon after launch, other account implementations will be integrated. The goal of the Module Store is to be account-agnostic, providing a plug-and-play solution for any smart account user.

Interested in building a module or getting early access to the store? Join the Waitlist here.

Why are we excited?

Modular accounts are a new distribution platform

The Module Store transitions embedded smart accounts from a “Wallet-as-a-Service” to a “Wallet-as-a-Platform”. Any developer is now able to build self-contained features for smart accounts that are then seamlessly distributed to dapps via their embedded wallet. This opens up a completely new distribution channel for web3 services. 

A great example of this is our partnership with Silence Laboratories — a cryptography specialist and the developer of Silent Shard-one, one of the fastest and most agile MPC-TSS libraries — who are building a unique SessionKey Manager module. This module allows dapps to access Silence Laboratories MPC network to embed custom off-chain transaction logic, such as monthly subscriptions or trading automation via bespoke session keys.

Session keys are like JSON web tokens (JWTs), giving dapps the ability to create granular permissions without compromising security or self-sovereignty. To empower dapps with modules for creating powerful applications, we needed to solve session key management, associated usability tradeoffs and device interoperability. We’re excited by what Silence Laboratories has achieved via this modular architecture and how they plan to use the Module Store to distribute their services.

Other early adopters of this modular architecture for distributing their services include Blockfence, a blockchain security provider, Fetcch, a chain-agnostic pull payments solution, Sukuri Protocol, a protocol for tokenised subscriptions, Moonchute with a stealth address product and BananaHQ which is looking to deliver intent-based products via modules.

Modules unlock limitless expression at the application layer

Modules have limitless potential when it comes to extending the functionality of a smart account. We’re excited to see how this can be employed by dapps to 10x their product. For example, a game developer may want to enable P2P NFT rentals without compromising self-custody or imposing ridiculous collateral requirements – there’s a module for that. A DeFi dapp developer may want to create automated investment strategies or position management – there are modules for this too. Or maybe the developer wants to offer passkeys or Oauth login to streamline new user onboarding. Whatever the need is, modules provide a seamless mechanism to deliver these features. 

What is unique about the Module Store and Rhinestone’s infrastructure?

Rhinestone’s infrastructure is built with interoperability as a primary focus, with the objective of enabling a completely open and permissionless module ecosystem. We believe this is the antidote to the current shortcomings of smart accounts – vendor lock-in, ecosystem fragmentation and developer complexity.

The foundational building block of this open ecosystem is the ownerless Module Registry. A singleton contract that allows any developer to deploy a module and any attester to make onchain assertions about that module. The Module Registry is built to be flexible and extensible via two core components; schemas and resolvers. A schema is a data structure that defines the attributes of an attestation. The resolver implements hooks to impose conditions or functions against the schema when attestations are made or revoked. These hooks could, for example, enforce a whitelist of attesters or certain monetization mechanisms. Any entity can create a schema and resolver. Ultimately the user (dapp or end-user) chooses one or many entities to delegate trust to when installing or interacting with modules (see ERC-7484 for more details).

The result is that the Module Registry can cater to many different account-agnostic “module marketplaces” without fragmenting the supply of modules across unrelated registries. For example, financial institutions that are utilizing the module ecosystem may have much higher security requirements than a degen application. Certain schemas, resolvers and attesters can be spun up to cater to these specific needs. 

In addition to the open registry, we require standardized module interfaces and functions to achieve interoperability between account vendors. This is why ModuleKit, a set of tools for module developers built by Rhinestone, is so important. Developers can rely on ModuleKit to abstract away the differences between existing account implementations. ModuleKit ensures that developers are conforming to the required interfaces via module templates, testing frameworks and helper libraries for integrating with external services (such as DeFi protocols, data oracles and relay services). Developers can also rely on ModuleKit to stay compatible as the space evolves and modular accounts are standardized (such as the efforts of ERC-6900).

With ModuleKit devs only need to build once to distribute everywhere. For more on ModuleKit, check out the Rhinestone documentation or our recent blog post.

Biconomy elevates their smart account security with the Module Registry

Biconomy is leveling up the security of its smart account system by integrating the Module Registry. This approach not only secures module installations and executions but also introduces a new layer of protection. In addition to the basic attestations outlined in the ERC-7484 standard, Biconomy is innovating by developing security plugins and a dedicated plugin manager. These additions are built on top of the ERC-7484 framework, enabling more comprehensive security checks during module interactions.

By incorporating these additional security checks, Biconomy is laying the groundwork for a future where even more diverse and complex types of attestations can be supported. As the module store expands and the demand for new attestation types grows—ranging from user experience enhancements to custom attestation requirements—Biconomy's approach ensures that its Smart Accounts will be well-equipped to handle these evolving security needs.

Conclusion

The Module Store is phase one for unlocking permissionless innovation within the embedded wallet space. We’re excited to be collaborating with Biconomy to deliver this product. If you’re a developer looking to build or utilize modules, get in touch!

Get early access by joining the waitlist!