# BLSWallet & 4337

## [1. Fully embrace 4337](https://hackmd.io/6_rTYV--SimB3lTlLVFOmg?both)

- Drop support for directly calling `VerificationGateway` for ordinary transactions and pivot to only using the 4337 `EntryPoint` contract
- Use the 4337 fee/gas mechanism
- Stop developing the model where the wallet adds an explicit `tx.origin` payment
- Continue to explore/promote an ecosystem where dApps can pay `tx.origin`, allowing us to set the 4337 fee fields to zero when this is available (relying on mev/etc to identify these opportunities)

This seems by far the best option. We can still promote an ecosystem where dApps pay `tx.origin` and enable us to set the 4337 fee fields to zero. This will always be a (perhaps rather small) subset of dApps, so we need to primarily support a payment mechanism that is universal, so dApps paying `tx.origin` is secondary.

I also believe we should not pursue a model where the user simply includes an extra `tx.origin` payment. It diverges from the 4337 ecosystem without benefit. At the very least, these `tx.origin` payments should be tied to `BASEFEE` for stability, but... that's just 4337. Let's just do that.

I think we might be overestimating the inertia of the current system. Most of the work we have done is really about bringing all these pieces together and assembling a team that deeply understands the idea. Pivoting to 4337 from this point is totally achievable, and trying to support a hybrid seems to be mostly a headache with little benefit.

## 2. Support 4337 in parallel

Like (1), but:

- Retain direct calls to `VerificationGateway`
- Always set 4337 fee fields to zero (or have different kinds of payment for each system?)
- Rely on wallets adding explicit `tx.origin` payments for all dApps that haven't integrated these kinds of payments

This option might cause less disruption to our current plans. It avoids new development to support the 4337 fee mechanism but depends on a separate `tx.origin` payment ecosystem emerging and relies on incomplete work to support wallets adding `tx.origin` payments.

It's also possible we could use the 4337 fee fields when using 4337, and separately use `tx.origin` payments when not using 4337.

Unless there is already a lot of momentum with third parties wishing to integrate the current system, I see it as an unnecessary fragmentation and source of confusion for BLSWallet.

## 2a. Support 4337 in parallel using extra contracts to avoid existing contract changes

In (2), the idea is to add the necessary 4337 mechanisms to `VerificationGateway` and `BLSWallet`. [There is a prototype for this](https://github.com/voltrevo/account-abstraction/tree/21b72dd/contracts/samples/BLSWallet).

There's been some discussion about using additional contracts to avoid any changes to the existing contracts, which may reduce our auditing costs.

However, this is currently incompatible with signature aggregation. The 4337 `EntryPoint` contract makes separate calls for signature verification and contract wallet calls. The only way to make our contract wallet do anything is to go via `VerificationGateway#processBundle`, which requires a valid signature. Because the 4337 `EntryPoint` makes a separate call for each operation, each operation would then need to have an individual signature for `VerificationGateway#processBundle` to accept it.

Conceivably the 4337 `EntryPoint` could be changed, but 4337 wants to measure the gas used by each operation to enable fee payment tied to those measurements according to the actual on-chain execution. It's not possible to do this without carving out another new 4337 flow specifically for our model which sets 4337 fees to zero (relying on paying `tx.origin` in other ways).

Instead, we should simply change `BLSWallet.sol` to trust calls from the 4337 `EntryPoint` or another proxy contract. This still allows us to avoid changing `VerificationGateway`, and instead have `BLSWallet.sol` or its proxy contract point to another place for aggregate signature verification.

"Proxy contract"s above would allow us to avoid adding `validateUserOp()` and `getAggregator()` to `BLSWallet.sol`. However, since these are simple, and we're modifying this contract anyway, I believe it makes a lot more sense to simply add these to `BLSWallet.sol` in addition to trusting another caller. Proxy contracts would also mean the `sender` field in the 4337 `UserOperation` would need to be these proxy contracts instead of the actual contract wallets (`BLSWallet.sol`), resulting in additional confusion for wallet implementers, users, block explorers, etc.

To summarize:

- Can avoid changing `VerificationGateway`
- Can't realistically avoid changing `BLSWallet.sol`
- May reduce auditing overhead because `VerificationGateway` is unchanged, but introduces a new contract to audit (the 'Aggregator' indicated by `getAggregator()`, which verifies aggregate signatures for 4337 calls)

## Contract wallet creation / 1st tx

For (2) and (2a) there's ambiguity about how the contract wallet (`BLSWallet.sol`) is created.

4337 supports contract wallet creation using the `initCode` field, which could be used, but creates confusion for the blskey <=> address relationship (now different depending on whether you use the 4337 `EntryPoint` or `VerificationGateway`). It also requires an extra contract interaction to configure the `VerificationGateway`, and might mean additional changes to `VerificationGateway` (relevant for (2a)).

Alternatively, we can rely on `VerificationGateway` for contract wallet creation, but it means users targeting 4337 will need to explicitly create their wallet.

## 3. Abandon all 4337 interop plans

Maybe it's possible that it's too important to keep things the way they are and 4337 isn't getting any traction anytime soon anyway. If these things are true it's conceivable we could just forget about 4337 and continue without it.

A related and more realistic point is that we could finalize V1 without any relationship to 4337 and focus on V2 as a 4337 wallet.