# **Cross-Chain Recovery for ERC7579 accounts**

This document investigates three approaches for adding cross-chain recovery to a ERC7579 smart account module in terms of architecture, comparisions around cost, complexity and security and pros, cons of each approach

## **Architecture**

#### KeyStore Rollup


The recovery state lives in the recovery modules and inside the keystore rollup in terms of the updated keys and the recovery update flow is described in the architecture

Some steps are not numbered correctly and there is a incomplete step description in the screenshot (excelidraw didn't allow me to edit the exported image)

- 1. sends an email with the recovery info to the zk email guardian
- 6. calls the complete recovery method
- 7. Recovery is successful and the validator key is updated and both validators A and B now refer to the same key

#### Biconomy’s Modular Execution Environment


The recovery state lives in the recovery modules and the recovery update flow is described in the architecture

MEEs execute Supertransactions through a Quote/Execute process.

The steps on how the biconomy mee network broadcasts the cross chain tx's as mentioned in the screenshot above

- User sends an array of different cross-chain actions to the mee node into a supertransaction

- The mee node encodes the array using a merkle tree approach into a supertransaction and returns the quote of the execution cost to the user

- The user signs the root hash of the merkle tree of the supertransaction

- The mee node then signs the hash themselves and executes the actions

#### Replayable guardian signatures


The recovery state lives in the recovery modules and the recovery update flow is described in the architecture

There is a incomplete step description in the screenshot (excelidraw didn't allow me to edit the exported image)

- 1. sends an email with the recovery info to the zk email guardian

## **Comparision**

| Criteria | **Signature‑Replay** | **Axiom Keystore Rollup** | **Biconomy MEE** |
|-----------|------------------------------------------------------|---------------------------------|-----------------------------|
| **Cost** | includes proof computation cost and gas spent by the relayer for each replayed signature, cheap overall | 100_000 gas for each key `UPDATE` operation, so cheap overall | can be high depending on the no of chains where recovery is needed |
| **Security** | secure, being a in-house solution | security can be compomised due to external dependency on axiom | security can be compomised due to external dependency on mee |
| **Latency** | fast overall (depends on the no of chains where recovery is needed ) | can take upto 1-1.5 hours for the updates to be reflected | better than the keystore rollup approach (depends on the no of chains where recovery is needed )

## **Pros/Cons**

### - Axiom Keystore Rollup

#### Pros

- allows to recover multi-chain accounts without replaying a message
- zk proof authentication
- cost efficient

#### Cons

- over reliance on axiom in terms of security
- latency can be high

### - Biconomy MEE

#### Pros

- allows the heavy lifting to be done my the mee node without any replaying involved
- low latency

#### Cons

- over reliance on biconomy in terms of security
- cost can be high
- requires an extra signature for executing the supertransaction

### - Signature Replay

#### Pros

- cost efficient
- secure
- low latency

#### Cons

- replaying the signature for each chain not efficient overall
- needs a relayer network to be more efficient

Note - In all approaches, the examples that I have used in the architecture diagrams I have assumed that the key on chain B needs to be recovered and the recovery request initiates from chain A