update terminologies

Author: yashovardhan

docs/features/mpc.mdx

@@ -40,8 +40,8 @@ read through [How Web3Auth Works](/how-web3auth-works) and
 
 In this setup, users are equipped with three factors for authentication and recovery:
 
-1. **OAuth Login Factor:** Managed across Web3Auth's Auth Network, accessible via OAuth providers
-   like Google.
+1. **OAuth Login Factor:** Managed across Web3Auth Network, accessible via OAuth providers like
+   Google.
 2. **Device Factor:** Stored securely on the user's device, often protected by device-specific
    security features such as biometrics.
 3. **Backup/ 2FA Factor:** Acts as a recovery share, stored separately or based on user's input with
@@ -79,7 +79,7 @@ Users employ OAuth logins, trusted devices, and other factors to manage their cr
 pairs. Importantly, the complete private keys are not stored anywhere within the Wallet
 Infrastructure system, including our databases or any participating nodes.
 
-To create a social login share, users interact with the Web3Auth Auth Network, where key generation
+To create a social login share, users interact with the Web3Auth Network, where key generation
 operates via a 5/9 consensus system. This setup guarantees that wallets remain non-custodial,
 ensuring that neither Web3Auth, Social Login Providers, nor any other party holding a key share can
 claim full ownership.

docs/how-web3auth-works.mdx

@@ -18,7 +18,7 @@ for each user and application.
 ## High-Level Architecture
 
 The Web3Auth SDK lives solely on the user/application's front-end client and handles the
-interactions between OAuth providers and the Auth Network.
+interactions between OAuth providers and the Web3Auth Network.
 
 The diagram below describes the relationship between the Web3Auth SDKs and integrating applications.
 It also depicts the difference between the products Web3Auth offers, to enable a developer-friendly
@@ -43,7 +43,7 @@ Users employ OAuth logins, trusted devices, and other factors to manage their cr
 pairs. Importantly, the complete private keys are not stored anywhere within the Wallet
 Infrastructure system, including our databases or any participating nodes.
 
-To create a social login share, users interact with the Web3Auth Auth Network, where key generation
+To create a social login share, users interact with the Web3Auth Network, where key generation
 operates via a 5/9 consensus system. This setup guarantees that wallets remain non-custodial,
 ensuring that neither Web3Auth, Social Login Providers, nor any other party holding a key share can
 claim full ownership.

docs/infrastructure/infrastructure.mdx

@@ -64,8 +64,8 @@ In a typical 2 out of 3 (2/3) setup, the user is provided with three factors: OA
 Device Factor, and Backup/ 2FA Factor. Please note that the threshold can increase for more
 security. It is dependent on the integrating application.
 
-- **OAuth Login Factor** is managed and divided across Web3Auth's Auth Network and can be accessed
-  through an OAuth login provider owned by the user, like their Google account.
+- **OAuth Login Factor** is managed and divided across Web3Auth Network and can be accessed through
+  an OAuth login provider owned by the user, like their Google account.
 - **Device Factor** is stored on the user's device. The method of storage is specific to the device
   and system. For instance, on mobile devices, the factor could be stored in device storage that's
   secured with biometrics.

docs/infrastructure/nodes-and-dkg.mdx

@@ -6,8 +6,8 @@ description: "DKG Nodes in Wallet Management | Documentation - Web3Auth"
 
 import CommonQuestions from "@site/src/components/CommonQuestions";
 
-The Web3Auth Auth Network Nodes run a Distributed Key Generation protocol amongst themselves to
-assign, store and return secrets/keys to users. In general within Auth Network, nodes manage a share
+The Web3Auth Network Nodes run a Distributed Key Generation protocol amongst themselves to assign,
+store and return secrets/keys to users. In general within Web3Auth Network, nodes manage a share
 retrieved via conventional OAuth flows.
 
 The architecture consists of four parts:‌
@@ -35,7 +35,7 @@ The client then assembles these shares and reconstructs the users key in the fro
 
 ### Initialization
 
-When a Auth Network Node is started, it tries to register its connection details on an Ethereum
+When a Web3Auth Network Node is started, it tries to register its connection details on an Ethereum
 smart contract. Once all nodes have been registered for that epoch, they try to connect with each
 other to set up the BFT network, and start generating distributed keys. They also listen for
 incoming information from nodes in the previous epoch.
