remove all tkey mentions

Author: yashovardhan

docs/connect-blockchain/connect-blockchain.mdx

@@ -41,10 +41,10 @@ transactions, smart contract wallets, different elliptic curve pairs and even RS
 
 ## Private Key Providers (PnP & SFA)
 
-The Private Key Providers work with the majority of Web3Auth products, including Plug and Play SDKs,
-Single Factor Auth SDKs, and tKey SSS (v1) SDKs. As the name suggests these providers are a wrapper
-around the user's private key, which is dynamically reconstructed with Shamir's Secret Sharing and
-is present in the user's frontend.
+The Private Key Providers work with the majority of Web3Auth products, including Plug and Play SDKs
+and Single Factor Auth SDKs. As the name suggests these providers are a wrapper around the user's
+private key, which is dynamically reconstructed with Shamir's Secret Sharing and is present in the
+user's frontend.
 
 Once the authentication happens, the returned result from the Web3Auth network is taken up by the
 provider to give a common interface to interact with the blockchain of your choice. Currently,

docs/infrastructure/mpc-architecture.mdx

@@ -12,15 +12,11 @@ import TkeyMpcFlowDark from "@site/static/images/tkey-mpc-flow-dark.png";
 import TkeyMpcFlowLight from "@site/static/images/tkey-mpc-flow-light.png";
 
 This document provides an in-depth exploration of the technical architecture of the MPC-based SDKs,
-this includes the tKey MPC SDK and CoreKit MPC SDK (a rundown of our SDKs
-[here](/how-web3auth-works/)).
+this includes the MPC Core Kit SDKs.
 
 The only difference between the SSS-based SDKs and MPC SDKs are that during usage/login MPC SDKs do
 not reconstruct user private keys.
 
-While the tKey MPC SDK, supports multiple configurations like 2/n, 2/2 flows, this documentation,
-for simplicity, focuses on a 2/3 setup.
-
 ## Overview of Cryptographic and Blockchain Support (compatibility and implementations)
 
 Web3Auth supports most popular blockchains & elliptic curves out there. In particular, out of the
@@ -58,8 +54,8 @@ much more convienent. Notably, but non-exhaustively, Web3Auth supports:
 
 ## User Key Overview
 
-Web3Auth uses tKey MPC to manage user wallets in a distributed fashion, leveraging various factors
-or shares managed by users, including their devices, private inputs, backup locations, and cloud
+Web3Auth uses MPC to manage user wallets in a distributed fashion, leveraging various factors or
+shares managed by users, including their devices, private inputs, backup locations, and cloud
 service providers. As long as a user can access 2 out of n (2/n) of these shares, they can access
 their key. This distributedly secure key is called the $TSSKey$.
 
@@ -99,8 +95,7 @@ $z_1,z_2 \in \mathbb{Z}_q$.
 
 This key's storage process mirrors that of the TSSKey, with the primary difference being that the
 metadataKey is always reconstructed and used for encryption/decryption tasks. It's based on the
-fundamental Shamir’s Secret Sharing scheme and initially generated on the user's front-end. Readers
-can further reference tKey v1 flows used by the metadataKey in our SSS Infrastructure Documentation.
+fundamental Shamir’s Secret Sharing scheme and initially generated on the user's front-end.
 
 ## Other components
 

docs/infrastructure/sss-architecture.mdx

@@ -11,17 +11,13 @@ import KeyReconstructionFlow from "@site/static/images/key-reconstruction-sss-fl
 import SSSArchitectureFlow from "@site/static/images/sss-architecture-flow.png";
 
 This document provides an in-depth exploration of the technical architecture of the Shamir's Secret
-Sharing(SSS)-based SDKs, this includes the current Plug and Play SDKs, tKey SSS SDKs (a rundown of
-our SDKs [here](/how-web3auth-works/)).
+Sharing(SSS)-based SDKs, this includes the current Plug and Play & Single Factor Auth SDKs.
 
 Shamir's Secret Sharing is a base form of MPC that splits a secret into $n$ shares, of which
 threshold $t$ are required to reconstruct the secret. You maybe looking for the
 [MPC Architecture documentation](/infrastructure/mpc-architecture/) instead which does not require
 the key to be reconstructed on usage.
 
-While the tKey SSS SDK, supports multiple configurations like 2/n, 2/2 flows, or m/n flows, this
-documentation, for simplicity, focuses on a 2/3 setup.
-
 ## Components
 
 The accompanying image illustrates the typical flow of wallet management within the SSS

docs/product/sfa.mdx

@@ -4,8 +4,6 @@ sidebar_label: Single Factor Auth
 description: "Single Factor Auth | Documentation - Web3Auth"
 ---
 
-import TkeyIntroduction from "@site/src/common/docs/_tkey-intro.mdx";
-
 import SFAInfraDark from "@site/static/images/sfa-infra-dark.png";
 import SFAInfraLight from "@site/static/images/sfa-infra-light.png";
 import { SFACards } from "@site/src/components/SDKReferenceCards";

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

