Problems We Are Solving

We are shaping the future of Web3

The Single Point of Failure

Most wallet services require users to back up the private key at the initial wallet creation stage, such as a mnemonic. It means users have to manage private keys that can obtain control over all assets of the wallet by themselves all the time. If only the private key is available, all assets can easily be stolen, which is structurally very dangerous and cannot be completely solved with the current wallet design structure.
To address this issue, the Multi Party Computation (MPC) method was introduced. This method splits the private key into several pieces and uses them. However, it also shares a single point of failure with EOA wallets. If hackers succeed in obtaining multiple key shares exceeding the threshold at any point in history, the wallet could be compromised.

Synchronization & Recovery

If a user wants to use an existing wallet account on a different device, the wallet must be restored through a private key. This means that there is no structural difference between enabling the same wallet on multiple devices and recovering a lost account. It all narrows down to a single point of failure: the private key. Regrettably, this process can enhance the risk of critical security accidents caused by private keys. Such an approach can be too risky and careless.

Too many Gas Tokens

As the blockchain mainnet becomes more diverse, it has become essential to use multiple chains to quickly capture opportunities and use various protocols smoothly. However, this has resulted in the inconvenience of having to put all the native tokens corresponding to each chain into the wallet to pay transaction and gas fees. To use a new chain that doesn't have gas tokens, you need to find an exchange that listed them, buy them, and transfer them to your wallet. If multiple wallets are used, this process must be repeated as many times as there are chains.

Time & Money Wasted

When using DeFi services such as yield farms, there are many simple transactions that need to be repeated periodically. Currently, these transactions must be processed manually, one by one. This inefficiency leads to wasted time and money for users. Waiting for confirmation of previous transactions before proceeding to the next step is necessary, but it also incurs additional gas fees for each transaction. These fees could be significantly reduced if transactions were batched into one.

Multichain Synchronization

Multichain syncing has always posed a challenge for smart contract wallets. For those familiar with EOA wallets such as Metamask, it's known that chains can be simply switched and the wallet used after topping up gas tokens. However, contract wallets operate differently.
Some account abstraction wallets don't even support a single-controller-multi-wallet setup within one chain. This situation means users must send transactions to register controller keys individually for each wallet. Furthermore, when crossing over to another chain, these users have to register their keys again, as the smart contract perceives it as a completely different wallet. The best solution available for these wallets is to set a default controller address upon deployment. Although this strategy may alleviate the initial burden, the same problem persists when adding different devices and wallets later on.
This issue discourages adoption of contract wallets, especially as there are now dozens of mainnets, and many users utilize multichain setups on their devices. The goal was to solve this problem in a non-custodial manner, avoiding the need to send private keys as was done by traditional EOA custodial wallets. Therefore, novel keychain technology was introduced, making multichain syncing frictionless for account abstraction wallets.