chore: fix some typos in comment

docs/src/zk_email_wallet.md

@@ -11,7 +11,7 @@ The ZK-Email Wallet currently supports the following functions:
 - **Extensions**: The wallet now allows users to seamlessly integrate with any DeFi protocol, such as Uniswap, directly from their email wallet.
 
 Currently, the wallet uniquely provides the following features:
-- **Send money to people without accounts**: Because transfers are authorized by an email address, you can mass send money or assets to people who have never used email wallet before but do have an email address. If the email address does not claim the money in 1 year (or another preset time), it can be returned to the sender. This avoids problems with dead email addresses or transactions the recipient does not want to recieve.
+- **Send money to people without accounts**: Because transfers are authorized by an email address, you can mass send money or assets to people who have never used email wallet before but do have an email address. If the email address does not claim the money in 1 year (or another preset time), it can be returned to the sender. This avoids problems with dead email addresses or transactions the recipient does not want to receive.
 - **No user interaction with Ethereum**: By delegating control of their account to an account abstraction wallet under their email provider (which they already trust with their bank account recovery and social media password reset control), users can avoid ever having to think about private keys or the complexity of the crypto ecosystem.
 - **Extension Integration for DeFi Interactions**: Users can enhance their email wallet with extensions, enabling direct interaction with external contracts. This feature allows operations such as token swapping via Uniswap, NFT minting from the email wallet, and adding any other desired extensions. Bulk sending can also be activated through extensions, allowing users to send varying amounts to multiple email addresses in a single email, with a limit of 988 characters in the email subject.
 - **Personal DKIM Registry**: Users now have the option to create their own DKIM Registry. This feature gives users complete control over their email wallet, enhancing its security and personalization. By establishing their own DKIM Registry, users can ensure that their email wallet is exclusively accessible and managed by them, offering an extra layer of security and privacy.

packages/circuits/README.md

@@ -62,7 +62,7 @@ The `email_auth.circom` makes constraints and computes the public output as foll
 14. Let `account_salt` be `PoseidonHash(from_addr|0..0, account_code, 0)`.
 15. Let `masked_subject` be a string that removes the invitation code with the prefix `code_str` and one email address from `subject`, if they appear in `subject`.
 
-Note that the email address in the subject is assumbed not to overlap with the invitation code.
+Note that the email address in the subject is assumed not to overlap with the invitation code.
 
 
 #### `email_auth_with_body_parsing_with_qp_encoding.circom`

packages/circuits/scripts/dev-setup.ts

@@ -114,7 +114,7 @@ async function generateKeys(
   await zKey.newZKey(r1cPath, phase1Path, zKeyPath + ".step1", console);
   log("✓ Partial ZKey generated");
 
-  await zKey.contribute(zKeyPath + ".step1", zKeyPath + ".step2", "Contributer 1", ZKEY_ENTROPY, console);
+  await zKey.contribute(zKeyPath + ".step1", zKeyPath + ".step2", "Contributor 1", ZKEY_ENTROPY, console);
   log("✓ First contribution completed");
 
   // await askBeacon();

packages/contracts/README.md

@@ -291,7 +291,7 @@ libraries = [
 
 About Create2, `L2ContractHelper.computeCreate2Address` should be used.
 `type(ERC1967Proxy).creationCode` doesn't work correctly in ZKsync.
-We need to use the bytecode hash intead of `type(ERC1967Proxy).creationCode`.
+We need to use the bytecode hash instead of `type(ERC1967Proxy).creationCode`.
 Perhaps that is a different value in each compiler version and library addresses.
 
 Run the following commands, you'll get the bytecode hash.