# MathChain SmartWallet Tech Design

A new crypto wallet for Web 3.0

#### Problem

Limitations of current Smart Wallets:

- Account creation costs are high, because it need to create the mainnet contract for each new user
- The recovery process still rely on centralized 3rd parties which may not exist years later
- Smart contract transaction has limitation in some scenarios
- Smart contract is difficult to upgrade

#### Goal

Non-custodial wallet with a unique on-chain recovery mechanism to bypass traditional recovery phrases process

#### Advantages

- Store and send crypto with simplicity and safety on chain
- No seed phrase. Easily recover without a paper backup
- Only you can access your assets
- Cross-chain assets supported
- Support staking
- Support governance discussion, notification and operation
- Support treasury discussion, notification and operation
- Support zero transaction fee tokens
- Set daily spending limit
- Support DID and KYC


#### Technical Design

The SmartChainWallet will leverage the combination of SecretStore and Recovery module to refine the wallet backup and find back process.

The overall process is the new user leverage SecretStore encrypt 3 secret questions' answer, and save the key in SecretStore.
When the user needs to recover the account, he needs to provide these 3 answers again, and the verifier will get the key from SecretStore to verify these answers, if they are the same, verifier will approve the recovery request.

##### Backup Process

1. User create new wallet address
2. User create recovery (threshold = 2, delay_period = 30 days) and the verify address 1 2 3. These 3 verify addresses are elected by MathChain council
3. User pick 3 secret questions from the open source secret questions list, and provide the answers
4. User get 3 encrypted_key & 3 document_key from SecretStore
5. User set the permission of 3 document_key to verify address 1 2 3
6. User encrypt 3 answers using 3 encrypted_key
7. User save the 3 encrypted answers together with question_id/document_key/verify_address to EncryptedAnswerStorage

##### Recovery Process

User
1. User initiate recovery request
2. User get the question_id from EncryptedAnswerStorage and provide 3 answers
3. User get 3 encrypted_key & 3 document_key from SecretStore
4. User set the permission of 3 document_key to verify address 1 2 3
5. User encrypt 3 answers using 3 encrypted_key
6. User save the 3 encrypted answers together with recovery_address/document_key/verify_address to VerifyAnswerStorage

Verifier
1. Verifier get related data from EncryptedAnswerStorage & VerifyAnswerStorage
2. Verifier get EncryptedAnswerKey from SecretStore
3. Verifier get VerifyAnswerKey from SecretStore
4. Verifier decrypt EncryptedAnswerStorage encrypted_answer_data with EncryptedAnswerKey
5. Verifier decrypt VerifyAnswerStorage encrypted_answer_data with VerifyAnswerKey
6. If the decrypted data is equal, verifier issue vouchRecovery
7. If 2 of 3 verifiers have issued vouchRecovery, the recovery delay period starts

30 days later, the user get the control of the request recovery address


#### Safety Considerations

- Verify address replacement: the proxy pallet can be used to the verify addresses, so that if there are replacement of verifier, just need to update the proxy.
- Front running: if someone is monitor the transaction pool and submit the exact same verify answers request, it is possible to do this even he do not know the answer. And if it is fast enough, these 2 requests can be in the same block so that the verifier cannot tell who is the real request address. Compare the owner of document_key in SecretStore should be able to solve this issue.
- Forget the answer: it is possible that after a period, user forget the answers. To improve this, the threshold of approvals is set to 2-of-3. User only need to answer 2 questions correctly. Also more verification methods can be added through the same process such as face recognition, social media verification, etc.

#### More Scenarios

Combine with IPFS storage, the process is able to support face recognition verification through the encrypted eigenvalue.
Combine with Off-chain worker, the process is able to support social media verification.
Send assets to any social media account before blockchain address creation.
Personal data storage and sharing.
Cross-chain recovery enablement.