Rhinestone is an ERC-7579 smart account infrastructure company that builds the open-source tooling, audited module registry, and Safe integration needed to deploy production-grade smart account modules. Its primary product, ModuleKit, is a development and testing framework for building ERC-7579 modules. The Module Registry is a curated listing of audited modules that smart account implementations can verify before enabling. Together, these products address the two hardest problems in smart account module development: writing modules that meet the ERC-7579 standard correctly and deploying them with sufficient security assurances.
​

ERC-7579 is a modular smart account standard ratified in 2024 that defines a common interface for attaching functionality to smart accounts. Rather than embedding every feature inside a single account contract, ERC-7579 allows developers to install discrete modules (validators, executors, hooks, and fallback handlers) that extend account behavior without forking the base account. Rhinestone's infrastructure is purpose-built for this standard. The ERC-7579 specification on Ethereum Improvement Proposals documents the full interface.
​

ERC-7579 is a smart account modularity standard ratified in 2024 that defines a shared ABI for attaching validator, executor, hook, and fallback modules to any compatible smart account. Before it existed, every implementation used proprietary interfaces, preventing module reuse across Safe, Biconomy, Kernel, ZeroDev, and Alchemy's Modular Account. Module infrastructure like ModuleKit makes writing and testing compliant modules tractable.
​

The practical problem module infrastructure solves is that writing an ERC-7579 module correctly requires setting up a local fork of multiple account implementations, writing tests against each, understanding the ERC-4337 execution lifecycle (validation phase vs. execution phase), and ensuring the module does not introduce reentrancy or storage collision vulnerabilities. Before ModuleKit, development teams built this scaffolding from scratch for every module, a process that took weeks and produced bespoke testing environments that were hard to audit.
​

ModuleKit provides a pre-built testing environment with account simulators for all major ERC-7579 compatible implementations. A developer writing a session key module runs it against Safe, Kernel, Biconomy, and Alchemy's Modular Account in a single test suite rather than maintaining four separate forks. The ModuleKit documentation includes setup guides, example modules, and integration test patterns.
​

The audit and registry problem is separate from the development problem. A module may be technically correct but undiscoverable: developers have no reliable way to know which third-party modules are safe to install. Rhinestone's Module Registry addresses this by listing only modules that have passed a defined audit process, providing on-chain verification that a given module at a given address was audited before listing.
​

ModuleKit is a Foundry-based smart contract development framework that provides abstract base contracts, account instance helpers, and test utilities specifically for building ERC-7579 modules. A developer inherits from ModuleKit's base contracts, which enforce the ERC-7579 interface and provide default implementations of required functions. The test utilities instantiate live account implementations against a local Anvil fork, allowing end-to-end tests that simulate real account behavior without deploying to a public testnet.
​

The framework ships with account instance wrappers for Safe (via Safe7579 adapter), Kernel, Biconomy Nexus, and Alchemy Modular Account. Each wrapper exposes the same test interface, so a single test suite verifies module behavior across all supported accounts. This cross-account compatibility testing is the primary value ModuleKit adds over writing tests directly: it surfaces incompatibilities before deployment rather than after.
​

ModuleKit also includes a module scaffolding CLI that generates boilerplate for each of the four ERC-7579 module types. Running the scaffold for a validator module produces a base contract, a test file, and a deployment script configured for ModuleKit's testing environment. Teams report that this scaffolding reduces initial setup time from days to hours, based on community feedback in the ModuleKit GitHub repository.
​

For production deployments, ModuleKit integrates with Foundry's deployment scripts. Modules deployed through the ModuleKit workflow automatically produce the artifact format required for Module Registry submission. This makes the development-to-registry pipeline continuous: write, test with ModuleKit, submit artifacts for audit, list in registry.
​

