typo corrections

docs/advanced/faq.md

@@ -10,7 +10,7 @@ If you intend to extend support for non-EVM chains in your wallet or dapp, it is
 
 No, the bridge servers are v1 only.
 
-## How can I reconnect to the same pairing if my browser was restarted?
+## How can I reconnect to the same pairing if my browser is restarted?
 
 The `signClient` will restore & reconnect its pairings automatically after the page is reloaded. All pairings are stored on the page's `localStorage`.
 
@@ -34,4 +34,4 @@ You are more than welcome to utilize a custom URI parameter during testing. Howe
 
 ## Why is self-hosting not an option at this time? Are there plans to make this possible in the future?
 
-We understand the desire for developers to self-host their own relay. We share this vision, and have embarked on a decentralization roadmap in order to achieve this. By the end of this summer, we will launch a permissioned network and invite a select group of partners to participate in this crucial first phase. Our objective is to make self-hosting relay a reality with the creation of the decentralized WalletConnect Network, and we appreciate your patience as we progress in this enormous mission.
+We understand the desire for developers to self-host their own relay. We share this vision and have embarked on a decentralization roadmap in order to achieve this. By the end of this summer, we will launch a permissioned network and invite a select group of partners to participate in this crucial first phase. Our objective is to make self-hosting relay a reality with the creation of the decentralized WalletConnect Network, and we appreciate your patience as we progress in this enormous mission.

docs/advanced/glossary.md

@@ -2,43 +2,43 @@
 
 ## Sequence
 
-Sequences refers to a complete flow starting from a Proposal and reaching Settlement. A proposer will create a sequence proposal that will derive a Signal to share out-of-band with the responder in order to reach agreement regarding different permissions and conditions for the sequence. A Sequence establishes how the two clients will relay messages with each other, which keys they will use to encrypt and authenticate messages and additionally what are the permissions regarding the JSON-RPC requests that can be made, notifications that can be emitted and what state will be shared.
+Sequences refer to a complete flow starting from a Proposal and reaching Settlement. A proposer will create a sequence proposal that will derive a Signal to share out-of-band with the responder in order to reach an agreement regarding different permissions and conditions for the sequence. A Sequence establishes how the two clients will relay messages to each other, which keys they will use to encrypt and authenticate messages and additionally, what are the permissions regarding the JSON-RPC requests that can be made, notifications that can be emitted and what state will be shared.
 
 There are two types of sequences specified by the protocol called Pairing and Session.
 
 ## Pairing
 
-Pairing is a specialized sequence which has fixed permissions to only allow a client to propose sessions through it using the method `wc_sessionPropose` which it will be used as a signal out-of-band for session proposals.
+Pairing is a specialized sequence that has fixed permissions to only allow a client to propose sessions through it using the method `wc_sessionPropose` which will be used as a signal out-of-band for session proposals.
 
 ## Session
 
-Session is a generalized sequence which has customizable permissions regarding JSON-RPC requests, notifications emitted and also what accounts are exposed based on the set of chains determined in the permissions.
+A session is a generalized sequence that has customizable permissions regarding JSON-RPC requests, notifications emitted, and also what accounts are exposed based on the set of chains determined in the permissions.
 
 ## Signal
 
 A signal is a payload that can be shared outside of the sequence (out-of-band) to communicate a proposal to another client. Each sequence has its own type of signal.
 
-Pairing is a specialized sequence which has fixed permissions therefore the signal can be encoded as an URI using only the proposal topic, proposer's publicKey, relay protocol options and the controller flag for the proposer. This can be shared either through a qrcode or deep link between clients.
+Pairing is a specialized sequence that has fixed permissions therefore the signal can be encoded as an URI using only the proposal topic, proposer's publicKey, relay protocol options, and the controller flag for the proposer. This can be shared either through a QR code or a deep link between clients.
 
-Session is a generalized sequence which has customized permissions therefore the signal is a proposal sent through a settled pairing already established between the two clients.
+Session is a generalized sequence that has customized permissions therefore the signal is a proposal sent through a settled pairing already established between the two clients.
 
 ## Settlement
 
-Settlement refers to the internal event which both clients will execute from a successful response of a sequence proposal.
+Settlement refers to the internal event that both clients will execute from a successful response to a sequence proposal.
 
 In the case of a responder, the settlement happens before the response is published to the proposer.
 
 In the case of a proposer, the settlement happens after receiving the response published by the responder.
 
-Settlement will generate a shared key using the key pairs of the participants and it will determine the topic from hashing the shared key which is only known to both participants
+The settlement will generate a shared key using the key pairs of the participants and it will determine the topic by hashing the shared key which is only known to both participants
 
 ## Controller
 
-A client can be either a controller or non-controller. This means that all sequences responded and/or proposed by this client will be controlled by it.
+A client can be either a controller or non-controller. This means that all sequences responded to and/or proposed by this client will be controlled by it.
 
-A controller is not bounded by the permissions set by the sequence, meaning it can send any JSON-RPC request, emit any notification type and is the only participant that upgrade the permissions or update the state of the sequence.
+A controller is not bounded by the permissions set by the sequence, meaning it can send any JSON-RPC request, emit any notification type, and is the only participant that upgrades the permissions or updates the state of the sequence.
 