@@ -163,7 +163,7 @@ unable to decrypt it.
 
 <CommonQuestions
   questions={[
-    "What are Web3Auth Auth Network Nodes and how do they work?",
+    "What are Web3Auth Network Nodes and how do they work?",
     "What is Distributed Key Generation (DKG) in Web3Auth?",
     "How does the node lifecycle work in Web3Auth?",
     "What are the trust assumptions for the Torus Network?",

docs/product/mpc-core-kit.mdx

@@ -20,8 +20,8 @@ Using the Web3Auth MPC Core Kit, you can authenticate users and generate signatu
 transactions through distributed key shares, without ever reconstructing the private key. The SDK
 uses a 2-of-3 threshold signature scheme where the key shares are distributed across:
 
-- **Auth Network Share:** Managed by Web3Auth's decentralized Auth Network and accessible through
-  OAuth providers like Google, providing a familiar authentication experience.
+- **Web3Auth Network Share:** Managed by Web3Auth Network and accessible through OAuth providers
+  like Google, providing a familiar authentication experience.
 
 - **Device Share:** Securely stored on the user's device, leveraging platform-specific security
   features like biometric authentication on mobile devices.

docs/product/sfa.mdx

@@ -29,7 +29,7 @@ The authentication flow is straightforward yet secure:
 1. Users click to login with their preferred method (social login, email, biometrics etc.), hosted
    by the application itself
 2. Web3Auth silently generates a wallet using Shamir's Secret Sharing
-3. The private key is split into shares, distributed across the Web3Auth Auth Network (using a 5/9
+3. The private key is split into shares, distributed across the Web3Auth Network (using a 5/9
    consensus mechanism) and derived from the user's identity after authentication.
 4. The complete wallet is reconstructed within your application environment
 

docs/sdk/gaming/unity/dapp-share.mdx

@@ -69,7 +69,7 @@ the login function.
 :::note
 
 One major thing to note here is that the `dappShare` is only available for custom verifiers and not
-in the standard Web3auth verifiers. This is done to make sure that an application only has access to
+in the standard Web3Auth verifiers. This is done to make sure that an application only has access to
 the corresponding share to the private key of their application's user. Hence, to use dApp Share,
 one has to use the custom authentication feature of Web3Auth. Also, the dApp Share is only returned
 to users who have enabled 2FA to their account.

docs/sdk/gaming/unity/initialize.mdx

@@ -92,7 +92,7 @@ arguments.
 | Parameter         | Description                                                                                                                                                          |
 | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `clientId`        | Your Web3Auth Client ID. You can get it from the Web3Auth [Dashboard](https://dashboard.web3auth.io/) under project details. It's a mandatory field of type `string` |
-| `network`         | Defines the Web3Auth network. It's a mandatory field of type Network.                                                                                                |
+| `network`         | Defines the Web3Auth Network. It's a mandatory field of type Network.                                                                                                |
 | `redirectUrl`     | URL that Web3Auth will redirect API responses upon successful authentication from browser. It's a mandatory field of type `Uri`.                                     |
 | `whiteLabel?`     | WhiteLabel options for web3auth. It helps you define custom UI, branding, and translations for your brand app. It takes `WhiteLabelData` as a value.                 |
 | `loginConfig?`    | Login config for the custom verifiers. It takes `Dictionary<string, LoginConfigItem>` as a value.                                                                    |

docs/sdk/gaming/unity/install.mdx

@@ -74,9 +74,9 @@ give you a reference on how your app's `redirect_url` should look like.
 
 :::
 
-### Add Web3auth Configuration Script to the scene
+### Add Web3Auth Configuration Script to the scene
 
-- Inside `Project > Assets > Plugins > Web3AuthSDK` there is a file called `Web3auth` that must be
+- Inside `Project > Assets > Plugins > Web3AuthSDK` there is a file called `Web3Auth` that must be
   dragged to the component in the scene. In our examples we are using a canvas. So you can now
   configure you clientId, rediretUrl and Network from the UI.
 

docs/sdk/gaming/unreal/initialize.mdx

@@ -41,7 +41,7 @@ arguments.
 | Parameter         | Description                                                                                                                                                          |
 | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `clientId`        | Your Web3Auth Client ID. You can get it from Web3Auth [Dashboard](https://dashboard.web3auth.io/) under project details. It's a mandatory field of type `FString`    |
-| `network`         | Defines the Web3Auth network. It's a mandatory field of type Network.                                                                                                |
+| `network`         | Defines the Web3Auth Network. It's a mandatory field of type Network.                                                                                                |
 | `redirectUrl`     | URL that Web3Auth will redirect API responses upon successful authentication from browser. It's a mandatory field of type `FString`.                                 |
 | `whiteLabel?`     | WhiteLabel options for web3auth. It helps you define custom UI, branding, and translations for your brand app. It takes `FWhiteLabelData` as a value.                |
 | `loginConfig?`    | Login config for the custom verifiers. It takes `TMap<FString, FLoginConfigItem>` as a value.                                                                        |