The Rhinestone Module Registry is an onchain and off-chain system for listing ERC-7579 modules that have passed a security audit. Registry entries include the module's contract address, the ERC-7579 module type (validator, executor, hook, or fallback), the auditor's identity, the audit report reference, and the date of listing. Smart account implementations can query the registry before enabling a user-requested module to verify that it was audited and listed, adding a programmatic safety check to the module installation flow.
​

The registry distinguishes between two listing tiers: community-submitted modules (listed after a basic interface check, no audit required) and audited modules (listed after a security review by an approved audit partner). The audited tier is what production wallet and DeFi applications use when gatekeeping module installation. The Module Registry documentation describes the submission process and the on-chain contract interface for querying audit status.
​

Registry queries are designed to be called from smart account logic. When a user or dapp requests a module installation, the account's installer hook can query the registry contract, passing the module address and required trust level, before completing the installation. If the module is not listed at the required tier, the installation reverts. This on-chain verification is what Rhinestone calls "registry-enforced security."
​

As of Q1 2026, the registry lists modules including auto-compound modules for yield protocols, session key validators, multi-owner validators, spending limit executors, and cross-chain execution hooks. Each category addresses a recurring smart account use case that developers previously had to implement from scratch per account implementation.
​

Rhinestone's Safe integration, called Safe7579, is an adapter that makes Safe smart accounts compatible with the ERC-7579 module standard. Safe is the most widely deployed smart account implementation, holding over $100B in secured assets as of Q1 2026, but Safe's native module system predates ERC-7579 and uses a different interface. Safe7579 wraps a Safe account with a proxy that implements the ERC-7579 ABI, allowing any ERC-7579 module to be installed on a Safe without modifying the underlying Safe contracts.
​

This is significant because Safe's existing security record and institutional adoption mean that many enterprise and treasury applications run on Safe. Without Safe7579, these applications could not use ERC-7579 modules (including the auto-compound, session key, and spending limit modules in the Rhinestone registry) without migrating away from Safe. Safe7579 makes the module ecosystem available to the entire existing Safe user base.
​

Safe7579 has been audited by Ackee Blockchain and reviewed by the Safe team. The source code is available in the safe7579 GitHub repository. Rhinestone recommends Safe7579 as the primary production deployment path for teams building on Safe that want to use ERC-7579 modules.
​

ERC-4337 is the account abstraction standard that defines UserOperations, bundlers, and paymasters (the execution infrastructure for smart accounts). ERC-7579 is the modularity standard layered on top: it specifies how smart accounts designed for ERC-4337 attach external modules. Rhinestone operates at the ERC-7579 layer. ModuleKit, the Module Registry, and Safe7579 are all module-layer infrastructure; they depend on the existence of ERC-4337 execution infrastructure (bundlers, paymasters) provided by other teams.
​

MEE providers (Multi-Execution Environment providers) are services that provide bundlers, paymasters, and execution infrastructure for ERC-4337 smart accounts. Examples include Pimlico, Stackup (now integrated into Biconomy), and Alchemy's Account Kit. These providers are the runtime infrastructure that executes UserOperations. Rhinestone's modules install into accounts that run on top of these providers; a session key module from the Rhinestone registry runs on whatever MEE provider the account uses. The relationship is analogous to browser extensions and a browser engine: the module (extension) runs in the account (browser), which runs on the MEE provider's infrastructure (engine).
​

This stack is documented in the Rhinestone overview documentation, which maps the relationship between ERC-4337 account abstraction infrastructure, ERC-7579 module standards, and Rhinestone's specific products. Developers building with ERC-4337 account abstraction typically encounter Rhinestone when they need to add session key management, automated execution, or programmable spending controls to an account.
​

ERC-7579 defines four module types, and Rhinestone's registry and ModuleKit support all four. The most in-demand module categories as of Q1 2026 are session key validators and automated execution modules, which together address the two most common reasons developers upgrade from an externally owned account to a smart account.
​