-The controller client will always be the "wallet" which is exposing blockchain accounts to a "dapp" and therefore is also in charge of signing.
+The controller client will always be the "wallet" which exposes blockchain accounts to a "dapp" and therefore is also in charge of signing.
 
 Disconnecting is however not exclusive to the controller client and can be triggered by either participants.
 
@@ -62,41 +62,41 @@ TTL times are always represented in seconds.
 
 Shared key is the key derived using both participants key pairs using the elliptic curve Diffie-Hellman (ECDH) key agreement scheme.
 
-The chosen elliptic curve was Curve25519 offering 128 bits of security (256 bits key size) which was specifically designed for ECDH and it's widely supported by many different platforms natively. The name of its DH function is X25519
+The chosen elliptic curve was Curve25519 offering 128 bits of security (256 bits key size) which was specifically designed for ECDH and is widely supported by many different platforms natively. The name of its DH function is X25519
 
 ## Authenticated Encryption
 
-Authentication Encryption refers to a form of encryption which simultaneously assures the confidentiality and authenticity of data.
+Authentication Encryption refers to a form of encryption that simultaneously assures the confidentiality and authenticity of data.
 
-The chosen approach was to encrypt-then-mac which produces a MAC based on the resulting ciphertext. The encryption uses AES-256-CBC with a random Initialization Vector (IV) and authentication uses HMAC-SHA256. The encrypted payloads are serialized in the following order: iv, publicKey, mac and cipherText.
+The chosen approach was to encrypt-then-mac which produces a MAC based on the resulting ciphertext. The encryption uses AES-256-CBC with a random Initialization Vector (IV) and authentication uses HMAC-SHA256. The encrypted payloads are serialized in the following order: iv, publicKey, mac, and cipherText.
 
 To derive the encryption and authentication keys it uses a SHA512 hash of the shared key using the first 32bytes for encryption and the last 32 bytes for authentication
 
 ## JSON-RPC
 
