This week was engrossed on Armor. Armor is a wallet application that uses account abstraction to leverage multi-transaction execution with social recovery features and MEV attack resistance.

Problem Statement:

The transaction-batching feature of account abstraction lets users batch multiple transactions together to save on the gas fees for a single transaction. However, when batching transactions, front-running and sandwich attacks cause a problem. Invalidation of even one transaction, though MEV attack, could lead to invalidation of the whole batch of transactions, also called mass invalidation.

This calls for MEV attack resistance on the wallet application to ensure that the multi-transaction feature cannot be exploited. For Starters, the Gnosis safe contracts serve as a reference implementation for the multisig wallet that supports social recovery and transaction batching.

Other reference implementations that helped me form a bare-bones multisig wallet with social recovery features are the Candide wallet and eth-infinitism.

For MEV attack resistance, flashbot protect is the go-to solution. Flashbot protect receives transactions into its own mempool instead of the public mempool. Here, the transactions are evaluated to check if the transaction needs flashbot protection or not, if it does not the transaction is sent back to the public mempool otherwise it is protected from MEV attacks.

Since the transactions using account abstraction use a separate mempool, the inclusion of the flashbot protect could cause a problem as it requires the transactions to be sent to the flashbot mempool instead followed by the transactions being sent to the public mempool. This piece of the puzzle needs a bit more brainstorming.

To infinity and beyond! 🚀