# Fetcch Wallet ID Protocol

## What is FetcchX Wallet ID Protocol?

FetcchX Wallet ID Protocol will enable wallets and dApps to start issuing **Cross Chain, Composable Wallet IDs** to their users, these IDs will be able to connect to any number of addresses from any chain, ultimately providing a single identity for a user across blockchain, basically working as an **Identity Aggregator.**


Wallet IDs can pay each other irrespective of which chains they are based out of and also can connect to any dApp and start executing transactions without worrying about chain, effectively laying up the ground work for a chainless world.

## What is the need for chainless world?

There are more 20+ chains currently in the market, with more and more liquidity fragmenting everyday.

Today, if a user needs to access a dApp on another chain, they need to go through a tedious process of creating new wallet, bridging tokens and probably using a dex.

As it is more work for user, it leads to **Bad UX** and blockchains will not be able to reach that scale which we are dreaming of.

To tackle all of this, we need to go chainless, wherein end user will have no idea about which chain the dApp is based out of, either they have gas or not etc, this should all be done in the background, but without an **identity aggregator**, we cannot do all of this efficiently.

## What can we do with Fetcch Wallet ID?

### ID
Wallets can issue their own IDs to their users, which will be connected to all IDs present in the protocol, So 2 users will not have to worry about which wallet they are using or even which chain/token they are dealing in.

Wallet ID abstracts away most of the difficulties of blockchains and increases overall UX a lot.

Wallet IDs can be independently verified on respective data sources using stored signatures and addresses.

dApps can also verify if an address exists in a Wallet ID directly on chain, just call our contract's function with an address and a ID, response will be either true or false, this will help dApps go truly address-less and embrace ID.

### Auth

Wallet ID will help wallets to connect with dApp without scanning QR Code, just type your ID and receive a connection request on Wallet OR use our whitelabel extension and connect all of your IDs to that extension, which can be used like any wallet extension.

Wallet ID helps dApps to manage user identities more efficiently, think if your wallet is hacked, then you can't access all the dApps you want and also you will not be able to port that same data to other wallet address, but if dApps use Wallet IDs to manage data, then even if your wallet is hacked, you can swap out your hacked wallet to a brand new one and use those website just how you were previously.

Wallet ID Auth will let you get a deeper insight into who your users are and what are they doing on your dApp, all of the data will be anonymized and only non-crucial part will be visible to dApps

### Pay

Wallet ID will help faciliate cross chain transactions using set of bridges and DEXs

Wallet ID will help faciliate cross chain smart contract execution even if dApp hasn't enabled that natively, we will bridge tokens to user's that chain on which the dApp is based out of chain address and execute transaction.

A Wallet ID can send **Payment Request** to another Wallet Id which can be paid asynchronosly

A dApp can also send **Payment Request** to a Wallet Id which can be paid asynchronosly, it can be sent **On Chain** using our contracts or **Off Chain** using our APIs

### Provider

Provider can choose which data source they want to use to store their users data, data source can be a blockchain like Polygon or Solana or it can be decentralized storage solution like Arweave/IPFS or even their own servers!

### Developers

We will have a developer plugin ecosystem, which dApps and wallets can directly integrate and with minimal steps integrate anything.
Let's say there will an plugin for on/off ramping, install the plugin and add it to fetcch config and call functions directly from already initialized `Fetcch` class.

## How are we implementing this?

We have 4 components that enables us to build **Cross Chain, Composable Wallet ID Protocol** in a decentralized, secure way.

Let’s break down each component and understand them.

### Decentralized Storage Solutions

We store Wallet IDs data on decentralized storage solutions like IPFS.

IPFS or Interplanetary File System is a decentralized storage solution wherein data is owned by no one other than uploader and this data is immutable, so once its on IPFS, no one can change it.

This helps us build **FetcchX Wallet ID Protocol** in a decentralized way, which helps users to own their ID truly in a cross chain manner.

### Indexer

Decentralized Storage Solutions are secure and decentralized but their querying time is very slow compared to its centralized counterparts.

