Smart Contract Wallet
This proposal aims to implement a smart contract wallet on Mina that can enable account abstraction by verifying different signature schemes, like ECDSA on the secp256r1 elliptic curve.
Proposal Overview
The Problem
Perhaps the greatest hurdle for new users onboarding to web3 applications is having to deal with their private keys. While great progress has been made in the infrastructure around it, the reality is the vast majority of us do not know how or simply do not want to deal with private keys.
And yet, we use them every day when we operate with our smartphones, sometimes without even realizing. The built-in security chips in our devices (like Apple’s Secure Enclave or Android’s Keystore system) allow us to safely perform cryptographic operations while ensuring the private key never leaves the device. The results is a much more convenient and intuitive user experience.
The reason why this built-in chip cannot be used to sign transactions in web3 comes down to cryptography, more specifically the choice of curve. While secp256r1 has reached mass adoption as the standard in the vast majority of consumer-facing applications (as is the case with these built-in security chips), this is largely not true for the web3 world.
In the case of Bitcoin and Ethereum, the choice of the secp256k1 curve over secp256r1 stemmed from concerns about a potential backdoor introduced on the latter by the NSA. This has arguably been counterproductive in bringing more users to the space. In the case of Mina, the choice of the Pasta Curves makes it more practical for proof recursion.
As a result of this curve mismatch, as far as the web3 space is concerned, it is not possible to directly use the cryptography and hardware built into consumer devices. The key pair generated by these built-in chips cannot natively sign Ethereum or Mina transactions, forcing users to create another key pair using different software that is completely new to them, resulting in a much more challenging onboarding process.
Proposed Solution
The Ethereum ecosystem has already started tackling this problem. The introduction of EIP-4337 enables account abstraction, avoiding the need for consensus-layer protocol changes. Users can sign transactions using their built-in chips on their smartphone devices, as the smart contract wallet can have arbitrary verification logic. Additionally, the proposed EIP-7212 would add a precompiled contract that performs signature verification in the secp256r1 curve.
Unfortunately, the use of a smart contract wallet that verifies secp256r1 signatures results in higher transaction costs, due to having to process additional non-native logic: an additional ~330k gas per signature. This has limited the use of these account abstraction features to rollups, which are only starting to be used now.
In the case of Mina, no native account abstraction or smart contract wallets that can perform these operations exist to this day. The main advantage of enabling such features is that, unlike other blockchains, the fixed fee model of Mina means that the additional logic would result in no additional cost to the end user (barring the increase in proving time).
Potential Impact and Applications
Arguably the best way to onboard users into the space will be via applications that consumers will use simply because they are better, without even having to know that crypto is involved.
A great recent example of such applications is Daimo, a non-custodial wallet enabling worldwide stablecoin payments in a reliable, secure, and very intuitive way: making use of these built-in chips and ERC-4337 contract accounts.
This proposal could be used to build more consumer friendly applications, which could take advantage of Mina’s ZK nativeness to enable worldwide private payments, or intuitive identity applications.
Architecture & Design
- Detailed Design/Architecture: the smart contract wallet implementation will look to adapt Ethereum’s EIP-4337 into o1js, but more specifically the Mina blockchain. The final implementation would be composable, enabling different signature schemes to be used, and allowing third party services to easily use it as a blueprint for their products.
- Vision: the final goal would be a contract standard that can be used by different applications. As an MVP, we would look into integrating into Pallad to define a simple wallet dashboard showing a possible usecase.
- Production Timeline: after the three months of development are done, the contract standard would have to undergo a security audit, after which it could start to be used in production.
Budget & milestones
- Deliverables:
- Implementing an EIP-4337-like smart contract wallet on o1js.
- Integrating secp256k1 and secp256r1 into the smart contract wallet API reference.
- Building an MVP wallet dashboard enabling account creation, topup, and fund transfers.
- Writing proper documentation for other parties to build on top of the contract standard.
- Laying out further research, steps, and potential usecases.
- Mid-Point milestones: smart contract wallet architecture and documentation
- Project Timeline: three months
- Budget Requested: 30,000 MINA
- Budget Breakdown: expected 20-25 hours/week of work at a $50/hour rate.
- Wallet Address: B62qmCR34F5ifz4AREu7Sy2d7HJcLaGYQaJp4BEQ2eCNPAVos6RUKbE
Team Info
Risks & Mitigations
As this proposal aims to build a fundamental piece of infrastructure, using it in production before a proper auditing process could result in large exploits.
To potentially mitigate the introduction of critical bugs and make the auditing process easier, the codebase must be built following best practices, looking to keep any implementation as simple and explicit as possible.
EDIT NOTE: the scope of the project no longer includes verifying secp256r1 signatures on o1js, and has moved into implementing an MVP that can make use of built-in chips to create accounts and send and receive funds.