Skip to main content

Multichain Account Abstraction Using Fetcch

· 8 min read

Conventional payment service providers (PSPs) and networks facilitating web3 payments (5).png

What is account abstraction?#

Before understanding account abstraction. first let’s understand what are accounts on Ethereum.

There are two types of accounts on Ethereum: EOAs (externally owned accounts) and Contract accounts (CAs or smart contracts). EOAs are regular accounts controlled by private keys. Having the key grants access to Ethereum actions, while losing it means no access. All actions, including transactions and interacting with smart contracts, need EOA initiation. This limits user-friendliness for tasks like batch transactions and needing enough ETH for gas. Smart contracts are code-based accounts, not controlled by users, executing when triggered by EOAs or other smart contracts. Flexibility exists, but EOAs must initiate all actions.

Untitled

Conventional payment service providers (PSPs) and networks facilitating web3 payments (4).png

'Account abstraction' addresses these problems by turning user accounts (EOAs) into smart contracts, allowing smart contracts to initiate transactions. This enables smart contract wallets with enhanced UX and security features. Seed phrases become unnecessary, as flexible security rules can include biometric verification or social recovery. Fees can be paid in any token, even subsidizing user gas fees for certain dApps. Complex actions can be batched, speeding up transactions and maintaining uninterrupted user experience. Smart contract wallets offer various possibilities: preset session durations, automatic payments, and more, fostering innovation in dApps and user experiences.

Why go multichain?#

Multichain adoption emerges as an essential paradigm to address the evolving needs and challenges of users within the web3 ecosystem. In the context of account abstraction and smart contract wallets, embracing a multichain approach becomes increasingly significant. One key reason is the fragmentation of liquidity across different chains. As the blockchain ecosystem becomes increasingly multi-chain, the liquidity also becomes fragmented. The influx of capital into the ecosystem has been abundant, but it is distributed among the different blockchain ecosystems and their respective dApps. From a user’s perspective, the ecosystems lack fluidity as different blockchains exist in isolation. This fragmentation becomes evident when users find themselves holding liquidity across multiple chains. This market structure underlines the pressing need for interoperability between the various blockchains in existence.

5.png

By extending account abstraction to multiple chains, users can seamlessly manage their assets and execute transactions across various blockchain networks. Consequently, this harmonization of liquidity not only enhances user convenience but also streamlines the process of accessing decentralized finance (DeFi) applications.

Moreover, the availability of diverse dApps on different chains adds to the allure of multichain adoption. As the blockchain landscape expands, certain dApps might find their natural habitat on specific chains due to technical nuances or thematic alignment. Enabling account abstraction on multiple chains empowers users to effortlessly navigate these ecosystems and engage with a plethora of decentralized applications catering to various needs and preferences.

Furthermore, users' preference for a multichain environment stems from a desire for flexibility and optimization. Different chains might offer distinct attributes, such as transaction speed, cost efficiency, or unique features, which users can leverage based on their requirements. Embracing account abstraction across multiple chains empowers users with the ability to customize their experiences by choosing the most suitable chain for a particular use case. This aligns with the overarching goal of enhancing user agency within the blockchain realm. In conclusion, adopting a multichain approach within the realm of account abstraction not only unifies liquidity and dApps availability but also caters to users' preferences and bolsters the overall resilience of the web3 ecosystem.

How would multichain smart contract wallet (SCW) look like?#

A multichain smart contract wallet (SCW) functions as a flexible solution for storing and managing assets across different blockchains from a single interface. This would make it easier for users to participate in DeFi applications on different blockchains, and it would also make it easier for users to transfer assets between different blockchains.

But can the same blockchain address be used on different chains for smart contract wallets?

Its possible because the addresses of smart contracts are predominantly established by the contract's bytecode and the deployer's address in contrast to conventional wallets that are controlled through private keys.

There are two ways to implement a multichain SCW:

  1. Same address on every blockchain. This would be possible using Ethereum Improvement Proposal (EIP) 1014, specifically the CREATE2 opcode. CREATE2 allows for the deployment of smart contract instances with the same address on multiple Ethereum Virtual Machine (EVM) blockchains. This approach tantalizingly merges user expectations with technical feasibility, offering the convenience of a consistent address regardless of the underlying chain.
