Smart Accounts


Smart accounts unlock exciting new features for users and developers, supercharging Zilliqa 2.0 accounts with powerful functionality.

One of the key improvements coming to Zilliqa 2.0 is the introduction of on-chain smart accounts, improving security and the overall user experience.

Smart accounts use decentralised smart contracts to link basic blockchain accounts to powerful suites of features that can be extended or customised as required.

The introduction of smart accounts to Zilliqa 2.0 unlocks new experiences for end-users and developers, allowing them to use and deploy powerful built-in tools that improve account functionality.

Native Account Abstraction

Zilliqa 2.0 features two types of accounts - smart contracts and externally owned accounts (EOAs). Native account abstraction allows EOAs to act as smart accounts through the deployment of ERC-4337-compatible smart contracts that extend wallet functionality.

Smart accounts on Zilliqa 2.0 can benefit from a number of helpful features designed to improve the user experience or enable improved security.

When smart accounts are enabled on Zilliqa 2.0, they will mimic standard account behaviour by default, but they can easily be customised or extended with third-party implementations.

Enabling Powerful Features

Zilliqa 2.0’s account abstraction layer unlocks a range of features and functionalities, allowing users to leverage their accounts for various purposes beyond simple transactions.

By introducing native account abstraction, Zilliqa 2.0 enables features such as multi-factor authentication, shared accounts, or address whitelists to be deployed as direct extensions of user wallets. This can deliver significant improvements to account security and accessibility for users on Zilliqa 2.0.

Other useful features enabled by account abstraction include transaction authentication using social login credentials and the subsidisation of gas fees by dApps.

Smart accounts can also improve the user experience by reducing the potential for irreversible errors when signing transactions by imposing additional checks on address formats and smart contract operations.

This diagram demonstrates how social login credentials can be used to authenticate transactions using native account abstraction on Zilliqa 2.0. After successful login, the user obtains an ID token from the respective ID provider. The user presents the ID token to a set of MPC nodes, requesting them to cosign the user operation. The resulting threshold signature is submitted as part of the user operation to the user's smart account. On successful verification, the smart account executes the requested contract calls.

Backwards Compatibility

Smart Accounts are backwards-compatible with Zilliqa 1.0 accounts, ensuring continuity and accessibility for all users.

Once account abstraction is implemented on Zilliqa 2.0, existing EOAs can be seamlessly converted to smart accounts.

Smart accounts mimic standard account behaviour by default, ensuring that users with existing accounts are not disrupted by the migration to Zilliqa 2.0. Once imported, these EOAs can be extended with smart account functionality at the owner’s discretion.

Building Value for the Network

Zilliqa 2.0's account abstraction supports multiple tokens in addition to ZIL as a means of payment for transaction fees, driving sustainable value for the main network. 

As a product of its native account abstraction, the Zilliqa 2.0 network supports the automatic conversion of gas payments through paymasters. This allows users to pay transaction fees using ERC-20 tokens, with the required token swaps and ZIL gas payments abstracted to a secondary process.

Account abstraction allows apps built on x-shards and the mainnet to exclusively transact in ERC-20 tokens with no need for users to hold ZIL for gas fees, while continuing to accrue value for the underlying ZIL-powered infrastructure of the Zilliqa 2.0 network. 

This value is driven by the demand for native ZIL by paymasters facilitating the automatic conversion of ERC-20 tokens to process transactions on the underlying Zilliqa 2.0 mainnet and on x-shards using ZIL as their native token.

The diagram above shows how end-users can pay for gas fees using ERC-20 tokens through paymasters and native account abstraction. The user submits a user operation that refers to an ERC-20 token's paymaster. The paymaster contract obtains the price of the native token and the ERC-20 token from oracles and calculates the amount of ERC-20 tokens needed to cover the gas fees of the user operation. In exchange for paying the fees in native token, it withdraws the converted amount from the ERC-20 token balance of the user's smart account. To maintain a sufficient native token balance, the paymaster can swap abundant ERC-20 tokens for the native token on a DEX.