Update according to comments

Author: yashovardhan

docs/sdk/mpc-core-kit/mpc-core-kit-js/authentication/login-jwt.mdx

@@ -151,6 +151,15 @@ By default, the ed25519 key is formatted in base58 and is 64 bytes long. This co
 32 bytes as the seed (also known as the private key) and the last 32 bytes as the public key. Ensure
 that the first 32 bytes are provided in hexadecimal format when using the ed25519 seed.
 
+:::info ED25519 Seed
+
+The ed25519 seed is a 64-byte value, where the first 32 bytes represent the private key and the last
+32 bytes represent the public key. When using the ed25519 seed, ensure that the first 32 bytes
+(private key) are provided in hexadecimal format. For example, a sample ed25519 seed in hexadecimal
+format could be `0x1a2b3c4d5e6f7890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f6789`.
+
+:::
+
 ```tsx
 import { JWTLoginParams } from "@web3auth/mpc-core-kit";
 

docs/sdk/mpc-core-kit/mpc-core-kit-js/authentication/login-oauth.mdx

@@ -202,6 +202,15 @@ By default, the ed25519 key is formatted in base58 and is 64 bytes long. This co
 32 bytes as the seed (also known as the private key) and the last 32 bytes as the public key. Ensure
 that the first 32 bytes are provided in hexadecimal format when using the ed25519 seed.
 
+:::info ED25519 Seed
+
+The ed25519 seed is a 64-byte value, where the first 32 bytes represent the private key and the last
+32 bytes represent the public key. When using the ed25519 seed, ensure that the first 32 bytes
+(private key) are provided in hexadecimal format. For example, a sample ed25519 seed in hexadecimal
+format could be `0x1a2b3c4d5e6f7890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f6789`.
+
+:::
+
 ```tsx
 import { SubVerifierDetailsParams } from "@web3auth/mpc-core-kit";
 

docs/sdk/mpc-core-kit/mpc-core-kit-js/initialize.mdx

@@ -19,6 +19,13 @@ After installation, the next step to use Web3Auth MPC Core Kit is to configure &
 Please note that these are the most critical steps where you need to pass on different parameters
 according to the preference of your project.
 
+:::info
+
+Ensure that you configure your authentication method and verifier prior to initializing the SDK in
+your codebase. This will streamline the implementation process.
+
+:::
+
 ### Parameters
 
 The Web3AuthMPCCoreKit constructor takes an object with `Web3AuthOptions` as input which helps you

docs/sdk/mpc-core-kit/mpc-core-kit-js/install.mdx

