Fix typos

docs/core--concepts/how-eas-works.md

@@ -14,7 +14,7 @@ Attestations are the building blocks of building trust online. Think of an attes
 But for this system to work seamlessly, we need a standardized way to structure this data. This is where schemas come into play.
 
 ## Schemas give structure to the attestation
-Think of a schema as a blueprint or template. It defines the structure and format of the data you want to attest to. For example if you want to attest to someone you trust, all you'd need is a true false field for "isTrusted". Or if you wanted to a vote, you might have a "eventName" and a "location" and "startTime" and "endTime". It's the builder's choice to determine the right schema for their particular use case.
+Think of a schema as a blueprint or template. It defines the structure and format of the data you want to attest to. For example if you want to attest to someone you trust, all you'd need is a true false field for "isTrusted". Or if you wanted to vote, you might have a "eventName" and a "location" and "startTime" and "endTime". It's the builder's choice to determine the right schema for their particular use case.
 
 Here's the general flow of how a schema is registered:
 1. The schema's structure is defined (e.g., what fields it will have and the data types).

docs/core--concepts/onchain-vs-offchain.md

@@ -26,7 +26,7 @@ Attestations can be made either onchain or offchain. While **onchain attestation
 | **Security**                    | Secured by blockchain consensus                           | Secured by cryptographic signatures                         |
 | **Scalability & Performance**   | Requires onchain transactions to process                  | Faster processing times; can lead to better scalability     |
 | **Timestamping**                | Inherent timestamping by the blockchain                   | The UID of the attestation can be timestamped onchain for verifiability |
-| **Lifecycle Management**        | Revocations stored onchain                                | Revocations require need separate management                  |
+| **Lifecycle Management**        | Revocations stored onchain                                | Revocations require separate management                     |
 
 
 ## Best Practices
@@ -45,7 +45,7 @@ Attestations can be made either onchain or offchain. While **onchain attestation
 It's important for builders to consider what data needs to go onchain or should live offchain. A common misconception with onchain attestations is that they do not have privacy features. There are several ways to keep onchain attestation data more private. 
 
 - **Offchain:** Generally preferable for confidentiality as no data is publicly visible unless explicitly stored in places like IPFS.
-- **Private Data Attestations:** An innovative solution to attest nearly an infinite amount of private data by attesting its [merkle root onchain](/docs/tutorials/private-data-attestations.md).
+- **Private Data Attestations:** An innovative solution to attest nearly an infinite amount of private data by attesting its [Merkle root onchain](/docs/tutorials/private-data-attestations.md).
 - **Onchain Adaptations:** Rather than placing the entire data on why something was true, one could attest to results, such as a true/false field of the verification. 
 - **Leverage ZKP:** Generate a zero-knowledge proof from the attestation data to keep information private and trustworthy. 
 - **Bottom Line:** Prioritize privacy. Whether you're storing a verification process or the verification result, sensitive data management is paramount.
@@ -56,7 +56,7 @@ Navigating the world of attestations might seem complex, but it boils down to un
 
 - **Authenticity is a Given:** Both onchain and offchain attestations offer the authenticity of a digital signature. No matter where it's stored, if the data changes, the signature won't verify.
 - **Smart Contract Interaction:** If your project requires smart contracts to frequently access or verify attestation data, onchain is your best bet. It ensures that the data is always available on the Ethereum blockchain for smart contracts to interact with.
-- **Privacy Matters:** If you're handling sensitive data or want to control who sees what and when, offchain offers more flexibility. Store data privately and share it selectively. But remember, onchain isn't out of the race for privacy. With techniques like private data attestations, you can store a merkle root onchain and then selectively disclose specific parts of your data when needed.
+- **Privacy Matters:** If you're handling sensitive data or want to control who sees what and when, offchain offers more flexibility. Store data privately and share it selectively. But remember, onchain isn't out of the race for privacy. With techniques like private data attestations, you can store a Merkle root onchain and then selectively disclose specific parts of your data when needed.
 
 In short, think about how your data will be used. If it's crucial for smart contracts, onchain might be the way. If it's about privacy and controlled sharing, offchain could be your answer. And sometimes, a blend of both might be the perfect solution. The power to choose is yours.
 