@@ -5,7 +5,7 @@ sidebar_label: "Log in with OAuth"
 description: "Web3Auth MPC Core Kit JS SDK - Log in with OAuth | Documentation - Web3Auth"
 ---
 
-import ServiceWorkerCode from "@site/src/common/sdk/infra/tkey/_sw-js.mdx";
+import ServiceWorkerCode from "@site/src/common/sdk/mpc-core-kit/_sw-js.mdx";
 
 import Tabs from "@theme/Tabs";
 import TabItem from "@theme/TabItem";
@@ -271,7 +271,7 @@ DOM with the parameters. These parameters are then used to log in the user with
 ### Service Worker
 
 A service worker is a script that is run by the browser. It does not have any direct relationship
-with the DOM and provides many out-of-the-box network-related features. Web3Auth Core Kit tKey SDK
+with the DOM and provides many out-of-the-box network-related features. Web3Auth MPC Core Kit SDK
 needs a service worker relative to `baseUrl` to capture the auth redirect at `redirectPathName`
 path.
 

docs/sdk/wallet-services/ChainConfigDropdown.js

@@ -85,14 +85,14 @@ Every product across the Web3Auth Stack has a different set of keys, owing to ho
 is set up and how the keys are generated. At large, we can consider 3 different sets of Web3Auth
 Products:
 
-- Core Kit: Includes Web3Auth SFA and tKey SDKs. Contain the base key generation logic according to
-  the verifier selected.
-- Plug and Play: Includes the Plug and Play SDKs across various platforms. The keys here are
-  generated from the Core Kit SDKs, however, the keys are different because of the subkey generation
-  logic. Keys here change according to the verifier and client ID selected.
-- Torus Wallet: It is a wallet built on top of our Core Kit SDK. It has a different set of keys
-  because it is an application integration Web3Auth and not directly related to any of our
-  infrastructure offerings.
+- Plug and Play SDKs: Includes the Plug and Play SDKs across various platforms. The accounts here
+  are generated from the Single Factor Auth SDKs, however, the keys are different because of the
+  subkey generation logic. Keys here change according to the verifier and client ID selected.
+
+- Single Factor Auth SDKs: Contain the base key generation logic according to the verifier selected.
+
+- MPC Core Kit SDKs: Includes the MPC Core Kit SDKs across various platforms. The accounts here are
+  generated using TSS (Threshold Signature Scheme) and are different from the other products.
 
 ### Migrating between SDKs
 
@@ -107,10 +107,7 @@ account. Please ensure you meet all the requirements for migrating between SDKs.
 
 :::
 
-#### Plug and Play to Core Kit Migration
-
-This is one of the most common migration paths. Usually, developers start with the Web3Auth Plug and
-Play for low engineering effort and then transition to Core Kit for a more customized integration.
+#### Plug and Play to Single Factor Auth Migration
 
 :::danger
 
@@ -143,21 +140,17 @@ subkey(PRIVATE_KEY.padStart(64, "0"), Buffer.from(CLIENT_ID, "base64"));
 
 :::info Pre-planning Migrations
 
-Ideally, we would recommend you use the products within the correct configuration to minimize the
-migration efforts. Ideally, using the Single Factor Auth SDK beforehand and then shifting to tKey
-SDK works best for most integrations, pre-planning your key requirements while using Plug and Play
-SDKs can be helpful.
-
-##### If you're looking to use Core Kit SDKs in the future, planning the use Plug and Play SDKs right now, make sure:
+If you're looking to use Single Factor Auth SDKs in the future, planning the use Plug and Play SDKs
+right now, make sure:
 
 - You're using Custom Authentication with your own login verifiers.
 - Set the `useCoreKitKey` flag to `true`
 
 :::
 
-#### Core Kit to Plug and Play Migration
+#### Single Factor Auth to Plug and Play Migration
 
 This migration typically occurs when developers want to leverage the prebuilt UI/UX of the Plug and
-Play SDKs for user MFA. Use the same verifier details from your Core Kit integration in the custom
-authentication feature of Plug and Play. Set the `useCoreKitKey` flag to `true` to use the same
-private key as the Core Kit SDKs.
+Play SDKs for user MFA. Use the same verifier details from your Single Factor Auth integration in
+the custom authentication feature of Plug and Play. Set the `useCoreKitKey` flag to `true` to use
+the same private key as the Single Factor Auth SDKs.

docs/troubleshooting/different-private-key.mdx

@@ -108,9 +108,7 @@ Some other errors could be found during `@web3auth/node-sdk` implementations:
 | `Error occurred while verifying params`     | Invalid parameter was passed.               |
 | `Duplicate token found`                     | An already used (JWT)`id_token` was passed. |
 
-## Web3Auth Core Kit tKey SDK (tKey)
-
-`@tkey/core`
+## Web3Auth Infrastructure Errors
 
 | Code   | Message                                                                                                         |
 | ------ | --------------------------------------------------------------------------------------------------------------- |