# rhinestone Grant proposal

## Project Abstract
Currently, smart contract wallets have three big problems: lack of customizability, vendor lock-in and duplication of engineering work.

Most smart wallets that are being built today are opinionated in the sense that developers decide on the features of the wallet, which entails that the user’s feature preferences are effectively ignored. Secondly, most smart wallets lock users into using a specific interface, making it essentially impossible to switch between interfaces while retaining the same wallet contract. Finally, many teams in the space are building their own smart wallet implementation (either from scratch or based on ERC-4337), meaning that they are spending a large part of their time duplicating each other’s work to build core features such as simple access control or email recovery. Instead of re-implementing these same features, developers should be building new features such as novel ways of recovering an account, implementing banking-like features or using different cryptographic primitives for signature verification.

## Objectives
The objective of this grant is to make rhinestone’s modular implementation of ERC-4337 production ready. On a very high level, this requires ensuring that the contracts are both secure and optimized. The contract standard will be open source using the GPL-3.0 license and our intention is to propose a new ERC for this open standard, should this be beneficial to the community.

So far, the rhinestone team has built a working prototype of a modular implementation of ERC-4337 using diamond proxies (ERC-2535). This prototype placed us as winners of the infrastructure track at ETHDenver and won us 6 bounties from sponsors, including Scroll, zkSync and Coinbase.

Our proposed contract standard allows developers to build and deploy stateless facets (or “plugins”) that users can add or remove from their modular smart wallet without needing to redeploy the plugins or the wallet.

However, in order to ensure that this new contract standard is production ready, we need to solve a number of open technical questions. These include:

1. How to resolve storage conflicts between plugins. As of yet, there is no guard in place to ensure that a plugin cannot override the same storage slot used by another plugin, hence leading to results that may be undesired (at best) to becoming serious security vulnerabilities (at worst).
1. How to ensure that the security of plugins is verified in a decentralized way.
1. How to resolve function selector clashes that become more likely as more plugins are created and used.

On top of this, there are numerous smaller questions, many relating to optimizing the contract while allowing it to be as flexible as possible for later changes. Hence, we would use this grant to focus on further building out the rhinestone contract standard and ensuring that it is as secure and optimized as possible.

Success will be measured by getting the rhinestone constract standard production ready, as measured internally and externally. Internally, we are setting specific goals in the form of unit tests, gas-consumption targets, etc which are required to pass before rhinestone can be used in production. On top of that, we want rhinestone’s security model and implementation to also be assessed by an external party, most likely an auditing firm.

## Outcomes for the ecosystem
The development of rhinestone benefits both developers and users of Ethereum.

Rhinestone gives smart wallet developers a more efficient way to build wallets, by allowing them to focus on building novel features in the form of plugins rather than needing to build the entire wallet implementation. This radically reduces the duplication of engineering work which could, for example, be building out the wallet implementation based on ERC-4337, setting up a bundler or configuring a paymaster. Instead, developers can build plugins with specific features that are easily integrated into the modular rhinestone contract standard. This also reduces the security risks for developers as they are able to focus on building code they might be more familiar with, rather than needing to get extensively acquainted with ERC-4337 and its particular security challenges. Therefore, we expect the rhinestone contract standard to be a major catalyst for innovation on top of ERC-4337.

The benefit for Ethereum network users is that rhinestone allows them to create and use a more customizable wallet, ensuring their preferences are matched to a higher degree. Some users, for example, might be looking to use their wallets in order to play on-chain games, others will look to go bankless and yet others might be after a more secure way to trustlessly store their assets. The features that each of these use-cases require are likely to be quite different, meaning that regular, non-modular wallets are unlikely to match the preferences of each of these users in an efficient and secure way. Using rhinestone, users are able to select the functionality that matches their preferences and are able to modify their selection at any time.

## Project Team
Konrad Kopp – Full-stack & Solidity Developer
* Previously exited edtech founder & CTO
* Finalist at ETHAmsterdam and ETHDenver
* Previously a core contributor to Retrox, an open-source public goods funding protocol that received grants from the Ethereum Foundation, Protocol Labs and Gitcoin (still involved with advising the Retrox team but very little time spent contributing code)
* Project input: Full-stack development, conception of the architecture and implementation in Solidity
* Time commitment: Full time