// contracts/Vault.solpragma solidity ^0.5.0;
import "@openzeppelin/upgrades/contracts/Initializable.sol";
contract Vault is Initializable {    address payable owner;
    function initialize(address payable _owner) initializer public {        owner = _owner;    }
    function withdraw() public {        require(owner == msg.sender);        owner.transfer(address(this).balance);    }}

However, there are some potential drawbacks to this approach, such as:

  • State drift. Since every blockchain is siloed and has its own state, it is possible that the state of the SCW could drift between different chains. This could lead to problems if the SCW is used to track assets or data.
  • Incompleteness. Not every EVM blockchain supports the CREATE2 opcode. This means that a multichain SCW that uses CREATE2 would not be able to be deployed on all EVM blockchains.
  1. Different addresses on every blockchain. 

    Creating unique addresses for each blockchain could be a straightforward way to establish a multichain Smart Contract Wallet (SCW). This would permit users to deploy the SCW on any preferred blockchain, resulting in distinct addresses for each instance. While this method avoids issues like state inconsistency and incompleteness, it might complicate SCW administration, as users would need to track multiple addresses across different blockchains.

    Nevertheless, this approach comes with its own challenges. Firstly, there's a risk of funds being lost if users share their account abstraction wallet address without specifying the intended blockchain for receiving assets. This scenario could occur if assets are sent to an unsupported chain, making the funds inaccessible. Secondly, assuming that addresses are the same on both sides of cross-chain bridges could lead users to unintentionally bridge assets to a blockchain where they lack access. Lastly, managing numerous addresses across various chains adds complexity, requiring users to handle multiple addresses associated with distinct blockchains. This extra complexity might discourage users from fully utilizing the benefits of a multichain SCW.

An optimal resolution would be to integrate unique low-level account addresses with a singular overarching identifier. Here is where Fetcch comes into the picture.

Fetcch comes to the rescue#

Chain-specific addresses remain critical to remove any ambiguity on the side of wallets and dApps but they can be abstracted away from the user using Fetcch's Universal Transactional Identities (UTIs) which allow wallets to convert wallet usernames into interoperable transactional identities.

This means that users who use multiple SCWs across different networks, such as Polygon, Ethereum, and Gnosis Chain, can consolidate all of these addresses under a single user ID, such as "user@metamask."

With UTIs, users no longer need to manage multiple wallet addresses. They can simply use their single UTI to send and receive payments across different chains. This makes it much easier for users to manage their assets and interact with dApps across multiple chains. Fetcch works on a multichain settlement structure, so wallets and dApps can specify on which blockchain(s) they want their user's data and it will be stored on that blockchain

Conventional payment service providers (PSPs) and networks facilitating web3 payments (5).png

Fetcch supports a wide range of blockchains, from EVM to Non-EVM, so a single id can have evm account abstraction addresses and also EOA addresses with that Solana, Aptos addresses too.

It also supports off-chain Ethereum Name Service (ENS) for convenient resolution, enhancing the overall user experience. This means that each UTI like user.fetcch.id can be resolved through ENS.

Fetcch also enables accounts to directly send payment requests across blockchains. This means that an SCW on Polygon can request an SCW or EOA on Ethereum to send them 10 MATIC on their own address. The SCW or EOA on Ethereum can then send any token to the SCW on Polygon, and the SCW on Polygon will receive their MATIC within some time. This makes it easy for users to send payments across different chains without having to worry about gas fees or liquidity. Payment request can help bootstrap a SCW on new chain by requesting tokens from the owner's account

Conclusion#

In summary, account abstraction in Ethereum enhances user interactions by converting externally owned accounts (EOAs) into more versatile smart contract wallets (SCWs). This evolution addresses transaction efficiency, security, and flexibility concerns.

In a multichain context, adopting account abstraction becomes pivotal due to liquidity fragmentation and the need for seamless interoperability. Utilizing the same address on every blockchain, made possible by mechanisms like EIP-1014, offers consistency but can encounter state and compatibility issues.

An alternative approach involves using distinct addresses on each blockchain, which simplifies management but could introduce complexities and potential user errors. However, by incorporating solutions like Fetcch's Universal Transactional Identities (UTIs), as demonstrated by Fetcch, the process of managing multichain smart contract wallets is streamlined.