# Smart Contract Wallet - Account Abstraction **URL:** \ **Category:** Mina Navigator Proposals\ **Created:** [July 8, 2024, 1:14pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352 "2024-07-08T13:14:31Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![hgedia](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/hgedia/32/1734_2.png) [@hgedia](https://forums.minaprotocol.com/u/hgedia)\ **Post date:** [July 8, 2024, 1:14pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/1 "2024-07-08T13:14:31Z")
This topic is to discuss the proposal submitted by @zkzoomer Please see below for the details of the proposal and discussion. **18th July,2024** _Current status: Funded_ _Funding Note: We see this proposal as a useful addition to the ecosystem tooling to do the groundwork towards an Account abstraction interface to be integrated with wallets. The proposer is collaborating with the Pallad wallet team to get guidance on the way forward. The proposer is experienced build and we classify this approval to have medium risk. The risk associated is due to the exploratory nature of this undertaking and we will work with the teams as they progress to provide any guidance or upcoming standards that might impact their work._ **08th July, 2024** _Current status: Under Consideration._ _Opened for community discussion on : 08th July, 2024._ ---
**Author:** ![zkzoomer](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/zkzoomer/32/2084_2.png) [@zkzoomer](https://forums.minaprotocol.com/u/zkzoomer)\ **Post date:** [July 8, 2024, 1:21pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/2 "2024-07-08T13:21:55Z")
# 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](https://neuromancer.sk/std/nist/P-256) 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](https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web) or [Android’s Keystore system](https://developer.android.com/privacy-and-security/keystore)) 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](https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryptography-standards/documents/papers/session6-adalier-mehmet.pdf) 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](https://secg.org/sec2-v2.pdf) 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](https://o1-labs.github.io/proof-systems/specs/pasta.html) 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](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/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](https://github.com/daimo-eth/p256-verifier) 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](https://daimo.com/), 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](https://eips.ethereum.org/EIPS/eip-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](https://eips.ethereum.org/EIPS/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](https://pallad.co/) 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](https://eips.ethereum.org/EIPS/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 - **Proposer Github** : [@zkzoomer](https://github.com/zkzoomer) - **Proposer Experience** : Working as ZK engineer for [Term Structure](https://ts.finance), hackathon experience with o1js ([MinaMix](https://ethglobal.com/showcase/minamix-dz9gc), [recursive-gaming](https://ethglobal.com/showcase/recursive-gaming-90co4)), mentor for zkIgnite Cohort 2. - **Team Members** : [@zkzoomer](https://github.com/zkzoomer) ## 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. ---
**Author:** ![inthestrongwind](https://avatars.discourse-cdn.com/v4/letter/i/2bfe46/32.png) [@inthestrongwind](https://forums.minaprotocol.com/u/inthestrongwind)\ **Post date:** [July 8, 2024, 1:52pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/3 "2024-07-08T13:52:08Z")
This is a great project,while I would prefer to see projects that can bring more players to the Mina ecosystem. ---
**Author:** ![bulingTang](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/bulingtang/32/2083_2.png) [@bulingTang](https://forums.minaprotocol.com/u/bulingTang)\ **Post date:** [July 8, 2024, 2:11pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/4 "2024-07-08T14:11:17Z")
How do you plan to use **o1js** on iOS and Android? ---
**Author:** ![zkzoomer](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/zkzoomer/32/2084_2.png) [@zkzoomer](https://forums.minaprotocol.com/u/zkzoomer)\ **Post date:** [July 9, 2024, 11:39am UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/5 "2024-07-09T11:39:34Z")
Good question. I understand there is some concerns with Auro Wallet regarding o1js compatibility with Chrome and Android. For some applications, users do not really need to interact with o1js directly, as what they would sign is something like an [ERC-4337 user operation](https://eips.ethereum.org/EIPS/eip-4337#useroperation) (using their built-in chips). This signature is what the smart contract wallet would be verifying, so the user does not need to interact with it directly. For privacy-preserving applications, it is a different story, since private data should not leave the user’s device. I am not sure if there is any workaround that does not rely on just using o1js. ---
**Author:** ![bulingTang](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/bulingtang/32/2083_2.png) [@bulingTang](https://forums.minaprotocol.com/u/bulingTang)\ **Post date:** [July 9, 2024, 1:23pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/6 "2024-07-09T13:23:42Z")
But for `Smart Contract Wallet`, you should use o1js or rewrite o1js, because only o1js can build contract transactions body. Have you done core feature preliminary research? That is, the application development of the demo version of the smart contract wallet. ---
**Author:** ![zkzoomer](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/zkzoomer/32/2084_2.png) [@zkzoomer](https://forums.minaprotocol.com/u/zkzoomer)\ **Post date:** [July 10, 2024, 12:12pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/7 "2024-07-10T12:12:22Z")
Users should not need to interact directly with the smart contract wallet: they simply sign their operation (using secp256r1 or the developer’s signature scheme of choice), which a third party can then use to build the actual Mina transaction. ---
**Author:** ![hgedia](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/hgedia/32/1734_2.png) [@hgedia](https://forums.minaprotocol.com/u/hgedia)\ **Post date:** [July 12, 2024, 3:36pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/8 "2024-07-12T15:36:37Z")
We have identified that this piece of work is currently being carried out ZKON team and they are close to releasing this to the public. We are investigating how this proposal can be re-scoped. ---
**Author:** ![bulingTang](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/bulingtang/32/2083_2.png) [@bulingTang](https://forums.minaprotocol.com/u/bulingTang)\ **Post date:** [July 13, 2024, 1:37am UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/9 "2024-07-13T01:37:04Z")
After the user signs, does the transaction need to be built by a third party(base signed data)? Sign first and then build the zk transaction? What is the third party here? Is there an architecture diagram here? ---
**Author:** ![zkzoomer](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/zkzoomer/32/2084_2.png) [@zkzoomer](https://forums.minaprotocol.com/u/zkzoomer)\ **Post date:** [July 13, 2024, 8:41am UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/10 "2024-07-13T08:41:16Z")
Yes, a third party interacts with the smart contract wallet, not the user. The user just provides the signature to this third party. The main focus of the proposal is defining a standard for a smart contract wallet, similar to ERC-4337. The third party service should be given by the wallet provider. ---
**Author:** ![bulingTang](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/bulingtang/32/2083_2.png) [@bulingTang](https://forums.minaprotocol.com/u/bulingTang)\ **Post date:** [July 13, 2024, 1:28pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/11 "2024-07-13T13:28:36Z")
Okay, thank you for your answer ---
**Author:** ![hgedia](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/hgedia/32/1734_2.png) [@hgedia](https://forums.minaprotocol.com/u/hgedia)\ **Post date:** [July 17, 2024, 3:37pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/12 "2024-07-17T15:37:55Z")
> [@zkzoomer](#): > > **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. I am highlighting this for anyone reading the proposal. The scope/deliverables of this proposal have now changed and the updates are part of the original post. ---
**Author:** ![hgedia](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/hgedia/32/1734_2.png) [@hgedia](https://forums.minaprotocol.com/u/hgedia)\ **Post date:** [July 22, 2024, 1:50pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/13 "2024-07-22T13:50:32Z")
This application is approved for Funding. Funding Note: We see this proposal as a useful addition to the ecosystem tooling to do the groundwork towards an Account abstraction styled interface to be integrated with wallets. The proposer is collaborating with Pallad wallet team to get guidance on the way forward. The proposer is experienced build and we classify this approval to have medium risk. The risk associated is due to the exploratory nature of this undertaking and we will work with the teams as they progress to provide any guidance or upcoming standards that might impact their work. ---
**Author:** ![zkzoomer](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/zkzoomer/32/2084_2.png) [@zkzoomer](https://forums.minaprotocol.com/u/zkzoomer)\ **Post date:** [August 12, 2024, 9:20pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/14 "2024-08-12T21:20:09Z")
Started to adapt [Infinitism’s ERC4337 implementation](https://github.com/eth-infinitism/account-abstraction/tree/187613b0172c3a21cf3496e12cdfa24af04fb510) for simple payments only. It seems for now that a general purpose implementation would be considerably more complex since it would need to support arbitrary computation while the circuit being verified would always need to be the same. Following the EC4337 definition, a contract `AccountFactory` deploys `Account` smart contracts that hold user’s assets. This effect is achieved in o1js by: 1. Setting a constant verification key to the `Account` public key, and 2. Customizing the `Account` by assigning it its specific variables, like the secp public key. This implementation is based on [TokeniZkFactory](https://github.com/TokeniZK/tokenizk-finance/blob/5f941c2c8572e6a9fbbc6570b3f86cdaf8c14b80/packages/contracts/src/TokeniZkFactory.ts#L261C86-L261C115). ---
**Author:** ![SebastienGllmt](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/sebastiengllmt/32/1974_2.png) [@SebastienGllmt](https://forums.minaprotocol.com/u/SebastienGllmt)\ **Post date:** [September 2, 2024, 9:57pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/15 "2024-09-02T21:57:48Z")
FYI we done some work for connecting to Mina zkApps from EVM wallets as part of our proposal and we wrote a blog post about the topic The code is open source as well, but we haven’t published it to NPM since it’s blocked on an o1js cache bug > [@Paima engine template](https://forums.minaprotocol.com/t/paima-engine-template/6353/5): > > We just released our blog post that talks about the Smart Contract vs ZkProgram topic precisely! It also talks about how we leverage this concept to build our account abstraction system so that players can access our game directly from EVM wallets ---
**Author:** ![zkzoomer](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/zkzoomer/32/2084_2.png) [@zkzoomer](https://forums.minaprotocol.com/u/zkzoomer)\ **Post date:** [October 29, 2024, 1:33pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/16 "2024-10-29T13:33:57Z")
After side questing at the [Succinct ZK Residency](https://blog.succinct.xyz/zk-residency/), the passage of time has lifted all major blockers, namely: - [Support of secp256r1](https://github.com/o1-labs/o1js/pull/1885), - [Offchain state finally getting fixed](https://github.com/o1-labs/o1js/pull/1834), and - There existing a native way for [zkApp composability](https://github.com/o1-labs/o1js/issues/303) ---
**Author:** ![zkzoomer](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/zkzoomer/32/2084_2.png) [@zkzoomer](https://forums.minaprotocol.com/u/zkzoomer)\ **Post date:** [November 24, 2024, 10:32am UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/17 "2024-11-24T10:32:05Z")
Some updates on the design, I’m following a similar pattern to ERC-4337 with some adaptations to conform to how smart contracts work on mina (eg: absence of a `msg.sender`, non-native arithmetic…). An _account_ in this context is a smart contract that implements the [`IAccountContract`](https://github.com/zkzoomer/minaa/blob/main/packages/contracts/src/interfaces/IAccountContract.ts) interface, which defines two methods: 1. `validateUserOp` to validate a user operation 2. `verifySignature` to verify a signature Internally, these can implement any logic to validate the user operation and signature. Examples will be provided that implement ECDSA on [secp256k1](https://github.com/zkzoomer/minaa/blob/main/packages/contracts/src/contracts/AccountContract.ts) and secp256r1 (wip). Interactions with the blockchain are defined via the [`UserOperation`](https://github.com/zkzoomer/minaa/blob/main/packages/contracts/src/interfaces/UserOperation.ts) struct, which contains the transaction data to be executed. Eventually, this will enable any smart contract call, but for now it just defines payments. Users sign these operations in a way that the corresponding `AccountContract` must be able to validate. We define an [`EntryPoint`](https://github.com/zkzoomer/minaa/blob/main/packages/contracts/src/contracts/EntryPoint.ts) contract that acts as a central hub for all accounts. This contract keeps track of the accounts (their balance and nonce). The `EntryPoint` contract receives the user operations, validates them (by calling the corresponding `AccountContract`), and executes them; via the `handleOp` call. In practice: any app/wallet that wants to implement account abstraction needs to: 1. Define what logic will be used to validate user operations. 2. Implement an `AccountContract` that verifies this logic. 3. Deploy these and link them to the `EntryPoint`. The [`AccountFactory`](https://github.com/zkzoomer/minaa/blob/main/packages/contracts/src/contracts/AccountFactory.ts) can be used to this end: deploying accounts that implement the same form of verification. Some usecases may benefit from forking this design and making the account abstraction less general purpose and more specific, like payments. ---
**Author:** ![zkzoomer](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/zkzoomer/32/2084_2.png) [@zkzoomer](https://forums.minaprotocol.com/u/zkzoomer)\ **Post date:** [December 20, 2024, 12:56pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/18 "2024-12-20T12:56:29Z")
The lack of a `msg.sender` equivalent on o1js proves tricky when basing your work on a Solidity implementation. I have been working on working around these limitations. As an example, in the Solidity implementation, the `EntryPoint` manages the nonce sequence for all registered `AccountContract`s. Since on o1js we cannot check that a caller to a function was a given smart contract, handling the nonce inside the `EntryPoint` means that executing operations from an `AccountContract` is vulnerable to replay attacks. Therefore, updating the nonce has to be made from the `AccountContract` side instead. Similarly, the Solidity implementation allows the `AccountContract` to send funds to the `EntryPoint` to cover transaction fees when their deposit is too low. Given that we cannot check that such call was indeed made by the `EntryPoint`, this can lead to more sophisticated attacks to drain an `AccountContract`’s balance. This functionality has to be removed altogether, although users can still top up their `EntryPoint` deposit to cover transaction fees, it always has to be done in a separate transaction. ---
**Author:** ![zkzoomer](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/zkzoomer/32/2084_2.png) [@zkzoomer](https://forums.minaprotocol.com/u/zkzoomer)\ **Post date:** [January 6, 2025, 7:47pm UTC](https://forums.minaprotocol.com/t/smart-contract-wallet-account-abstraction/6352/19 "2025-01-06T19:47:41Z")
As I wrap up my work, the main limitation found is o1js’s lack of a `msg.sender` equivalent: it is not possible to guarantee that the caller to some function is a given `AccountContract`. This in turn means that making a zkApp that uses account abstraction is not possible without: 1. Implementing a custom `AccountContract` that executes the logic of the given zkApp. 2. Adapting the zkApp logic to accept such calls. By simply adding a `msg.sender` equivalent to o1js, much of the added complexity of the current design could be removed. In turn, it could be possible to define an almost general-purpose `UserOperationCallData` that can be used for any application. Such a design could look like the following: ```typescript class UserOperationCallData extends Struct({ address: PublicKey, dataFields: Array(n), }) {} ``` Where the `address` is the contract being called, and the `dataFields` is an array of _n_ fields that acts as the calldata. Each smart contract would then have to define an additional method to parse the `dataFields` into the appropriate arguments. This would allow for the creation of a general-purpose `UserOperationCallData` that can be used for many applications, abstracting away much of the added complexity of the current design.