Fix mistakes.

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.
 
 <!-- The above life cycle can support various practical implementations of account recovery. For example, if your wallet contract requires confirmations from multiple guardians and sets a timelock if only less than three guardians confirm the recovery, you can implement such functions as follows:
 1. (Setting a guardian) Your wallet contract stores a list of multiple guardians' Ethereum addresses. When the wallet approves a new guardian’s email, it deploys a new