-JSON-RPC is a stateless, light weight remote procedure call (RPC) protocol which uses JSON (RFC 4627) as data format. You can read more about JSON-RPC specification [here](https://www.jsonrpc.org/specification)
+JSON-RPC is a stateless, lightweight remote procedure call (RPC) protocol that uses JSON (RFC 4627) as data format. You can read more about JSON-RPC specification [here](https://www.jsonrpc.org/specification)
 
 ## Relay
 
-Relay refers to the system, network and/or mechanism used to send and receives messages between the two clients.
+Relay refers to the system, network and/or mechanism used to send and receive messages between the two clients.
 
 ## Publish-Subscribe pattern
 
-Publish-Subscribe (also known as PubSub) is a messaging pattern where senders of messages (publishers) do not send messages directly to receivers but instead label messages with a topic that can be listened to by subscribers. Subscribers only receive messages matching the topics that have expressed interest on.
+Publish-Subscribe (also known as PubSub) is a messaging pattern where senders of messages (publishers) do not send messages directly to receivers but instead label messages with a topic that can be listened to by subscribers. Subscribers only receive messages matching the topics that have expressed interest in.
 
 ## Topics
 
-Topics are 32 bytes hexadecimal strings which are used to identify messages sent between two clients regarding either proposed sequences or settled sequences. Proposed sequences use a randomly generated topic while Settled sequences use a SHA256 hash of the sharedKey.
+Topics are 32-byte hexadecimal strings which are used to identify messages sent between two clients regarding either proposed sequences or settled sequences. Proposed sequences use a randomly generated topic while Settled sequences use a SHA256 hash of the sharedKey.
 
 ## Namespaces
 
-Namespaces are used to specify the chains, methods and events that are intended to be used in a particular session. They establish the minimal requirement for a wallet and a dapp to get paired. There are two types of namespaces,
+Namespaces are used to specify the chains, methods, and events that are intended to be used in a particular session. They establish the minimal requirement for a wallet and a dapp to get paired. There are two types of namespaces,
 
 ### Proposal namespaces
 
-A dapp sends a proposal namespace to the wallet for pairing. The proposal namespace contains the list of chains, methods and events that are required for the dapp. The wallet validates if the received proposal namespaces are valid and returns a session namespace as a response if it is valid. If the requested proposal namespaces are not valid, the session cannot be established and the wallet rejects it with an error code that tells the dapp if the proposal namespaces have invalid chains, methods, events or if it was rejected by the user
+A dapp sends a proposal namespace to the wallet for pairing. The proposal namespace contains the list of chains, methods, and events that are required for the dapp. The wallet validates if the received proposal namespaces are valid and returns a session namespace as a response if it is valid. If the requested proposal namespaces are not valid, the session cannot be established and the wallet rejects it with an error code that tells the dapp if the proposal namespaces have invalid chains, methods, or events or if it was rejected by the user
 
-**Example :** If a dapp wants access to Ethereum Mainnet, Polygon and Cosmos Mainnet - the required chains, methods and events should be mentioned in the proposal namespaces request as follows :
+**Example :** If a dapp wants access to Ethereum Mainnet, Polygon, and Cosmos Mainnet - the required chains, methods, and events should be mentioned in the proposal namespaces request as follows :
 
 ```js
 {
@@ -115,9 +115,9 @@ A dapp sends a proposal namespace to the wallet for pairing. The proposal namesp
 
 ### Session namespaces
 
-The dapp validates if the received proposal namespaces comply with the session namespaces. If they comply, a session is established successfully and pairing is completed. If not, the session is not established and all the cached data related to the namespaces are deleted. The session namespace can also choose to provide access to more chains, methods or events that were not a part of the proposal namespaces.
+The dapp validates if the received proposal namespaces comply with the session namespaces. If they comply, a session is established successfully and pairing is completed. If not, the session is not established and all the cached data related to the namespaces are deleted. The session namespace can also choose to provide access to more chains, methods, or events that were not a part of the proposal namespaces.
 
-**Example :** The following is an example for a session namespace which complies with the requested proposal namespace example,
+**Example :** The following is an example of a session namespace that complies with the requested proposal namespace example,
 
 ```js
 {
@@ -139,4 +139,4 @@ The dapp validates if the received proposal namespaces comply with the session n
 }
 ```
 
-You can also see that `personal_sign` method and `proofFinalized` event are not requested by the proposal namespaces but is still granted by the session namespaces. Hence, session namespaces can grant additional access to more chains, methods and events which were not requested by the proposal namespaces.
+You can also see that `personal_sign` method and `proofFinalized` event are not requested by the proposal namespaces but are still granted by the session namespaces. Hence, session namespaces can grant additional access to more chains, methods, and events that were not requested by the proposal namespaces.

docs/advanced/push-server.md

@@ -18,7 +18,7 @@ It is recommended that you use WalletConnect Cloud for simplicity and ease of in
 
 ![create-push-url](/assets/create-push-url.png)
 
-3. From the same settings tab, you will see the FCM and the APNS settings becomes available to setup. Add your [FCM](#Firebase Cloud Messaging API (FCM v1)) and/or [APNs](#apple-push-notifications-apns) details.
+3. From the same settings tab, you will see the FCM and the APNS settings become available to set up. Add your [FCM](#Firebase Cloud Messaging API (FCM v1)) and/or [APNs](#apple-push-notifications-apns) details.
 
 ![fmc-and-apns-details-form](/assets/apns-fmc-details.png)
 
@@ -44,9 +44,9 @@ If you already have FCM Legacy enabled and then enable FCM v1, push notification
     ![Create new key](/assets/push-fcmv1-sa-new-key.png)
   - Select _JSON_ and click _Create_
   - A `.json` file containing the service account credentials will be automatically downloaded to your computer
-- Upload the credentaials JSON file to your Cloud project's FCM V1 settings and click _Save_
+- Upload the credentials JSON file to your Cloud project's FCM V1 settings and click _Save_
 
-You should now see a green checkbox indicating that FCM V1 has been enabled! Now any clients that register themselves on the Push Server will receive FCM push notifications for relay messages to that client.
+You should now see a green checkbox indicating that FCM V1 has been enabled! Now any clients that register themselves on the Push Server will receive FCM push notifications to relay messages to that client.
 
 ### Cloud Messaging API (FCM Legacy)
 
@@ -58,7 +58,7 @@ FCM Legacy is deprecated and [will be removed June 20, 2024](https://firebase.go
 When FCM v1 is enabled in WalletConnect Cloud, it will replace the use of the legacy FCM API. No migration of devices/apps is necessary.
 :::
 
-Google's FCM allows you to use send notifications to both Android and Apple devices. At this time, we only support apps using the FCM client API.
+Google's FCM allows you to send notifications to both Android and Apple devices. At this time, we only support apps using the FCM client API.
 
 - Enable Legacy Cloud Messaging API in the Firebase project settings
   ![legacy-fcm-cloud-messaging](/assets/legacy-fcm-cloud-messaging-api.png)

docs/advanced/walletconnectmodal/about.mdx

@@ -42,7 +42,7 @@ Instead of using the npm package, you can simply import it from their CDN and us
 :::caution
 **The WalletConnectModal SDK is currently in Alpha and is not production-ready**.
 
-It's public API and associated documentation may still see significant and breaking changes.
+Its public API and associated documentation may still see significant and breaking changes.
 :::
 
 #### SwiftPackageManager
@@ -91,7 +91,7 @@ array of that target:
 :::caution
 **The WalletConnectModal SDK is currently in Alpha and is not production-ready**.
 
-It's public API and associated documentation may still see significant and breaking changes.
+Its public API and associated documentation may still see significant and breaking changes.
 :::
 
 Kotlin implementation of WalletConnectModal for Android applications.
@@ -168,7 +168,7 @@ Example:
   <string>safe</string>
   <string>rainbow</string>
   <string>uniswap</string>
-  <!-- Add other wallet schemes names here -->
+  <!-- Add other wallet scheme names here -->
 </array>
 ```