Rhinestone Protocol 1.0 Hits Mainnet

Since the launch of ERC-4337, we’ve seen the accelerated development of Smart Account implementations and account features (such as passkeys and session keys). Some features have been built natively into the account, and others via module systems.

This results in fragmented accounts across supported features and security models, with added overhead for users and developers to manage these various account implementations. Ultimately, developers must choose which platforms to support, creating either vendor lock-in or duplicate work.

Introducing Rhinestone Protocol 1.0. The first interoperability protocol for Modular Smart Accounts (“Smart Accounts”) is now live and in production on all major EVM chains. The protocol addresses vendor lock-in, ecosystem fragmentation, and security. Rhinestone enables any developer to build self-contained components, called Modules, that securely extend the feature set of any Smart Account — making Modules the Smart Account equivalent of apps on a smartphone. This allows developers to tap into programmable account authentication and execution, extending the functionality of applications and protocols to unlock new onchain products.

Rhinestone Protocol 1.0 makes Smart Accounts extensible, portable, and secure, unlocking three core benefits for the ecosystem:

• Permissionless innovation: It transforms Smart Accounts into an open platform by allowing any developer to extend the features of any Smart Account with a single Module.
• Maximum distribution: Developers can tap into the power of Modules, while building products that seamlessly integrate with any account / wallet vendor.
• Account portability: This enables Web3’s “one account, one identity, and limitless apps” promise to extend to Smart Accounts while allowing the account to remain completely customizable.

Alongside the protocol, Rhinestone offers tools and services to make building, auditing, and using Modules at the application layer seamless for developers.

For conciseness, this article focuses only on Rhinestone’s onchain environment. We share the “why” behind what we are building, its role in the smart account stack, an overview of protocol components, and the future opportunities we’re working toward for Rhinestone Protocol 2.0.

Why We Built Rhinestone

Traditionally, the teams building and maintaining Smart Accounts are the only ones able to contribute to their feature set. Smart Account modularity changes the game, allowing any developer to customize the Smart Account stack.

Modules enable any developer to tap into programmable Smart Account validation and execution to build features that are impossible with standard smart contracts. Examples include account automations that unlock new DeFi experiences, cross-chain intents with zero bridging through resource locks, privacy with zero-knowledge proofs for signature validation, new credit and margin account systems, and many more.

For Smart Accounts to be an open platform, three foundational problems must be solved. Rhinestone Protocol 1.0 directly addresses each of these problems:

• Security: Unchecked installation of a Module opens up a wide range of attack vectors. Unlike the relationship between smart contracts and Externally Owned Accounts (EOAs), modules can directly manipulate an account’s authentication and authorization controls.
• Fragmentation: The development of new Smart Account implementations fragments the ecosystem, with tooling and application developers having to choose which to prioritize. This reduces component reuse, increases security risks, and reduces innovation with teams rerunning what already exists elsewhere.
• Vendor lock-in: A direct symptom of fragmentation is vendor lock-in. As developer tooling becomes more opinionated toward certain account implementations, application developers and users can be locked into a local optimum that limits innovation and reduces competition. Unlike EOAs, users cannot seamlessly move between clients offering similar but competing services.

The Smart Account Stack

Many projects work across different layers of the Smart Account stack to enable an account-centric developer platform.

The Interoperability Layer sits at the intersection of the Smart Account and Application layers. It acts as an aggregation and compatibility layer that enables developers to build Modules that can be securely plugged into any existing Smart Account.

Several market dynamics make this Interoperability Layer necessary:

• The accelerated development of new smart account implementations since the launch of ERC-4337 has led to significant ecosystem fragmentation. There are 15 ERC-4337 account implementations publicly tracked, excluding new wallets and dapps building opinionated Smart Accounts.
• The fragmentation of EVM liquidity across L2s necessitates leveling up our UX infrastructure toward a unified stack that maintains interoperability and composability as Smart Accounts become the de facto account (especially post-EIP-7702).
• Embedded wallets continue to fragment users across app-specific wallets that are not extensible, portable, and interoperable.