Kurt Larsen – Product
* Previously Product Lead for Marketplace Algorithms at Deliveroo. Applied machine learning to solve problems in the fields of pricing, incentives, demand and supply matching, and personalisation. Extensive experience leading developer teams tackling complex technical problems.
* Project input: Project coordination, research, external communication and documentation
* Time commitment: Part time

zeroknots – Solidity Developer
* Founder and CTO of a pentesting and security assesment company
* 7+ years of experience as a pen-tester
* Experience as a Solidity auditor
* Project input: Conception of architecture, development of security models and implementation in Solidity
* Time commitment: Full time

## Background
**Konrad Kopp**
Code
* https://github.com/Retrox-PGF/retrox
* https://github.com/kopy-kat/ethdenver-aa

Papers
* https://mirror.xyz/konradkopp.eth/e-g57omzdToypDC0yUB09JOfg0zhYhBRRwW6UWjbckw
* https://mirror.xyz/kristoflommers.eth/WQrVSJd5aKz2fZotKeBfGuUOmCeG7rXLC0Xk-pQzf98
* https://mirror.xyz/retroxblog.eth

**Kurt Larsen**
Papers
* https://kurtlarsen.substack.com/

Past experience
* https://www.linkedin.com/in/kurt-larsen-9680a447/

**zeroknots**
Code
* https://github.com/zeroknots/brokentoken
* https://github.com/zeroknots/boilerplate.sol

Papers
* https://zeroknots.dev/

## Architecture
The architecture for our proposed modular smart wallet consists of three parts: the modular smart wallet implementation, the plugins and a plugin registry.

*Modular smart wallet architecture chart*

The modular wallet implementation consists of a single wallet that interfaces with stateless plugins. Every user needs to deploy their own wallet contract but plugins only need to be deployed once and can be reused by any wallet. The wallet uses diamond storage to store active plugins and then routes to these based on how the wallet is called.

*Registry architecture chart*

The goal of the registry is to ensure security for the wallet user. Hence, the registry only stores verified plugins and is called when a user wants to add a new plugin to their wallet. Adding the plugin will only be possible if it is approved by the registry that the users wallet currently consults. However, the user can easily switch to a different registry in order to prevent vendor lock-in. Registries could plausibly be controlled be DAOs, companies or even individuals.

## Milestones
* Build registry protocol implementation
* Main technical objective: building the registry to be secure and future-proof for potentially different modular smart contract wallet implementations
* Deliverable: implementation of a registry and modules that can be plugged into an existing modular smart contract wallet, e.g. Safe
* Time estimate: 1.25 developers full time for 1 months (200 hours)
* Cost estimate: $12,000
* Sketch out path to decentralization of registry
* Main objective: creating a plan for how to introduce different entities into the registry ecosystem and decentralize the authority over the registry
* Deliverable:
* Time estimate: 1 person full time for 2 weeks (80 hours)
* Cost estimate: $4,800
* Build standardized interfaces for modules and test on various modular account implementations
* Main technical objective: build interfaces for modules in order to ensure cross-compatibility with existing design choices (e.g. zodiac or using diamond storage) and test with different implementations (e.g. Safe, rhinestones Diamond Account Prototype, ZeroDev’s Kernel)
* Deliverable: standardized module interfaces and a write-up of design choices
* Time estimate: 1.25 developers full time for 1 months (200 hours)
* Cost estimate: $12,000
* Design monetization and incentive structures
* Main objective: conceptualize and extensively sketch out the different paths to monetization and incentive structures that would allow for the registry to become self-sustaining
* Deliverable:
* Time estimate: 1 person full time for 3 weeks (120 hours)
* Cost estimate: $7,200

## Budget
Total budget requested: $36,000

Breakdown of budget:
* Salaried time: $36,000
* Salaried time rate: $60/hour
* Total salaried hours: 600 planned hours