From a379e7e77b9e0d5236f39e52e563c8b7c49a4030 Mon Sep 17 00:00:00 2001 From: SoraSuegami Date: Tue, 23 Apr 2024 17:01:25 +0900 Subject: [PATCH] Fix mistakes. --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index a6919c3c..e0e0a012 100644 --- a/README.md +++ b/README.md @@ -135,13 +135,13 @@ Notably, our SDK **does not** specify concrete wallet specifications and the log Our SDK cannot ensure security and privacy in the entire process without your careful implementation. You can integrate the email-based account recovery into your wallet in the following steps. -1. (Contracts 1/) First, you import the `EmailAccountRecovery` abstract contract in `EmailAccountRecovery.sol` and have your wallet contract inherit it. Your Solidity compiler will require you to implement five functions: `acceptanceSubjectTemplates`, `recoverySubjectTemplates`, `acceptGuardian`, `processRecovery`, and `completeRecovery`. -2. (Contracts 2/) You define expected subject templates for two types of emails sent from guardians, one for accepting the role of the guardian, and the other for confirming the account recovery. You can implement the former and latter subject templates in the `acceptanceSubjectTemplates` and `recoverySubjectTemplates` functions, respectively. This is an example of the subject templates: +1. (Contracts 1/5) First, you import the `EmailAccountRecovery` abstract contract in `EmailAccountRecovery.sol` and have your wallet contract inherit it. Your Solidity compiler will require you to implement five functions: `acceptanceSubjectTemplates`, `recoverySubjectTemplates`, `acceptGuardian`, `processRecovery`, and `completeRecovery`. +2. (Contracts 2/5) You define expected subject templates for two types of emails sent from guardians, one for accepting the role of the guardian, and the other for confirming the account recovery. You can implement the former and latter subject templates in the `acceptanceSubjectTemplates` and `recoverySubjectTemplates` functions, respectively. This is an example of the subject templates: - Template in `acceptanceSubjectTemplates`: `"Accept guardian request for {ethAddr}"`, where the value of `"{ethAddr}"` represents the wallet address. - Template in `recoverySubjectTemplates`: `"Set the new signer of {ethAddr} to {ethAddr}"`, where the values of the first and second `"{ethAddr}"`, respectively, represent the wallet address and the new owner address. -3. (Contracts 3/) Before implementing the remaining functions in `EmailAccountRecovery`, you implement a requesting function for the wallet owner to request a guardian, which is expected to be called by the wallet owner directly. Our SDK **does not** specify any interface or implementation of this function. For example, it can simply take as input a new guardian's Ethereum address, which will be the contract address of the guardian's email-auth contract to be deployed later, and store the given address as a guardian candidate. If you want to set a timelock for each guardian, the requesting function can additionally receive the timelock length from the wallet owner. -4. (Contracts 4/) You implement the `acceptGuardian` and `processRecovery` functions. These two functions are, respectively, called by your wallet contract itself after verifying the email-auth messages for accepting a guardian and processing a recovery. Each of them takes as input the contract address of the guardian's email-auth contract, an index of the chosen subject template, the values for the variable parts of the message in the Subject, and the email nullifier. You can assume these arguments are already verified. In the `acceptGuardian` function, for example, the wallet contract stores the given guardian's address as the confirmed guardian. In the `processRecovery` function, for instance, it stores the given new owner address or sets a timelock. -5. (Contracts 5/) You finally implement the `completeRecovery` function. It should rotate the owner address in the wallet contract if some required conditions hold. Notably, it does not take any arguments. Therefore, this function should only depend on the storage data. +3. (Contracts 3/5) Before implementing the remaining functions in `EmailAccountRecovery`, you implement a requesting function for the wallet owner to request a guardian, which is expected to be called by the wallet owner directly. Our SDK **does not** specify any interface or implementation of this function. For example, it can simply take as input a new guardian's Ethereum address, which will be the contract address of the guardian's email-auth contract to be deployed later, and store the given address as a guardian candidate. If you want to set a timelock for each guardian, the requesting function can additionally receive the timelock length from the wallet owner. +4. (Contracts 4/5) You implement the `acceptGuardian` and `processRecovery` functions. These two functions are, respectively, called by your wallet contract itself after verifying the email-auth messages for accepting a guardian and processing a recovery. Each of them takes as input the contract address of the guardian's email-auth contract, an index of the chosen subject template, the values for the variable parts of the message in the Subject, and the email nullifier. You can assume these arguments are already verified. In the `acceptGuardian` function, for example, the wallet contract stores the given guardian's address as the confirmed guardian. In the `processRecovery` function, for instance, it stores the given new owner address or sets a timelock. +5. (Contracts 5/5) You finally implement the `completeRecovery` function. It should rotate the owner address in the wallet contract if some required conditions hold. Notably, it does not take any arguments. Therefore, this function should only depend on the storage data.