Feat/rename

README.md

@@ -1,7 +1,7 @@
-# Ether Email-Auth SDK
+# Email Tx-Builder SDK
 ## Overview
 One issue with existing applications on Ethereum is that all users who execute transactions on-chain must install Ethereum-specific tools such as wallets and manage their own private keys.
-Our ether email-auth SDK solves this issue: it allows users to execute any transaction on-chain simply by sending an email.
+Our email tx-builder SDK solves this issue: it allows users to execute any transaction on-chain simply by sending an email.
 
 Using the SDK, a developer can build a smart contract with the following features without new ZKP circuits.
 1. (Authorization) The contract can authorize any message in the email body that the user sends with a DKIM signature generated by an email provider, e.g., Gmail. 
@@ -13,7 +13,7 @@ In social recovery, the account owner must appoint trusted persons as guardians
 However, not all such persons are necessarily Ethereum users.
 Our solution mitigates this constraint by allowing guardians to complete the recovery process simply by sending an email.
 In other words, any trusted persons can work as guardians as long as they can send emails.
-Using the ether email-auth SDK, we construct a library and tools for any smart account providers to integrate our email-based account recovery just by implementing a few Solidity functions and a frontend!
+Using the email tx-builder SDK, we construct a library and tools for any smart account providers to integrate our email-based account recovery just by implementing a few Solidity functions and a frontend!
 
 ## Architecture
 In addition to a user and a smart contract employing our SDK, there is a permissionless server called Relayer.

docs/getting-started.md

@@ -1,6 +1,6 @@
 # Getting Started 
 
-The following steps are for developers to implement account recovery using ether-email-auth.
+The following steps are for developers to implement account recovery using email-tx-builder.
 
 ## Prerequisites
 
@@ -13,7 +13,7 @@ curl -L https://foundry.paradigm.xyz | bash
 ## Clone the repository
 
 ```sh
-git clone https://github.com/zkemail/ether-email-auth.git
+git clone https://github.com/zkemail/email-tx-builder.git
 ```
 
 ## Set up

package.json