docs/core--concepts/privacy.md

@@ -15,9 +15,9 @@ The blockchain's defining feature of immutability is a double-edged sword. While
 Below are a few concepts to consider when building with privacy in mind.
 
 ### Private Data Attestations
-Private Data Attestations are a way to attest to nearly an infinite amount of arbitrary data, generate a merkle tree of that data, and then only attest to the merkle root onchain or offchain. The data can then be provided to specific individuals and allow them to selectively disclose or verify the data against the merkle root. 
+Private Data Attestations are a way to attest to nearly an infinite amount of arbitrary data, generate a Merkle tree of that data, and then only attest to the Merkle root onchain or offchain. The data can then be provided to specific individuals and allow them to selectively disclose or verify the data against the Merkle root. 
 
-For example, a university could attest to a student's entire transcript by creating a merkle tree of the courses and grades, and then only attesting to the root onchain. The student can then provide specific courses to employers without revealing their entire transcript.
+For example, a university could attest to a student's entire transcript by creating a Merkle tree of the courses and grades, and then only attesting to the root onchain. The student can then provide specific courses to employers without revealing their entire transcript.
 
 **📘 Read More:** [**Private Data Attestations**](/docs/tutorials/private-data-attestations.md)
 

docs/developer-tools/eas-sdk.md

@@ -3,7 +3,7 @@ sidebar_position: 1
 ---
 
 # EAS SDK