As apps increasingly become the defacto onboarding vehicle for new users, we require a credibly neutral interoperability layer to enable an open, extensible, and interoperable account ecosystem. This is the core mission of Rhinestone Protocol 1.0.

Rhinestone Protocol 1.0

The protocol consists of four major components: 1) Modules, 2) The Module Registry, 3) Adapters and 4) Smart Accounts. The Module Registry is the Schelling point for the ecosystem where developers deploy Modules and security entities to make onchain assertions about their security. It is a core mechanism for user security, discovery, and distribution. Adapters allow smart accounts to be plugged into the Module Registry and, in some cases, ensure protocol compatibility.

Modules

Modules are smart contracts that extend the features of Smart Accounts. They are equivalent to apps on the smartphone platform. Current module types include Validators, Executors, Hooks, and Fallback Handlers. We imagine new module types emerging, and we encourage developers to append these to ERC-7579 through an extension of the ERC. For example, ERC-7780 is a new standard for Stateless Validator, Signer, and Policy module types for more advanced and composable signing logic and permissions.

• Validators are used during the validation phase to determine whether an account action is authorized and should be executed. These include passkeys and Session keys, but can also unlock more creative validation methods and integrations, such as zkKYC or proof of humanity.
• Executors execute transactions on the Account’s behalf. This allows developers to extend their applications through custom account execution logic, such as DeFi automations and intent-centric transactions.
• Hooks are functions that “hook” into an execution pre- or post and enforce constraints against that execution. This type is perfect for applications that require advanced security features, policy enforcement, or conditional account behavior.
• Fallback Handlers can extend a Smart Account’s fallback functionality. When an Account is called with an unsupported function, it will call the correct Fallback Handler to process the request. This future-proofs the account for new standards, token types, module types, etc.

Module Registry

The Module Registry provides a credibly neutral, permissionless, and highly scalable trust delegation mechanism. Its primary function is to store security Attestations on Modules, and it allows Smart Accounts to query them when installing and executing a Module.

It is an ownerless singleton contract that any developer can build upon. We utilize Schemas and Resolvers to allow any entity to define a “sub-registry” within the Module Registry. There are two major benefits to this design:

• Security: It focuses Smart Account integrations into a single source of truth where a maximum number of security entities attest. This increases the maximum quantity and types of Attestations per Module and removes the need for Smart Accounts to verify the authenticity of a given registry.
• Interoperability: A singleton approach increases Module liquidity and ensures greater Module interoperability. Developers need only deploy their Modules to one place to achieve maximum distribution.

The Module Registry is credibly neutral and open. It provides user security and enables permissionless innovation by eliminating the need for a centralized gatekeeper. Any entity can Attest to module security, and users can select any trusted Attester via the Account Adapter. All Adapters will have default trusted Attesters set by the Smart Account or Application developer.

Module installation flow:

Note: Module usage flow can optionally follow the same flow for added security.

Schemas: A Schema is a predefined data structure utilized to verify Attestation data. The Module Registry employs flexible Schemas that any entity can define. Attestation data can be encoded to custom-fit different security postures or use cases. For example, the data of an Attestation about the outcome of formal verification will have a different format than the data of an Attestation about what interfaces a module supports.

Resolvers: Resolvers are smart contracts that govern one or many Schemas. Module developers elect the Resolver, which determines the Attestation processes. Resolvers aim to provide flexibility to entities curating lists of Modules, as they allow for custom business logic while maintaining the core security properties of the Module Registry. For example, a Resolver can enforce token mechanics and fee mechanisms.

Resolvers can also be used to bring automated functionality to the Module Registry. For example, a Resolver could automatically respond to threat detection systems, revoking Attestations under certain thresholds to protect users.

Attesters: Attesters perform security reviews of Modules and make Attestations about them on the Module Registry. They can be anyone. However, the Attesters that build credibility and trust will be established security entities like auditing firms, audit competition platforms, or solo auditors.

Adapters

Adapters focus on three functions:

1. Allowing users to elect their trusted Attesters
2. Fetching and validating attestations from the Module Registry
3. Bringing about ERC-7579 compliance