We are going to support various data sources like blockchains, decentralized storage solutions etc

To tackle this, we are building an Indexer, which will index all of the IDs and then from here, we will able to query data in millisecond timing, increasing UX.

Indexer will be stateless, in a sense that data is stored on IPFS and anybody could cross verify Indexer’s data with IPFS and determine if its valid or not. Anybody could rebuild Indexer’s data on a new server, a whole new database because ultimately data is stored on IPFS and its public.

Also, Wallet ID will have an version history, as owner can update their Wallet IDs addresses and chains anytime they want, Indexer helps us to keep track of that version history even if the underlying CID is always changing.

### Bridges

Bridges are an important part of going chainless.

2 Wallet IDs can send each other tokens without worrying about Chain, we are going to use bridges and DEXs in the background to faciliate cross chain transactions and from users POV it will seem as if its same chain transaction.

We will also enable cross chain smart contract execution through ID, any ID can connect to a dApp and be able to execute smart contract tx using a combination of Token and possibly Data bridge (based on params)

### Authentication

Wallet ID can authenticate with various dApps and to enable this, we are going to have websocket connection opened up with wallets, with which a dApp can communicate directly with wallet, with increased security and UX

---

We also have a GraphQL API to interact with **Indexer** and through the same API we provide a way to upload data to **IPFS** and pay for Filecoin on behalf of wallets

## Rules

### Provider

Wallet or dApp that can issue a Wallet ID is called as **Provider**

Provider will have their own delimiter and name

for ex

- If Metamask becomes a provider they can reserve `metamask` as their name and `@` as their delimiter
- Then they can issue Wallet IDs like `satyam@metamask`

There are a **set of rules** for choosing a name and delimiter for provider

- Name can only contain characters `[A-Z][a-z]`
- Name will not be case sensitive, so `Metamask` and `metaMask` will be the same
- Delimiter should be chosen from a set of characters
- `@`
- `-`
- `.`

### Wallet ID

Wallet IDs need to be maintain a certain rules

- They should be greater than 4 characters
- They can be alphanumeric
- They are case insensitive
- They should be unique to provider
- We can `satyam@metamask` and some other guy can have `satyam@fetcch`
- Both IDs will be treated as different
- They should set a single address as default address and a chain as default chain
- They can have multiple addresses and chains in `others` section
- They should follow this schema

{
  "id": "satyam@fetcch",
  "provider": "fetcch",
  "identifier": "satyam",
  "default": {
    "address": "0x00",
    "chain": {
            "name": "Polygon Mainnet",
            "id": 2,
            "chainId": 137				
        }
  },
  "others": [
    {
      "address": "0x0000",
      "chain": [
                {
                    "name": "Ethereum Mainnet",
                    "id": 1,
                    "chainId": 1
                }, 
                {
                    "name": "Polygon Mainnet",
                    "id": 1,
                    "chainId": 137				
                }
            ]
    }
  ]
}

- Signed Messages
- Only `default.address` can sign messages on behalf of Wallet ID when creating or updating Wallet ID
- There are 2 cases where signed messages are needed
- Creating ID
- Generate a message using this [GraphQL Endpoint](https://www.notion.so/GraphQL-API-de6972a735194a12aa17bfccb6b3fee7)
- Sign it using `default.address`
- Store it in Wallet ID, at `currentSignature`
- Keep `previousSignature` null in this case
- This helps us be sure that `default.address` is owned by the creator of ID
- Updating ID
- Generate a message using this [GraphQL Endpoint](https://www.notion.so/GraphQL-API-de6972a735194a12aa17bfccb6b3fee7)
- If updating `default.address`, user needs to sign this message twice
- First sign this message using updated `default.address`
- Second sign this message using previous `default.address`
- Store first signature in `currentSignature`
- Store second signature in `previousSignature`
- This helps us to verify if data is updated by the owner of ID and not by others
- We need this type of verification, because anybody can upload data to a data source and share unique identifier with us, this will help malicious users get access to a ID and possibly divert all payments to their address