Feat: add check spelling (#188)

* add cspell to package and start exec

* small typo fixs

.cspell.json

@@ -0,0 +1,71 @@
+{
+    "version": "0.2",
+    "language": "en",
+    "ignorePaths": ["node_modules", "dist", "build", 
+                "docs/advanced/multichain/polkadot/dapp-integration-guide.md", "docs/web3modal/v2/_partials/themeVariablesTable.mdx", 
+                "docs/web3modal/v2/_partials/wcModalThemeVariablesTable.mdx", "docs/advanced/multichain/polkadot/wallet-integration-guide.md",
+                "docs/advanced/multichain/rpc-reference/bitcoin-rpc.md", "docs/advanced/multichain/rpc-reference/dogecoin-rpc.md",
+                "docs/advanced/multichain/rpc-reference/everscale-rpc.md", "docs/advanced/multichain/rpc-reference/litecoin-rpc.md"
+
+            ],
+    "overrides": [
+      {
+        "filename": "**/*.md",
+        "languageId": "markdown",
+        "ignoreRegExpList": [
+            "/`[^`]*`/",  // Ignore inline code,
+          "/```[\\s\\S]*?```/"  // Ignore everything between triple backticks
+        ]
+      },
+      {
+        "filename": "**/*.mdx",
+        "languageId": "markdown",
+        "ignoreRegExpList": [
+          "/`[^`]*`/",  // Ignore inline code
+          "/```[\\s\\S]*?```/"  // Ignore everything between triple backticks
+        ]
+      }
+    ],
+    "words": [
+      "npm",
+      "webpack",
+      "prettier",
+      "markdownlint",
+      "mdx",
+      "appkit",
+      "reown",
+      "solana",
+      "wagmi",
+      "siwe",
+      "viem",
+      "Farcaster",
+      "Nethereum",
+      "walletconnect",
+      "CAIP",
+      "deeplink",
+      "RDNS",
+      "siws",
+      "siwx",
+      "walletkit",
+      "Cocoapods",
+      "Podfile",
+      "Multichain",
+      "devnet",
+      "testflight",
+      "nuxt",
+      "jitpack",
+      "Linea",
+      "polkadot",
+      "anza",
+      "kadena",
+      "keccak",
+      "XRPL",
+      "keypair","tezos","Starknet", "utxos", "litecoin", "hedera", "satoshi", "kusama", "westend", "statemint", "passwordless",
+      "Blockhash", "UTXO", "PSBT", "keypair", "keypairs", "deeplinking", "chainlist", "pubspec","artefacts","artefact","artefactId", "WCURI",
+      "qrcode", "ECDH", "ciphertext", "HMAC", "mutez", "rebranded", "clickjacking", "openupm", "walletids", "walletid", "Keyserver", "CAPI",
+      "Newtonsoft", "mainnets", "Netherum's", "Starscream", "lokijs", "linkining", "themself", "triggermodal", "Coinbasewallet", "bera", "UXML", "preconfigured",
+      "Rebalancing", "hackathons", "eviluniswap", "permissioned", "Diffie", "prioritise", "synchronise", "scriptable", "dedup", "Zora", "Fraximal", "Podspec", "Wormfare",
+      "johnsmith", "secp", "reimagined"
+    ]
+  }
+

docs/api/notify/usage.mdx

@@ -276,7 +276,7 @@ try Notify.configure(environment: APNSEnvironment, crypto: CryptoProvider)
 ```
 
 environment - Use `debug` environment for debug builds and `release` for release and TestFlight builds
-crypto - CruptoProvider is a protocol, you are required to provide an implementation of two methods recoverPubKey and keccak256.
+crypto - CryptoProvider is a protocol, you are required to provide an implementation of two methods recoverPubKey and keccak256.
 
 #### Register for Push Notifications
 
@@ -397,7 +397,7 @@ public func subscribe(metadata: AppMetadata, account: Account, onSign: @escaping
 
 `metadata` - metadata object of publicly discoverable dapp fetched from WalletGuide
 
-`account` - an account you want to associate a sebscription with
+`account` - an account you want to associate a subscription with
 
 `onSign` - callback that requires a signature from a user
 

docs/appkit/flutter/core/email.mdx

@@ -16,7 +16,7 @@ Remember to whitelist your dapp's iOS's bundleId and Android's packageName in yo
 :::
 
 :::info
-Social Login are avaiable from version `1.2.0-beta01`
+Social Login are available from version `1.2.0-beta01`
 :::
 
 ## Integration
@@ -56,11 +56,11 @@ final _appKitModal = ReownAppKitModal(
 
 - **_email `bool`_** : This boolean defines whether you want to enable email login. Default `true`
 - **_socials `List<AppKitSocialOption>`_** : This list contains the list of social platforms that you want to enable for user authentication. The platforms in the example include Farcaster, X, Discord. Is empty by default, it means that no social options is enabled.
-- **showMainWallets `bool`_** : This boolean defines whether you want to show the main wallet options on the first connect screen. If this is `false` it will show a button that directs you to a new screen displaying all avaiable wallets. Default `true`.
+- **showMainWallets `bool`_** : This boolean defines whether you want to show the main wallet options on the first connect screen. If this is `false` it will show a button that directs you to a new screen displaying all available wallets. Default `true`.
 
 :::note
 
-In order for Email Wallet to work propertly, `AppKitModalConnectButton()` has to be instantiated during the whole lifetime of the app. 
+In order for Email Wallet to work properly, `AppKitModalConnectButton()` has to be instantiated during the whole lifetime of the app. 
 
 If you already use `AppKitModalConnectButton()` then nothing else has to be done, but in case you don't use it but still want to support Email Wallets you can instantiate and hide it as follows:
 

docs/appkit/flutter/core/options.mdx

@@ -59,7 +59,7 @@ These are the set of namespaces that will be requested to the wallet you are con
 
 These values are optionals and, in most cases, not required since AppKit already defines every required and optional namespace internally based on configured networks.
 
-However, if you would want to override that definition with your own or support more networks than just EVM and Solana (i.e. Polkadot, Kadena, etc...) these are the object yout should modify. See [Custom Networks](../core/custom-chains.mdx). section.
+However, if you would want to override that definition with your own or support more networks than just EVM and Solana (i.e. Polkadot, Kadena, etc...) these are the object you should modify. See [Custom Networks](../core/custom-chains.mdx). section.
 
 ### featuredWalletIds:
 

docs/appkit/flutter/core/usage.mdx

@@ -128,7 +128,7 @@ But in order for the redirect mechanism to work you would also need to add the f
 </PlatformTabItem>
 <PlatformTabItem value="android">
 
-1. Locate your `AndroidManifest.xml` file under `your_project/android/app/src/main/` fodler.
+1. Locate your `AndroidManifest.xml` file under `your_project/android/app/src/main/` folder.
 2. Locate the `<Activity .MainActivity` inside `<application />` scope.
 3. Add the following intent
 
@@ -189,7 +189,7 @@ Column(
 ),
 ```
 
-`AppKitModalAccountButton` is composed by `AppKitModalBalanceButton` and `AppKitModalAddressButton` and you can use these separatedly from `AppKitModalAccountButton`
+`AppKitModalAccountButton` is composed by `AppKitModalBalanceButton` and `AppKitModalAddressButton` and you can use these separately from `AppKitModalAccountButton`
 
 ```javascript
 AppKitModalBalanceButton(appKitModal: _appKitModal, onTap: _appKitModal.openModalView);

docs/appkit/ios/core/options.mdx

@@ -103,7 +103,7 @@ override func application(_ app: UIApplication, open url: URL, options: [UIAppli
 }
 ```
 
-or for SwiftUI attach `onOpenURL` modifier somewhere in your view hieararchy like shown below.
+or for SwiftUI attach `onOpenURL` modifier somewhere in your view hierarchy like shown below.
 
 ```swift
 WindowGroup {

docs/appkit/javascript/notifications/backend-integration.mdx

@@ -211,7 +211,7 @@ curl 'https://notify.walletconnect.com/<PROJECT_ID>/subscribers' \
 Unless marked as read by an app frontend, notifications will always be "unread". Because of this, when you
 initially add support for displaying unread status or unread count to your frontend, users that have received
 notifications in the past will have notifications display as "unread" even if they already have seen them.
-This can potentially be an undesireable user experience.
+This can potentially be an undesirable user experience.
 
 To mitigate this problem, you can make a one-time call to the `/v1/<project-id>/mark-all-as-read` API endpoint
 which will mark all existing notifications as read. Notifications marked as read in this way will not contribute

docs/appkit/next/notifications/backend-integration.mdx

@@ -27,7 +27,7 @@ To send a notification notification you can call the `/notify` endpoint. This en
 - `body` - The body of the notification containing more detail. Max 255 characters.
 - `url` (optional) - A URL attached to the notification that the user can navigate to. Max 255 characters.
 - `accounts` - A list of [CAIP-10](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-10.md) account IDs for which to send the notification to. Max 500 accounts per request. Also see the [rate limits](#rate-limits) below.
-- `notification_id` (optional) - An idempotency key of arbitrary format used to dedup multiple requests. Max 255 characters. Multiple calls with the same `notification_id` will use the first call's `notification` content, but will send to any additional account IDs listed in `accounts`.
+- `notification_id` (optional) - An idempotency key of arbitrary format used to deduplicate multiple requests. Max 255 characters. Multiple calls with the same `notification_id` will use the first call's `notification` content, but will send to any additional account IDs listed in `accounts`.
 
 ```typescript
 type RequestBody = {
@@ -211,7 +211,7 @@ curl 'https://notify.walletconnect.com/<PROJECT_ID>/subscribers' \
 Unless marked as read by an app frontend, notifications will always be "unread". Because of this, when you
 initially add support for displaying unread status or unread count to your frontend, users that have received
 notifications in the past will have notifications display as "unread" even if they already have seen them.
-This can potentially be an undesireable user experience.
+This can potentially be an undesirable user experience.
 
 To mitigate this problem, you can make a one-time call to the `/v1/<project-id>/mark-all-as-read` API endpoint
 which will mark all existing notifications as read. Notifications marked as read in this way will not contribute

docs/appkit/react-native/core/installation.mdx

@@ -366,7 +366,7 @@ npx pod-install
 </array>
 ```
 
-7. Add Coinbase reponse handler in your app. More info <a href="https://mobilewalletprotocol.github.io/wallet-mobile-sdk/docs/client-sdk/rn-setup#listening-for-responses">here</a>
+7. Add Coinbase response handler in your app. More info <a href="https://mobilewalletprotocol.github.io/wallet-mobile-sdk/docs/client-sdk/rn-setup#listening-for-responses">here</a>
 
 ```tsx
 import { handleResponse } from '@coinbase/wallet-mobile-sdk'

docs/appkit/react-native/notifications/backend-integration.mdx

@@ -211,7 +211,7 @@ curl 'https://notify.walletconnect.com/<PROJECT_ID>/subscribers' \
 Unless marked as read by an app frontend, notifications will always be "unread". Because of this, when you
 initially add support for displaying unread status or unread count to your frontend, users that have received
 notifications in the past will have notifications display as "unread" even if they already have seen them.
-This can potentially be an undesireable user experience.
+This can potentially be an undesirable user experience.
 
 To mitigate this problem, you can make a one-time call to the `/v1/<project-id>/mark-all-as-read` API endpoint
 which will mark all existing notifications as read. Notifications marked as read in this way will not contribute

docs/appkit/react/notifications/backend-integration.mdx

@@ -211,7 +211,7 @@ curl 'https://notify.walletconnect.com/<PROJECT_ID>/subscribers' \
 Unless marked as read by an app frontend, notifications will always be "unread". Because of this, when you
 initially add support for displaying unread status or unread count to your frontend, users that have received
 notifications in the past will have notifications display as "unread" even if they already have seen them.
-This can potentially be an undesireable user experience.
+This can potentially be an undesirable user experience.
 
 To mitigate this problem, you can make a one-time call to the `/v1/<project-id>/mark-all-as-read` API endpoint
 which will mark all existing notifications as read. Notifications marked as read in this way will not contribute

docs/appkit/shared/notifications/frontend-integration/api/registering-push/javascript.mdx

@@ -19,4 +19,4 @@ const clientId = client.registerWithPushServer(firebaseToken)
 
 - `registerWithPushServer`: `(token: string, platform: 'fcm' | 'apns') => string`
 
-Either APNS or FCM can be used to recieve push notifications. Token here is the respective platform's token.
+Either APNS or FCM can be used to receive push notifications. Token here is the respective platform's token.

docs/appkit/shared/notifications/frontend-integration/migration/react.mdx

@@ -87,7 +87,7 @@ setAccount(`eip155:1:0x...`)
 #### Managing notifications
 
 Messages (notifications) function a little differently now. One of the big changes is that you can no longer delete messages.
-Furthermore, messages can now be paged. For convenience, "infinte scroll" paging functionality is available, as in keeping older pages in the
+Furthermore, messages can now be paged. For convenience, "infinite scroll" paging functionality is available, as in keeping older pages in the
 returned array.
 
 - **Retrieving notifications**

docs/appkit/shared/siwe/code.mdx

@@ -6,7 +6,7 @@ import TabItem from '@theme/TabItem'
 
 :::info
 
-If you are not using our library on the server-side, please normalize the address with eip-55 in the createMessage function. You can check our example for that funcionality.
+If you are not using our library on the server-side, please normalize the address with eip-55 in the createMessage function. You can check our example for that Functionality.
 
 :::
 

docs/appkit/unity/core/siwe.mdx

@@ -97,7 +97,7 @@ user successfully verifies the address.
 To use 1-CA + SIWE at full extend, a backend for communication is required. This backend will be used to generate a nonce,
 verify messages and handle sessions. You can read more about SIWE backend implementation at [here](https://docs.login.xyz/sign-in-with-ethereum/quickstart-guide/implement-the-backend).
 
-### 0. Create SIWE congiguration
+### 0. Create SIWE configuration
 ```csharp
 var siweConfig = new SiweConfig
 {

docs/appkit/upgrade/from-web3modal-android.mdx

@@ -14,7 +14,7 @@ This upgrade guide helps developers transition from using the Web3Modal library
 
 ### Step 1. Update the Repository Dependencies
 
-The Web3Modal library has been deprecated and moved to a new repository under the reown-com organization. Update your dependecies to use AppKit:
+The Web3Modal library has been deprecated and moved to a new repository under the reown-com organization. Update your dependencies to use AppKit:
 
 ```swift
 /* highlight-delete-start */

docs/appkit/upgrade/from-web3modal-unity.mdx

@@ -131,7 +131,7 @@ await AppKit.Evm.SendTransactionAsync(address, value);
 
 ### Step 5. Rename USS variables
 
-If you customised any AppKit USS variables, simply change `--wui` part of the variable name to `--ro`. For example:
+If you customized any AppKit USS variables, simply change `--wui` part of the variable name to `--ro`. For example:
 
 ```css
 /* highlight-delete-start */

docs/appkit/vue/notifications/backend-integration.mdx

@@ -211,7 +211,7 @@ curl 'https://notify.walletconnect.com/<PROJECT_ID>/subscribers' \
 Unless marked as read by an app frontend, notifications will always be "unread". Because of this, when you
 initially add support for displaying unread status or unread count to your frontend, users that have received
 notifications in the past will have notifications display as "unread" even if they already have seen them.
-This can potentially be an undesireable user experience.
+This can potentially be an undesirable user experience.
 
 To mitigate this problem, you can make a one-time call to the `/v1/<project-id>/mark-all-as-read` API endpoint
 which will mark all existing notifications as read. Notifications marked as read in this way will not contribute

docs/cloud/paymaster.mdx

@@ -111,7 +111,7 @@ curl --location <YOUR_PAYMASTER_URL> \
 
 ### Basics
 The schema itself is a simple object representation of the following
-> Is some key from a user operation equivelant to _(or some other comparision)_  some value?
+> Is some key from a user operation equivalent to _(or some other comparison)_  some value?
 
 This is defined in `params` as such:
 ```json
@@ -174,9 +174,9 @@ accompanied with an `ands` OR an `ors` field which is an array of more params th
 either all pass as true, or only one of them is true, respectively.
 
 A `params` object can not have both an `ors` and
-an `ands` simultanousely. However, its "children" (the params in an `ands` or `ors`) can have different conditonals than their parent.
+an `ands` simultaneously. However, its "children" (the params in an `ands` or `ors`) can have different conditionals than their parent.
 
-For example, to make it so that the above policy also passes for `methodBar` and `methodBaz`, it can be ammended as follows:
+For example, to make it so that the above policy also passes for `methodBar` and `methodBaz`, it can be amended as follows:
 
 ```json
 {
@@ -259,7 +259,7 @@ However, the <span style={{color: 'red'}}>following is incorrect </span>:
 }
 ```
 
-***In this case, the `ors` will be completely ignored. If both `ors` and `ands` are present, then the `ands` will take presedence.***
+***In this case, the `ors` will be completely ignored. If both `ors` and `ands` are present, then the `ands` will take precedence.***
 
 ### ABI Parsing
 
@@ -268,7 +268,7 @@ For the policy to actually know how to read the `callData` it needs to know the
 For this we introduce 2 new fields. `policyStaticProps` and `metadata`. Both are essentially free range key-value 
 dictionaries used to store information within the policy to be accessed later. The key thing to note is that
 values within `policyStaticProps` can be accessed from within `metadata`. This becomes invaluable with policies
-that have multiple conditonals like the one above.
+that have multiple conditionals like the one above.
 
 ```json
   "policyStaticProps": {
@@ -466,11 +466,11 @@ The operation to apply within the params. Currently available:
 The value to be compared to. Can be a string, number or boolean.
 
 ### `ands`
-Array consistening of policies (with `policyType` and `policyStaticProps`
+Array consisting of policies (with `policyType` and `policyStaticProps`
 omitted)
 
 ### `ors`
-Array consistening of policies (with `policyType` and `policyStaticProps`
+Array consisting of policies (with `policyType` and `policyStaticProps`
 omitted)
 
 ### `metadata`

docs/walletkit/android/notifications/notify/overview.mdx

@@ -15,7 +15,7 @@ Coupled with the [AppKit Notifications](../../../../appkit/features/notification
 Some of the key features of the Notify API include:
 
 - **Push Notifications for Desktop and Native Platforms**: This feature enables dapps to directly send vital notifications to user wallets, ensuring timely and relevant communication.
-- **Robust Spam Protection**: Users have complete authority over which dapps can send them notifications, effectively eliminating any unsolicited messages from unknown sources. Furthermore, users can fine-tune their preferences to only receive notifications types they are interested in, like new features or some important events occurence.
+- **Robust Spam Protection**: Users have complete authority over which dapps can send them notifications, effectively eliminating any unsolicited messages from unknown sources. Furthermore, users can fine-tune their preferences to only receive notifications types they are interested in, like new features or some important events occurrence.
 - **Chain Agnostic Architecture**: The Notify API is built to be compatible with any blockchain, allowing seamless multi-chain support without the need for writing additional integration code. **As of November 2023, the Notify Server and Clients are equipped to support EVM chains. Plans to extend support to non-EVM chains are in progress and are a significant part of our upcoming development roadmap.**
 
 _Example integration_

docs/walletkit/android/notifications/notify/spam-protection.mdx

@@ -14,7 +14,7 @@ Once users have subscribed to their chosen apps, they have the option to define
 
 ### Rate limiting
 
-Apps are limited to a maximum number of notifications they’re able to send to their community. Specifically, apps may send accounts notifications twice an hour on average, but may exceeed that average in bursts of up to 50 at a time.
+Apps are limited to a maximum number of notifications they’re able to send to their community. Specifically, apps may send accounts notifications twice an hour on average, but may exceed that average in bursts of up to 50 at a time.
 
 ## Our continued pledge on spam protection