Introduction

Before discussing the problem with cross-chain account abstraction and how we solve, let me introduce you to Banana SDK.

Banana SDK is a cross-chain account abstraction wallet SDK that is being developed in collaboration with Axelar and SAFE. It is currently live on testnets and is being used by multiple dApps and wallets to enhance the onboarding experience for their users. You can watch a demo of Banana in action with Lenster at https://youtu.be/TTZs2Mx2x4Y.

Banana's integration is straightforward, with dApps requiring only a few lines of code to incorporate it into their applications. Detailed documentation on how to use Banana can be found at https://banana-wallet-docs.rizelabs.io/.

What is the problem with cross-chain account-abstraction wallets?

Account abstraction wallets offer users unique smart contract instances on individual chains, but this presents some challenges compared to conventional Externally Owned Accounts (EOAs) that have consistent addresses on all Ethereum Virtual Machine (EVM) chains. Users of account abstraction wallets expect a consistent address for their wallets on different chains, like they have with conventional wallets. However, creating account abstraction wallets on different chains ultimately results in distinct account addresses, which poses several drawbacks for users.

The major issue is the risk of lost funds when account holders share their account abstraction wallet address without specifying the particular chain where they can receive assets. Cross-chain bridges also assume identical addresses on both sides of bridging, which can mislead users into bridging assets to a chain where they lack access. Additionally, managing multiple addresses across chains is more complex than having a single consistent address on all EVM chains, which can add an extra workload for users.

How will we solve it at Banana SDK?

To address the challenges posed by distinct account addresses in account abstraction wallets, an ideal solution combines these addresses with a single overarching identifier. However, using a single consistent address across all chains is not practical due to the unique nature of account abstraction wallets. Chain-specific addresses are essential to remove any ambiguity on the side of wallets and dApps. Ethereum Name Service (ENS) offers a solution to this challenge by allowing users to register human-readable domain names and map them to blockchain addresses.

ENS allows a single ENS name to be mapped to different addresses depending on the chain. This approach provides a unified human-readable identifier while still using distinct low-level addresses for the unique accounts on each chain. This is a better alternative to using counterfactual deployments, as it reduces complexity for users and dApps while still maintaining the necessary chain-specific addresses.

Additionally, this approach could be used even outside the EVM ecosystem. Wallets that accept ENS names as an address input can then automatically resolve the correct low-level address without any additional complexity for the sender. This solution ensures that account holders do not lose funds by sharing the wrong wallet address, and cross-chain bridges do not mislead users into bridging assets to a chain where they lack access. The use of ENS thus provides users with the convenience and ease of use they expect from conventional EOA wallets while still leveraging the benefits of account abstraction wallets.

In future, we could also enable every banana wallet to have an ENS by default making the UX even better.

How will it work?

At present, there exists no mechanism to register and trade ENS domains on Layer 2 networks, which mandates users to bear the cost of L1 gas fees to engage with ENS. Despite ENS's efforts to integrate L2s using off-chain data lookups and wildcard domain names, this approach fails to cater to the registration of top-level domains. This poses a significant challenge, given that top-level domains represent the most prevalent use-case of ENS and the primary source of ENS's revenue.

We will design a registrar contract with the user bidding on ENS on L2 and a relayer fulfills the bid by purchasing it on L1 and bridging the domain to all the supported L2s. The user will get their ENS attached to their Smart contract wallet across all the supported chains. The process of registering ENS domains on L2s involves a user submitting a request to purchase a domain with a commitment hash and deposited funds for fee payment. A relayer creates a commitment on L1 using the L1 BananaEnsSupport smart contract and sends it to L2 using the BananaEnsSupport bridge smart contract. The L2 BananaEnsSupport contract processes the first payment from the user to the relayer and the user shares a signature with the relayer containing the domain name. The relayer then sends a second L1 transaction to register the domain names and transfer ownership to the BananaEnsSupport smart contract. Finally, the BananaEnsSupport smart contract sends the registration contracts across the BananaEnsSupport bridge to L2, which confirms the domain registrations, processes the second payment, and mints an L2 NFT representing the ENS domain.