-Here, you'll find everything you need to get started with integrating EAS into a **Javascript/Typescript** project. 
+Here, you'll find everything you need to get started with integrating EAS into a **JavaScript/TypeScript** project. 
 
 You can also reference our SDK directly in the [**SDK Github repo**](https://github.com/ethereum-attestation-service/eas-sdk).
 

docs/developer-tools/hash-a-file.md

@@ -12,7 +12,7 @@ You can hash any local file:
 - Images
 - Any type of file
 
-## Understanding How Hash's Work
+## Understanding How Hashes Work
 A hash function like `SHA256` takes an input (or 'message') and returns a fixed-size string of bytes. The output, typically a 'digest', is unique to each unique input. Even a minor change, like a single letter or single pixel of the file changes, it will produce a vastly different output, this is also known as the `avalanche effect`. This makes hashing a powerful tool for verifying data integrity. 
 
 SHA-256, which stands for Secure Hash Algorithm 256-bit, is one of the cryptographic hash functions in the SHA-2 family. It's widely used in the world of cryptography and is integral to the functioning of modern technologies, including blockchain systems.

docs/developer-tools/sdk-wagmi.md

@@ -28,7 +28,7 @@ The `useProvider` hook gets the `publicClient` and returns a provider compatible
 Usage:
 
 ```typescript
-const signer = useProvider();
+const provider = useProvider();
 ```
 
 ### Code Implementation

docs/developer-tools/verify-timestamp.md

@@ -3,15 +3,15 @@ sidebar_position: 4
 ---
 
 # Batch Timestamping
-Timestamping is a crucial aspect of ensuring the authenticity and integrity of data. Timestamping provides a verifiable proof of existence for offchain attestations. This doc delves into the concept of Merkle Trees and how they can be used to efficiently timestamp multiple offchain attestations in a single transaction.
+Timestamping is a crucial aspect of ensuring the authenticity and integrity of data. Timestamping provides a verifiable proof of existence for offchain attestations. This doc delves into the concept of Merkle trees and how they can be used to efficiently timestamp multiple offchain attestations in a single transaction.
 
 ## Understanding Merkle Trees
-A Merkle Tree is a binary tree where each leaf node represents a piece of data, and each non-leaf node is a hash of its child nodes. The topmost node, known as the Merkle Root, provides a single hash representation for all the data in the tree.
+A Merkle tree is a binary tree where each leaf node represents a piece of data, and each non-leaf node is a hash of its child nodes. The topmost node, known as the Merkle root, provides a single hash representation for all the data in the tree.
 
 ### Key Features:
 - **Efficiency:** Allows for efficient and secure verification of large data sets.
-- **Proof of Inclusion:** Any piece of data can be verified to be a part of the tree by providing a 'proof path', a sequence of hashes leading to the Merkle Root.
-- **Immutability:** Any change in data, even at the leaf level, results in a change in the Merkle Root.
+- **Proof of Inclusion:** Any piece of data can be verified to be a part of the tree by providing a 'proof path', a sequence of hashes leading to the Merkle root.
+- **Immutability:** Any change in data, even at the leaf level, results in a change in the Merkle root.
 
 ## Why Timestamp Offchain Attestations?
 Offchain attestations, by their nature, lack an onchain consensus timestamp, making their exact time of creation unverifiable. Timestamping the UID of the offchain attestation onchain provides:
@@ -20,20 +20,20 @@ Offchain attestations, by their nature, lack an onchain consensus timestamp, mak
 - **Data Integrity:** The UID, being a unique hash of the entire valid attestation data, ensures that the attestation hasn't been altered post-timestamping.
 
 ## Batch Timestamping with Merkle Trees
-While individual timestamping is straightforward, it may not be efficient for large volumes of attestations. This is where Merkle Trees shine:
+While individual timestamping is straightforward, it may not be efficient for large volumes of attestations. This is where Merkle trees shine:
 
-- **Batch Multiple UIDs:** Instead of timestamping each UID individually, multiple UIDs are combined to form a Merkle Tree.
-- **Generate the Merkle Root:** The Merkle Root, representing all the UIDs, is generated.
-- **Single Onchain Transaction:** Only the Merkle Root is timestamped onchain, saving on transaction costs and gas.
-- **Proof of Inclusion:** Any individual UID can later be verified against the timestamped Merkle Root.
+- **Batch Multiple UIDs:** Instead of timestamping each UID individually, multiple UIDs are combined to form a Merkle tree.
+- **Generate the Merkle Root:** The Merkle root, representing all the UIDs, is generated.
+- **Single Onchain Transaction:** Only the Merkle root is timestamped onchain, saving on transaction costs and gas.
+- **Proof of Inclusion:** Any individual UID can later be verified against the timestamped Merkle root.
 
 ## Using easscan.org for Batch Timestamping
 EAS provides a simple container on the easscan.org site to facilitate this process:
 
 - **Paste UIDs:** Users can easily paste multiple offchain attestation UIDs.
-- **Timestamp All:** Upon clicking "Timestamp All", the site generates the Merkle Root for all the UIDs.
-- **Onchain Timestamping:** The platform assists users in creating an onchain timestamp for the Merkle Root.
-- **Results Page:** Post timestamping, users receive a results page listing all UIDs that are part of the timestamped Merkle Root.
+- **Timestamp All:** Upon clicking "Timestamp All", the site generates the Merkle root for all the UIDs.
+- **Onchain Timestamping:** The platform assists users in creating an onchain timestamp for the Merkle root.
+- **Results Page:** Post timestamping, users receive a results page listing all UIDs that are part of the timestamped Merkle root.
 
 ## Example Flow
 Here's an example batch timestamp flow on Sepolia.
@@ -46,16 +46,16 @@ Here's an example batch timestamp flow on Sepolia.
 ![Timestamp UID List](./img/batch-timestamp-list.png)
 
 
-3. Nice! Now we can see the `Batch Timestamp Details` which generated a Merkle Tree of the **12** `UIDs`. You can see the onchain transaction ID of `0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85`. You can see this example here: [https://sepolia.easscan.org/timestamp/0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85](https://sepolia.easscan.org/timestamp/0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85)
+3. Nice! Now we can see the `Batch Timestamp Details` which generated a Merkle tree of the **12** `UIDs`. You can see the onchain transaction ID of `0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85`. You can see this example here: [https://sepolia.easscan.org/timestamp/0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85](https://sepolia.easscan.org/timestamp/0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85)
 ![Timestamp Result](./img/timestamp-result.png)
 
-4. When you go to a public offchain attestation record that has been timestamped, you'll see there is an `onchain timestamp` in the top right hand side of the attestation record. You can click the eye and it will take you to the merkle tree record and highlight the `UID` is in fact a part of the batch timestamp record. 
+4. When you go to a public offchain attestation record that has been timestamped, you'll see there is an `onchain timestamp` in the top right hand side of the attestation record. You can click the eye and it will take you to the Merkle tree record and highlight the `UID` is in fact a part of the batch timestamp record. 
 ![Timestamp Result](./img/onchain-timestamp-record.png)
 
-5. This is showing that the `UID` of the offchain attestation was found in the merkle tree.
+5. This is showing that the `UID` of the offchain attestation was found in the Merkle tree.
 ![Timestamp Highlighted](./img/timestamp-highlighted.png)
 
 
 
 ## Conclusion
-Merkle Trees offer a powerful and efficient mechanism to timestamp large volumes of offchain attestations with a single onchain transaction. This ensures not only the proof of existence but also the integrity of the attestations, providing a robust and cost-effective solution for developers and users alike.
+Merkle trees offer a powerful and efficient mechanism to timestamp large volumes of offchain attestations with a single onchain transaction. This ensures not only the proof of existence but also the integrity of the attestations, providing a robust and cost-effective solution for developers and users alike.

docs/easscan/utilities.md

@@ -23,7 +23,7 @@ Easily hash any file and attest to it. There are two schemas you can use for thi
     ![Ethereum Whitepaper](./img/ethereum-whitepaper-hash-verified.png)
 
 ### Private Data Attestations
-Attest to the merkle root of a bunch of private data. This can be useful for attesting to an `allowlist` of users, selective information or private info. The `merkle root` is attested to onchain and then you can selectively share each of the individual merkle tree leaves, effectively selectively disclosing the information, and allowing others to verify that that piece of data was indeed a part of the merkle tree. The value comes from the entity that attested to the private data merkle root, and then allowing others to verify the data.
+Attest to the Merkle root of a bunch of private data. This can be useful for attesting to an `allowlist` of users, selective information or private info. The `Merkle root` is attested to onchain and then you can selectively share each of the individual Merkle tree leaves, effectively selectively disclosing the information, and allowing others to verify that that piece of data was indeed a part of the Merkle tree. The value comes from the entity that attested to the private data Merkle root, and then allowing others to verify the data.
 
 **Tutorial:** [Private Data Attestations](/docs/tutorials/private-data-attestations.md)
 
@@ -49,7 +49,7 @@ Upload any offchain attestation raw data into this tool so you can easily see if
 ![Verify Offchain Attestation Container](./img/verify-offchain.png)
 
 ### Timestamping Offchain Attestations
-Offchain attestations do not have a verifiable timestamp. If you want to timestamp multiple `UID`s of the offchain attestation, it will generate a merkle root and timestamp just that root. Then you can verify any of the individual UIDs.
+Offchain attestations do not have a verifiable timestamp. If you want to timestamp multiple `UID`s of the offchain attestation, it will generate a Merkle root and timestamp just that root. Then you can verify any of the individual UIDs.
 
 **Tutorial:** [Timestamping Offchain](/docs/developer-tools/verify-timestamp)
 

docs/idea--zone/use--case--examples/digital-identity.md

@@ -33,7 +33,7 @@ The privacy of individuals must be a top priority. For example, instead of a gov
 
 Similarly, for a KYC compliance, the KYC service would only need to attest to a true/false flag that shows that the address successfully passed their KYC compliance process. It wouldn't need to store any information beyond that.
 
-EAS also allows users to create [Private Data Attestations](/docs/tutorials/private-data-attestations). `Private Data Attestations` take advantage of Merkle Trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy.
+EAS also allows users to create [Private Data Attestations](/docs/tutorials/private-data-attestations). `Private Data Attestations` take advantage of Merkle trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy.
 
 Attestations with `Zero Knowledge Proofs` are another path forward to explore. 
 

docs/idea--zone/use--case--examples/healthcare-records.md

@@ -21,7 +21,7 @@ Attestation-based healthcare records can also be used to track medication adhere
 :::
 EAS does not presuppose which privacy-preserving technology is best for any use case. However, the privacy of individuals must be a top priority. 
 
-EAS also allows users to create [Private Data Attestations](/docs/tutorials/private-data-attestations). `Private Data Attestations` take advantage of Merkle Trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy.
+EAS also allows users to create [Private Data Attestations](/docs/tutorials/private-data-attestations). `Private Data Attestations` take advantage of Merkle trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy.
 
 Attestations with `Zero Knowledge Proofs` are another path forward to explore.