Some Account implementations, such as Biconomy’s Nexus, support the Module Registry natively, while others will do so via a module installed as a Global Hook. The Safe7579 Adapter is an early example of an Adapter that integrates the Module Registry and acts as a translation layer to bring about ERC-7579 compliance.

Smart Accounts

Rhinestone Protocol 1.0 currently supports any smart account that is compliant with ERC-7579, a shared standard for scalable interoperability coordination. This includes Safe, Biconomy, ZeroDev, OKX, Trust Wallet, and Etherspot, with more vendors in the works. For Smart Accounts that are not natively ERC-7579 compliant, Rhinestone is writing Adapters that bring about compatibility and natively plug into the Module Registry via ERC-7484 (an example is the Safe7579 Adapter).

The Account-Centric Developer Platform

The account-centric developer platform sees the onchain logic of applications and protocols becoming more tightly coupled to the Smart Account stack. This does not replace existing tech stacks but supplements them. It enables custom logic for account validation and execution that was previously impossible without compromising web3 values of self-custody and trustlessness. Our Scheduled Orders Module for Uniswap is a very simple example of enabling intent-like actions through this account-centric model.

The account-centric platform concept is not new; teams have already demonstrated the power of building Smart Account-native products that use Modules. For example, Gnosis Pay utilizes Modules for withdrawal rights on Safe accounts and timelocks to prevent double-spending. However, Gnosis Pay is only compatible with Safe and requires the user to deploy a new account per debit card.

Instead, applications can take full advantage of the account-centric platform by utilizing Rhinestone’s infrastructure and tools to

• Increase their addressable market by ensuring compatibility with all account implementations.
• Increase security and trust through the Module Registry.
• Increased developer efficiency through reusable Modules and Module Services.

Klaster, a Chain Abstraction protocol, is a prime example of this. Klaster utilizes Rhinestone to build an account-agnostic cross-chain intent protocol. The Klaster Module (iTx Module) is pivotal in allowing users of any Smart Account to sign cross-chain transaction bundles managed and executed by the Klaster Protocol.

Superform, an onchain finance marketplace, is another project utilizing Rhinestone to create advanced execution flows into onchain vaults with Modules, such as pre- and post-deposit hooks and automations with Executor Modules.

To make the account-centric developer stack more accessible, Rhinestone builds and maintains multiple open-source development kits, free reusable Modules, an offchain service for account automations, and Smart Sessions, an open-source permissioning framework that is interoperable across all supported Smart Accounts.

Future Opportunities

Modular Smart Accounts flip the Fat Protocol thesis toward a Fat Account thesis. They allow concepts previously built at the protocol level to be directly integrated into the account, such as credible commitment machines for chain-agnostic intents and ZK proofs for privacy.

Opportunities we’re actively working on for Rhinestone Protocol 2.0:

Onchain Permissions: Smart Sessions allows users to create self-custodial authorizations for external services. This is a powerful session key framework that is highly composable, interoperable across all ERC-7579 Smart Accounts, and chain abstracted. We’re excited to partner with Reown as the first wallet developer kit to integrate this Module.

Resource Locking: Making credible commitments within a Smart Account through Resource Locking modules. These modules prevent the user from double-spending assets already committed to another user intent without the need to escrow funds. Resource Locking systems can form the backbone of many new account-centric applications:

• Cross-chain intents through solver network integration
• Account-centric credit and margin protocols
• Offchain order book integration
• Onchain clearing houses with pre-defined clearing policies

Module incentives: A credibly neutral payment system that can easily scale and provide a positive-sum game for building and integrating Module-enabled applications. An in-module payments system that allows developers to easily embed fee mechanisms into a Module and customize the business logic for fee-split beneficiaries.

Get involved

If you’re building with Smart Accounts, developing a new module, or if your game is security (with experience in Smart Accounts), we want to speak to you.

Reach out:

• On X @Rhinestonewtf
• By email gm@rhinestone.wtf
• Check out our website and docs

Acknowledgments

Thanks to all the supporters who helped shape this work with your feedback: Lukas, Auryn, Ahmed, Sachin, Noam, Tom, Nich, Diana, Alokik, Derek, Jaemin, Sean, Dennis, David, Yuliya, Ryan, Kaimi, Josef, and Vik.