Session key modules allow a smart account to authorize a temporary signing key with scoped permissions: the session key can send transactions only within a specified time window, only to specific contract addresses, and only up to a maximum value. This enables dapps to request session-scoped signing authority without asking users to sign every transaction. This pattern is used by games, trading bots, and automated DeFi strategies. Rhinestone's registry lists audited session key validator modules compatible with Safe, Kernel, and Biconomy Nexus.
​

Auto-compound modules enable a smart account to automatically reinvest yield from protocols like Aave or Compound without the user signing a transaction each time. An executor module is triggered by an external caller (often a keeper network) and executes a defined set of transactions on behalf of the account. The account's session key or multi-sig controls who can trigger the executor and under what conditions. Rhinestone's auto-compound module works with Aave V3, which holds $13.7B TVL as of April 2026 per DeFiLlama.
​

Spending limit modules enforce daily or weekly transfer caps on a smart account, preventing any single transaction from exceeding a defined value regardless of other authorization. These are particularly relevant for treasury accounts and user-controlled smart accounts where the account owner wants belt-and-suspenders protection against large unauthorized transfers. The module enforces limits at the account layer rather than in application code, making it auditable and portable across any ERC-7579 compatible account.
​

Hook modules execute logic before and after every transaction the account processes. Use cases include: logging all outgoing transfers to an index, blocking transactions to blacklisted addresses, requiring multi-step approval for transactions above a threshold, and emitting standardized events for compliance monitoring. Hooks run synchronously in the account execution context and can revert the transaction if their conditions are not met.
​

Rhinestone is the most focused ERC-7579 module infrastructure project as of Q1 2026, but several adjacent ecosystems address similar problems. The table below compares the main options developers evaluate.
​

The key Rhinestone differentiator is the combination of a cross-account development framework and an audited registry. Most MEE providers offer an SDK for their specific account implementation but do not provide a framework for testing a module against multiple implementations simultaneously. Rhinestone's ModuleKit is the only widely adopted tool that abstracts across Safe, Kernel, Biconomy Nexus, and Alchemy Modular Account in a single test suite as of Q1 2026.
​

ModuleKit is an open-source Foundry framework for building and testing ERC-7579 smart account modules. Teams building session key management, automated DeFi execution, spending controls, or compliance hooks for ERC-7579 compatible smart accounts should use it. It reduces setup time by providing pre-built account instance wrappers for Safe, Kernel, Biconomy Nexus, and Alchemy Modular Account, enabling cross-account compatibility tests in a single suite.
​

The community tier of the registry accepts permissionless submissions with a basic interface check. The audited tier requires a security review by an approved audit partner before listing. Production wallet and DeFi applications are expected to query the audited tier when gatekeeping user-requested module installations. The Module Registry documentation describes both tiers and the submission process for each.
​

Yes. Safe7579 is Rhinestone's adapter that makes ERC-7579 modules compatible with Safe accounts. It wraps a Safe instance with a proxy implementing the ERC-7579 ABI, so any module in the Rhinestone registry can be installed on a Safe without modifying the underlying Safe contracts. Safe7579 has been independently audited and is the recommended production path for Safe-based ERC-7579 module deployments.
​

ERC-4337 defines the execution infrastructure for smart accounts: UserOperations, bundlers, paymasters, and the EntryPoint contract. ERC-7579 defines how smart accounts designed for ERC-4337 attach external modules. Rhinestone operates at the ERC-7579 layer, building the framework and registry for modules. The ERC-4337 execution layer is provided by MEE providers like Pimlico, Alchemy, and Biconomy that run the bundler and paymaster infrastructure.
​

Sources and methodology. ERC-7579 standard details verified from EIP-7579. Rhinestone product details from official Rhinestone documentation and ModuleKit GitHub. Safe asset figures from Safe official communications. Aave V3 TVL from DeFiLlama, April 29, 2026. Figures refresh quarterly.
​

By Eco research. Updated Apr 2026.
​