@@ -18,6 +18,14 @@ flexibility to customize the UI and UX of the authentication process.
 npm install @web3auth/mpc-core-kit
 ```
 
+:::note
+
+If you were using the MPC Core Kit JS SDK in your react native application, you need to follow this
+[migration guide](/migration-guides/mpc-core-kit-react-native-migration) to migrate to the new MPC
+Core Kit React Native SDK.
+
+:::
+
 ## Common Types and Interfaces
 
 This package gives access to common types and interfaces for Web3Auth. This comes in handy by

docs/sdk/mpc-core-kit/mpc-core-kit-js/mpc-core-kit-js.mdx

@@ -11,9 +11,11 @@ Web3Auth's [`@web3auth/mpc-core-kit`](https://github.com/Web3Auth/mpc-core-kit)
 easy-to-use SDK, that helps you implement Web3Auth's MPC Threshold Signature Scheme (TSS) features
 in which the private key is never reconstructed.
 
-Compared to other Web3Auth SDKs, such as Plug and Play(PnP), and Single Factor Auth(SFA) SDKs where
-the private key is securely reconstructed on user's device, and is used to sign transactions. In the
-MPC TSS architecture, the private key is never reconstructed.
+Compared to other Web3Auth SDKs, such as Plug and Play (PnP) and Single Factor Auth (SFA) SDKs,
+where the private key is securely reconstructed on the user's device and used to sign transactions,
+the MPC TSS architecture ensures that the private key is never reconstructed for signing. However,
+the SDK provides options to export the private key if the user wants to use their account in other
+wallets. This approach eliminates vendor lock-in, unlike other MPC solutions.
 
 Instead, the partial key shares are stored at different locations which are used to generate the
 partial signatures. The final signature is generated combining the partial signatures using the TSS.
@@ -33,8 +35,8 @@ in a single location, the key is divided into multiple parts and distributed acr
 devices and our Auth Network. This means that the key is always available and never in danger of
 being compromised.
 
-The traditional Web3Auth SDK uses threshold signatures to dynamically reconstruct the key in the
-frontend. However, with the new Web3Auth MPC (Multi Party Computation) architecture, this is no
+The traditional Web3Auth SDK uses Shamir Secret Sharing (SSS) to dynamically reconstruct the key in
+the frontend. However, with the new Web3Auth MPC (Multi Party Computation) architecture, this is no
 longer necessary. Instead, partial keys are stored in different locations, and the user's device is
 used to make partial signatures for messages and transactions.
 
@@ -64,16 +66,6 @@ transactions on the blockchain. Let's understand each of these stages in detail.
 
 ## Types of Factors
 
-### Hashed Cloud Factor
-
-The MPC Core Kit SDK starts in a 2/2 flow by default. This means when user's logs in, a social login
-factor is generated and at the same time SDK will generate a hashed cloud factor. This hashed cloud
-factor is derived on the front end and stored in the encrypted metadata server. Please refer to the
-above architecture to understand more about factors.
-
-This is done to make sure the user can access their account from any device without having to
-generate a new factor. The hashed cloud factor is deleted when the user enables the MFA.
-
 ### Social Login Factor
 
 This is the primary way for a user to access their account. This step involves authentication of
@@ -85,6 +77,16 @@ When a user logs in, the Auth Network generates signatures corresponding to the
 nodes and returns them to the user's end. These signatures are then used alongside other shares to
 generate the final TSS Account signatures.
 
+### Hashed Cloud Factor
+
+The MPC Core Kit SDK starts in a 2/2 flow by default. This means when user's logs in, a social login
+factor is generated and at the same time SDK will generate a hashed cloud factor. This hashed cloud
+factor is derived on the front end and stored in the encrypted metadata server. Please refer to the
+above architecture to understand more about factors.
+
+This is done to make sure the user can access their account from any device without having to
+generate a new factor. The hashed cloud factor is deleted when the user enables the MFA.
+
 ### Device Factor (Factor Index: 2)
 
 This is the second factor used to access the user's account. This step involves the generation of a
@@ -106,12 +108,23 @@ backup factor of your choice like social recovery, Email OTP, SMS OTP, Authentic
 ## Threshold
 
 The threshold is the minimum number of shares required to generate a final signature for the TSS
-Account. This threshold, by default, is set to 3/5 on the Auth Network and 2/3 for the user's device
-front. This ensures high availability and ease of access on both ends alongside optimum security.
-Both these thresholds can be customized according to the requirements.
+Account. By default, the Auth Network requires 3 out of 5 shares (3/5) to generate a signature. This
+means that out of the 5 shares distributed across different nodes, any 3 shares can be combined to
+create the final signature. This setup ensures high availability and security, as it allows for some
+shares to be unavailable or compromised without affecting the overall system.
+
+On the user's device front, the default threshold is set to 2 out of 3 shares (2/3). This means that
+out of the 3 shares available on the user's device, any 2 shares can be used to generate the final
+signature. This setup provides a balance between security and ease of access, ensuring that the user
+can still access their account even if one share is unavailable.
+
+Only the user level threshold can can be customized according to the requirements. The Auth Network
+threshold is fixed at 3/5.
 
-Please note that when user logs in for the first time, the threshold is set to 2/2. The threshold is
-set to 2/3 after the user enables the MFA flow.
+Please note that when a user logs in for the first time, the threshold is set to 2 out of 2 shares
+(2/2). This means that both shares are required to generate the final signature. After the user
+enables the MFA flow, the threshold is set to 2 out of 3 shares (2/3), providing an additional layer
+of security.
 
 ## Components of a Factor
 
@@ -122,9 +135,10 @@ the user. These shares are generated using distributed key generation(DKG) and a
 Auth Network and the user's device. Since these shares are generated using MPC, they are **never
 reconstructed** and always stay decentralized and secure.
 
-However, we have exposed a function to reconstruct the TSS Key from the shares in the SDK. This
-function has been marked unsafe since there is no direct use case for it other than key exports in
-the case the user wants to own it completely.
+We've included a function in the SDK that lets you reconstruct the TSS Key from the shares. Just a
+heads-up, this function is marked as unsafe, so it's best to use it with extra layers of security.
+For example, only make this function available when MFA is enabled and ask the user to input their
+MFA share while exporting.
 
 ### Metadata Key & Shares
 

docs/sdk/mpc-core-kit/mpc-core-kit-react-native/authentication.mdx

@@ -169,6 +169,15 @@ By default, the ed25519 key is formatted in base58 and is 64 bytes long. This co
 32 bytes as the seed (also known as the private key) and the last 32 bytes as the public key. Ensure
 that the first 32 bytes are provided in hexadecimal format when using the ed25519 seed.
 
+:::info ED25519 Seed
+
+The ed25519 seed is a 64-byte value, where the first 32 bytes represent the private key and the last
+32 bytes represent the public key. When using the ed25519 seed, ensure that the first 32 bytes
+(private key) are provided in hexadecimal format. For example, a sample ed25519 seed in hexadecimal
+format could be `0x1a2b3c4d5e6f7890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f6789`.
+
+:::
+
 ```tsx
 const jwtLoginParams = {
   verifier: "YOUR_VERIFIER_NAME",

docs/sdk/mpc-core-kit/mpc-core-kit-react-native/initialize.mdx

@@ -15,6 +15,13 @@ After installation, the next step to use Web3Auth MPC Core Kit is to configure &
 2. [Configure Web3AuthMPCCoreKit instance](#configure-instance)
 3. [Initialize Web3AuthMPCCoreKit](#initialize-web3authmpccorekit)
 
+:::note
+
+Ensure that you configure your authentication method and verifier prior to initializing the SDK in
+your codebase. This will streamline the implementation process.
+
+:::
+
 ## Configure React Native Environment
 
 In order to make this SDK compatible with the React Native development environment, you need to
@@ -459,22 +466,16 @@ To initialize the instance, you need to call the `init` method. The method also
 
 <TabItem value="table">
 
-| Parameter              | Description                                                               |
-| ---------------------- | ------------------------------------------------------------------------- |
-| `handleRedirectResult` | Handles the redirect result during initialization. Default value is true. |
-| `rehydrate`            | Rehydrates the session during initialization. Default value is true.      |
+| Parameter   | Description                                                          |
+| ----------- | -------------------------------------------------------------------- |
+| `rehydrate` | Rehydrates the session during initialization. Default value is true. |
 
 </TabItem>
 
 <TabItem value="interface">
 
 ```typescript
 export interface InitParams {
-  /**
-   * @defaultValue `true`
-   * handle the redirect result during init()
-   */
-  handleRedirectResult: boolean;
   /**
    * @defaultValue `true`
    * rehydrate the session during init()

docs/sdk/mpc-core-kit/mpc-core-kit-react-native/install.mdx

@@ -21,6 +21,14 @@ flexibility to customize the UI and UX of the authentication process.
 npm install @web3auth/react-native-mpc-core-kit
 ```
 
+:::note
+
+If you were using the MPC Core Kit JS SDK in your react native application, you need to follow this
+[migration guide](/migration-guides/mpc-core-kit-react-native-migration) to migrate to the new MPC
+Core Kit React Native SDK.
+
+:::
+
 ## Common Types and Interfaces
 
 This package gives access to common types and interfaces for Web3Auth. This comes in handy by

docs/sdk/mpc-core-kit/mpc-core-kit-react-native/mpc-core-kit-react-native.mdx

@@ -12,9 +12,11 @@ Web3Auth's
 is simple and easy-to-use SDK for react native environment, that helps you implement Web3Auth's MPC
 Threshold Signature Scheme (TSS) features in which the private key is never reconstructed.
 
-Compared to other Web3Auth SDKs, such as Plug and Play(PnP), and Single Factor Auth(SFA) SDKs where
-the private key is securely reconstructed on user's device, and is used to sign transactions. In the
-MPC TSS architecture, the private key is never reconstructed.
+Compared to other Web3Auth SDKs, such as Plug and Play (PnP) and Single Factor Auth (SFA) SDKs,
+where the private key is securely reconstructed on the user's device and used to sign transactions,
+the MPC TSS architecture ensures that the private key is never reconstructed for signing. However,
+the SDK provides options to export the private key if the user wants to use their account in other
+wallets. This approach eliminates vendor lock-in, unlike other MPC solutions.
 
 Instead, the partial key shares are stored at different locations which are used to generate the
 partial signatures. The final signature is generated combining the partial signatures using the TSS.
@@ -34,8 +36,8 @@ in a single location, the key is divided into multiple parts and distributed acr
 devices and our Auth Network. This means that the key is always available and never in danger of
 being compromised.
 
-The traditional Web3Auth SDK uses threshold signatures to dynamically reconstruct the key in the
-frontend. However, with the new Web3Auth MPC (Multi Party Computation) architecture, this is no
+The traditional Web3Auth SDK uses Shamir Secret Sharing (SSS) to dynamically reconstruct the key in
+the frontend. However, with the new Web3Auth MPC (Multi Party Computation) architecture, this is no
 longer necessary. Instead, partial keys are stored in different locations, and the user's device is
 used to make partial signatures for messages and transactions.
 
@@ -65,16 +67,6 @@ transactions on the blockchain. Let's understand each of these stages in detail.
 
 ## Types of Factors
 
-### Hashed Cloud Factor
-
-The MPC Core Kit SDK starts in a 2/2 flow by default. This means when user's logs in, a social login
-factor is generated and at the same time SDK will generate a hashed cloud factor. This hashed cloud
-factor is derived on the front end and stored in the encrypted metadata server. Please refer to the
-above architecture to understand more about factors.
-
-This is done to make sure the user can access their account from any device without having to
-generate a new factor. The hashed cloud factor is deleted when the user enables the MFA.
-
 ### Social Login Factor
 
 This is the primary way for a user to access their account. This step involves authentication of
@@ -86,6 +78,16 @@ When a user logs in, the Auth Network generates signatures corresponding to the
 nodes and returns them to the user's end. These signatures are then used alongside other shares to
 generate the final TSS Account signatures.
 
+### Hashed Cloud Factor
+
+The MPC Core Kit SDK starts in a 2/2 flow by default. This means when user's logs in, a social login
+factor is generated and at the same time SDK will generate a hashed cloud factor. This hashed cloud
+factor is derived on the front end and stored in the encrypted metadata server. Please refer to the
+above architecture to understand more about factors.
+
+This is done to make sure the user can access their account from any device without having to
+generate a new factor. The hashed cloud factor is deleted when the user enables the MFA.
+
 ### Device Factor (Factor Index: 2)
 
 This is the second factor used to access the user's account. This step involves the generation of a
@@ -107,12 +109,23 @@ backup factor of your choice like social recovery, Email OTP, SMS OTP, Authentic
 ## Threshold
 
 The threshold is the minimum number of shares required to generate a final signature for the TSS
-Account. This threshold, by default, is set to 3/5 on the Auth Network and 2/3 for the user's device
-front. This ensures high availability and ease of access on both ends alongside optimum security.
-Both these thresholds can be customized according to the requirements.
+Account. By default, the Auth Network requires 3 out of 5 shares (3/5) to generate a signature. This
+means that out of the 5 shares distributed across different nodes, any 3 shares can be combined to
+create the final signature. This setup ensures high availability and security, as it allows for some
+shares to be unavailable or compromised without affecting the overall system.
+
+On the user's device front, the default threshold is set to 2 out of 3 shares (2/3). This means that
+out of the 3 shares available on the user's device, any 2 shares can be used to generate the final
+signature. This setup provides a balance between security and ease of access, ensuring that the user
+can still access their account even if one share is unavailable.
+
+Only the user level threshold can can be customized according to the requirements. The Auth Network
+threshold is fixed at 3/5.
 
-Please note that when user logs in for the first time, the threshold is set to 2/2. The threshold is
-set to 2/3 after the user enables the MFA flow.
+Please note that when a user logs in for the first time, the threshold is set to 2 out of 2 shares
+(2/2). This means that both shares are required to generate the final signature. After the user
+enables the MFA flow, the threshold is set to 2 out of 3 shares (2/3), providing an additional layer
+of security.
 
 ## Components of a Factor
 
@@ -123,9 +136,10 @@ the user. These shares are generated using distributed key generation(DKG) and a
 Auth Network and the user's device. Since these shares are generated using MPC, they are **never
 reconstructed** and always stay decentralized and secure.
 
-However, we have exposed a function to reconstruct the TSS Key from the shares in the SDK. This
-function has been marked unsafe since there is no direct use case for it other than key exports in
-the case the user wants to own it completely.
+We've included a function in the SDK that lets you reconstruct the TSS Key from the shares. Just a
+heads-up, this function is marked as unsafe, so it's best to use it with extra layers of security.
+For example, only make this function available when MFA is enabled and ask the user to input their
+MFA share while exporting.
 
 ### Metadata Key & Shares