@@ -1,5 +1,5 @@
 {
-  "name": "@zk-email/ether-email-auth",
+  "name": "@zk-email/email-tx-builder",
   "private": true,
   "version": "1.0.0",
   "description": "Smart contracts to auth messages via emails",

packages/circuits/package.json

@@ -1,5 +1,5 @@
 {
-  "name": "@zk-email/ether-email-auth-circom",
+  "name": "@zk-email/email-tx-builder-circom",
   "license": "MIT",
   "version": "1.0.3",
   "scripts": {

packages/contracts/.zksolc-libraries-cache/missing_library_dependencies.json

@@ -6,6 +6,11 @@
       "src/libraries/DecimalUtils.sol:DecimalUtils"
     ]
   },
+  {
+    "contract_name": "StringUtils",
+    "contract_path": "src/libraries/StringUtils.sol",
+    "missing_libraries": []
+  },
   {
     "contract_name": "DecimalUtils",
     "contract_path": "src/libraries/DecimalUtils.sol",

packages/contracts/README.md

@@ -55,10 +55,10 @@ It is an interface of the DKIM registry contract that traces public keys registe
 It is defined in [the zk-email library](https://github.com/zkemail/zk-email-verify/blob/main/packages/contracts/interfaces/IDKIMRegistry.sol).
 It requires a function `isDKIMPublicKeyHashValid(string domainName, bytes32 publicKeyHash) view returns (bool)`: it returns true if the given hash of the public key `publicKeyHash` is registered for the given email-domain name `domainName`.
 
-One of its implementations is [`ECDSAOwnedDKIMRegistry`](https://github.com/zkemail/ether-email-auth/blob/main/packages/contracts/src/utils/ECDSAOwnedDKIMRegistry.sol).
+One of its implementations is [`ECDSAOwnedDKIMRegistry`](https://github.com/zkemail/email-tx-builder/blob/main/packages/contracts/src/utils/ECDSAOwnedDKIMRegistry.sol).
 It stores the Ethereum address `signer` who can update the registry.
 
-We also provide another implementation called [`UserOverrideableDKIMRegistry`](https://github.com/zkemail/ether-email-auth/blob/main/packages/contracts/node_modules/@zk-email/contracts/UserOverrideableDKIMRegistry.sol). 
+We also provide another implementation called [`UserOverrideableDKIMRegistry`](https://github.com/zkemail/email-tx-builder/blob/main/packages/contracts/node_modules/@zk-email/contracts/UserOverrideableDKIMRegistry.sol). 
 
 Key features of `UserOverrideableDKIMRegistry` include:
 1. User-specific public key setting
@@ -69,8 +69,8 @@ Key features of `UserOverrideableDKIMRegistry` include:
 This implementation provides a balance between centralized management and user autonomy in the DKIM registry system.
 
 ### `Verifier` Contract
-It has the responsibility to verify a ZK proof for the [`email_auth_with_body_parsing_with_qp_encoding.circom` circuit](https://github.com/zkemail/ether-email-auth/blob/main/packages/circuits/src/email_auth_with_body_parsing_with_qp_encoding.circom).
-It is implemented in [`utils/Verifier.sol`](https://github.com/zkemail/ether-email-auth/blob/main/packages/contracts/src/utils/Verifier.sol).
+It has the responsibility to verify a ZK proof for the [`email_auth_with_body_parsing_with_qp_encoding.circom` circuit](https://github.com/zkemail/email-tx-builder/blob/main/packages/circuits/src/email_auth_with_body_parsing_with_qp_encoding.circom).
+It is implemented in [`utils/Verifier.sol`](https://github.com/zkemail/email-tx-builder/blob/main/packages/contracts/src/utils/Verifier.sol).
 
 It defines a structure `EmailProof` consisting of the ZK proof and data of the instances necessary for proof verification as follows:
 ```
@@ -86,7 +86,7 @@ struct EmailProof {
 }
 ```
 
-Using that, it provides a function `function verifyEmailProof(EmailProof memory proof) public view returns (bool)`: it takes as input the `EmailProof proof` and returns true if the proof is valid. Notably, it internally calls [`Groth16Verifier.sol`](https://github.com/zkemail/ether-email-auth/blob/main/packages/contracts/src/utils/Groth16Verifier.sol) generated by snarkjs from the verifying key of the [`email_auth_with_body_parsing_with_qp_encoding.circom` circuit](https://github.com/zkemail/ether-email-auth/blob/main/packages/circuits/src/email_auth_with_body_parsing_with_qp_encoding.circom).
+Using that, it provides a function `function verifyEmailProof(EmailProof memory proof) public view returns (bool)`: it takes as input the `EmailProof proof` and returns true if the proof is valid. Notably, it internally calls [`Groth16Verifier.sol`](https://github.com/zkemail/email-tx-builder/blob/main/packages/contracts/src/utils/Groth16Verifier.sol) generated by snarkjs from the verifying key of the [`email_auth_with_body_parsing_with_qp_encoding.circom` circuit](https://github.com/zkemail/email-tx-builder/blob/main/packages/circuits/src/email_auth_with_body_parsing_with_qp_encoding.circom).
 
 ### `EmailAuth` Contract
 It is a contract deployed for each email user to verify an email-auth message from that user. The structure of the email-auth message is defined as follows:

packages/contracts/package.json

@@ -1,5 +1,5 @@
 {
-  "name": "@zk-email/ether-email-auth-contracts",
+  "name": "@zk-email/email-tx-builder-contracts",
   "version": "1.0.3",
   "license": "MIT",
   "scripts": {

packages/contracts/test/bin/accept.sh

@@ -6,7 +6,7 @@ ACCOUNT_CODE=$2
 SCRIPT_DIR=$(cd $(dirname $0); pwd)
 WORKSPACE_DIR="${SCRIPT_DIR}/../../"
 INPUT_FILE="${SCRIPT_DIR}/../build_integration/accept_input.json"
-yarn workspace @zk-email/ether-email-auth-circom gen-input \
+yarn workspace @zk-email/email-tx-builder-circom gen-input \
     --email-file $EMAIL_FILE_PATH \
     --account-code $ACCOUNT_CODE \
     --input-file $INPUT_FILE \

packages/contracts/test/bin/recovery.sh

@@ -6,7 +6,7 @@ ACCOUNT_CODE=$2
 SCRIPT_DIR=$(cd $(dirname $0); pwd)
 WORKSPACE_DIR="${SCRIPT_DIR}/../../"
 INPUT_FILE="${SCRIPT_DIR}/../build_integration/recovery_input.json"
-yarn workspace @zk-email/ether-email-auth-circom gen-input \
+yarn workspace @zk-email/email-tx-builder-circom gen-input \
     --email-file $EMAIL_FILE_PATH \
     --account-code $ACCOUNT_CODE \
     --input-file $INPUT_FILE \

packages/prover/Dockerfile

@@ -37,8 +37,8 @@ RUN n 22
 RUN npm install -g yarn snarkjs
 
 
-RUN git clone https://github.com/zkemail/ether-email-auth.git
-WORKDIR /ether-email-auth/packages/prover
+RUN git clone https://github.com/zkemail/email-tx-builder.git
+WORKDIR /email-tx-builder/packages/prover
 RUN pip install -r requirements.txt
 RUN cp ./circom_proofgen.sh /root
 # RUN cp ./email_auth_with_body_parsing_with_qp_encoding /root

packages/relayer/README.md

@@ -3,9 +3,9 @@ This is a Relayer server implementation in Rust for email-based account recovery
 ## How to Run the Relayer
 You can run the relayer either on your local environments or cloud instances (we are using GCP).
 ### Local
-1. Clone the repo, https://github.com/zkemail/ether-email-auth.
+1. Clone the repo, https://github.com/zkemail/email-tx-builder.
 2. Install dependencies.
-    1. `cd ether-email-auth` and run `yarn`.
+    1. `cd email-tx-builder` and run `yarn`.
 3. If you have not deployed common contracts, build contract artifacts and deploy required contracts.
     1. `cd packages/contracts` and run `forge build`.
     2. Set the env file in `packages/contracts/.env`, an example env file is as follows,