# Hexlink: The Smart Account Layer for Web3

## Our vision

Hexlink aims to be the unified pluggable smart account layer for Web3, which enables seamless Web2 user experience for Web3 applications. We hope Hexlink account can be easily plugged into various Web3 applications so users can use Hexlink account just like using social accounts(google/twitter/facebook/github e.t.c.) in Web2 applications. The goal of Hexlink is to onboard next billion users to Web3 by improving the end-to-end user experience and simplify the developer experience.

### Existing Efforts: Wallet vs Auth

There are already a lot of on-going efforts to improve the user experience via AA. We categorize existing AA solutions as __Wallet__ and __Auth__.

Wallet is the most common way for users to interact with dApps. It holds the credentails(e.g. private key) for users to interact with dApps. Users normally login the wallet first and then connect with varies dApps with the wallet. The architecture is as following.

<img src="https://hackmd.io/_uploads/B1sMHpfD3.png" height="300"></br>

For dApps integrating with wallet, the user experience is very different from traditional Web2 applications. Users have to set up a wallet first before using dApps so the onboarding process is heavily relis on the design of the wallet. Unfortunately, most of the wallets are not good enough to onboard massive Web2 users in.

Auth solutions are designed to solve this problem. It provides Web2 level user experience by supporting email/social login and normally creates an embeded wallet for each user when signing up. By getting rid of the dependency of wallet, it reduces the user friction dramatically.

<img src="https://hackmd.io/_uploads/rk8Q9NQPh.png" height="300"></br>

Auth service normally relies on centralized services to for private key storage and signing. This increases the risk of provider lockout: If the auth service is down or the dApp is blocked by the auth service, users will not be able to login it anymore. The interoperability is also pretty bad since users cannot login dApp B with the account registered in dApp A.

### Comparison

| | Wallet | Auth |
| ---- | ----| ----|
| dApp Interaction | Connect Wallet | Embeded wallet with email/social login |
| Target Audiences | To Consumer | To Business |
| Unified account across multiple dApps | Yes | No |

## The Unified Smart Account Layer

Hexlink aims to unify Wallet and Auth by proposing a unified pluggable smart account layer. Hexlink Account provides better user experience for dApps by supporting email/phone/social login while maintains a unifed account layer across dApps. It is easy to be embeded into different dApps including Wallets.

<img src="https://hackmd.io/_uploads/B1sI9VXD3.png" height="300"></br>

In article [Demystifying Wallets: A Revolutionary dApp User Flow](https://medium.com/@hexlinkofficial/demystifying-wallets-a-revolutionary-dapp-user-flow-b72c3656f9dd), we break down the wallet into two parts: Account and Assets Managment. Wallet is just a dApp to manage assets owned by the account. After abstracing the account layer out, we see no difference between wallets and other dApps.

There are several advantages of Hexlink Account we'd like to emphasize.

### Easy Onboarding

Hexlink Accounts are derived from existing identities, such as email, phone number or ENS. In other words, Hexlink gives every email/phone number/ENS user a ready-to-use smart contract account. The mapping from existing identity to wallet address is on-chain so users can use their email addresses and phone numbers as on-chain username to receive cryptos.

### Modularized

Hexlink Account is fully modularized. In default the account is setup with very basic functionalities but users can customize their account by enable different plugins such as auth module and social recovery module.

### Auth Agnostic

Hexlink Account support varies auth options such as dAuth, ParticleNetwork and Web3Auth. We abstract different auth solutions as "Auth Provider" which user can config in its account with "Auth Module". Users can switch to different auth provider, or even enable multiple auth providers for multi-factor authentication, by configuring its auth modules. The auth module may contain the metadata explaining how the authentication workflow works. We proposed EIP-6662 to standardize the authentication metadata.

## Architecture

The overall achitecture is as following. To send a transaction, user will have to authenticate through the auth provider with the user operation to process. The auth provider information may be parsed from the auth module. After authenticated, auth provider will signing the user operation, which will be sent to bundler network. Users can also customize their accounts by enabling varies modules. During the transaction processing, the Hexlink Account contract may call other contracts(e.g. ERC20 token contracts) to finish the execution.

<img src="https://hackmd.io/_uploads/rkoqc7QPh.png" width="300"></br>

### Auth Provider

Auth Provider is the service or library to authenticate users and sign user operations. It may defines how the private key is preseved and exposes proper signing APIs for users to call. It could be as simple as an non-custodial wallet, or as complicated as an MPC service which does both email/social login and transaction signing. Hexlink abstract EOA based Wallet/Auth solutions as Auth Providers, including non-custodial wallets such as Metamask/TrustWallet, custodial wallets such as Fireblocks/MagicLink and MPC solutions such as Web3Auth and ParticleNetwork.

### The Default Auth Provider for Hexlink Account


Hexlink uses __DAuth__ as the default Auth Provider for accounts derived from email, phone number or social accounts. DAuth follows the TEE + ZKP tech stack and supports varies authentication methods including email/sms otp and oauth. We believe DAuth balances well between performance, cost and security. With DAuth, business entities can also self-host private nodes to serve its users to prevent the risk of provider lockout. You can learn more about DAuth [here](https://dauth.gitbook.io/dauth-docs/dauth-network/introduction).

For account derived from ENS, the ownership of the account is defined by ENS contract. Users have to use the wallet(e.g. Metamask) holding the owner key to signing the user operation.

### Challenges of EIP-4337

Per EIP-4337, the account cannot access external storage not associated with the contract during validation. However, for our use cases, we have to break the rule since we need to read the dAuth validator registry contrac, which contains all valid validators registered at the network, to check if the request is signed by a valid validator.


We are solving the problem in two different ways:

1. We are working closely with bundler services to investigate the option to whitelist dAuth validator contract.
2. We are exploring the option to let users pick up one or two dedicated nodes to serve them, and write these validators into the account contract as authentication metadata(EIP-6662). If the validator is not available, users can use social recovery to pick up a different validator set.

We face the same issue for ENS derived accounts and are following the same principle here to solve the problem. The EIP-4337 author Yoav proposed a [solution](https://hackmd.io/A7B6VpG7RaCnphITwsym6Q) which we are going to implement.

## Growth strategy

Check out our go to market strategy [here](https://www.notion.so/hexlink/PMF-and-Partnerships-737ef28bb02d40d494d93dd9302da80a).