# Crypto Banks as L2

## Overview

Proposed below is a construction of a fully onchain “crypto bank” using an L2.

- Fast settlement of ERC20/ETH transfer between users of the same bank (L2 transfer)
- Settlement to L1 (settlement layer) via trustless rollup bridge
- Support for relaying arbitrary transaction to L1
- Fully EVM equivalent (existing block explorer, wallet, etc) works
- Automatic ERC20 token contract address mirroring between L1 <> L2
- User obtains access to smart accounts in both L1 and L2 with the same addresss
- Simpler/faster fraud/ZK proving system
- [Optional] ETH deposited to the “bank” (L2) can be trustlessly staked via liquid staking protocols to generate yield

## Architecture

The rollup is a modified EVM rollup with the following modification

- Endusers are not able to deploy their own custom smart contracts or invoke CREATE/CREATE2.
- Smart accounts
- **Creation** — End users are able to request the creation of a smart account by signing a transaction and submitting it to the L2 mempool or through the L1 escape hatch.
- **Representation** — Smart accounts are represented as smart contract wallets ala Gnosis on both L1 and L2 capable of executing arbitrary smart contract calls and eth transfers
- An ERC20 token deposit from L1 will:
- Automatically create a smart contract on the L2 with the same contract address in L1 that will be used to do ERC20 accounting on the L2.
- If the recipient address does not exist in the L2 yet, the token will be stored for safe keeping but can be claimed by proving ownership of the account.
- This can be done via EOA signature or smart contract signature verification (EIP-1271) from both the L1 (through escape hatch) or L2
- A transaction submitted to the L2 mempool will:
- If the transaction is an ETH or ERC20 transfer:
- Does the destination have a smart account in the L2?
- **Yes** → Do the transfer in the L2
- **No** → The ERC20 transfer function will call the rollup L1 bridge to withdraw the ERC20 from the L2 smart account into the L1 smart account, then the L1 smart account will execute transfer to the destination address.
- **Why is it withdrawn to the L1 smart account instead of directly to the destination address?** → It provides better clarity on who the sender (making address book tracking/block explorer cleaner) instead of just making it seems like the sequencer smart contract on L1 is doing these transfers.
- **Who signs/executes the L1 txs?** → ****Once the sequencer have posted the tx data to L1 and the rollup proof (let it be optimistic or ZK) is satisfied, anyone can trigger the L1 transaction on the behalf of anyone.
- Practically, this would be the rollup operator, but if the rollup operators fails to do this, the user or 3rd party can complete this step.
- If the transaction is anything else:
- The L2 sequencer is responsible in relaying the transaction to the smart account representation in the L1 to be executed.
- Rollup ZK/fraud proof
- Since the rollup is strictly limited to eth/token transfer, the proving system can be significantly optimized
- Proving complexity is significantl lower because the state transition you need to proof are just account balance updates instead of the actual op code execution
- **ZK** → Faster ZK proving time → Faster withdrawals to L1 and lower fees
- **Optimistic** → Transactions are simpler to replay onchain in 1 tx, allowing single-shot fraud proofing → Challenge window can be significantly decreased → Faster withdrawals to L1