Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` ## What's Next? Onboard users via the [built-in plug-and-play login UI](../../onboard/react-nextjs/use-plug-play-auth/) or a [custom login UI](../../onboard/react-nextjs/custom-ui/). Use `AuthProvider`, the EIP-1193 provider offered by the SDK, to call supported JSON/RPC functions and [Web3 wallet operations](../../web3-ops/evm/) in the authenticated user's context. ## See also **'React/NextJS'** integration example: See `sample-auth-react` submodule in [SDK Example GitHub repository.](https://github.com/arcana-network/auth-examples) - [FAQ](../../../faq/faq-gen/) - [Troubleshooting Guide](../../../troubleshooting/) - [Arcana Auth SDK Errors](../../auth-error-msg/) - [Arcana Auth SDK Usage Guide](../../auth-usage-guide/) Arcana Auth SDK Quick Links - [Arcana Auth SDK Reference](https://authsdk-ref-guide.netlify.app/) - [Release notes](../../../relnotes/latest-auth-release-note/) - [Changelog](https://github.com/arcana-network/auth/releases) - [Download SDK](https://www.npmjs.com/package/@arcana/auth) [Try Demo App](https://demo.arcana.network) # Integrate Solana App Integrate 'Solana' apps with [Arcana Auth SDK](../../../concepts/authsdk/) and onboard users via [social login](../../../concepts/social-login/). Enable users to sign blockchain transactions with the in-app [Arcana wallet](../../../concepts/anwallet/). ## Prerequisites - [Register](../../../setup/config-dApp-with-db-for-Solana/) the 'Solana' app and configure Arcana Auth SDK SDK usage [settings for social login](../../../setup/) providers, manage app [manage app chains](../../../setup/config-wallet-chains/) and [wallet user experience](../../../setup/config-wallet/). Non-EVM Chains When registering an app through Arcana Developer Dashboard, the choice of chain type (EVM, Solana, MultiversX, Near) is final. App developers can't change it later. They can switch the default chain within the same type. For example, a Solana app on Testnet can switch to Solana Mainnet or Solana Dev but not to MultiversX or an EVM chain. ## Steps Select your 'Solana' app type and follow the integration instructions. Solana apps will require to initialize and use **Solana Provider** in addition to the `AuthProvider`. ## 1. Install Depending upon the [app type](../../../web3-stack/apps/), you may need to [install one or more Arcana Auth SDK SDK flavors](../../sdk-installation/) and the integration steps may vary. ### 2. Integrate App Select your 'Solana' app type and follow the integration instructions. [HTML/CSS/JS App](../vanilla-html-css-js/) [React/Next.js App](../react-nextjs/) [Wagmi App](../wagmi/) [WalletConnect App](../walletconnect/) [RainbowKit App](../rainbow/) [Web3-React App](../web3-react/) [Unity App](../unity/) [Flutter Apps](../../mobile/flutter-get-started/) [React-Native Apps](../../mobile/react-native-get-started/) [Custom Auth](../../custom-auth/) ## 3. Initialize Solana Provider Solana apps can use the `auth.provider` to make standard JSON RPC calls in the context of an authenticated user. ``` const provider = auth.provider; ``` Use the Solana provider for issuing Solana Web3 wallet operations in the context of an authenticated user. ``` const solanaP = auth.solana; ``` ## What's Next? Add code to [onboard users](../../onboard/solana/). Use `AuthProvider`, the standard EIP-1193 Web3 provider to call support JSON/RPC functions and Web3 wallet operations. [Learn more...](../../web3-ops/solana/) ## See also **'Solana'** integration example: See `sample-auth-solana` submodule in [SDK Example GitHub repository.](https://github.com/arcana-network/auth-examples) - [Solana FAQ](../../../faq/faq-solana/) [Try Demo App](https://demo.arcana.network) # Integrate Unity App Integrate 'Unity' apps with [Arcana Auth SDK](../../../concepts/authsdk/) and onboard users via [social login](../../../concepts/social-login/). Enable users to sign blockchain transactions with the in-app [Arcana wallet](../../../concepts/anwallet/). ## Prerequisites - [Register](../../../setup/config-dApp-with-db-for-Unity/) the 'Unity' app and configure SDK usage [settings for social login](../../../setup/) providers, manage app [manage app chains](../../../setup/config-wallet-chains/) and [wallet user experience](../../../setup/config-wallet/). Non-EVM Chains When registering an app through Arcana Developer Dashboard, the choice of chain type (EVM, Solana, MultiversX, Near) is final. App developers can't change it later. They can switch the default chain within the same type. For example, a Solana app on Testnet can switch to Solana Mainnet or Solana Dev but not to MultiversX or an EVM chain. ## Steps ### 1. Setup #### Setup Unity - Install [NuGetForUnity](https://github.com/GlitchEnzo/NuGetForUnity). - In the NuGet Toolbar at the top, click **NuGet > Manage NuGet packages**. Manage NuGet Packages - Install the following packages by STA: `Nethereum.Web3`, `WebsocketSharp.Core` - Use the Unity Editor Project Settings window to edit package settings for your project. Click **Edit > Project Settings > Package Manager**. - [Edit Project Settings](https://docs.unity3d.com/Manual/class-PackageManager.html) with URL **https://npm-registry.arcana.network/** and set the scope to `com.cysharp.unitask, dev.voltstro` Edit Project Settings - Add another new scoped registry with URL **https://unitynuget-registry.azurewebsites.net** and set the scope to `org.nuget`. Add Scoped Registry - In the NuGet window, use the NuGet Toolbar at the top, and click **Window > Package Manager > Add Package by Name**. Add Package by Name - Add the following packages: `com.cysharp.unitask`, \`\`dev.voltstro.unitywebbrowser.engine.cef\` - **Windows**: `dev.voltstro.unitywebbrowser.engine.cef.win.x64` - **Linux**: `dev.voltstro.unitywebbrowser.engine.cef.linux.x64` - **MacOS**: `dev.voltstro.unitywebbrowser.engine.cef.macos.x64` See [Unity Web Browser package list](https://projects.voltstro.dev/UnityWebBrowser/latest/articles/user/packages/#package-list) for details. - Download the Arcana Auth Unity SDK package: [https://npm-registry.arcana.network/](https://npm-registry.arcana.network/-/web/detail/arcana-auth-sdk). Unzip the contents and copy them to the **Assets** folder of the Unity Project. - Search for **ArcanaSDK** prefab in the 'Project Window' of the Unity Editor. Click **Assets > ArcanaSDK > Prefabs > ArcanaSDK**. Drag this prefab into the project 'Hierarchy' and configure the prefab as shown here: Configure Arcana Prefab #### Install Auth SDK ``` npm install --save @arcana/auth ``` ``` yarn add @arcana/auth ``` ### 2. Initialize Auth SDK ``` using ArcanaSDK; await arcanaSDK.InitializeSDK(env, "unique_clientID_for_registed_app"); ``` ## What's Next? After integrating an app with the Arcana Auth Unity SDK, developers can add code to [onboard users](../../onboard/unity/) and [enable Web3 wallet operations](../../web3-ops/unity-wallet-ops/) for authenticated users to sign transactions. ## See also **'Unity'** integration example: See `sample-auth-unity` submodule in [SDK Example GitHub repository.](https://github.com/arcana-network/auth-examples) [Try Demo App](https://demo.arcana.network) # Integrate HTML/CSS/JS App Integrate 'HTML/CSS/JS' apps with[Arcana Auth SDK](../../../concepts/authsdk/) and onboard users via [social login](../../../concepts/social-login/). Enable users to sign blockchain transactions with the in-app [Arcana wallet](../../../concepts/anwallet/). ## Prerequisites - [Register](../../../setup/config-auth/register-app/) the 'HTML/CSS/JS' app and configure SDK usage [settings for social login](../../../setup/) providers, manage app [manage app chains](../../../setup/config-wallet-chains/) and [wallet user experience](../../../setup/config-wallet/). Non-EVM Chains When registering an app through Arcana Developer Dashboard, the choice of chain type (EVM, Solana, MultiversX, Near) is final. App developers can't change it later. They can switch the default chain within the same type. For example, a Solana app on Testnet can switch to Solana Mainnet or Solana Dev but not to MultiversX or an EVM chain. ## Steps ### 1. Install ``` npm install --save @arcana/auth ``` ``` yarn add @arcana/auth ``` ### 2. Initialize `AuthProvider` ``` import { AuthProvider } from '@arcana/auth' ``` ``` const auth = new AuthProvider( "xar_test_445007f942xxxxxxxxxxxxxxxxxx484cAfd2", // App client ID { alwaysVisible: false, // default: true, wallet always visible connectOptions: { compact: true // default: false, regular plug-and-play login UI }, position: 'left', // default: right setWindowProvider: true, // default: false, window.ethereum not set theme: 'light', // default: dark }) ``` Initialize First! After creating the `AuthProvider`, wait until the `init` call is complete before invoking any of the other SDK functions. ``` try { await auth.init() } catch (e) { // Handle exception case } ``` `AuthProvider` Optional Parameters Besides Client ID input parameter, you can optionally customize these settings in the `AuthProvider` constructor: ______________________________________________________________________ **`position`:** wallet position within the app context - `left`|`right` **`theme`:** wallet theme - `light`|`dark` **`connectOptions`:** [compact mode](../../../concepts/plug-and-play-auth/#compact-modal) for the built-in plug-and-play login UI - `true`|`false` ``` connectOptions: { compact: true // default - false }, ``` ______________________________________________________________________ See [`AuthProvider` constructor parameters](https://authsdk-ref-guide.netlify.app/interfaces/constructorparams) for details. The 'HTML/CSS/JS' Web3 app is now **integrated** with the Arcana Auth SDK. ## What's Next? Onboard users via the [built-in plug-and-play login UI](../../onboard/vanilla/use-plug-play-auth/) or a [custom login UI](../../onboard/vanilla/custom-ui/). Use `AuthProvider`, the EIP-1193 provider offered by the SDK, to call supported JSON/RPC functions and [Web3 wallet operations](../../web3-ops/evm/) in the authenticated user's context. ## See also **'HTML/CSS/JS'** integration example: See `sample-auth-html-css-js` submodule in [SDK Example GitHub repository.](https://github.com/arcana-network/auth-examples) - [FAQ](../../../faq/faq-gen/) - [Troubleshooting Guide](../../../troubleshooting/) - [Arcana Auth SDK Errors](../../auth-error-msg/) - [Arcana Auth SDK Usage Guide](../../auth-usage-guide/) Arcana Auth SDK Quick Links - [Arcana Auth SDK Reference](https://authsdk-ref-guide.netlify.app/) - [Release notes](../../../relnotes/latest-auth-release-note/) - [Changelog](https://github.com/arcana-network/auth/releases) - [Download SDK](https://www.npmjs.com/package/@arcana/auth) [Try Demo App](https://demo.arcana.network) # Integrate Vue App Integrate 'Vue' apps with[Arcana Auth SDK](../../../concepts/authsdk/) and onboard users via [social login](../../../concepts/social-login/). Enable users to sign blockchain transactions with the in-app [Arcana wallet](../../../concepts/anwallet/). ## Prerequisites - [Register](../../../setup/config-auth/register-app/) the 'Vue' app and configure SDK usage [settings for social login](../../../setup/) providers, manage app [manage app chains](../../../setup/config-wallet-chains/) and [wallet user experience](../../../setup/config-wallet/). Non-EVM Chains When registering an app through Arcana Developer Dashboard, the choice of chain type (EVM, Solana, MultiversX, Near) is final. App developers can't change it later. They can switch the default chain within the same type. For example, a Solana app on Testnet can switch to Solana Mainnet or Solana Dev but not to MultiversX or an EVM chain. ## Steps ### 1. Install ``` npm install --save @arcana/auth ``` ``` yarn add @arcana/auth ``` ### 2. Initialize `AuthProvider` ``` import { AuthProvider } from "@arcana/auth"; let authInstance; //Mainnet ClientId const clientId = "xar_live_d7c88d9b033d100e4200d21a5c4897b896e60063"; if (authInstance == null) { authInstance = new AuthProvider(clientId); await authInstance.init(); } // Use authInstance for user onboarding, JSON/RPC and wallet ops ``` `AuthProvider` Optional Parameters Besides Client ID input parameter, you can optionally customize these settings in the `AuthProvider` constructor: ______________________________________________________________________ **`position`:** wallet position within the app context - `left`|`right` **`theme`:** wallet theme - `light`|`dark` **`connectOptions`:** [compact mode](../../../concepts/plug-and-play-auth/#compact-modal) for the built-in plug-and-play login UI - `true`|`false` ``` connectOptions: { compact: true // default - false }, ``` ______________________________________________________________________ See [`AuthProvider` constructor parameters](https://authsdk-ref-guide.netlify.app/interfaces/constructorparams) for details. The 'Vue' Web3 app is now **integrated** with the Arcana Auth SDK. ## What's Next? Onboard users via the [built-in plug-and-play login UI](../../onboard/vue/use-plug-play-auth/) or a [custom login UI](../../onboard/vanilla/custom-ui/). Use `AuthProvider`, the EIP-1193 provider offered by the SDK, to call supported JSON/RPC functions and [Web3 wallet operations](../../web3-ops/evm/) in the authenticated user's context. ## See also **'Vue'** integration example: See `sample-auth-vue` submodule in [SDK Example GitHub repository.](https://github.com/arcana-network/auth-examples) - [FAQ](../../../faq/faq-gen/) - [Troubleshooting Guide](../../../troubleshooting/) - [Arcana Auth SDK Errors](../../auth-error-msg/) - [Arcana Auth SDK Usage Guide](../../auth-usage-guide/) Arcana Auth SDK Quick Links - [Arcana Auth SDK Reference](https://authsdk-ref-guide.netlify.app/) - [Release notes](../../../relnotes/latest-auth-release-note/) - [Changelog](https://github.com/arcana-network/auth/releases) - [Download SDK](https://www.npmjs.com/package/@arcana/auth) [Try Demo App](https://demo.arcana.network) # Integrate Wagmi App [Wagmi](https://wagmi.sh/) is a React Hooks library for Ethereum that simplifies connecting Web3 apps to multiple wallets and chains. Integrate 'Wagmi' apps with Arcana Auth SDK and onboard users via [social login](../../../concepts/social-login/). Enable users to sign blockchain transactions with the in-app [Arcana wallet](../../../concepts/anwallet/). ## Prerequisites - [Register](../../../setup/config-auth/register-app/) the 'Wagmi' app and configure SDK usage [settings for social login](../../../setup/) providers, manage app [manage app chains](../../../setup/config-wallet-chains/) and [wallet user experience](../../../setup/config-wallet/). Non-EVM Chains When registering an app through Arcana Developer Dashboard, the choice of chain type (EVM, Solana, MultiversX, Near) is final. App developers can't change it later. They can switch the default chain within the same type. For example, a Solana app on Testnet can switch to Solana Mainnet or Solana Dev but not to MultiversX or an EVM chain. ## Steps ### 1. Install **Wagmi 2.0** ``` npm install --save @arcana/auth-wagmi@3.0.0 @arcana/auth@1.0.12 ``` **Wagmi 1.0** ``` npm install --save @arcana/auth-wagmi@2.0.0 @arcana/auth ``` **Wagmi 2.0** ``` yarn add @arcana/auth-wagmi@3.0.0 @arcana/auth@1.0.12 ``` **Wagmi 1.0** ``` yarn add @arcana/auth-wagmi@2.0.0 @arcana/auth ``` ### 2. Create `AuthProvider` & `ArcanaConnector` Specify the **Client ID** assigned to the registered app to create the `AuthProvider`. Then use the `AuthProvider` to create `ArcanaConnector`. ``` import { AuthProvider } from "@arcana/auth"; import { ArcanaConnector } from "@arcana/auth-wagmi" const auth = new AuthProvider('your-client-id'); const connector = new ArcanaConnector({ auth }); ``` `AuthProvider` Optional Parameters Besides Client ID input parameter, you can optionally customize these settings in the `AuthProvider` constructor: ______________________________________________________________________ **`position`:** wallet position within the app context - `left`|`right` **`theme`:** wallet theme - `light`|`dark` **`connectOptions`:** [compact mode](../../../concepts/plug-and-play-auth/#compact-modal) for the built-in plug-and-play login UI - `true`|`false` ``` connectOptions: { compact: true // default - false }, ``` ______________________________________________________________________ See [`AuthProvider` constructor parameters](https://authsdk-ref-guide.netlify.app/interfaces/constructorparams) for details. Compact Mode While creating the `AuthProvider`, you can choose the [compact mode (optional)](../../../concepts/plug-and-play-auth/#compact-modal) for the plug-and-play login UI. ### 3. Setup `WagmiConfig` Create Wagmi config and specify the `ArcanaConnector`. ``` import { http, createConfig } from 'wagmi' import { mainnet, sepolia } from 'wagmi/chains' import { coinbaseWallet, injected, walletConnect } from 'wagmi/connectors' import { AuthProvider } from '@arcana/auth'; import { ArcanaConnector } from "@arcana/auth-wagmi" let auth: AuthProvider | null; if (!auth) { auth = new AuthProvider( "xar_dev_c2fb7be163754e57d384e24257ea2c8d2a5dd31a" ); } export const connector = () => { return new ArcanaConnector({auth,}) }; export const config = createConfig({ chains: [mainnet, sepolia], connectors: [ injected(), coinbaseWallet({ appName: 'Create Wagmi' }), walletConnect({ projectId: import.meta.env.VITE_WC_PROJECT_ID }), connector(), ], transports: { [mainnet.id]: http(), [sepolia.id]: http(), }, }) declare module 'wagmi' { interface Register { config: typeof config } } ``` ``` // Note: // This sample code is for // wagmi versions 1.x.y and auth-wagmi 2.a.b import { configureChains, createConfig, WagmiConfig } from "wagmi"; import { publicProvider } from "wagmi/providers/public"; import { ArcanaConnector } from "@arcana/auth-wagmi"; import { polygon, polygonAmoy } from "wagmi/chains"; import { newAuthProvider } from "./utils/newArcanaAuth"; import { useAccount, useConnect, useDisconnect, useBalance } from 'wagmi' import "../styles/globals.css"; const { chains, provider, webSocketProvider } = configureChains( [mainnet, polygon, polygonAmoy], [publicProvider()], { targetQuorum: 1 } ); export const connector = (chains: Chain[]) => { return new ArcanaConnector({ chains, options: { auth: newAuthProvider(), login: { provider: "google", }, }, }); }; const { chains, publicClient } = configureChains( [polygon, polygonAmoy], [publicProvider()] ); export const wagmiEntity = createConfig({ autoConnect: true, connectors: [connector(chains)], publicClient, }); ... ``` The 'Wagmi' Web3 app is now **integrated** with the Arcana Auth SDK. ## What's Next? Onboard users via the [built-in plug-and-play login UI](../../onboard/wagmi/wagmi-pnp-ui/) or a [custom login UI](../../onboard/wagmi/wagmi-custom-ui/). Use `AuthProvider`, the EIP-1193 provider offered by the SDK, to call supported JSON/RPC functions and [Web3 wallet operations](../../web3-ops/evm/) in the authenticated user's context. ## See also **'Wagmi'** integration example: See `sample-auth-wagmi-2`, `sample-auth-wagmi-viem`, `sample-auth-wagmi` submodule in [SDK Example GitHub repository.](https://github.com/arcana-network/auth-examples) - [FAQ](../../../faq/faq-gen/) - [Troubleshooting Guide](../../../troubleshooting/) - [Arcana Auth SDK Errors](../../auth-error-msg/) - [Arcana Auth SDK Usage Guide](../../auth-usage-guide/) Arcana Auth SDK Quick Links - [Arcana Auth SDK Reference](https://authsdk-ref-guide.netlify.app/) - [Release notes](../../../relnotes/latest-auth-release-note/) - [Changelog](https://github.com/arcana-network/auth/releases) - [Download SDK](https://www.npmjs.com/package/@arcana/auth) Arcana Auth Wagmi SDK Quick Links - [Arcana Auth Wagmi SDK Reference Guide](https://wagmi-authsdk-ref-guide.netlify.app/) - [Release notes](../../../relnotes/latest-auth-release-note/) - [Changelog](https://github.com/arcana-network/auth-wagmi/releases) - [Download SDK](https://www.npmjs.com/package/@arcana/auth-wagmi) [Try Demo App](https://demo.arcana.network) # Integrate WalletConnect App [WalletConnect](https://walletconnect.com/) allows Web3 app users to seamlessly switch between multiple connected wallets within a dApp. Integrate 'WalletConnect' apps with Arcana Auth SDK and onboard users via [social login](../../../concepts/social-login/). Enable users to sign blockchain transactions with the in-app [Arcana wallet](../../../concepts/anwallet/). ## Prerequisites - [Register](../../../setup/config-auth/register-app/) the 'WalletConnect' app and configure SDK usage [settings for social login](../../../setup/) providers, manage app [manage app chains](../../../setup/config-wallet-chains/) and [wallet user experience](../../../setup/config-wallet/). Non-EVM Chains When registering an app through Arcana Developer Dashboard, the choice of chain type (EVM, Solana, MultiversX, Near) is final. App developers can't change it later. They can switch the default chain within the same type. For example, a Solana app on Testnet can switch to Solana Mainnet or Solana Dev but not to MultiversX or an EVM chain. ## Steps ### 1. Install **Wagmi 2.0** ``` npm install --save @arcana/auth-wagmi@3.0.0 @arcana/auth@1.0.12 ``` **Wagmi 1.0** ``` npm install --save @arcana/auth-wagmi@2.0.0 @arcana/auth ``` **Wagmi 2.0** ``` yarn add @arcana/auth-wagmi@3.0.0 @arcana/auth@1.0.12 ``` **Wagmi 1.0** ``` yarn add @arcana/auth-wagmi@2.0.0 @arcana/auth ``` ### 2. Create `AuthProvider` & `ArcanaConnector` ``` // Set up Arcana Auth import { AuthProvider } from "@arcana/auth"; let auth: AuthProvider | null; const getAuthProvider = () => { if (!auth) { auth = new AuthProvider( "xar_test_b2dde12aad64eb35d72b2c80926338e178b1fa3f" ); } return auth; }; export { getAuthProvider }; ``` Initialize First! After creating the `AuthProvider`, wait until the `init` call is complete before invoking any of the other SDK functions. ``` try { await auth.init() } catch (e) { // Handle exception case } ``` ``` //This example uses Arcana Wallet connector and Coinbase Wallet import { http, createConfig } from 'wagmi' import { mainnet, sepolia } from 'wagmi/chains' import { coinbaseWallet, injected, walletConnect } from 'wagmi/connectors' import { ArcanaConnector } from "@arcana/auth-wagmi"; import { getAuthProvider } from './arcanaConnector'; export const config = createConfig({ chains: [mainnet, sepolia], connectors: [ injected(), coinbaseWallet({ appName: 'Create Wagmi' }), walletConnect({ projectId: '3fcc6bba6f1de962d911bb5b5c3dba68', //WalletConnect ProjectID }), ArcanaConnector( { auth: getAuthProvider(), } ) ], transports: { [mainnet.id]: http(), [sepolia.id]: http(), }, }) declare module 'wagmi' { interface Register { config: typeof config } } ``` `AuthProvider` Optional Parameters Besides Client ID input parameter, you can optionally customize these settings in the `AuthProvider` constructor: ______________________________________________________________________ **`position`:** wallet position within the app context - `left`|`right` **`theme`:** wallet theme - `light`|`dark` **`connectOptions`:** [compact mode](../../../concepts/plug-and-play-auth/#compact-modal) for the built-in plug-and-play login UI - `true`|`false` ``` connectOptions: { compact: true // default - false }, ``` ______________________________________________________________________ See [`AuthProvider` constructor parameters](https://authsdk-ref-guide.netlify.app/interfaces/constructorparams) for details. ### 3. Set up `WagmiProvider` Create Wagmi config and specify the `ArcanaConnector`. ``` //Use "`auth-wagmi` version > v2.0.0" import { QueryClient, QueryClientProvider } from '@tanstack/react-query' import { Buffer } from 'buffer' import React from 'react' import ReactDOM from 'react-dom/client' import { WagmiProvider } from 'wagmi' import App from './App.tsx' import { config } from './wagmi.ts' import './index.css' globalThis.Buffer = Buffer const queryClient = new QueryClient() ReactDOM.createRoot(document.getElementById('root')!).render(Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` The figure below shows the built-in login UI plug-and-play pop-up authentication screen for a test app. Plug-and-play Login UI Compact Mode While creating the `AuthProvider`, use `connectoOptions` to optionally choose the [compact mode](../../../../concepts/plug-and-play-auth/#compact-modal) for the plug-and-play login UI. ``` connectOptions: { compact: true // default - false }, ``` Login UI Options No plug-and-play support for Firebase authentication. The [plug and play feature](../../../../concepts/plug-and-play-auth/) of the Arcana Auth SDK does not support social login via Firebase. Developers must build a custom login UI and add code to onboard users. For details, see [onboarding users via Firebase and custom login UI](../custom-ui/build-idm/firebase-login/) No plug-and-play support for Telegram authentication. The [plug and play feature](../../../../concepts/plug-and-play-auth/) of the Arcana Auth SDK does not support social login via Telegram. Developers must build a custom login UI and add code to onboard users. For details, see \[\[{{ no such element: dict object['telegram_custom_ui_tag'] }}|onboarding users via Telegram and custom login UI\]\]. ## What's Next? Use `AuthProvider`, the EIP-1193 provider offered by the SDK, to call supported JSON/RPC functions and [Web3 wallet operations](../../../web3-ops/evm/) in the authenticated user's context. ## See also **'React/Next.js'** integration example: See `sample-auth-react`,`sample-auth-nextjs` submodule in [SDK Example GitHub repository.](https://github.com/arcana-network/auth-examples) - [FAQ](../../../../faq/faq-gen/) - [Troubleshooting Guide](../../../../troubleshooting/) - [Arcana Auth SDK Errors](../../../auth-error-msg/) Arcana Auth SDK Quick Links - [Arcana Auth SDK Reference](https://authsdk-ref-guide.netlify.app/) - [Release notes](../../../../relnotes/latest-auth-release-note/) - [Changelog](https://github.com/arcana-network/auth/releases) - [Download SDK](https://www.npmjs.com/package/@arcana/auth) Arcana Auth Wagmi SDK Quick Links - [Arcana Auth Wagmi SDK Reference Guide](https://wagmi-authsdk-ref-guide.netlify.app/) - [Release notes](../../../../relnotes/latest-auth-release-note/) - [Changelog](https://github.com/arcana-network/auth-wagmi/releases) - [Download SDK](https://www.npmjs.com/package/@arcana/auth-wagmi) [Try Demo App](https://demo.arcana.network) # Custom Login UI [Enable Passwordless Auth](build-pwdless-auth/) [Social Login Providers](build-social/) [IAM Providers](build-idm/) # Build Passwordless Auth Learn how React/Next.js app can use custom login UI and allow users to onboard via passwordless login option. ## Prerequisites - Make sure you can access the Arcana Developer Dashboard:Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` **That is all.** The React/Next.js app is all set for onboarding users via Cognito. Arcana JWT Token Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/jwt-token-validation/) and subsequently generate another token for app use if required. In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user. Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/an-did-token/#verify-did-token) and subsequently generate another token for app use. ## What's Next? Authenticated users can instantly access the in-app Arcana wallet UI for signing blockchain transactions. Use the `AuthProvider` EIP-1193 standard Ethereum provider to call JSON/RPC functions and Web3 wallet operations in the app. [Learn more...](../../../../../web3-ops/evm/) ## See also - [Authentication Types](../../../../../../concepts/authtype/). - [Arcana Auth React SDK Reference Guide](https://auth-react-sdk-ref-guide.netlify.app/) - [Handling authentication errors](../../../../../auth-error-msg/) - [Auth Examples](https://github.com/arcana-network/auth-examples) # User Login with Firebase In this guide, you will learn how a React/Next.js app integrated with the Arcana Auth SDK and Firebase SDK can onboard users via custom login UI and Firebase as the authentication provider. ## Prerequisites - Make sure you can access the Arcana Developer Dashboard:Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` **That is all.** The React/Next.js app is all set for onboarding users via Apple. Arcana JWT Token Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/jwt-token-validation/) and subsequently generate another token for app use if required. In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user. Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/an-did-token/#verify-did-token) and subsequently generate another token for app use. ## What's Next? Authenticated users can instantly access the in-app Arcana wallet UI for signing blockchain transactions. Use the `AuthProvider` EIP-1193 standard Ethereum provider to call JSON/RPC functions and Web3 wallet operations in the app. [Learn more...](../../../../../web3-ops/evm/) ## See also - [Authentication Types](../../../../../../concepts/authtype/). - [Arcana Auth React SDK Reference Guide](https://auth-react-sdk-ref-guide.netlify.app/) - [Handling authentication errors](../../../../../auth-error-msg/) - [Auth Examples](https://github.com/arcana-network/auth-examples) # User Login with Discord In this guide, you will learn how a React/Next.js app integrated with the Arcana Auth SDK and Arcana Auth React SDK can onboard users with a custom login UI through Discord authentication. ## Prerequisites - Make sure you can access the Arcana Developer Dashboard:Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` **That is all.** The React/Next.js app is all set for onboarding users via Discord. Arcana JWT Token Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/jwt-token-validation/) and subsequently generate another token for app use if required. In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user. Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/an-did-token/#verify-did-token) and subsequently generate another token for app use. ## What's Next? Authenticated users can instantly access the in-app Arcana wallet UI for signing blockchain transactions. Use the `AuthProvider` EIP-1193 standard Ethereum provider to call JSON/RPC functions and Web3 wallet operations in the app. [Learn more...](../../../../../web3-ops/evm/) ## See also - [Authentication Types](../../../../../../concepts/authtype/). - [Arcana Auth React SDK Reference Guide](https://auth-react-sdk-ref-guide.netlify.app/) - [Handling authentication errors](../../../../../auth-error-msg/) - [Auth Examples](https://github.com/arcana-network/auth-examples) # User Login with GitHub In this guide, you will learn how a React/Next.js app integrated with the Arcana Auth SDK and Arcana Auth React SDK can onboard users with a custom login UI through GitHub authentication. ## Prerequisites - Make sure you can access the Arcana Developer Dashboard:Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` **That is all.** The React/Next.js app is all set for onboarding users via GitHub. Arcana JWT Token Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/jwt-token-validation/) and subsequently generate another token for app use if required. In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user. Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/an-did-token/#verify-did-token) and subsequently generate another token for app use. ## What's Next? Authenticated users can instantly access the in-app Arcana wallet UI for signing blockchain transactions. Use the `AuthProvider` EIP-1193 standard Ethereum provider to call JSON/RPC functions and Web3 wallet operations in the app. [Learn more...](../../../../../web3-ops/evm/) ## See also - [Authentication Types](../../../../../../concepts/authtype/). - [Arcana Auth React SDK Reference Guide](https://auth-react-sdk-ref-guide.netlify.app/) - [Handling authentication errors](../../../../../auth-error-msg/) - [Auth Examples](https://github.com/arcana-network/auth-examples) # User Login with Google In this guide, you will learn how a React/Next.js app integrated with the Arcana Auth SDK and Arcana Auth React SDK can onboard users with a custom login UI through Google authentication. ## Prerequisites - Make sure you can access the Arcana Developer Dashboard:Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` **That is all.** The React/Next.js app is all set for onboarding users via Google. Arcana JWT Token Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/jwt-token-validation/) and subsequently generate another token for app use if required. In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user. Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/an-did-token/#verify-did-token) and subsequently generate another token for app use. ## What's Next? Authenticated users can instantly access the in-app Arcana wallet UI for signing blockchain transactions. Use the `AuthProvider` EIP-1193 standard Ethereum provider to call JSON/RPC functions and Web3 wallet operations in the app. [Learn more...](../../../../../web3-ops/evm/) ## See also - [Authentication Types](../../../../../../concepts/authtype/). - [Arcana Auth React SDK Reference Guide](https://auth-react-sdk-ref-guide.netlify.app/) - [Handling authentication errors](../../../../../auth-error-msg/) - [Auth Examples](https://github.com/arcana-network/auth-examples) # User Login with Steam In this guide, you will learn how a React/Next.js app integrated with the Arcana Auth SDK and Arcana Auth React SDK can onboard users with a custom login UI through Steam authentication. ## Prerequisites - Make sure you can access the Arcana Developer Dashboard:Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` **That is all.** The React/Next.js app is all set for onboarding users via Steam. Arcana JWT Token Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/jwt-token-validation/) and subsequently generate another token for app use if required. In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user. Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/an-did-token/#verify-did-token) and subsequently generate another token for app use. ## What's Next? Authenticated users can instantly access the in-app Arcana wallet UI for signing blockchain transactions. Use the `AuthProvider` EIP-1193 standard Ethereum provider to call JSON/RPC functions and Web3 wallet operations in the app. [Learn more...](../../../../../web3-ops/evm/) ## See also - [Authentication Types](../../../../../../concepts/authtype/). - [Arcana Auth React SDK Reference Guide](https://auth-react-sdk-ref-guide.netlify.app/) - [Handling authentication errors](../../../../../auth-error-msg/) - [Auth Examples](https://github.com/arcana-network/auth-examples) # User Login with Telegram In this guide, you will learn how a React/Next.js app integrated with the Arcana Auth SDK and Arcana Auth React SDK can onboard users with a custom login UI through Telegram authentication. ## Prerequisites - Make sure you can access the Arcana Developer Dashboard:Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` **That is all.** The React/Next.js app is all set for onboarding users via Telegram. Arcana JWT Token Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/jwt-token-validation/) and subsequently generate another token for app use if required. In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user. Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/an-did-token/#verify-did-token) and subsequently generate another token for app use. ## What's Next? Authenticated users can instantly access the in-app Arcana wallet UI for signing blockchain transactions. Use the `AuthProvider` EIP-1193 standard Ethereum provider to call JSON/RPC functions and Web3 wallet operations in the app. [Learn more...](../../../../../web3-ops/evm/) ## See also - [Authentication Types](../../../../../../concepts/authtype/). - [Arcana Auth React SDK Reference Guide](https://auth-react-sdk-ref-guide.netlify.app/) - [Handling authentication errors](../../../../../auth-error-msg/) - [Auth Examples](https://github.com/arcana-network/auth-examples) # User Login with Twitch In this guide, you will learn how a React/Next.js app integrated with the Arcana Auth SDK and Arcana Auth React SDK can onboard users with a custom login UI through Twitch authentication. ## Prerequisites - Make sure you can access the Arcana Developer Dashboard:Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` **That is all.** The React/Next.js app is all set for onboarding users via Twitch. Arcana JWT Token Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/jwt-token-validation/) and subsequently generate another token for app use if required. In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user. Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/an-did-token/#verify-did-token) and subsequently generate another token for app use. ## What's Next? Authenticated users can instantly access the in-app Arcana wallet UI for signing blockchain transactions. Use the `AuthProvider` EIP-1193 standard Ethereum provider to call JSON/RPC functions and Web3 wallet operations in the app. [Learn more...](../../../../../web3-ops/evm/) ## See also - [Authentication Types](../../../../../../concepts/authtype/). - [Arcana Auth React SDK Reference Guide](https://auth-react-sdk-ref-guide.netlify.app/) - [Handling authentication errors](../../../../../auth-error-msg/) - [Auth Examples](https://github.com/arcana-network/auth-examples) # User Login with Twitter In this guide, you will learn how a React/Next.js app integrated with the Arcana Auth SDK and Arcana Auth React SDK can onboard users with a custom login UI through Twitter authentication. ## Prerequisites - Make sure you can access the Arcana Developer Dashboard:Loading...
; } if (!isLoggedIn) { return ( ); } } export default App ``` **That is all.** The React/Next.js app is all set for onboarding users via Twitter. Arcana JWT Token Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/jwt-token-validation/) and subsequently generate another token for app use if required. In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user. Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../../../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../../../concepts/an-did-token/#verify-did-token) and subsequently generate another token for app use. ## What's Next? Authenticated users can instantly access the in-app Arcana wallet UI for signing blockchain transactions. Use the `AuthProvider` EIP-1193 standard Ethereum provider to call JSON/RPC functions and Web3 wallet operations in the app. [Learn more...](../../../../../web3-ops/evm/) ## See also - [Authentication Types](../../../../../../concepts/authtype/). - [Arcana Auth React SDK Reference Guide](https://auth-react-sdk-ref-guide.netlify.app/) - [Handling authentication errors](../../../../../auth-error-msg/) - [Auth Examples](https://github.com/arcana-network/auth-examples) # Plug-and-Play Login UI Use the built-in, [plug-and-play login UI modal](../../../../concepts/plug-and-play-auth/) to quickly onboard users in a 'Vanilla HTML/CSS/JS' app integrated with the Arcana Auth Wagmi SDK. Custom Login UI You can onboard users through a [custom login UI](../../../../concepts/custom-login-ui/) instead of the [built-in plug-and-play](../../../../concepts/plug-and-play-auth/) one. See [how to use custom login UI](../custom-ui/) and onboard users in a 'Vanilla HTML/CSS/JS' app. ## Prerequisites - [Register](../../../../setup/config-auth/register-app/) the app that uses `wagmi` and configure the SDK usage [settings for social login](../../../../setup/) providers, [manage app chains](../../../../setup/config-wallet-chains/) and [wallet user experience](../../../../setup/config-wallet/). - Install the [required SDK packages](../../../sdk-installation/) for 'Vanilla HTML/CSS/JS'. - [Integrate](../../../integrate/wagmi/) 'Vanilla HTML/CSS/JS' app, create and initialize the `AuthProvider`. ## Steps ### 1. `connect` Use the `connect()` function to bring up the plug-and-play pop-up modal in the app context and display the available options for user onboarding. Only those options are displayed that were earlier configured by the developer using the Arcana Developer Dashboard. The passwordless login option is enabled by default. ``` await auth.connect(); ``` Plug-and-Play Login UI Compact Mode While creating the `AuthProvider`, use `connectoOptions` to optionally choose the [compact mode](../../../../concepts/plug-and-play-auth/#compact-modal) for the plug-and-play login UI. ``` connectOptions: { compact: true // default - false }, ``` Login UI Options Arcana JWT Token Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../concepts/jwt-token-validation/) and subsequently generate another token for app use if required. In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user. Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../../../../concepts/an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object. Developers can use this token to [verify the user](../../../../concepts/an-did-token/#verify-did-token) and subsequently generate another token for app use.. No plug-and-play support for Firebase authentication. The [plug and play feature](../../../../concepts/plug-and-play-auth/) of the Arcana Auth SDK does not support social login via Firebase. Developers must build a custom login UI and add code to onboard users. For details, see [onboarding users via Firebase and custom login UI](../custom-ui/build-idm/firebase-login/) No plug-and-play support for Telegram authentication. The [plug and play feature](../../../../concepts/plug-and-play-auth/) of the Arcana Auth SDK does not support social login via Telegram. Developers must build a custom login UI and add code to onboard users. For details, see \[\[{{ no such element: dict object['telegram_custom_ui_tag'] }}|onboarding users via Telegram and custom login UI\]\]. ## What's Next? Use `AuthProvider`, the EIP-1193 provider offered by the SDK, to call supported JSON/RPC functions and [Web3 wallet operations](../../../web3-ops/evm/) in the authenticated user's context. ## See also **'Vanilla HTML/CSS/JS'** integration example: See `sample-auth-html-css-js` submodule in [SDK Example GitHub repository.](https://github.com/arcana-network/auth-examples) - [FAQ](../../../../faq/faq-gen/) - [Troubleshooting Guide](../../../../troubleshooting/) - [Arcana Auth SDK Errors](../../../auth-error-msg/) Arcana Auth SDK Quick Links - [Arcana Auth SDK Reference](https://authsdk-ref-guide.netlify.app/) - [Release notes](../../../../relnotes/latest-auth-release-note/) - [Changelog](https://github.com/arcana-network/auth/releases) - [Download SDK](https://www.npmjs.com/package/@arcana/auth) [Try Demo App](https://demo.arcana.network) # Custom Login UI [Passwordless Auth](build-pwdless-auth/) [Social Providers](build-social/) [IAM Providers](build-idm/) Refer to the [Auth Examples](https://github.com/arcana-network/auth-examples) for sample applications that use custom login UI to onboard users. # Build Custom Passwordless Auth In this guide, you will learn how to integrate 'Vanilla HTML/CSS/JS' app with the Arcana Auth SDK and then onboard users through custom login UI and passwordless login option. ## Prerequisites - Make sure you can access the Arcana Developer Dashboard:AuthProvider]
A1 -- 2.Integrate App --> D1[Install Auth SDK] --> E1 --> O[Onboard Users]
end
classDef an-pink stroke:#ff4e9f,stroke-width:0.25rem;
class F1 an-pink
```
```
flowchart LR
subgraph B [Onboard Users]
direction LR
O[Onboard Users] -- Plug-and-Play Login UI--> F1[connect]
O -- Custom Login UI --> P1{Provider Type} -- Social Providers --> G1[loginWithSocial]
P1 -- IAM Provider Firebase --> H1[loginWithBearer]
end
classDef an-pink stroke:#ff4e9f,stroke-width:0.25rem;
class F1 an-pink
```
## Compact Modal
The built-in plug-and-play login UI includes a compact modal and a normal-sized modal. Choose the compact modal by setting `compact: true` in `connectOptions` when instantiating `AuthProvider`. For more details, see [`AuthProvider` constructor parameters](https://authsdk-ref-guide.netlify.app/interfaces/constructorparams).
```
import { AuthProvider, CHAIN } from '@arcana/auth'
interface ChainConfig {
chainId: CHAIN
rpcUrl?: string
}
const auth = new AuthProvider(`${clientId}`, {
position: 'left', // default - right
theme: 'light', // default - dark
alwaysVisible: false, // default - true
setWindowProvider: true, // default - false
connectOptions: {
compact: true // default - false
},
chainConfig: {
chainId: CHAIN.POLYGON_MAINNET,
rpcUrl: '',
},
})
await auth.init()
```
Plug & Play Login UI Types
Arcana JWT Token
Upon successful authentication, Arcana Auth SDK returns a unique JWT token to the app called the [Arcana JWT Token](../an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `loginToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object.
Developers can use this token to [verify the user](../jwt-token-validation/) and subsequently generate another token for app use if required.
In the future, the Arcana JWT Token will be deprecated. Use `userDIDToken` to verify user.
Upon successful authentication, Arcana Auth SDK returns a unique DID token to the app called the [Arcana DID Token](../an-jwt-token/). App developers can access this token via `getUser()` method and refer to the `userDIDToken` field of the [`UserInfo`](https://authsdk-ref-guide.netlify.app/interfaces/userinfo) object.
Developers can use this token to [verify the user](../an-did-token/#verify-did-token) and subsequently generate another token for app use.
# Private Key
A private key is a secret linked to the user's Arcana wallet. It is generated by the asynchronous distributed key generator ([ADKG](../adkg/)) component of the protocol used by the Arcana Auth SDK. [Only the user can access it](../../faq/faq-auth/#user-key-privacy).
Users can export their private key securely via the Arcana wallet UI. The user is responsible for securing the exported key.
# Arcana Session Types
Session management settings allow Web3 app developers to decide if a user session persists after the browser window or tab is closed and reopened. Session cookies control how long an authenticated user session remains active without requiring the user to log in again.
Arcana wallet supports two types of sessions:
- Persistent
- Non-Persistent
Session Cookies
In both these cases, the session cookies are immediately invalidated once the user logs out of the app.
## Persistent Session
The authenticated session remains valid within a specified time, so users don't need to log in again after closing and reopening the browser.
Use the 'Require Log-in After' setting to specify how long a session is persisted once the browser is closed. The 'Require Log-in After' setting does not impact any active user session. The user is not forcefully logged out after the time expires. It is only used to track session persistence in case the user closes the browser without explicitly logging out.
Session cookies are used to manage session persistence. After the specified timeout, the cookies are deleted.
A persistent session is convenient for app users but carries some risk since it automatically logs the user in when the app is reopened. Ensure the re-login time aligns with the app's security and risk management profile.
Not supported for Global Keyspace Setting
The persistent session type is enabled only for the default [app-specific keyspace](../keyspace-types/) setting. For security reasons, it is disabled for apps using global keyspace.
Incognito/Private Browser Mode
If the session cookies are disabled in incognito or private browsing mode, then there is no user session persistence when the browser is closed. The behavior is the same as the non-persistent mode.
## Non-Persistent Session
If the browser is closed, the authenticated session is invalidated immediately. Users must log in again to continue using the app. By default, a newly registered app is configured to use a non-persistent session type.
# Social Login
Social Login allows users to sign in using popular Web2 identity providers like Google and Twitter or through passwordless authentication.
Web3 apps require private keys to operate wallets, but managing them can be complex for new users, often leading to drop-offs during onboarding.
By removing the need to set up and manage private keys, social login simplifies Web3 onboarding. The familiar Web2-style login makes the process seamless for new users.
## Non-Custodial Social Login
Arcana Auth SDK offers social login without compromising privacy.
Many Web3 authentication providers offer social login, but most rely on custodial wallets, meaning a third party can access users' keys and funds, compromising privacy and control.
Arcana Auth SDK's social login provides a non-custodial, in-app wallet. It combines the ease of social login with full user privacy, security, and key ownership.
## Enabling Social Login
The Arcana Auth SDK supports user onboarding via email, [social login providers](../../web3-stack/auth/), [third-party IAM providers](../../web3-stack/auth/) and [custom authentication](../authtype/custom-auth/) as well.
Compare Wallet Types & Capabilities
# Application Usage Metrics
Arcana Developer Dashboard displays the aggregate value of **Monthly Active Users (MAU)** for the Arcana Mainnet. The aggregate value includes MAU for all the applications that are registered against a developer's Arcana account.
The aggregate usage metrics are displayed in the *Manage Apps Screen*. The per-application metrics are displayed on the *Application Dashboard* screen.
**Manage Apps Screen**:
- Aggregate Monthly Active Users (Mainnet)
- Number of free MAU (Mainnet)
- Number of paid MAU (Mainnet)
Per App Usage Metrics
**Application Dashboard**:
- Testnet: Daily MAU, Monthly MAU
- Mainnet: Daily MAU, Monthly MAU
Testnet/Mainnet Usage Metrics
Mainnet Usage
The number of logged-in users is tracked separately for the 'Testnet' and 'Mainnet' application profiles. Arcana Testnet usage is not billed.
# Validator Nodes
Validator nodes play a crucial role in ensuring the decentralization of the Arcana blockchain protocol components used in securely generating user's [private key](../private-key/) for signing blockchain transactions. These partner infrastructure nodes participate in the distributed key generation process([ADKG](../adkg/)), that generates key shares (not the key itself) for users. The private key is only created within the authenticated user's context in the app.
At the launch of the Mainnet, some nodes in the DKG subsystem are owned and operated by Arcana, while the remaining nodes are owned and run by trusted partners. In the future, other third parties will be allowed to participate in the key generation protocol.
For more information on the latest implementation of asynchronous distributed key generation (ADKG), consult the see [Arcana Technical Whitepaper](https://www.notion.so/Arcana-Technical-Docs-a1d7fd0d2970452586c693e4fee14d08).
# Smart Contracts
The Arcana [Chain Abstraction(CA)](../../ca/chain-abstraction/) and Web3 authentication protocols are implemented through a bunch of smart contracts. These upgradeable contracts enforce protocol rules, ensure user data privacy, security and work with the Arcana Gateway for enabling [unified balance](../../ca/unified-balance/) and [social-login](../../social-login/) for Web3 authentication and wallet access control.
## Chain Abstraction
The Arcana chain abstraction feature is implemented through components built and deployed in the Cosmos ecosystem. In addition to those, it also implements smart contracts for Vault functionality on all supported chains.
## Web3 Authentication
Arcana Auth feature related smart contracts are implemented on the Polygon Network. These define and manage the logic and state of Web3 authentication for app users without storing any user credentials.
# Arcana Auth SDK: Deployed Contracts
| Arcana Auth SDK Contract | Type/Category | Purpose | | --- | --- | --- | | `Arcana.sol` [V1 or V2] | Beacon Proxy/Core System | Main logic contract for Arcana Store operations primarily associated with managing user data privacy and access control. | | `Factory.sol` | UUPS Proxy/Core System | Smart contract generator per app that registers with Arcana | | `ArcanaBeacon.sol` | UUPS Proxy/Core System | Smart contract to manage the per app association between the latest `Arcana.sol` main logic contract and the app | | `BeaconProxy.sol` | Beacon Proxy/dApp | This is a per app smart contract that stores the data related to the program state. It interacts with `ArcanaBeacon.sol` smart contract to refer to the latest Arcana Auth SDK authentication core logic contract. | | `Forwarder.sol` | UUPS Proxy/Core System | Manages meta transactions for app users. Forwards Gateway proxy calls (on behalf of the app) to `Arcana.sol` main logic contract | | `NodeList.sol` | Core System | Keeps track of ADKG nodes and their epochs. |
**`Arcana.sol`**
The `Arcana.sol` contract is crucial for the Arcana Auth SDK protocol. It handles UI configuration for managing blockchain transaction signing experience. It’s an upgradable beacon proxy and shares metadata with other contracts via pass-through data mechanisms.
**`Factory.sol`**
When a new app registers with Arcana Auth SDK, the factory contract activates. This singleton UUPS proxy contract generates app-specific `BeaconProxy.sol` contracts and implements core system logic.
**`BeaconProxy.sol`**
During registration with Arcana Developer Dashboard, each app gets a BeaconProxy contract. The Arcana Auth SDK Factory.sol deploys it. The BeaconProxy always points to the latest `Arcana.sol` version, managed by `ArcanaBeacon.sol`.
**`ArcanaBeacon.sol`**
The Arcana Beacon contract points to the latest Arcana Auth SDK core logic, whether V1, V2, or Vn. It’s a UUPS proxy upgradable contract, ensuring the Arcana Auth SDK Protocol remains upgradeable.
**`Forwarder.sol`**
The UUPS proxy upgradable `Forwarder.sol` manages meta transactions, which are Ethereum transactions containing another transaction. Meta transactions allow external entities like the Arcana Gateway to pay gas fees, thus easing onboarding for new users. The Gateway uses them for Arcana Auth SDK related data and access. `Forwarder.sol` works with an ERC-2771 compatible contract to forward transactions from the Gateway to the core `Arcana.sol` contract.
**`NodeList.sol`**
`NodeList.sol` manages the Arcana Auth SDK protocol functionality related to the asynchronous distributed key generation (ADKG). It tracks public ADKG node information, epoch details, the buffer size for ‘pre-generated’ keys, and validator node whitelisting.
## Contract Flows
The workflows below show how Arcana smart contracts implement the Arcana Auth SDK protocol:
1. Data access flow
1. New app registration flow
- All app user operation-related calls made via the client-side Arcana Auth SDK are intercepted by the Arcana Gateway.
- The Gateway executes the meta transactions with relevant data and signatures.
- Forwarder forwards the transaction via the per-app `BeaconProxy.sol` smart contract.
- The BeaconProxy requests the current Arcana core system contract, `Arcana.sol`, from the `ArcanaBeacon.sol` contract.
- After receiving the address of the latest Arcana core system contract from the `ArcanaBeacon` contract, the BeaconProxy delegates the forwarded call to the Arcana system contract.
- Arcana contract actually executes the transaction.
- When a new app is registered at the Arcana Developer Dashboard, it interacts with the Arcana Gateway to initialize the program state of the app.
- The `Factory.sol` smart contract is invoked to create a new `BeaconProxy.sol` contract that is solely associated with this newly registered app. Each app has its own BeaconProxy contract deployed.
- The `BeaconProxy.sol` contract stores the per-app data related to the program state.
- The BeaconProxy communicates with the `ArcanaBeacon` contract to obtain the address of the latest Arcana core system contract. This ensures that each app contract knows and utilizes the latest supported Arcana Auth SDK protocol.
# Arcana Smart Contract Types
Arcana uses different smart contracts to implement unified balance and social login features through its blockchain protocol. Some contracts are deployed by default, while others activate when apps register. The protocol uses an upgradable proxy contract pattern.
## Proxy Contract Patterns
Multiple [upgradable proxy contract](https://docs.openzeppelin.com/contracts/3.x/api/proxy#UpgradeableProxy) patterns are available, including [diamond proxy](https://blog.logrocket.com/using-uups-proxy-pattern-upgrade-smart-contracts/#what-is-a-diamond-pattern), [transparent proxy](https://blog.logrocket.com/using-uups-proxy-pattern-upgrade-smart-contracts/#what-is-a-transparent-proxy-pattern), [beacon proxy](https://docs.openzeppelin.com/contracts/3.x/api/proxy#beacon), and [UUPS proxy](https://blog.logrocket.com/using-uups-proxy-pattern-upgrade-smart-contracts/#what-is-a-uups-proxy-pattern).
Arcana Auth SDK uses the following proxy contract patterns:
- UUPS proxy
- Beacon proxy
Proxy Contract Patterns
## Arcana Contract Types
The smart contracts used to implement the logic for the Arcana Auth SDK fall into two categories:
1. **Core System Contracts:** These singleton contracts implement the core Arcana Auth SDK protocol. Not all of them store data (program state).
1. **dApp Contracts:** Deployed per app after registration with Arcana Developer Dashboard. Only registered apps can integrate with the Arcana Auth SDK.
Arcana Contract Types
# Overview
Arcana wallet is an in-app, non-custodial wallet embedded in Web3 apps that use Arcana Auth SDK. No browser extension is needed. Authenticated users get instant, secure access to the wallet for blockchain transactions. Keys are generated locally via the asynchronous distributed key generation system, ensuring full control over key privacy without complex cryptography.
## Wallet Features
- Check account balance
- Sign (Approve/Reject) blockchain transactions
- Speed up transactions
- Add, modify, switch blockchain networks
- Deploy smart contracts
- Manage token assets (native and custom)
- Check account balance
- List token assets
- Add custom tokens (ERC-20)
- Send and receive tokens
- Buy/Sell crypto
- Manage NFTs
- List NFT assets
- View NFT details
- Send NFTs (ERC-721, ERC-1155)
- Add NFTs
- Modify (edit, delete) NFT metadata
- View account transaction activity (NFT, Token send transactions, contracts deployment, etc.)
- View pending transactions in the activity tab
- Use the standard Ethereum 1193 provider interface to call [JSON/RPC functions](https://ethereum.github.io/execution-apis/api-documentation/) and supported Web3 wallet operations for the network
- Export private key
- Enable [enhanced security via MFA](../../user-guides/mfa/mfa-ug/)
- Logout
**Not Supported**
The Arcana wallet does not allow an app user to import any blockchain account created using a third-party wallet provider.
## Wallet Customization
Arcana wallet offers great flexibility and customization options as per the app requirements.
- **UX:** Developers can manage the users' blockchain signing experience by [customizing branding, theme](../../setup/config-dApp-with-db/#settings-overview), [wallet positioning](https://authsdk-ref-guide.netlify.app/interfaces/constructorparams) in the app, selecting the default active chain, [modifying pre-configured networks](../../user-guides/wallet-ui/use-wallet-ui/#addselect-a-network), and using [visibility](walletvisibility/) options.
- **Custom Wallet UI:** Replace the built-in, default wallet UI with a [custom wallet UI](../custom-wallet-ui/).
## Supported Chains
Arcana wallet comes pre-configured with a subset of the [supported blockchain networks](../../web3-stack/chains/). This pre-configured list can be updated with other supported networks [programmatically](../../auth/web3-ops/evm/#add-network) or via the [wallet UI](../../user-guides/wallet-ui/use-wallet-ui/).
[Learn more...](../../user-guides/wallet-ui/)
# Network Switching
The Arcana wallet UI shows a subset of supported blockchain networks. Users can switch the active wallet network by clicking the dropdown next to the network icon in the UI. They can also add to the network list or edit the entries.
Web3 app developers can programmatically modify the pre-configured network list and set a default network during app setup via Arcana Developer Dashboard. This is done using the `wallet_addEthereumChain` and `wallet_switchEthereumChain` JSON/RPC methods supported by the Arcana Auth SDK.
The `wallet_switchEthereumChain` method switches the active chain only after the user approves the network switch transaction.
Wallet Chain Edit Persistence
The list of networks configured by the developer, either programmatically or via the dashboard, persists across user login sessions.
User changes to blockchain networks through the Arcana wallet UI are stored locally and lost when the user logs out.
Switching Blockchain Networks
Switching chains in the wallet typically doesn’t change the wallet address when switching to another EVM-compatible chain. However, switching to a non-EVM-compatible blockchain supported by Arcana Auth SDK will assign a new set of keys and a different wallet address.
# Transaction Types
Blockchain transactions triggered through Arcana wallet require user review and approval or rejection. Users see a notification message in the app context for review. Depending on the transaction type, the message may be:
- Personal Sign
- Chain Switch
- Send Transaction
- Deploy Contract
Each message appears in a minimized notification widget. Users can click the arrow button to expand and review the details.
## Personal Sign
Personal Sign Message
## Chain Switch
Switch Chain Transaction
## Send Transaction
Send Transaction
## Deploy Contract
Deploy Contract Sign Message
# UI Modes
The [Arcana wallet](../) can be customized by Web3 app developers through the Arcana Developer Dashboard. When registering the app via the dashboard, developers must choose one of the wallet UI modes:
- Built-in Arcana wallet UI (default)
- Custom wallet UI.
To use a custom wallet UI, developers should select the UI mode as 'Custom UI' during app creation on the Arcana Developer Dashboard. This choice is final and cannot be changed later.
AuthProvider: `appMode` and `alwaysVisible` flags
Developers can control the wallet UI mode and when the wallet UI is displayed in the app context through the following customizations:
1. **UI Mode**: Choose between the Arcana wallet UI or a custom wallet UI. Set this in the dashboard's Wallet UI Mode when creating and registering a new app. There is also an [`appMode` flag](https://authsdk-ref-guide.netlify.app/interfaces/constructorparams) in the `AuthProvider` which can override this setting in the dashboard. If 'Custom UI' is selected via the dashboard then the `appMode` flag in `AuthProvider` is ignored.
1. **Always Visible**: Decide if the wallet is always visible in the app or only during a blockchain transaction. The [`alwaysVisible` flag](https://authsdk-ref-guide.netlify.app/interfaces/constructorparams) can be set to false (default is true) when creating a new `AuthProvider`. If using the Arcana wallet UI, this flag controls visibility. By default, the UI is always visible as a minimized widget. When set to `false`, the UI only appears during a blockchain transaction or when the developer calls the [`showWallet()`](https://authsdk-ref-guide.netlify.app/classes/authprovider#showWallet) method of the `AuthProvider`. The `alwaysVisible` flag is ignored if a custom UI is selected in the dashboard's Wallet UI Mode.
# Wallet Visibility
Web3 app developers can control Arcana wallet visibility by setting the `alwaysVisible` flag when instantiating the `AuthProvider` during app integration with the Arcana Auth SDK.
By default, `alwaysVisible` is set to `true` and the wallet is displayed immediately after a user logs into the app that is integrated with the Arcana Auth SDK. As the wallet is always visible in the context of the app, an authenticated user has full access to all the Web3 wallet operations supported by the Arcana wallet.
Wallet In-app Visibility: Enabled
If `alwaysVisible` is set to `false`, then the Arcana wallet UI does not show up on the application window immediately after a user logs in. The Arcana wallet UI is displayed only when a blockchain transaction is triggered that requires the user's approval or if the app issues the `showWallet()` method.
Wallet In-app Visibility: Disabled
AuthProvider: `appMode` and `alwaysVisible` flags
Developers can control the wallet UI mode and when the wallet UI is displayed in the app context through the following customizations:
1. **UI Mode**: Choose between the Arcana wallet UI or a custom wallet UI. Set this in the dashboard's Wallet UI Mode when creating and registering a new app. There is also an [`appMode` flag](https://authsdk-ref-guide.netlify.app/interfaces/constructorparams) in the `AuthProvider` which can override this setting in the dashboard. If 'Custom UI' is selected via the dashboard then the `appMode` flag in `AuthProvider` is ignored.
1. **Always Visible**: Decide if the wallet is always visible in the app or only during a blockchain transaction. The [`alwaysVisible` flag](https://authsdk-ref-guide.netlify.app/interfaces/constructorparams) can be set to false (default is true) when creating a new `AuthProvider`. If using the Arcana wallet UI, this flag controls visibility. By default, the UI is always visible as a minimized widget. When set to `false`, the UI only appears during a blockchain transaction or when the developer calls the [`showWallet()`](https://authsdk-ref-guide.netlify.app/classes/authprovider#showWallet) method of the `AuthProvider`. The `alwaysVisible` flag is ignored if a custom UI is selected in the dashboard's Wallet UI Mode.
# Web3 Onboarding
In Web3, decentralized systems use trustless protocols and cryptography for identity verification, which involves complex key management. This makes onboarding to Web3 apps harder for users as they require private keys for signing transactions. Managing these keys is challenging, with no central recovery if lost, unlike Web2's password recovery.
The [Arcana Auth SDK](../authsdk/) simplifies Web3 onboarding by enabling secure Web3 access and blockchain transaction signing. Users can log into apps using familiar Web2 methods and have self-custody of their cryptographic keys.
## Authentication Options
Web3 apps using the Arcana Auth SDK can authenticate users via any of these options:
- [Social Login Providers](socialauth/)
- [Custom Auth](custom-auth/)
- [Passkey Auth](auth-passkeys/)
User Key Security & Privacy
The Arcana Auth SDK uses the asynchronous distributed key generation ([ADKG](../adkg/)) to securely assign key shares to authenticated users. The user's private key is generated from these key shares on the client side. For added security, users can enable multi-factor authentication ([MFA](../mfa/)).
# Passkey Auth
Passkey is a digital credential that binds a user account with a website or application.
Passkeys use public key cryptography that reduces the threat from potential data breaches. They are safer than passwords as they reduce the attack surface. Since passkeys are uniquely generated for every account by the user device and work only on the registered websites and apps, they are less vulnerable to phishing.
The Passkeys Auth feature in the Arcana Auth SDK lets Web3 apps to onboard users through a biometrics sensor (such as a fingerprint or facial recognition), a PIN, or a pattern supported by the OS or device where the app is running.
```
graph LR
A[[User]]--Create Passkey--> D(Public/Private Key)--Store-->C>Browser/User Device];
classDef an-pink stroke:#ff4e9f,stroke-width:0.25rem;
class C,D an-pink
```
## Security & Privacy
Passkeys are based on [FIDO standards](https://en.wikipedia.org/wiki/FIDO_Alliance), they work on Android, Chrome, Microsoft Windows, Microsoft Edge, MacOS, iOS and Safari.
Note that when logging in to an app via a passkey, there is no biometrics information or any sensitive information that is shared with the associated website for authentication. Also, passkeys by themselves do not allow tracking of users or devices across sites. Passkeys use public key cryptography. A public–private key pair is generated when a user creates a passkey for a site or application. This is generated on the user's device. Only the public key is stored by the site. Device based passkey managers protect passkeys from unauthorized access and use.
Passkeys do not expire but they can be unlinked/deleted and new ones linked/created, if required.
## How do Passkeys Work?
Passkeys are intended to be used through operating system infrastructure that allows passkey managers to create, backup, and make passkeys available to the applications running on that operating system.
Each passkey is linked or bound to the app or website.
Users aren't restricted to using the passkey only on the device where they're available. The passkey available on phones can be used when logging into a laptop, even if the passkey isn't synchronized to the laptop, as long as the phone is near the laptop and the user approves the sign-in on the phone.
```
graph LR
L[[User on Device A]]--1.Choose Login with Passkeys Option-->M[App/Website]
M --2.Passkey Challenge-->L
L --3.Challenge Response--> M
M -.-> V{Challenge Match}==Yes==>M--4.User Authenticated-->L
```
## Passkey Usage Options
Apps can enable passkey authentication for onboarding in two ways:
- Use passkeys for **sign-up & login**
- Offer passkeys as an **alternate login** method
### Sign-up & Login
Apps that support only passkey auth can go all-in on this option. Users can sign up, create an account, and set up passkey login all in one go—no need for any other login method.
```
graph LR
U[[User on Device/Browser]] --1a.App Sign-up/Register Passkey--> K>App/Website];
U --1b.Create Passkey--> PK(Public/Private Key)-->U;
U --Store Public Key--> K
U --2.Login with Passkey--> K --> L((User Authenticated));
classDef an-pink stroke:#ff4e9f,stroke-width:0.25rem;
class L an-pink
```
For subsequent app logins, the browser or operating system will prompt the user to select and use one of the passkeys linked with the app. To validate and ensure that the rightful owner uses a passkey, the operating system may ask users to unlock their device before supplying the passkey for authentication.
### Alternate Login
Apps with multiple onboarding options only let users log in with passkeys after they’ve first used another login method and set up passkeys for future use.
Users need to sign up and log in using a different method before they can enable passkeys for future logins. Keep in mind, passkeys can’t be used for the initial sign-up.
```
graph LR
U[[User on Device/Browser]]--1.App Login (non-passkey)-->K>App/Website];
U--2.Create/Link Passkey-->PK(Public/Private Key)-->U;
U--Store Public Key-->K
U--3.Login with Passkey-->K-->L((User Authenticated));
classDef an-pink stroke:#ff4e9f,stroke-width:0.25rem;
class L an-pink
```
After setting up passkey for an account, on the subsequent log in attempt to the website or app, passkeys can be used. When signing in via passkeys, the browser or operating system will prompt the user to select one of the passkey associated with the app or website. To validate and ensure that the rightful owner uses a passkey, the operating system may ask users to unlock their device before supplying the passkeys list to choose from.
## Passkey Configuration
1. Log in to the Arcana Developer Dashboard and register the app to get a unique Client ID. Then configure [domain](#domain) setting in the dashboard.
```
graph TD
DFLA{{ Developer }} --Login --> setup
subgraph setup[Arcana Developer Dashboard]
direction LR
SP1[1.Register App] --> CLID((Unique ClientID))
SP2[2.Configure App] --> SP3[Edit/Save Passkey Usage Settings]
end
classDef an-pink stroke:#ff4e9f,stroke-width:0.25rem;
class CLID an-pink
```
2. Install Arcana Auth SDK, integrate it with your app, and initialize `AuthProvide`r. Choose the passkey onboarding option that fits your needs: use `registerWithPasskey()` for [sign-up with passkey](./#sign-up-login) option or `linkPasskey()` for using passkey as an [alternate login](./#alternate-login). Then, log in users with `loginWithPasskeys()`.
```
graph TD
DFLA{{ Developer }} --1.Install --> authsdk
DFLA --2.ClientID -->AUTHP
DFLA --3.Select Sign-up/Alternate Login Passkey Onboarding -->POP -->COA
subgraph app[App]
AUTHP[Create/Init AuthProvider] --> authsdk
COA[B. Call loginWithPasskeys] --> authsdk
POP[A. Call registerWithPasskey/linkPasskey]
subgraph authsdk[Arcana Auth SDK]
direction TB
SDK1[AuthProvider Interface]
end
end
linkStyle 1,2 stroke: deeppink;
authsdk --Process Passkeys Login --> STD[Standard Passkey Validation via OS/Browser]
authsdk --Fetch Key Shares --> BEP[Arcana Auth Protocol] <--> BEK[DKG]
```
1. The Arcana Auth SDK uses the application details from the dashboard settings and `loginWithPasskeys` input data for Passkeys login processing. After verification, it gets the user's key shares from the Arcana backend and generates a user specific key locally in the app. This key lets users securely sign blockchain transactions.
```
graph LR
BED[Arcana Developer Dashboard] --Passkey Usage Settings--> BEC{Gateway}
BEC <--> BEA[Arcana Auth Protocol] <--> BEDKG[DKG]
```
### Domain
To enable passkey login for an app, as part of configuration settings, the developer must use the Arcana Auth SDK and specify the **Domain** of the relying party. The domain is typically a CNAME or vanity URL.
Relying Party
The relying party is the website or Web3 app that allows user to create passkeys or authenticate with passkeys.
When a user enrolls a passkey, it associates with the relying party domain. If the domain name changes at any time, all of the passkeys associated with the old domain become invalid.
# Custom Auth
The custom Auth feature enables Web3 apps to use the Arcana Auth SDK for secure key assignment. Authenticate users with a Custom Auth service, issue JWT tokens, and send them to the SDK. The SDK verifies users, retrieves key shares, and generates the private key for blockchain transactions on the client side.
Global Key Apps not supported!
Custom Auth feature is supported only if the app is configured for [app-specific key type](../../keyspace-types/).
## Authentication Flow
1. Log in to the Arcana Developer Dashboard and register the app to get a unique Client ID. Then [configure Custom Auth settings](#custom-auth-settings) in the dashboard.
```
graph TD
DFLA{{ Developer }} --Login --> setup
subgraph setup[Arcana Developer Dashboard]
direction LR
SP1[1.Register App] --> CLID((Unique ClientID))
SP2[2.Configure App] --> SP3[Edit/Save Custom Auth Settings]
end
classDef an-pink stroke:#ff4e9f,stroke-width:0.25rem;
class CLID an-pink
```
1. Add code in the app for using a Custom Auth service and obtains a JWT after user authentication.
```
graph LR
IAP{{ Developer }}
MMM(Custom Authentication Service)
subgraph app[App]
direction LR
CL[Custom Login]
end
IAP --> CL --> MMM --->|JWT Token| CL
linkStyle 2 stroke: deeppink;
```
1. Next, install Arcana Auth SDK, integrate app with the SDK, initialize `AuthProvider` and then use the JWT obtained after the Custom Auth processing to call the `loginWithCustomProvider()` method.
```
graph TD
DFLA{{ Developer }} --install --> authsdk
DFLA --ClientID -->AUTHP
DFLA --JWT Token -->COA
subgraph app[App]
AUTHP[Create/Init AuthProvider] --> authsdk
COA[Call loginWithCustomOAuth] --> authsdk
subgraph authsdk[Arcana Auth SDK]
direction TB
SDK1[AuthProvider Interface]
end
end
linkStyle 1,2 stroke: deeppink;
authsdk --Verify JWT Claims --> STD[Standard JWT/JWK Validation]
authsdk --Fetch Key Shares --> BEP[Arcana Auth Protocol] <--> BEK[DKG]
```
1. The Arcana Auth SDK checks the JWT using dashboard settings. After verification, it gets the user's key shares from the Arcana backend and generates the key locally in the app. This key lets users securely sign blockchain transactions.
```
graph LR
BED[Arcana Auth Protocol] --Custom Auth Settings--> BEC{Gateway}
BEC <--> BEA[Arcana Auth Protocol] <--> BEDKG[DKG]
```
## Custom Auth Settings
The following Custom Auth settings can be specified via the Arcana Developer Dashboard.
### JWKS Endpoint
A JWKS Endpoint is a read-only URL exposed by the Custom Auth server or any other server that manages the cryptographic keys or JSON Web Keys (JWK) as per the [IETF RFC7517](https://datatracker.ietf.org/doc/html/rfc7517) and [IETF RFC7519](https://datatracker.ietf.org/doc/html/rfc7519) standards. JWKs are used to validate the integrity of a JWT and the encoded data by the Arcana Auth SDK.
### User Identifier String
The 'User Identifier String' links a unique identifier with the user's key. Developers can choose the string from one of the options:
- Sub: The user identifier string identifies the principal that is the subject of the JWT.
- Email: JWT Token claim email identifier for the user
- Custom: A custom string used for JWT Token claim.
### Issuer
The issuer claim identifies the principal that issued the JWT. For example, it could be the app identifier or deployed app URL.
*Example:* `Issuer: "https://myapp.example.com"`
### Audience
The audience claim identifies the recipients that the JWT is intended for.
*Example:* `Audience: "arcana-login-nnnnnn"`
### JWK Validation (Optional)
Claims are pieces of information asserted about a subject or user. A JWT can contain a claim called name that asserts that the name of the user authenticating is "John Doe." JWT Validation entities specified by the developer via the Arcana Developer Dashboard are key, value pairs. These are used to validate the JWT provided by the developer to the Arcana Auth SDK via the `loginWithCustomProvider()` method for authenticated users.
*Examples*
`purpose: 'login'`
`keyUse: 'arcana'`
# Authentication Providers
Apps integrating with the Arcana Auth SDK can use the built-in [plug-and-play login UI](../../plug-and-play-auth/) or a [custom login UI](../../custom-login-ui/) to onboard users through any of the supported authentication providers:
- Social Providers
- Custom IAM Providers
## Social Providers
The Arcana Auth SDK supports popular Web2 [social login](../../social-login/) providers for onboarding users and verifying their identities.
- Apple
- Cognito
- Discord
- Firebase
- GitHub
- Google
- Steam
- Telegram
- Twitch
- Twitter
## Custom IAM Providers
The following IAM providers are supported for user authentication:
- Cognito
- Firebase
These third-party IAM providers may require separate configuration of the underlying user authentication mechanisms such as social logins, OpenID, etc.
Passwordless Login
Besides these providers, users can log into a Web3 app in a passwordless manner by verifying the OTP received over email. Passwordless login is enabled by default in all apps using the Arcana Auth SDK.
# Allowances
Allowances activate Arcana Network's Chain Abstraction feature.
Allowances must be set up to enable a chain abstracted transaction that involves multiple source chains. With allowance setup, users can unlock the fragmented liquidity across multiple chains in their EOA. Effectively, this lets the user spend on any destination chain—even with insufficient balance on the destination chain.
By approving allowances for chain abstraction on the source chains, users can:
- Spend anywhere with funds from multiple chains.
- Bypass bridging to enable liquidity on the destination chain.
- Transact seamlessly across chains.
- Setup once, use repeatedly.
As part of allowance setup, users **permit Arcana Vault contracts on the source chains to collect the funds required** to execute the transaction seamlessly on the destination chain.
Note that the allowance set up transaction itself requires gas fee. This gas fee is payable by the user. In some cases, Arcana may sponsor gas fee for the allowance setup.
By default, the allowance limit for each supported chain is set to `unlimited`. This default setting ensure that all the supported tokens on the chain can be utilized as the unified balance available to spend. The protocol can collect the required funds according to the allowance limit and pay for the chain abstracted transactions on any destination chain. Developers can choose to modify the default allowance limits via the `setOnAllowanceHook`.
## How Allowances Work?
Here is how the allowances enables chain abstracted transactions:
1. User approves the protocol to access funds from multiple source chains.
1. Protocol unifies user balance across these chains.
1. Unified funds get deposited into protocol vaults.
1. User can now transact on any destination chain using your combined balance.
## Allowance Setup
Users have two allowance setup choices that differ by:
- Which chains are included for chain abstraction allowance setup?
- Who pays the gas fees for the allowance transaction?
| Option | Chains included | ETH Balance Required | User Pays Gas Fee | Arcana Pays Gas Fee | | --- | --- | --- | --- | --- | | 1. | Ethereum Mainnet + Avalanche + L2 chains | Yes | `$1`-`$5` (as per current Ethereum Mainnet gas price) | Avalanche + L2 only | | 2. | Avalanche + L2 chains | No | Nothing | All gas sponsored |
# Arcana CA Wagmi SDK
Arcana CA Wagmi SDK enables unified balance in Web3 apps using the [Wagmi](https://wagmi.sh/) framework. The SDK offers a plug-and-play widget that display the unified balance for the app users and helps them transact on any chain.
Web3 Wagmi app builders can integrate the Arcana's [Chain Abstraction](../chain-abstraction/) feature via the SDK and let users spend on any chain, as long as they have sufficient funds across chains to cover for the transaction amount and the required gas fee.
Arcana CA Wagmi SDK Usage Overview
# Arcana CA SDK
The Arcana CA SDK is meant for Web3 builders and app developers. It unifies user balance in the wallet account spread across [chains](../../../web3-stack/ca_stack/#chains) and [tokens](../../../web3-stack/ca_stack/#tokens).
Web3 app builders can integrate Arcana's [Chain Abstraction](../chain-abstraction/) feature via the SDK and let users spend on any chain, as long as they have sufficient funds across chains to cover for the transaction amount and the required gas fee.
Arcana CA SDK Architecture Overview
# Chain Abstraction
Managing multiple chains, tokens, and accounts fragments wallet liquidity for Web3 users. Even with enough assets overall, funds scattered across chains make transacting difficult and require complex, time-consuming conversions.
Chain abstraction lets users access a [unified balance](../unified-balance/) across all wallet-linked chains, enabling transactions anywhere. Instead of converting funds first, users specify a [clear intent](../intent/). The protocol collects funds from source chains, shows intent and fees for confirmation, then publishes the intent to solvers. Solvers compete to provide liquidity on the destination chain, and once available, users confirm the transaction. Settlement with solvers happens asynchronously using the collected funds.
As part of setup, devs configure [allowances](../allowances/) per chain and token. Users approve or reject these allowances. For [supported tokens](../../../web3-stack/ca_stack/#tokens) on [source chains](../../../web3-stack/ca_stack/#chains), the protocol uses these allowances to deposit required funds for transactions on the destination chain.
Arcana's Chain Abstraction
## Why Chain Abstraction?
Chain abstraction enables unified balance to simplify and streamline Web3 transactions. It offers:
- **Faster Intent Processing:** Enables quick and seamless transaction execution across chains.
- **Unified Liquidity:** Provides a consolidated view of user assets across wallet-linked chains with no asset bridging.
- **Simplified UX:** Removes multi-step hurdles for a seamless experience, making transactions easy for all users.
- **Streamlined DX:** Developers can add unified balances to dApps with minimal changes and no smart contract updates for new chains.
# Intent Explorer
The [Arcana Intent Explorer](https://explorer.arcana.network/) is used to check the status or details of an [intent](../intent/). To view intent details in the Intent Explorer, you need the unique [intent identifier](./#intent-identifier).
Each stage of chain abstracted transaction processing can be viewed in the Intent Explorer. All the intent details are populated once the intent is fulfilled and the transaction is complete.
Intent Explorer
## Intent Identifier
Each [intent](../intent/) is associated with a unique identifier.
How you access this identifier depends on whether you’re using the Arcana CA Wallet or a third-party wallet in a Web3 app integrated with the Arcana CA SDK.
### Arcana CA Wallet
When using the Arcana CA Wallet for issuing a chain abstracted transaction, you can obtain the intent identifier by clicking 'View Intent.'
The 'View Intent' option becomes available in the transaction UI after a user authorizes a transaction that involves chain abstraction. The transaction is then published to [solvers](../solver/), who compete to provide liquidity on the destination chain as specified in the intent.
Get Intent Identifier
To find the intent identifier for past transactions:
- Open the 'Activity' tab in the CA Wallet to view your transaction history.
- Click the down arrow next to a transaction to expand its details.
- In the details, click 'View Intent' to see the unique intent identifier for that transaction and other intent details.
Activity Tab: Get Intent Identifier
}
### Third-party Wallets
Accessing the intent identifier for a chain-abstracted transaction issued through a third-party wallet depends on how the Web3 app is built and integrated with the Arcana chain abstraction SDK.
The Arcana CA SDK provides methods and hooks that developers can use to:
- Implement chain-abstracted transactions.
- Show transaction progress, including the intent identifier, in the app’s UI.
Developers can:
- Add code to let users view intent details before authorizing a chain abstracted transaction.
- Use SDK hooks to track events and [progress after the intent is published](https://ca-sdk-ref-guide.netlify.app/types/progressstep), retrieving the intent identifier once it’s created.
- Offer options in the UI to display the intent identifier or a button to view details at different stages (for example, when liquidity is supplied or the intent is fulfilled).
For Web3 apps using the Arcana CA Wagmi SDK, no extra code is needed. The 'View Intent' option is already built into the transaction UI. Users can click it to open the Intent Explorer and see the intent details and identifier.
Previous Transactions
Unlike the Arcana CA Wallet activity tab, the chain abstraction SDKs do not provide a mechanism to access the intent identifier for past transactions.
If required for transparency or compliance, the developers can provision saving and tracking the intent identifiers for past transactions in the context of the Web3 app by listening to the event data through SDK hooks.
In the [chain abstraction](../chain-abstraction/) context, an intent represents an objective to transact on a destination chain where user does not have sufficient funds available.
An intent specifies what the user is willing to offer (tokens from various source chains) to cover the transaction amount, gas fees, solver fees, and the Arcana chain abstraction (CA) protocol service fee for receiving the desired liquidity on the destination chain.
By signing the intent, user agrees to perform the following in one shot:
- Allow the Arcana CA protocol to collect necessary assets available in the EOA across one or more source chains to pay for the transaction and the fees.
- Enable the available [solvers](../solver/) in the ecosystem to provide the desired liquidity on the destination chain in the user's EOA.
- Let the Arcana CA protocol settle deposited funds and applicable fees with the solvers at regular intervals.
As part of the Arcana CA protocol setup, the user must complete a one-time set up of [allowances](../allowances/) on every source chain. This is required before an intent can be raised for a chain abstracted transaction. Allowances are used to specify the limits of funds that can be deposited per source chain in order to receive the required funds on the destination chain.
Each intent specifies:
- **Source Chains:** The blockchains where the user has funds/tokens.
- **Destination Chain:** The blockchain where the transaction will occur (where the user lacks liquidity).
- **Tokens and Amounts:** Specifies which tokens and how much from each source chain will be used.
- **Fees:** Includes CA gas fee (for cross-chain operations), protocol fee (for the service), solver fee (for the liquidity provider), and any supplied gas.
- **Total Amount:** The full cost, combining the transaction amount and all fees.
The intent processing begins when the user signs an intent and authorizes a transaction. Once the intent is signed by the user and submitted to the protocol, each intent is assigned a unique identifier. For every chain abstracted transaction, users can click on the 'view intent' link to see the intent details or to note down the intent identifier for future references. [Learn more...](../intent-explorer/#arcana-ca-wallet)
This intent identifier is used to track the intent status. Users can supply the intent identifier in the [Arcana Intent Explorer](https://explorer.arcana.network/%5D) to check the intent’s status or details later.
Intent Details
## Stages
Following are some of the key stages of intent processing:
- Intent Accepted - User has agreed to chain abstracted transaction intent and accepted the associated fees
- Intent Hash Signed - User has signed the intent hash
- Intent Submitted - Intent for CA is submitted to the chain
- Intent Collection - Funds associated with the intent are collected on the source chains
- Intent Mined - CA protocol has mined the intent on the chain
- Intent Deposits Confirmed - Deposit on source chains is confirmed
- Intent Fulfilled - The liquidity is supplied on the destination chain by the solver
In Arcana's chain abstraction protocol, a solver facilitate cross-chain transactions by supplying liquidity on the destination chain.
After a user signs and authorizes an intent, the protocol ensures that the required funds are collected on the source chains via the user's EOA and publishes the request for funds as per the user's [intent](../intent/). Solvers listen for the published intent and compete with other solvers to instantly provides the required liquidity on the destination chain.
In return for the liquidity provisioning services provided by the respective solvers, the CA protocol periodically settles funds periodically. While settling, it aggregates all the successful transactions made by the solver and pays through the funds collected on the source chains from the user's EOA, as agreed to in the intent.
# Wagmi Plug & Play Widget
Arcana CA Wagmi SDK provides a plug and play widget that displays the [Unified balance](../unified-balance/) associated with the user's wallet address. This widget is available only for the [Wagmi](https://wagmi.sh/) apps.
Follow these steps to use this widget:
1. Install and integrate the app with the Arcana CA SDK.
1. Use `CAProvider` to enable the plug-and-play unified balance widget in the app. [Learn more...](../../../quick-start/ca-wagmi-quick-start/)
Plug & Play Unified Balance Widget
# Unified balance
Unified balance shows all the liquidity in a user's EOA account across multiple chains in one view. It lets users transact seamlessly on any chain without needing bridges or pre-provisioning gas for token swaps. Chain abstraction handles all the complexity involved in a cross-chain transaction while enabling better UX through a single intent approval.
For instance, let us take the case where a user intends to spend 18 USDC on Scroll and does not have any balance on Scroll.
- Optimism: 0.1 ETH, O USDT, 0 USDC
- Arbitrum: 0 ETH, 12 USDT, 0 USDC
- Base: 0 ETH, 10 USDT, 0 USDC
- Scroll: 0 ETH, 0 USDT, 0 USDC
To spend 18 USDC on Scroll (destination chain) with the given liquidity fragmentation, it would typically require multiple clicks and steps for swapping or bridging different assets available on the source chains, so that user can convert the assets to the desired token balance on Scroll.
Through chain abstraction and ability to swap cross-chain, users have the convenience to view the consolidated token balance across supported tokens and chains. This simplifies the process of sending 18 USDC on Optimism, as users can sign the intent without the need for bridging, swapping, or considering the optimal routes.
The cross-chain swap enables users to:
- Spend assets on any destination chain without prior liquidity.
- Collate payable amount by combining multiple supported assets across source chains to address liquidity fragmentation.
Single chain liquidity vs. Unified Balance with Chain Abstraction
**Plug & Play Widget**
Arcana CA Wagmi SDK provides a plug and play widget that displays the [Unified balance](./) associated with the user's wallet address. This widget is available only for the [Wagmi](https://wagmi.sh/) apps.
Follow these steps to use this widget:
1. Install and integrate the app with the Arcana CA SDK.
1. Use `CAProvider` to enable the plug-and-play unified balance widget in the app. [Learn more...](../../../quick-start/ca-wagmi-quick-start/)
Plug & Play Unified Balance Widget
# Arcana Auth SDK
## Onboarding Users
______________________________________________________________________
Can app users onboard app only via social login or do they have the flexibility to use any third-party Web3 wallets to connect to an app integrated with the Arcana Auth SDK?
Yes.
Besides social login, Arcana Auth SDK allows Web3 app users to log in to a Web3 app via any supported third-party browser-based Web3 wallets.
Apps using wallet connectors, [Wagmi](../../quick-start/wagmi-quick-start/), and [RainbowKit](../../quick-start/rainbowkit-quick-start/), [Web3-React](../../quick-start/web3-react-quick-start/), and [WalletConnect](../../quick-start/walletconnect-quick-start/) SDKs can enable Arcana wallet to sign blockchain transactions.
Is social login via a Microsoft account or Hotmail supported?
No.
Arcana Auth SDK does not support passwordless login through a Hotmail account. Also users cannot log in using Microsoft accounts.
Can a Web3 app use the Arcana Auth SDK only for onboarding users and disable the Arcana wallet feature altogether?
There is no way to selectively turn off the Arcana wallet features. However, if the application **does not perform any blockchain transactions**, the wallet feature can be disabled by setting the [wallet visibility mode](../../concepts/anwallet/walletvisibility/) to `false` while integrating the app with the Arcana Auth SDK. In this case, the Arcana wallet will not be visible to the authenticated user as long as **no blockchain transaction is triggered**.
If you need to completely disable the Arcana wallet feature in the app, you can request a private build of the Arcana wallet by [contacting Arcana](../../support/) with the use case details.
Will the Arcana Network's distributed key generation algorithm be affected if a node with a key share becomes temporarily inaccessible?
No.
Arcana's [ADKG](../../concepts/adkg/) algorithm can still generate the key using the key shares from the other nodes that are accessible. The algorithm is designed to tolerate a certain number of nodes being inaccessible, depending on the total number of participating nodes. For more details, see [Arcana's Technical Whitepaper](https://www.notion.so/Arcana-Technical-Docs-a1d7fd0d2970452586c693e4fee14d08).
Does the authenticated user see the same wallet address if they use different authentication providers to log into a Web3 app integrated with the Arcana wallet?
Yes. This is made possible by the [aggregate login](../../concepts/aggregatelogin/) feature of the Arcana Auth SDK.
*For this feature to work, the user* **must** *have the same email ID registered with the different authentication providers.*
Arcana Auth SDK uses the email ID to uniquely identify the user even if the user uses different social login providers or the passwordless email option to log in to a Web3 app. It associates a single key for such a user which results in the user seeing the same wallet address. If the user has different email IDs associated with different social login providers then each login is treated as a unique, different user and the same user will see a different wallet address when logging into the same Web3 app.
Does the authenticated user see the same wallet address across multiple Web3 applications that integrate with the Arcana Auth SDK?
Arcana Auth SDK allows Web3 app developers to tailor the wallet address experience for their users. It provides two 'Keyspace' options at the time of application registration:
- App-Specific Keys
- Global Keys
If a developer selects the **Global Keys** option, then the user gets assigned the same key across all applications that integrate with the Arcana Auth SDK and chooses the same **Global Keys** option. The same key means the wallet address of the user is the same across different Web3 apps that integrate with the Arcana Auth SDK. This is true across apps that use EVM-compatible chains. If two apps use global keys but one of them is on an EVM-compatible chain and the other is not, then the keys will be different across such apps. The Arcana's ADKG subsystem will assign the user different sets of keys for such apps resulting in different wallet addresses across such apps.
For more details, see [app-specific vs. global keys](../../concepts/keyspace-types/)
Does the **global keys** feature work across EVM-compatible and not EVM-compatible chains?
**No**.
The global keys feature enables an authenticated user to have the same wallet address across different Web3 apps in the Arcana ecosystem.
However, an authenticated user will see \*\*different wallet addresses across two chains configured in a single Web3 app if one of them is EVM-compatible whereas the other is not. Also, in the case of two Web3 apps, one of which uses an EVM-compatible chain and the other that uses chains that are not EVM-compatible, the authenticated user's wallet address will be different for each app.
Why is the Global Keyspace option not enabled if I select the 'Custom Wallet UI' option during app registration in the Arcana Developer Dashboard?
If a Web3 app developer chooses the 'Custom Wallet UI' instead of the built-in Arcana wallet UI, during app registration via Arcana Developer Dashboard, only 'app-specific keys' are allowed. This is for [keyspace security](../../concepts/keyspace-types/#security).
Global keys allow users to have the same private key across all the apps that integrate with the Arcana Auth SDK. With custom wallet UI, global keys are disallowed to mitigate the security risk of a malicious app hacking into user keys and gaining access to not just one but all such apps with 'Global Keys' enabled.
Are incognito/private windows in browsers and 'third-party cookies blocked' option supported by the Arcana Auth SDK?
Yes.
The Arcana wallet supports Chrome browser `Incognito Window` as well as `Private Window` in the case of Safari browsers. Earlier, if third-party cookies were disabled, the built-in, plug-and-play login pop-up modal did not show up in some cases. These use cases are now addressed by the SDK.
Developers can use the `canReconnect` and `reconnect` [functions of the `AuthProvider`](https://authsdk-ref-guide.netlify.app/classes/authprovider) to check before allowing users to reconnect whereby users do not need to re-login if they refresh the page or close the tab and re-open it again within a 30-minute window.
Does Arcana Auth SDK return a JWT token to verify users post social login?
Yes. See [Arcana JWT Token](../../concepts/authtype/) for details.
How does the app access an authenticated user's information such as name, email, login token, the wallet address?
Apps can use the [`getUser()`](https://authsdk-ref-guide.netlify.app/classes/authprovider#getUser) method to obtain the user's name, email, login token ([Arcana JWT Token](../../concepts/an-jwt-token/), [DID Token](../../concepts/an-did-token/)), wallet address, etc. See [Arcana Auth SDK Reference](https://authsdk-ref-guide.netlify.app/) for details.
For Twitter, the `getUser()` function of the `AuthProvider` does not always return the user's email?
You can create a Twitter account using your phone number without needing to provide an email address. If you do this, the getUser() function won't give you the user's email address.
However, web3 app developers have the [option to configure settings on the Twitter developer dashboard](https://developer.twitter.com/en/docs/twitter-api/v1/accounts-and-users/manage-account-settings/api-reference/get-account-verify_credentials#:~:text=Request%20a%20User's%20Email%20Address,email%20address%20access%20to%20function) to request users' email addresses. If they do this, Arcana Auth SDK can access and retrieve the user's email through Twitter, and it will be included in the result when you use the getUser() function.
Does login via Passkey share any user or device information with the website or application?
No.
With [passkeys](../../concepts/authtype/auth-passkeys/), the user's biometric information, secrets, or private keys are never revealed to the website or the app where user is trying to sign in. User digital credentials do not leave the user's personal device. Also, the passkey protocols are carefully designed so that no information shared with sites can be used as a tracking vector.
[See FIDO standard](https://fidoalliance.org/how-fido-works/), [Apple Passkeys security](https://support.apple.com/en-in/102195), [Microsoft Passkey Support](https://support.microsoft.com/en-us/account-billing/signing-in-with-a-passkey-09a49a86-ca47-406c-8acc-ed0e3c852c6d), [Google Passkey Security](https://developers.google.com/identity/passkeys/faq) for details.
Is there any expiration limit on passkeys?
No.
If required, users can delete passkeys associated with a website or application and create new ones.
Can users create accounts with passkeys on Arcana Auth SDK?
Yes.
Web3 apps using Arcana Auth SDK can use passkeys for signups and login or as an alternative login mechanism.
Refer to [Passkey Support](../../concepts/authtype/auth-passkeys/) for details.
Does the Arcana Auth SDK support role based access control (RBAC)?
Yes.
After the user authenticates through the chosen [social login](../../concepts/social-login/) provider, the Arcana Auth SDK receives the JWT token from the provider. It verifies the user with this token, and then creates and returns an Arcana JWT token to the app.
If the app developer needs to implement *Role Based Access Control (RBAC)* and authorize the authenticated user for some specific actions, they can first [verify the JWT token returned by Arcana](../../concepts/jwt-token-validation/). Upon verification they can issue a new app-specific JWT that enables RBAC and authorization.
Alternately, developers can use Sign-In with Ethereum ([SIWE](https://www.npmjs.com/package/siwe)) by signing a standard message format parameterized by scope, session details, and security mechanisms (e.g., a nonce).
SIWE allows users to log in to applications using their Ethereum wallet and ENS (Ethereum Name Service) profile.
## Arcana wallet
______________________________________________________________________
How does the in-app Arcana wallet allow developers to manage UX for signing blockchain transactions?
Apps can integrate with the Arcana Auth SDK to enable an embedded, non-custodial Web3 Arcana wallet for every authenticated app user.
To integrate an app, developers must register and configure the app with Arcana, and then install the `auth` package and create a new `AuthProvider`. While instantiating the `AuthProvider` developers can manage the user experience for signing blockchain transactions through the input parameter `alwaysVisible`. This parameter controls whether the Arcana wallet UI is automatically displayed in the application's context right after a user authenticates or it shows up only when the app triggers a blockchain transaction that requires the user's approval.
For details, see [Arcana wallet visibility modes](../../concepts/anwallet/walletvisibility/).
Does the Arcana Auth SDK set `window.ethereum` value in the app's context?
By default, Arcana wallet does not set the `window.ethereum` value in the app's context. To explicitly set this value, during the integration of the app with the Arcana wallet, when `AuthProvider` is instantiated, developers must specify the `setWindowParameter=true`. For details, see the [Arcana wallet Usage Guide](../../auth/auth-usage-guide/).
How is the in-app Arcana wallet different from self-custodial wallets?
Arcana wallet is a non-custodial wallet. Here is how it differs from the self-custodial wallets:
| Self-custodial wallets | Arcana's non-custodial wallet | | --- | --- | | Users need to be responsible for and remember their passphrases. | Users are not required to remember any passphrase. | | Users need to manage keys themselves in case of self-custody wallets. | Arcana wallet offers a sweet spot, users don't have to manage keys as in the self-custody wallet and yet their keys can be generated in a distributed manner via the Arcana wallet, a non-custodial wallet. | | Users who are new to Web3 typically find self-custodial wallets very challenging to use. | Arcana wallet offers a really simple Web2-like onboarding experience for new Web3 users without sacrificing security and ownership. |
## User Key Privacy
______________________________________________________________________
If Arcana is storing nothing related to the user's private keys, how does Arcana provide the same wallet to a user when the user signs in for the second time?
The Arcana Auth SDK maintains a UserID -> Public Key mapping, that is how the user is identified across successive login sessions and the correct wallet is assigned for the authenticated user. This mapping is stored in the DKG nodes.
How does the Arcana Auth SDK ensure that the key shares are fetched by the correct user only?
A user can log in only after the social login provider authenticates or if the user provides the OTP shared via email during passwordless onboarding. Providers share JWT/other identifiers with Arcana Auth SDK once the user authenticates. So unless the user themselves share their social ID / OTP, only an authenticated user will be allowed to access their key shares. The token (idToken) is verified with the DKG nodes before the key shares are sent back to the user. The token can be used only once per user login session.
Can a malicious entity reconstruct the user's private key if they get all the requisite key shares?
There are several safeguards against this and we are continuously evolving the ADKG protocol to make it more robust and fast.
One of the methods is MFA. When the MFA feature is enabled, it further strengthens the security by using multiple factors to generate the private key besides the key shares. A local share is created for the user at the first login that lives on the user's device. This local key component stored on the user's device is required to get the actual private key. If a user changes the device, they are validated via PIN setup during MFA or security answers before the local share is re-created on the new device.
Irrespective of whether MFA is enabled or not, the reconstruction of the private key happens only after ensuring that the user is:
- authenticated through one of the configured social login providers,
- verified by DKG before sharing the key shares.
The verification token ID changes for every user session so a malicious entity cannot reuse it. Also, note that the same set of key shares is not returned for every user session by the DKG nodes. Only a random subset of shares is needed to construct the private key.
In a future version of the ADKG protocol, the key shares will be periodically refreshed to safeguard against an eventuality if some of them are somehow stolen by a malicious user.
# Arcana Developer Dashboard
## General
______________________________________________________________________
Is it mandatory to use the Arcana Developer Dashboard before integrating with the Arcana Auth SDK to enable social login?
Yes.
To integrate any app with the Arcana Auth SDK, it is not sufficient to simply download and install the SDK. A unique Client ID is also required. This is available once the app is registered using the Arcana Developer Dashboard.
Note that the Client ID per app is different when using Testnet or Mainnet. When deploying the app on Testnet use the Client ID meant for Testnet and vice-versa.
How do I delete the application configuration and start afresh?
To delete an application from Arcana ecosystem, follow these instructions:
- Log into the Arcana Developer Dashboard.
- In the **Manage Apps** screen, select the card displayed there for the registered application you wish to delete.
- Click the trash icon on the top right and delete the app entry.
- The application registration will be canceled and the **Client ID** assigned to your application will no longer work.
De-register & Delete App
How do I migrate an application from using Arcana Testnet to Mainnet?
To migrate an application from using the Arcana Testnet to Mainnet, follow these steps:
1. Use the Arcana Developer Dashboard, visit the 'Manage App' page, and select the application entry. By default, when you register any application, a 'Testnet' configuration profile is created for the application. Click on the app card to see the application configuration screen.
1. On the application configuration screen, switch the network from 'Testnet' to 'Mainnet' on the top right to create a 'Mainnet' configuration profile. You will be asked to approve the creation of the 'Mainnet' configuration profile. To begin with, you can use a copy of the 'Testnet' profile to generate the 'Mainnet' profile. Later, you can edit and manage it independently. Note that a new **Client ID** is assigned to the 'Mainnet' profile.
1. Use the 'Mainnet' profile **Client ID** and update it in the app integration code instead of the earlier value which corresponds to 'Testnet'. You will need to restart your application after this change. This is important to ensure that the app uses the 'Mainnet' configuration settings.
Use appropriate **Client ID**
To migrate an app from using Testnet to Mainnet, the developers must ensure that the new **Client ID** corresponding to the application's 'Mainnet' profile is used to initialize the `AuthProvider` while integrating the app with the Arcana Auth SDK. After that, the app must be restarted to switch over from using Arcana Testnet to the Mainnet.
Can a developer run one instance of the app, say dev version on Testnet while publishing the release instance to use the Arcana Mainnet?
Yes, developers can run two instances of the app simultaneously, one on the Arcana Testnet and the other on the Mainnet as each app instance is assigned a unique **Client ID**.
Use the 'Mainnet' configuration profile **Client ID** in your app's integration code and instantiate the `AuthProvider`. Then deploy this app instance to use Arcana Mainnet.
Similarly, use the 'Testnet' configuration profile **Client ID** in another copy (branch / different version of the code) of your app where Arcana Auth SDK is integrated and instantiate the `AuthProvider`. Then deploy this app instance to run it using the Arcana Testnet.
How do I delete Mainnet configuration settings and run my application using Arcana Testnet only?
Once you have enabled 'Mainnet' for an application, you cannot delete the 'Mainnet' configuration profile independently in the current release. You can [switch your application from 'Mainnet' to 'Testnet'](../../setup/config-dApp-with-db/#switch-profile) by using the dropdown button in the application configuration screen to edit or modify it.
The only way to delete Mainnet settings is to deregister the app and delete the app entry altogether. This removes both Testnet and Mainnet configuration profiles. You will need to re-register the application. This will create a new **Client ID** and you will be required to specify this new Client ID when integrating your application with the Arcana Auth SDK. As a result, when you deploy your app and the users log in, they will see brand-new wallet addresses.
If you wish to ensure that the user wallet address does not change, you must register your application and request for the [Shared Key Space](../../concepts/keyspace-types/) option at the very start. In that case, users will be allowed to use the same wallet address across all applications in the Arcana ecosystem and even if an application is de-registered and re-registered.
## Branding Settings
Why do I see an error when uploading the logo file?
Make sure the file is less than the 1 MB limit for a successful upload.
How do I change the logo file that I uploaded earlier?
Click on the 'x' icon next to the uploaded logo file. You will see a notification about the successful deletion of the file. Click on the upload icon and upload a new logo file.
## Social Auth Settings
______________________________________________________________________
Is it mandatory to specify all configurations in the Arcana Developer Dashboard *Configure* section?
No.
If no authentication provider is configured via the Arcana Developer Dashboard, the app users can log in through the default passwordless option that requires no configuration. Developers can use the `connect` method to bring up plug-and-play login UI or build a custom login UI. When using the custom login UI, call the `loginWithLink` method (deprecated), `loginWithOTPStart` and `loginWithOTPComplete` methods to onboard users.
Besides the default passwordless login option, developers can choose to enable one or more authentication providers as the onboarding options for users. That requires configuring authentication providers through the Arcana Developer Dashboard. For details, check out [how to configure authentication providers](../../setup/).
Can an application enable more than one authentication provider to onboard users?
Yes. Developers can configure one or more authentication providers as additional onboarding options besides the default passwordless login option. Users can choose any one of the supported authentication mechanisms to onboard the app.
## Wallet Settings
______________________________________________________________________
Why do I need to specify Wallet Website Domain setting?
This is an optional setting for additional security. If specified, the Arcana Auth SDK configuration subsystem uses this setting to restrict the Arcana wallet from loading anywhere else other than the application website domain that a developer specifies. for restricted domains, the [frame-ancestor Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/web/http/headers/content-security-policy#frame-ancestors) is used.
Is there a way to control when, which position in the application window, and what kind of theme is used for displaying the Arcana wallet in the apps' context?
**Wallet Display Controls**
1. **Visibility**
The application developer can use the `alwaysVisible` parameter in the `AuthProvider` to control whether the Arcana wallet UI is automatically displayed once the user has authenticated (default) or it shows up only when a blockchain transaction is triggered that requires the user's approval.
If `AuthProvider` is instantiated with `alwaysVisible = false` then the wallet UI will not be displayed by default in the app's context. However, when a blockchain transaction is triggered by the app, a transaction notification is displayed in the app's context, requesting the user's approval for the transaction. Once the user takes the appropriate action, the transaction notification will disappear.
For more details, see [Arcana wallet visibility modes](../../concepts/anwallet/walletvisibility/).
1. **Position**
The `position` parameter in the `AuthProvider` controls whether the wallet is displayed on the left or the right side of the Web3 app UI window.
1. **Light/Dark Theme**
The `theme` parameter in the `AuthProvider` controls whether the wallet is displayed using the light theme or the dark theme. Developers can set the theme via the Arcana Developer Dashboard by using the 'Branding' tab on the LHS.
Can any Web3 app user access the in-app Arcana wallet?
No. The in-app Arcana wallet is accessible by the authenticated users only if the app is integrated with the Arcana Auth SDK. Web3 users cannot download and install the in-app wallet like other standalone, browser-based third-party wallets.
## Integrating Web3 Apps
______________________________________________________________________
How can I enable the [social login](../../concepts/social-login/) in a Web3 app?
Web3 developers can simply download and integrate dApps with the Arcana Auth SDK.
Login to the Arcana Developer Dashboard to configure Arcana Auth SDK usage settings before actually integrating the application.
How can I access in-app Arcana wallet in the context of a Web3 applications?
App users can access the in-app Arcana wallet in the context of a Web3 application only if the app developer has integrated it with the Arcana Auth SDK.
Web3 app developers can enable the in-app Arcana wallet by:
1. [Registering the app](../../setup/config-auth/register-app/) and [configuring the app settings](../../setup/config-auth/) using the Arcana Developer Dashboard.
1. Download and install the [Arcana Auth SDK](https://www.npmjs.com/package/@arcana/auth) and then use the unique Client ID assigned to the registered app in the dashboard to [integrate the app](../../auth/integrate/vanilla-html-css-js/) with the Arcana Auth SDK.
1. Add code in the app to use the Arcana Auth SDK functions and [onboard users](../../auth/onboard/vanilla/use-plug-play-auth/).
The authenticated users can instantly access the Arcana wallet in the app context and sign blockchain transactions. Developers can control the user experience for signing blockchain transactions with the appropriate [wallet visibility](../../concepts/anwallet/walletvisibility/) specification.
The in-app wallet can be displayed for the authenticated users in the app context always or the app can be configured to display blockchain transaction request notifications for approval by the user only when a transaction is triggered. Developers can display the wallet as per the application logic using the `showWallet()` function.
How can developers access the standard EIP-1193 provider from the `AuthProvider` object once the Arcana Auth SDK is integrated with the Web3 app?
In the case of EVM chains, developers can access the EIP-1193 provider once an `AuthProvider` object is created and the `init` function is successful. See code snippets below for details:
```
// ethers
const provider = new ethers.providers.Web3Provider(auth.provider)
// web3js
const provider = new Web3(auth.provider)
```
## Application Frameworks
______________________________________________________________________
Does the Arcana Auth SDK support Web3 application frameworks such as React, Next.js, Vue?
Yes. You can integrate the Arcana Auth SDK with any vanilla HTML/CSS/JS app or an app that uses React, Next.js, and Vue frameworks. [Learn more...](../../auth/integrate/vanilla-html-css-js/)
## Wallet Connectors
______________________________________________________________________
If an application uses wallet connector frameworks such as Wagmi, RainbowKit, WalletConnect or Web3-React, can the in-app Arcana wallet be plugged into those wallet connectors?
Yes.
- Applications using Wagmi, RainbowKit or WalletConnect must install and integrate with the `auth`, `auth-wagmi` packages.
- Applications using Web3-React framework can install and integrate with the `auth`, `auth-web3-react` packages.
As part of the integration, these applications can enable the Arcana wallet as one of the wallet choices for the app users in addition to the built-in wallets available in the wallet connect frameworks.
For step-by-step integration instructions for these wallet connector frameworks, see how to [integrate Wagmi apps](../../auth/integrate/wagmi/), how to [integrate RainbowKit apps](../../auth/integrate/rainbow/), how to [integrate WalletConnect apps](../../auth/integrate/walletconnect/), and [how to integrate Web3-React apps](../../auth/integrate/web3-react/).
## User Onboarding
______________________________________________________________________
How do I enable the Web2-like social login experience in a Web3 app to onboard users?
1. Register the app with the Arcana Network.
1. Configure one or more authentication providers for onboarding app users by configuring the **Social Auth** settings using the Arcana Developer Dashboard.
1. Integrate the app with the Arcana Auth SDK and add code to onboard users. For example, see [how to onboard users via Google](../../auth/onboard/vanilla/custom-ui/build-social/google-oauth/).
Is there a passwordless login option to onboard the users?
The passwordless login option to onboard app users is enabled once the app registers through the Arcana Developer Dashboard and then integrates with the Arcana Auth SDK.
Initialize the Arcana Auth SDK and use the `connect` method to bring up the built-in, [plug-and-play login UI](../../auth/onboard/vanilla/use-plug-play-auth/) that allows passwordless login. Alternatively, add custom login UI and call the Arcana Auth SDK methods for passwordless login. See [how to enable passwordless login](../../auth/onboard/vanilla/custom-ui/build-pwdless-auth/) for details.
## Deployment
______________________________________________________________________
Does each registered app have a single unique Client ID?
No.
Each app registered with the Arcana using the Arcana Developer Dashboard is assigned not one but two unique Client ID.
One for the Testnet configuration profile and a different Client ID for the Mainnet configuration profile.
What is the difference between Testnet and Mainnet?
Arcana Testnet and Mainnet are two **different** blockchain networks. The features offered by the Arcana Auth SDK available on Testnet may be different from the ones available on the Mainnet.
Following are the key differences between Arcana Testnet and Mainnet:
- **Client ID**: To deploy the app on Testnet, the developer must specify the Client ID assigned to the Testnet configuration profile after app registration, when creating the `AuthProvider`. Similarly, for Mainnet deployment, the Client ID assigned to the Mainnet configuration profile should be used.
- **Key/Wallet Address**: The authenticated user is assigned a unique key/wallet address for Testnet app deployment. The same user is assigned a different key/wallet address when this app is deployed on the Mainnet.
- **Billing**: App usage is tracked for both the Arcana Testnet as well as the Mainnet. However, only Mainnet usage is billed.
What is the difference in the in-app Arcana wallet behavior when an app is deployed on Testnet vs. the Mainnet?
If a user logs into the app that is integrated with the Arcana Auth SDK and deployed on the Arcana Testnet, they will see a warning on the main 'Token Assets' tab of the built-in Arcana wallet UI. The warning indicates that the app is deployed on the Testnet.
There is no such warning displayed in the Arcana wallet UI when the app is deployed on the Mainnet.
How does a developer migrate an app deployed on the Arcana Testnet to Mainnet?
See [how to migrate an app deployed on Testnet to Mainnet](../../deploy/migrate-testnet-mainnet/) for details.
Are there any configuration changes that must be done when migrating an app deployed on Testnet to the Mainnet?
Yes. Following are the configuration changes required for migrating app deployment from the Testnet to the Mainnet:
**1. Create a Mainnet Configuration Profile**: To deploy the app on Mainnet, developers need to first create a Mainnet configuration profile by either copying the Testnet profile or creating a fresh one from scratch.
**2. Redirect URI**: After creating the 'Mainnet' profile, developers **must** also update the social login provider 'Redirect URI' settings via the respective provider developer consoles or dashboards.
Copy the 'Redirect URI' displayed for the 'Mainnet' profile and update this value in the social login provider's developer console. For e.g., for Google, update the Redirect URI in the Google Developer Console. [Learn more...](../../setup/config-social/google-oauth/)
**3. Update Client ID**: The Client ID specified as the input parameter while integrating the app with the Arcana Auth SDK is the one assigned to the default Arcana Testnet profile. This works fine when the app is deployed on the Testnet. For deploying the app on the Mainnet, the developer must create the Mainnet configuration profile and carefully copy the newly assigned Mainnet Client ID. Use the Mainnet Client ID as the input parameter while integrating the app with the Arcana Auth SDK. This will ensure that the app gets deployed on the Mainnet and not on the Testnet. For details, see [how to migrate an app deployed on the Testnet to the Mainnet.](../../deploy/migrate-testnet-mainnet/)
# Using MultiversX
## Configuration
______________________________________________________________________
Is MultiversX the only non-EVM chain supported by the Arcana Auth SDK?
No.
Refer to the [list of pre-configured, supported chains - EVM and non-EVM](../../web3-stack/chains/) for details.
Can a developer choose to use some EVM-compatible chains along with MultiversX in an app?
No. Either EVM-compatible chain type or MultiversX (non-EVM-compatible chain type) chains can be used at a time in an app. When a user logs into an app that is enabled for MultiversX the keys (wallet address) are different from the one assigned to the same user when EVM-compatible chain is selected or a different non-EVM chain is selected.
## Keys
Why are the MultiversX keys different from EVM-compatible chains?
MultiversX uses [BLS multi-signature](https://en.wikipedia.org/wiki/BLS_digital_signature) cryptographic keys.
BLS is different from the [secp256k1](https://www.secg.org/sec2-v2.pdf) curve used for EVM-compatible chains.
## Shard Selection
What is the impact of selecting the same shard in two different apps registered via the dashboard?
MultiversX uses [adaptive state sharding](https://docs.multiversx.com/technology/adaptive-state-sharding/) for horizontal scaling. Shards allow it to process far more transactions through parallelization, improving transaction throughput and efficiency.
If two apps are configured to use the same shard, then all the app interactions whether they are with the app contracts on the same shard or between the wallets of the users across these two apps will be faster.
## Seed Phrase
When is the seed phrase displayed?
When you log into a Web3 app for the first time that uses the MultiversX chain and integrates with the Arcana Auth SDK, the system displays a 24-word seed phrase. You can copy this seed phrase or save it as a PDF file using the "print as PDF" option. You must verify and save this seed phrase immediately, as it will not be shown again. After this initial display, you won't be able to access the seed phrase through the Arcana wallet interface in future logins.
## Export MVX Wallet
How can a user export MVX wallet credentials from the app using the Arcana Auth SDK?
When you first log into a Web3 app using the MultiversX chain and Arcana Auth SDK, copy and save the seed phrase securely. Use this seed phrase to access your MVX wallet via the MVX Portal or MVX Wallet app. [Learn more...](https://docs.multiversx.com/wallet/wallet-extension/#import-existing-wallet)
# Using Near
## Configuration
______________________________________________________________________
Is Near the only non-EVM chain supported by the Arcana Auth SDK?
No.
Refer to the [list of pre-configured, supported chains - EVM and non-EVM](../../web3-stack/chains/) for details.
Can a developer choose to use some EVM-compatible chains along with Near in an app?
No. Either EVM-compatible chain type or Near (non-EVM-compatible chain type) chains can be used at a time in an app. When a user logs into an app that is enabled for Near chain, the keys (wallet address) are different from the ones assigned to the same user when an EVM-compatible chain is selected or a different non-EVM chain is selected.
## Keys
Why are the Near keys different from EVM-compatible chains?
TBD
# Using Solana
## Configuration
______________________________________________________________________
Is Solana the only non-EVM chain supported by the Arcana Auth SDK?
No.
Refer to the [list of supported chains - EVM and non-EVM](../../web3-stack/chains/) for details.
Can a developer choose to use some EVM-compatible chains along with Solana in an app?
No. Either EVM-compatible chain type or Solana (non-EVM-compatible chain type) chains can be used at a time in an app. When a user logs into an app that is enabled for Solana the keys (wallet address) are different from the one assigned to the same user when EVM-compatible chain is selected.
## Keys
Why are the Solana keys different from EVM-compatible chains?
The cryptographic keys used by Solana are based on [ED 25519 curve](https://en.wikipedia.org/wiki/EdDSA#Ed25519). This is different from the [secp256k1](https://www.secg.org/sec2-v2.pdf) curve used for EVM-compatible chains.
# Validator Onboarding
Frequently asked questions regarding setting up [Arcana DKG validator nodes](../../concepts/validator-nodes/).
## General
______________________________________________________________________
What role do validators play in the Arcana Network?
Validator nodes refer to partner infrastructure that participates in the distributed key generation protocol (DKG). This is used to assign unique keys to authenticated users and manage them in a decentralized manner.
Validators play a key role in achieving the decentralization goal thereby making Arcana Network more secure and truly open.
Where do I get the DKG binaries from?
Refer to the [latest DKG release](https://github.com/arcana-network/adkg/releases) at GitHub.
What is starting ceremony?
It is mandatory for all nodes in the Arcana DKG subsystem to start at the same time for the protocol to function correctly. This is referred to as the starting ceremony aimed at synchronizing the start of DKG nodes.
Node crashed at startup with 'tx fees exceed the configured cap' error
DKG Node Start Error
You will see this error if you are not using the latest DKG binary. After the node crash, before restarting, please make sure that there is no `dkg.sock` file and that you are using the [latest DKG release](https://github.com/arcana-network/adkg/releases) before issuing the `dkg start` command. See [restarting a node](../../validators/onboard-validators/#steps) section in the Arcana Auth Validator Onboarding Guide.
After starting up, I see this. Is this an error?
Current Node List Error
This is not an error. Your validator node is waiting and polling for the other nodes to start up and join in the DKG protocol.
How do I fix the polyfilling issues right after import statement when integrating React and Vite app with the Arcana CA SDK?
To fix polyfilling issues, make sure `vite.config.ts` has the polyfilling options configured.
```
import { defineConfig, Plugin } from "vite";
import react from "@vitejs/plugin-react";
import { nodePolyfills, PolyfillOptions } from "vite-plugin-node-polyfills";
import tailwindcss from "@tailwindcss/vite";
const nodePolyfillsFix = (options?: PolyfillOptions | undefined): Plugin => {
return {
...nodePolyfills(options),
resolveId(source: string) {
const m =
/^vite-plugin-node-polyfills\/shims\/(buffer|global|process)$/.exec(
source
);
if (m) {
return `node_modules/vite-plugin-node-polyfills/shims/${m[1]}/dist/index.cjs`;
}
},
};
};
// https://vite.dev/config/
export default defineConfig({
plugins: [
react(),
tailwindcss(),
nodePolyfillsFix({
include: ["buffer"],
globals: {
Buffer: true,
global: true,
process: true,
},
}),
],
define: {
"process.env": {},
},
});
```
Is there a refund if a chain abstracted transaction fails after funds have been pulled out of the source chains in the user's EOA?
For chain abstracted transaction safety, follow these guidelines:
1. **Failed transactions?** *Don't panic* - you'll get your tokens back automatically in the next settlement cycle (usually within 15 minutes but it may take an hour in some cases).
1. **Before transacting:** Always check the transaction details including the gas fee requirements, before issuing a transaction.
1. **During transacting:** The status of the chain abstracted transaction is displayed in the app's context. Click on 'View Intent' details link and **save** the unique intent identifier associated with the transaction. You'll need the **intent identifier** if something goes wrong.
1. **Track your transaction:** Use the [Arcana Intent Explorer](https://explorer.arcana.network/) with your intent ID to monitor status. **Critical:** Keep your app/wallet open and logged in if you encounter a failed transaction—refunds require an active session and typically complete within 15 minutes.
1. **No refund after 1 hour:** The protocol auto-retries, but you must stay logged in. If you closed the app/wallet, reopen and log back in to enable refund processing. Did not get a refund? Contact Arcana team via the [support](../../../support/) channels and make sure you mention the **intent identifier** that failed to refund or your wallet address with date / time of the transaction.
**Bottom line:** Your funds are protected - failed transactions always get refunded, either automatically or with the team's assistance.
Viewing Refund
To view the refund, the user must open or log into the app and access the wallet that was used to sign the intent and confirm the chain abstracted transaction.
Why is liquidity fragmentation an issue and how does chain abstraction solve it?
Liquidity fragmentation is an issue because it makes it difficult for users to spend their assets on any chain.
Let us take a simple case of a user's wallet that contains 3 USDC on Arbitrum and 2 USDC on Optimism. If the user intends to send 4 USDC on Base, it is not possible to do so through a traditional wallet because there is liquidity fragmentation for USDC in the wallet across Arbitrum and Optimism. To be able to send USDC on Base, there are multiple complex steps for the user.
First, there is no USDC on Base to be sent. The user cannot directly spend USDC on Base even though there are enough USDC tokens when put together on the other two chains in the same wallet account. To spend on Base, the user has to bridge tokens from one or more source chains. That is a complex, multi-step, multi-click, time-consuming process. It also needs non-trivial knowhow about secure bridging and getting the best token exchange deals. Next, the user is required to switch the network to Base and then send the tokens.
[Chain Abstraction (CA)](../../../concepts/ca/chain-abstraction/) enables unified balance across source chains that can help the user spend 4 USDC on Base with a single click. The user is not required to manually convert the tokens on Optimism or Arbitrum to make this transaction on Base. With a unified balance, onboarding a new chain does not necessarily require the user to procure tokens on the new chain. The user can pledge or sign an intent to send tokens from any of the source chains to the destination chain.
I'm a Web3 dApp developer. how can I enable unified balance for dApp users?
Download and [install the appropriate CA SDK flavor](../../../ca/ca-sdk-installation/) as per the app type.
- **Web3 apps**: Install the [Arcana CA SDK](https://www.npmjs.com/package/@arcana/ca-sdk). Check out the integration example in [codesandbox](https://codesandbox.io/p/github/arcana-network/ca-sdk-example/main)
- Web3 apps using the **Wagmi library**: Install the [Arcana CA Wagmi SDK](https://www.npmjs.com/package/@arcana/ca-wagmi). Try the [codesandbox](https://codesandbox.io/p/github/arcana-network/ca-wagmi-example/main) integration example.
Refer to the respective SDK quick start guide for integration details.
I'm a Web3 wallet user, how can I enjoy unified balance with chain abstraction?
Web3 wallet users can unify assets across chains and spend on any chain. To do this, they must log into a Web3 app that is integrated with the Arcana CA SDK and supports any third-party browser-based wallet.
Alternatively, wallet users can [download](https://chromewebstore.google.com/detail/arcana-wallet/nieddmedbnibfkfokcionggafcmcgkpi) and install the Arcana Standalone CA wallet browser extension to try [unified balance](../../../concepts/ca/unified-balance/) in the context of some of the popular [Web3 apps](../../../web3-stack/ca_stack/#apps).
Why do users need to pay gas fees to set up CA with Layer 1 chains?
When setting up Arcana chain abstraction to include Layer 1 chains, users need ETH to pay gas fees for signing the token allowance transaction with the Arcana vault smart contract. The Arcana standalone CA wallet doesn't cover these Layer 1 chain gas fees. As a result, users who choose to include Layer 1 chains in their CA scope must pay these gas fees themselves to set up the CA allowance.
What is a CA allowance and why are allowances needed?
Allowance or 'Permit' in the blockchain context allows a third party, such as a smart contract, to perform transactions from a user's EOA for a specified amount — without accessing the user's private key.
In Arcana chain abstraction, [allowances](../../../concepts/ca/allowances/) enable unified balance. This lets users spend on any destination chain when they have enough funds and gas fees on their source chains.
Which ERC20 tokens does the unified balance feature support?
Refer to the latest [supported token list](../../../web3-stack/ca_stack/#tokens).
Which chains does the unified balance feature support?
Arcana's chain abstraction and unified balance works for some select [chains](../../../web3-stack/ca_stack/#chains) and [tokens](../../../web3-stack/ca_stack/#tokens). We are working on adding support for more chains in the future.
Does dApp integration with the Arcana CA SDK enable an in-app wallet like the Auth SDK?
No there is no built-in in-app wallet offered by the Arcana SDKs. Web3 apps integrating with the Arcana CA SDK must use a third-party wallet for blockchain transactions.
How does a dApp access unified balance for a user account?
The dApp must download and integrate with the CA-SDK and use the EIP-1193 provider to access the unified balance in the context of an authenticated user. See [Arcana CA SDK Reference](https://ca-sdk-ref-guide.netlify.app/) and [the usage guide](../../../ca/ca-usage-guide/) for details.
Does the Arcana CA SDK enable unified balance and chain abstracted transactions in a Web3 app built using Wagmi?
For Web3 app built using Wagmi, integrate with the Arcana CA Wagmi SDK.
How do I enable unified balance and chain abstracted `sendTransaction`, `bridge` and `transfer` functions in a Web3 app that uses the Wagmi library?
To enable unified balance and chain abstraction in a Web3 app that uses the Wagmi library, integrate the app with the Arcana CA Wagmi SDK. This SDK replaces the Wagmi hooks: `useSendTransaction` and `useWriteContract`. Additionally, it provides hooks such as `useBalance`, `useBalanceModal` and `useCAFn` to enable unified balance plug-and-play popup modal and chain abstracted `bridge` and `transfer` functions. For details see [Arcana CA Wagmi SDK Quick Start Guide](../../../quick-start/ca-wagmi-quick-start/) and the [Arcana CA Wagmi SDK Reference](https://ca-wagmi-sdk-ref-guide.netlify.app/).
Who is the target audience for the Arcana CA SDKs?
Arcana CA SDKs help Web3 dApp developers handle fragmented blockchain assets, letting users spend on any chain. These SDKs can integrates with dApps to offer unified balances across chains and chain abstracted transactions.
For a complete list of real life applications of unified balance, see [use cases](../../../ca/introduction/use-cases/) section.
Who is the target audience for the standalone Arcana standalone CA wallet?
The standalone Arcana standalone CA wallet is meant for wallet users that want to try unified balance in the context of some of the popular [Web3 apps](../../../web3-stack/ca_stack/#apps).
It enables unified balance and solves liquidity fragmentation when using any of the supported [chains](../../../web3-stack/ca_stack/#chains) and [tokens](../../../web3-stack/ca_stack/#tokens) in the context of these supported [Web3 apps](../../../web3-stack/ca_stack/#apps). We will be adding support for newer Web3 apps soon.
$100 limit
The standalone Arcana standalone CA wallet has a $100 limit for transactions needing chain abstraction. Transfers on the same chain have no limit.
Can you give me an example of liquidity fragmentation and how the CA SDK solves it?
**Liquidity Fragmentation**
Imagine a user with assets spread across chains:
Arbitrum: 3 USDC Optimism: 4 USDC Base: 0 USDC Ethereum: 0.001 ETH
If the user wants to send 5 USDC to Base, they can't because no single chain has enough funds. Liquidity fragmentation forces the user to make multiple transactions, complicating the process.
**How unified balance through chain abstraction solves this?**
With chain abstraction, users first set up allowances before issuing a multi-chain transaction intent.
In this case, the user signs an intent to send 5 USDC to Base by pledging 3 USDC from Arbitrum and 2.2 USDC from Optimism (including gas and service fees). The intent specifies the amount to be deposited on source chains and the agreed amount received on the destination chain.
Arcana's Chain Abstraction protocol collects the pledged tokens and gas fees based on the user's allowances. Once the intent is signed, Arcana processes the 5 USDC transaction on Base and deducts the gas fee from the pledged USDC.
Can I request gas tokens using ERC20 through Arcana Chain Abstraction??
Yes, you can request gas tokens using ERC20 via Chain Abstraction.
For example, if you have 13 USDC and 0 ETH on Optimism but need to make a 15 USDC transaction requiring 0.0000001 ETH for gas, you'll need an extra 2 USDC plus the gas fee.
You can pledge or sign an intent to pay the additional USDC and gas fees using funds from other supported chains like Arbitrum or Base, assuming you have enough USDC to cover the deficit and fees.
Once you sign the intent, Arcana CA SDK supplies the needed USDC and gas in a single transaction. Charges include the deficit amount, CA Gas Fees, protocol fees, and Solver fees.
*Note: Fees are deducted from the main token requested, such as USDC. Arcana CA SDK supports ETH, USDC, and USDT.*
Can a user review intent details before issuing a transaction that requires chain abstraction with two or more source chain tokens?
Yes, user's can review the intent details before issuing a CA transaction via the Arcana CA Wallet. Before submitting a transaction, click 'View Intent' to see the intent details. Once the transaction is successful, there are options to view the intent details as well as the transaction details.
To view the intent details at a later point in time, you need to save the intent identifier displayed in the details during the transaction, before closing the wallet screen.
Use the Arcana Intent Explorer accessible at: AuthProvider] --> F1[Social Login Fns]
E1 --> G1[Web3 Wallet Ops]
end
classDef an-pink stroke:#ff4e9f,stroke-width:0.25rem;
class C1 an-pink
```
**Key Features**
- Onboard users quickly, at scale, via popular [social login providers](../web3-stack/auth/).
- Provide instant access to use the in-app, non-custodial Arcana wallet.
- Easy to customize and integrate with various [Web3 app types](../auth/sdk-installation/).
Current Version
Arcana CA SDK: Use [**v1.0.1**](https://www.npmjs.com/package/@arcana/ca-sdk).
Arcana Auth SDK: Use [**v1.0.12**](https://www.npmjs.com/package/@arcana/auth). Older versions may encounter potential breaking changes that require app reconfiguration, integration code updates, and redeployment.[Migrate](../migration/main-auth-v1.0.12-migration/) **Arcana Auth SDK v1.0.11 -> v1.0.12**.
## See Also
- [Wallet User Guide](../user-guides/wallet-ui/)
- [Dashboard User Guide](../setup/config-dApp-with-db/)
- [Auth SDK](../concepts/authsdk/)
# Arcana Auth SDK v0.2.x -> v0.3.0 Migration
This guide is meant for developers who have already integrated apps with an older version of the Arcana Auth SDK and run them using Arcana Network Testnet. If you are new to Arcana Auth SDK, see Quick Start Guides to get started.
When you migrate from an older version of the Arcana Auth SDK to v0.3.0, there are some breaking changes. These changes are mostly related to deploying an app on the Arcana Testnet and the use of Arcana Storage SDK (no longer supported). No breaking changes are expected in the Arcana Auth SDK usage related to user onboarding or blockchain transaction signing functions. Also, the Arcana wallet has a revamped, better look in this release.
## What has Changed?
- This release **does not** contain Arcana Storage SDK.
- Arcana Blockchain is no longer listed in the list of available blockchain networks in the Arcana wallet dropdown.
- Now you can use the Arcana Auth SDK and the Arcana wallet on any supported EVM-compatible chain for user onboarding and signing of blockchain transactions.
- The blockchain transaction activity is no longer available in the form of a tab in the main Arcana wallet. You can see the activity listed in the newly added combined notification screen in the Arcana wallet .
### Arcana Developer Dashboard
- In this release there are some breaking changes in the registered application database schema. If you were already using an older version of the Arcana Auth SDK, you need to re-register and configure your application again using the latest Arcana Developer Dashboard. The **Client ID** assigned to you earlier will not work. You need to re-register and obtain a new one. Make sure you use the new **Client ID** while integrating with the Arcana Auth SDK .
### Arcana Auth SDK
- In this release there is no usage change in the Arcana Auth SDK.
- After re-registering your app, the dashboard will assign a new **Client ID**. You need to use the new Client ID during integration with the Arcana Auth SDK.
## How to Migrate to v0.3.0
1. You need to re-register your app using the Arcana Developer Dashboard. This is required to obtain a fresh **Client ID** and use that for integrating with the Arcana Auth SDK. The older **Client ID** will **NOT WORK** with the latest Arcana Auth SDK v0.3.0 release. Follow the instructions in the [Registration Guide](../../setup/config-auth/register-app/) to re-register and re-configure your app.
1. If you were using the Arcana Storage SDK, that is no longer supported. You need to stop using Storage SDK in your app for the time being until we begin supporting Storage SDK in a future release.
1. You need to [re-integrate your app with the Arcana Auth SDK](../../auth/integrate/vanilla-html-css-js/) by providing the new **Client ID** after re-registering and configuring your application using the developer dashboard.
1. If you had enabled the **Arcana Testnet** blockchain network in Web3 wallet operations, you will need to remove this network altogether as it no longer exists. Also, the Arcana Testnet Blockchain Explorer is no longer available. Arcana smart contracts are deployed on Polygon now. In this release, the Arcana wallet supports all EVM-compatible chains besides the default ones that show in the drop-down. See [Wallet User Guide](../../user-guides/wallet-ui/use-wallet-ui/).
1. The wallet activity tab on the wallet token asset tab is gone. A new 'notification' tab is available in the wallet. You can see the list of all activities in the [activity tab](../../user-guides/wallet-ui/use-wallet-ui/#transaction-activity). It lists send tokens, contract deployment, and contract interaction transactions performed by the wallet user.
## What's New?
The new improved Arcana Auth SDK now supports NFT preview, NFT transactions, and management of NFT collections. A new combined notification screen displays blockchain transactions related to smart contracts, tokens as well as NFTs. For details, see [Arcana Auth SDK release notes](../../relnotes/rn-beta-auth-v0.3.0/).
New to Arcana Network? Get started with the Arcana Auth SDK Quick Start Guides.
Using an older version and want to migrate? Read on...
## What has Changed?
If you are already using the SDK, there are no usage changes in this release.
This new release includes support for Custom Auth and wallet UI features for off-ramping crypto to fiat.
## How to Migrate to v1.0.12?
Install and upgrade to the latest Arcana Auth SDK v1.0.12. No integration code updates are required for the features in the previous release.
If you plan on using the Passkeys, check out the section about [Passkeys](../../concepts/authtype/auth-passkeys/) and [how to onboard users via passkeys](../../auth/passkeys-auth/) in apps integrated with the Arcana Auth SDK. See how to set up user onboarding via [Telegram, Apple](../../setup/) in the setup section of the documentation. Then refer to the usage section for [how to install the SDK, integrate app and onboard users](../../auth/sdk-installation/) depending upon the app type.
That's all!
## Previous Releases
Are you using an older version of the Arcana Auth SDK?
Refer to the [release notes archive](../../relnotes/archives/) and [Migration Guides](../archives/). Upgrade to the latest version.
## Questions?
______________________________________________________________________
Refer to the [Arcana Auth FAQ](../../faq/faq-gen/), [Troubleshooting Guide](../../troubleshooting/), and other developer resources.
Can't find what you are looking for? Contact [Arcana Support](../../support/).
# Arcana Auth SDK v0.3.0 -> v1.0.0 Migration
This guide is meant for developers who have already integrated apps with an older version of the Arcana Auth SDK and run them using Arcana Network Testnet.
If you are new to Arcana Network, see Arcana Auth SDK Quick Start Guides to get started.
When you migrate from using the Arcana Auth SDK v0.3.0 to the v1.0.0 release, please note that there are a few breaking changes that require you to use Arcana Developer Dashboard and re-register, re-configure the app settings as per the Arcana Auth SDK configuration setting requirements, and obtain a new **Client ID**. Only then you can re-integrate the app successfully with the Arcana Auth SDK .
## What has Changed?
The following section lists changes between Arcana Auth SDK v0.3.0 and v1.0.0.
Use Latest Release
If you are using Arcana Auth SDK v0.2.2 or older, please see [How to migrate to Arcana Auth SDK v0.3.0](../beta-auth-v0.3.0-migration/).
### Arcana Developer Dashboard
Earlier, by default, each registered application was associated with a 'Testnet' configuration profile and an **Client ID**. Now you can have a 'Testnet' as well as a 'Mainnet' configuration profile associated with your registered application. Each profile has its unique **Client ID**. You can deploy an app on the Arcana Testnet and run another instance (a stable version) on the Arcana Mainnet.
#### Mainnet Configuration Profile
- By default, when any new application is registered and configured, a 'Testnet' profile is created. The new dashboard allows developers to also create a 'Mainnet' configuration profile for the app. Developers can create a Mainnet profile and switch to using the Arcana Mainnet or deploy two instances of their app, one for Testnet and the other for Mainnet.
- To create the 'Mainnet' profile you can choose to copy the existing 'Testnet' profile or create a new 'Mainnet' configuration profile. Note that a unique, **new Client ID** is assigned to the 'Mainnet' profile whether it is copied or created afresh.
- To deploy an app on the Arcana Mainnet, developers are required to perform two things:
- First, use the dashboard to create a 'Mainnet' configuration profile for the app and obtain a **new Client ID**.
- Second, the developers must also re-integrate their app and update the code where they instantiate the `AuthProvider` appropriately so that the 'Mainnet' **Client ID** is used and the `network` parameter is initialized as `mainnet` in the `AuthProvider` constructor.
#### Keyspace in Mainnet Deployments
- The 'Mainnet' configuration profile for the app has an additional setting meant for selecting the **Keyspace** type. Developers can choose between the default **App-specific Keys** or **Global Keys**. [Global Keyspace](../../concepts/keyspace-types/) enables a better user experience whereby the user is assigned the same wallet address across applications in the Arcana ecosystem in a secure manner. Enabling the global keys feature requires developer verification and whitelisting. For details, see ['How to Configure Keyspace'](../../setup/config-dApp-with-db/#configure-keyspace) section in the Dashboard User Guide.
#### Usage Tracking
- In this release, the Developer Dashboard tracks application usage data in terms of MAU, both for Arcana Testnet as well as Mainnet deployments. Billing is applicable only for Mainnet deployments and bills are generated at the end of the month for Arcana Mainnet usage.
### Arcana Auth SDK
The Arcana Auth SDK v1.0.0 supports deploying apps on the Arcana Mainnet. As there are breaking changes in the App database schema, you need to re-register your apps using the Arcana Developer Dashboard and obtain a new **Client ID** before you can integrate the app with the Arcana Auth SDK . This is required irrespective of whether you chose to deploy your app on the Arcana Testnet or the Mainnet.
To deploy an app on the Arcana Mainnet, you need to first login into the Arcana Developer dashboard, create a 'Mainnet' configuration profile for your app and choose the requisite 'Keyspace' type. In addition to creating the 'Mainnet' configuration profile, developers need to update the Arcana Auth SDK integration code for creating a new `AuthProvider` as follows:
- Use the **Client ID** specified to the 'Mainnet' configuration profile in the dashboard
- Set the `network` parameter in the `AuthProvider` constructor to 'mainnet'
## How to Migrate to v1.0.0?
*Do not jump into installing, and upgrading the Arcana Auth SDK in your sources and running your app.*
To successfully use the Arcana Auth SDK, you need to first **re-create your app configuration profile** using the Arcana Developer Dashboard and then integrate your app with the Arcana Auth SDK for onboarding users and enabling the Arcana wallet.
If you wish to deploy your app on Arcana Testnet, follow steps 1 and 3. To deploy your app on Arcana Mainnet, follow all three steps:
1. **Reconfigure & Get Client ID**: If you are using v0.3.0, you would already have created a 'Testnet' configuration profile for your app. When you log into the dashboard, this profile will not show up by default. Due to breaking changes in the Arcana Auth SDK release v1.0.0, you will be required to re-register your app using the Arcana Developer Dashboard. When you re-register and create a new profile for the app, by default, it is assigned as a 'Testnet' configuration. This step is mandatory irrespective of whether you want to deploy your app on Arcana Testnet or Mainnet or both.
1. **Mainnet Configuration**: To deploy your app on the Arcana Mainnet, you must first create a 'Mainnet' configuration profile using the Arcana Developer Dashboard. See instructions [here](../../setup/config-dApp-with-db/#manage-configuration-profiles). Once you have the 'Mainnet' configuration profile ready, copy the new **Client ID** assigned to the 'Mainnet' configuration profile. This will be required during Arcana Auth SDK integration later. At the time of 'Mainnet' profile creation, you need to specify whether you would like to use the **App-specific Keys** (default) or use the **Global Keys** feature for your app. To enable the global keys feature, developers must submit a verification form and get approval. Wait to onboard users until you receive a response to your verification request. Otherwise, the wallet address assigned to your app users may change after the **Global Keys** feature takes effect. If you do not choose **Global Keys**, your 'Mainnet' profile is configured to use **App-specific** keys by default. What this means is that your app users will see different wallet addresses across different apps in the Arcana ecosystem. For details, see [Global Keys](../../concepts/keyspace-types/).
Update Redirect URI for Mainnet
You must update the OAuth redirect URI values for all the social providers configured for your 'Mainnet' profile. Use the respective social provider console to update callback URL values for Mainnet. Copy the new **redirect URI** value from the application's 'Mainnet' configuration settings dashboard page and add it to the list of redirect URIs setup in the OAuth configuration settings for your provider. You would have earlier added the redirect URI for the 'Testnet' configuration profile, now update the 'Mainnet' URI too. That's all.
1. **Install & Integrate**: Install and upgrade the Arcana Auth SDK to v1.0.0. Integrate the Arcana Auth SDK and create a new `AuthProvider` instance by specifying the **Client ID**. If you wish to deploy your app on the Arcana Testnet, provide the **Client ID** listed in the 'Testnet' configuration profile of your app in the dashboard. Also, you need to set the `network` parameter in the `AuthProvider` constructor to `testnet`. This is important because, by default, Arcana Auth SDK v1.0.0 has the `network` parameter set to using 'mainnet'. Similarly, if you want to deploy your app on the Arcana Mainnet, then use the **Client ID** assigned to the 'Mainnet' configuration profile of your app in the dashboard and set the `network` parameter to 'mainnet'.
Refer to the examples below to see how to integrate and deploy your app on the Arcana Testnet and Mainnet after successfully registering and configuring the app.
### Example: Deploy on Testnet
Register your app using the Arcana Developer Dashboard. By default, the 'Testnet' configuration profile is created. You can provide the social provider settings as per your user onboarding requirements. Save the **Client ID** assigned to your app displayed on the top right of the dashboard screen. This will be required during integration with the Arcana Auth SDK as shown below:
```
import {AuthProvider} from "@arcana/auth";
const provider = new AuthProvider(
"xar_test_87f34a9c7879cd4b726ba36a99e164837d70143a", { // testnet Client ID
// network: 'testnet', // optional
chainConfig: {
chainId: '80002', // selected chain in the wallet network dropdown UI
rpcUrl: 'https://rpc.ankr.com/polygon_amoy', // RPC URL of the selected chain in the wallet network dropdown UI
},
alwaysVisible: true,
setWindowProvider: true,
debug: true,
position: 'right',
theme: 'dark',
});
```
Once a user authenticates, the following wallet UI is displayed when the app is deployed on the Arcana Testnet.
Testnet Wallet
### Example: Deploy on Mainnet
Register your app using the Arcana Developer Dashboard. By default, the 'Testnet' configuration profile is created. Make sure you create a 'Mainnet' profile and save the **Client ID** assigned to your app for the 'Mainnet' configuration. It is displayed on the top right of the dashboard screen.
To bring up your app on Arcana Mainnet, in your integration code, use the `Mainnet` **Client ID** and specify the `network` parameter as 'mainnet' while instantiating the `AuthProvider` as shown below:
```
import {AuthProvider} from "@arcana/auth";
const provider = new AuthProvider(
"xar_live_d7c88d9b033d100e4200d21a5c4897b896e60063", { //mainnet Client ID
// network: 'mainnet', // optional
chainConfig: {
chainId: '137', // selected chain in the wallet network dropdown UI
rpcUrl: 'https://polygon-rpc.com/', // RPC URL of the selected chain in the wallet network dropdown UI
},
alwaysVisible: true,
setWindowProvider: true,
debug: true,
position: 'right',
theme: 'dark',
});
```
Once a user authenticates, the following wallet UI is displayed when the app is deployed on the Arcana Mainnet.
Mainnet Wallet
## What's New?
Besides Testnet/Mainnet and Global Keyspace features, the Arcana Auth SDK v1.0.0 uses a new, improved asynchronous distributed key generation (ADKG) subsystem. In addition to the DKG nodes operated by Arcana, two nodes are run and managed by Comdex and LugaNodes.
For more details, see [Arcana Auth SDK v1.0.0 release notes](../../relnotes/rn-main-auth-v1.0.0/) for details.
# Arcana Auth SDK v1.0.0 -> v1.0.1 Migration
This guide is meant for developers who have already integrated apps with Arcana Auth SDK v1.0.0 and run them using Arcana Testnet.
If you are new to Arcana Network, see Arcana Auth SDK Quick Start Guides to get started.
## What has Changed?
The following section lists changes between Arcana Auth SDK v1.0.0 and v1.0.1.
### Arcana Developer Dashboard
No changes or updates in the dashboard usage.
### Arcana Auth SDK
When you migrate from using the Arcana Auth SDK v1.0.0 to the v1.0.1 release, there is no breaking change or reconfiguration required. The default setting of the `network` parameter in the `AuthProvider` constructor has changed. Earlier it was set to 'mainnet' but now it is set to 'testnet' by default.
## How to Migrate to v1.0.1?
1. If you are deploying your app on the Arcana Testnet, make sure that the app integration code uses the **Client ID** specified in the 'Testnet' configuration profile in the app dashboard. You can set the `network` parameter in the `AuthProvider` constructor as 'testnet' but it is not essential since the default setting in the Arcana Auth SDK v1.0.1 is 'testnet'.
1. If you are deploying your app on the Arcana Mainnet, make sure that the app integration code uses the **Client ID** assigned to the 'Mainnet' configuration profile in the app dashboard. Also, you need to specify the `network` parameter in the `AuthProvider` constructor as 'mainnet' in order to deploy your app on the Arcana Mainnet. This is important because, by default, the Arcana Auth SDK uses 'testnet' as the default `network` value.
1. Upgrade your Arcana Auth SDK to v1.0.1 and you are good to go.
### Example: Deploy on Testnet
If you have not already registered, only then register your app using the Arcana Developer Dashboard. By default, the 'Testnet' configuration profile is created. You can provide the social provider settings as per your user onboarding requirements. Save the **Client ID** assigned to your app displayed on the top right of the dashboard screen. This will be required during integration with the Arcana Auth SDK as shown below:
```
import {AuthProvider} from "@arcana/auth";
const provider = new AuthProvider(
"xar_test_87f34a9c7879cd4b726ba36a99e164837d70143a", { // testnet Client ID
// network: 'testnet', // optional
chainConfig: {
chainId: '80002', // selected chain in the wallet network dropdown UI
rpcUrl: 'https://rpc.ankr.com/polygon_amoy', // RPC URL of the selected chain in the wallet network dropdown UI
},
alwaysVisible: true,
setWindowProvider: true,
debug: true,
position: 'right',
theme: 'dark',
});
```
Once a user authenticates, the following wallet UI is displayed when the app is deployed on the Arcana Testnet.
Testnet Wallet
### Example: Deploy on Mainnet
If you have not already registered your app using theArcana Developer Dashboard , only then register it. By default, the 'Testnet' configuration profile is created and associated with a 'Testnet' **Client ID**. If you want to deploy on the Arcana Mainnet, then make sure you create a 'Mainnet' profile using the Arcana Developer Dashboard. Save the **Client ID** assigned to your app for the 'Mainnet' configuration. It is displayed on the top right of the dashboard screen when you select 'Mainnet' from the dropdown or when you click on the 'Mainnet' button displayed on the app card in the **Manage Apps** screen.
In the app integration code, use the `Mainnet` **Client ID** and specify the `network` parameter as 'mainnet' while instantiating the `AuthProvider` as shown below:
```
import {AuthProvider} from "@arcana/auth";
const provider = new AuthProvider(
"xar_live_d7c88d9b033d100e4200d21a5c4897b896e60063", { //mainnet Client ID
// network: 'mainnet', // optional
chainConfig: {
chainId: '137', // selected chain in the wallet network dropdown UI
rpcUrl: 'https://polygon-rpc.com/', // RPC URL of the selected chain in the wallet network dropdown UI
},
alwaysVisible: true,
setWindowProvider: true,
debug: true,
position: 'right',
theme: 'dark',
});
```
Once a user authenticates, the following wallet UI is displayed when the app is deployed on the Arcana Mainnet.
Mainnet Wallet
## What's New?
This release has no new features.
For more details about this release, see [Arcana Auth SDK v1.0.1 release notes](../../relnotes/rn-main-auth-v1.0.1/) for details.
# Arcana Auth SDK v1.0.9 -> v1.0.10 Migration
New to Arcana Network? Visit see Arcana Auth SDK Quick Start Guides to get started.
Using an older version and want to migrate? Read on...
## What has Changed?
In this release there are **no usage changes** from the previous version of the SDK.
This new release includes support for Web3 gaming apps based on the Unity framework, support for MultiversX chain in the Arcana wallet, and minor bug fixes.
## How to Migrate to v1.0.10?
Install the latest Arcana Auth SDK v1.0.10. No integration code updates are required for the features in the previous release.
### MultiversX Support
If you wish to use this new release and add support for MultiversX in your app, there may be some changes related to the [configuration of MultiversX](../../setup/config-dApp-with-db-for-mvx/) as the default chain in the dashboard. Note that the [supported Web3 wallet operations for the MultiversX chain](../../auth/web3-ops/mvx/) are different from those for the EVM-compatible chains. See [MultiversX Quick Start Guide](../../quick-start/mvx-quick-start/) for more details.
That's all!
# Arcana Auth SDK v1.0.10 -> v1.0.11 Migration
New to Arcana Network? Get started with the Arcana Auth SDK Quick Start Guides.
Using an older version and want to migrate? Read on...
## What has Changed?
In this release there are **no usage changes** from the previous version of the SDK.
This new release includes support for Custom Auth and wallet UI features for off-ramping crypto to fiat.
## How to Migrate to v1.0.11?
Install and upgrade to the latest Arcana Auth SDK v1.0.11. No integration code updates are required for the features in the previous release.
If you plan on using the Custom Auth or wallet off-ramping feature, check out the following documentation updates:
- What is [Custom Auth](../../concepts/authtype/custom-auth/)?
- [How to configure](../../setup/config-custom-auth/) Custom Auth feature usage via the Arcana Developer Dashboard?
- [How to integrate an app that uses custom user authentication](../../auth/custom-auth/) and enable Arcana Auth SDK and signing of blockchain transactions for authenticated users?
- [How to buy/sell crypto](../../user-guides/wallet-ui/use-wallet-ui/#buysell-crypto) when using Arcana wallet?
That's all!
# Arcana Auth SDK v1.0.11 -> v1.0.12 Migration
New to Arcana Network? Get started with the Arcana Auth SDK Quick Start Guides.
Using an older version and want to migrate? Read on...
## What has Changed?
If you are already using the SDK, there are no usage changes in this release.
This new release includes support for Custom Auth and wallet UI features for off-ramping crypto to fiat.
## How to Migrate to v1.0.12?
Install and upgrade to the latest Arcana Auth SDK v1.0.12. No integration code updates are required for the features in the previous release.
If you plan on using the Passkeys, check out the section about [Passkeys](../../concepts/authtype/auth-passkeys/) and [how to onboard users via passkeys](../../auth/passkeys-auth/) in apps integrated with the Arcana Auth SDK. See how to set up user onboarding via [Telegram, Apple](../../setup/) in the setup section of the documentation. Then refer to the usage section for [how to install the SDK, integrate app and onboard users](../../auth/sdk-installation/) depending upon the app type.
That's all!
# Arcana Auth SDK v1.0.1 -> v1.0.2 Migration
This guide is meant for developers who have already integrated apps with an older version of the Arcana Auth SDK and run them using Arcana Testnet.
If you are new to Arcana Network, see Arcana Auth SDK Quick Start Guides to get started.
When you migrate from using the Arcana Auth SDK v1.0.1 to the latest v1.0.2 release, there is no major update besides minor bug fixes and wallet UI updates.
## What has Changed?
The following section lists changes between Arcana Auth SDK v1.0.1 and v1.0.2.
### Arcana Developer Dashboard
**App Address** is now referred to as **Client ID** in the dashboard. The format of the unique identifier associated with all registered apps has changed.
### Arcana Auth SDK
- Arcana wallet now supports fiat/on-ramp feature that allows users to buy cryptocurrency and tokens.
- The wallet UI has a new minimized widget.
- A bug in the previous release allowed users to log into a different app using the same tab where they had logged in without having to explicitly log in to a different app in the same tab. This is now fixed. For details, see the [release notes](../../relnotes/rn-main-auth-v1.0.2/).
## How to Migrate to v1.0.2?
Upgrade the Arcana Auth SDK to the latest package v1.0.2. No other change is required. You **do not** need to re-register your apps via the dashboard. Developers can continue to use the old **App Address** obtained for using v1.0.0/v1.0.1 with the latest Arcana Auth SDK. However, if you re-register your app and get a new **Client ID**, you cannot use older versions of the Arcana Auth SDK and are required to migrate to the latest Arcana Auth SDK v1.0.2 or higher.
Client ID
Earlier, the documentation may have referred to the unique Arcana identifier assigned to each app after registration as **App Address**. In the latest release, we refer to it as **Client ID**.
## What's New?
See [Arcana Auth SDK v1.0.2 release notes](../../relnotes/rn-main-auth-v1.0.2/) for details.
# Arcana Auth SDK v1.0.2 -> v1.0.3 Migration
This guide is meant for developers who have already integrated apps with an older version of the Arcana Auth SDK and run them using Arcana Testnet.
If you are new to Arcana Network, see Arcana Auth SDK Quick Start Guides to get started.
When you migrate from using the Arcana Auth SDK v1.0.2 to the latest v1.0.3 release, there is no breaking change.
## What has Changed?
**No Usage Changes**.
## How to Migrate to v1.0.3?
Upgrade the Arcana Auth SDK from v1.0.2 to v1.0.3 and re-run your Web3 app.
## What's New?
See [Arcana Auth SDK v1.0.3 release notes](../../relnotes/rn-main-auth-v1.0.3/) for details.
# Arcana Auth SDK v1.0.3 -> v1.0.4 Migration
This guide is meant for developers who have already integrated apps with v1.0.3 of the Arcana Auth SDK and deploy them using Arcana Testnet or Mainnet.
If you are new to Arcana Network, see Arcana Auth SDK Quick Start Guides to get started.
## Backward Compatibility
The latest release of the Arcana Auth SDK does not cause any breaking changes for most of the Web3 apps that may have integrated with the earlier release v1.0.3 of the Arcana Auth SDK. Those apps should continue to work with no changes to the app code. Some changes are required in the Arcana Developer Dashboard settings to ensure smooth operation. If the app has explicitly specified a default chain via the `chainConfig` option in the `AuthProvider` then make sure the chain appears in the list of blockchains configured in the Arcana Developer Dashboard. If the chain does not show up, it can be manually added via the [chain management configuration settings](../../setup/config-wallet-chains/) in the dashboard. See the chain management section below for details.
### Same Wallet Address
Apps using Arcana Auth SDK v1.0.3 or the latest v1.0.4 should see **no change** in the user wallet address. This is true for all types of apps and supported frameworks, irrespective of whether they are using the global or app-specific keys. Apps deployed earlier will continue to work on the Arcana Testnet and Mainnet.
## New Release: What has Changed?
### Wagmi or RainbowKit Apps
Earlier, apps using `auth-wagmi` package v0.0.4 were **not** required to install the `auth` package v1.0.3 but this has changed in the current release.
Now Wagmi / RainbowKit Apps need to install both the packages and then as part of integrating with the Arcana Auth SDK, first create `AuthProvider` using the Client ID. Then use the `AuthProvider` to create the `ArcanaConnector`.
For details, see how to onboard users in Web3 apps using [Wagmi](../../auth/integrate/wagmi/) or [RainbowKit](../../auth/integrate/rainbow/) wallet connectors.
### Chain Management
The latest release allows developers more flexibility as they can configure blockchains displayed in the Arcana wallet dropdown list and set one of them as the default chain by either using the Arcana Developer Dashboard or programmatically through `chainConfig` setting and JSON-RPC calls to add and switch chains.
Earlier, developers could programmatically manage chains only via the add/switch chain functions and the default chain setting was done via the `chainConfig` option of the `AuthProvider`. Now this can also be managed using the dashboard. For details, see [how to configure chain settings for the wallet via the dashboard](../../setup/config-wallet-chains/).
In the latest release v1.0.4, developers can use the Arcana Developer Dashboard to configure blockchains and specify a default chain. Later, in the app integration code, they can override the default chain programmatically using the `chainConfig` parameter. The default chain configuration setting in the Arcana Developer Dashboard can be overridden with the `chainConfig` option while instantiating the `AuthProvider` **only if** the default chain selected in the `chainConfig` option is present in the list of chains configured through the Arcana Developer Dashboard. If the selected chain is not part of the Arcana Developer Dashboard blockchain settings then the default chain configured in the Arcana Developer Dashboard setting takes precedence and is displayed in the wallet UI. The rest of the dashboard configured ones show in the dropdown list.
Chain Configuration Example
**Example I**
Dashboard setting for App A: `Polygon, Ethereum, Shardeum, Arbitrum (default selection)`
`chainConfig` option in the `AuthProvider`: `Shardeum`
In this case, the Arcana wallet UI will display `Shardeum` as the default and other chains in the dropdown list as Polygon, Ethereum, and Arbitrum.
**Example II**
Dashboard setting for App A: `Polygon, Ethereum, Shardeum, Arbitrum (default selection)`
`chainConfig` option in the `AuthProvider`: `Avalanche`
In this case, the Arcana wallet UI will display `Arbitrum` as the default and other chains in the dropdown list as Polygon, Ethereum, and Shardeum.
### Transaction Summary View
When a blockchain transaction is triggered either by the app programmatically or via a wallet user action, a transaction notification pops up in the wallet context displaying the transaction summary along with the option to approve or reject the request. Only when the user clicks 'v' icon on the top right, the notification details are displayed. Earlier, the notification details were displayed by default.
## How to Migrate to v1.0.4?
We highly recommend that Web3 apps that are integrated with v1.0.3 releases of the Arcana Auth SDK migrate to the latest Arcana Auth SDK v1.0.4 release.
For vanilla HTML/CSS/JS apps or React apps that do not use `window.ethereum` setting, no code changes are required. Just install and upgrade to the latest v1.0.4 release and redeploy the app.
However, if the apps use `window.ethereum` browser setting or wallet connectors such as Wagmi or RainbowKit then migrating to the latest release may require some integration code changes. In the case of Wagmi or RainbowKit apps, it requires not only upgrading the `auth-wagmi` package but also installing an additional SDK package and some new code to use the SDK.
### Apps using `windows.ethereum`
Previously, Web3 desktop apps could integrate with the Arcana Auth SDK and directly access the [standard EIP-1193 Ethereum provider](https://eips.ethereum.org/EIPS/eip-1193) via `window.ethereum` in the web browser. In the latest release of the Arcana Auth SDK, `window.ethereum` is not automatically set to the provider. To enable this feature, specify `setWindowProvider=true` when creating the `AuthProvider`.
For details, see [Arcana Auth SDK Usage Guide](../../auth/auth-usage-guide/).
### Apps using `CHAIN` enum
If you are upgrading any app that is using `CHAIN` enum in the `chainConfig` option of the `AuthProvider` to v1.0.4, then there is a breaking change.
Update the integration code to **not** use the `CHAIN` enum as it is no longer supported. Instead, use the chain identifier of the chain that you are specifying in the `chainConfig` parameter. For example:
```
const auth = new AuthProvider('xar_test_87f34xxxxxxxxxxxxxxxxxxxxxxxxxxxß7d70143a', {
network: "testnet", //defaults to 'testnet'
position: "right", //defaults to right
theme: "dark", //defaults to dark
alwaysVisible: true, //defaults to true which is Full UI mode
chainConfig: {
chainId: "80002", //defaults to Ethereum
rpcUrl: "https://rpc.ankr.com/polygon_amoy" //defaults to 'https://rpc.ankr.com/eth'
}
});
```
### Wagmi or RainbowKit Apps
For Wagmi or RainbowKit Apps, see how to onboard users in Web3 apps using [Wagmi](../../auth/integrate/wagmi/) or [RainbowKit](../../auth/integrate/rainbow/) wallet connectors.
### Apps using `chainConfig` setting in `AuthProvider`
Apps using the `chainConfig` setting to set the default chain in the Arcana wallet dropdown list must ensure that it is included in the list of configured blockchains in the Arcana Developer Dashboard. The `chainConfig` parameter in the `AuthProvider` setting will only work if the chain is part of the configured chains in the Arcana Developer Dashboard. Otherwise, the wallet user may see a different default chain according to the Arcana Developer Dashboard settings. To ensure the `chainConfig` setting takes effect, the specified chain can be manually added through the Arcana Developer Dashboard interface. For details, see the chain management section above and refer to the [list of supported chains for the wallet](../../web3-stack/chains/).
## What's New?
See [Arcana Auth SDK v1.0.4 release notes](../../relnotes/rn-main-auth-v1.0.4/) for details.
# Arcana Auth SDK v1.0.4 -> v1.0.5 Migration
This guide is meant for developers who have already integrated apps with v1.0.4 of the Arcana Auth SDK and deploy them using Arcana Testnet or Mainnet.
If you are new to Arcana Network, see Arcana Auth SDK Quick Start Guides to get started.
## Backward Compatibility
The latest release of the Arcana Auth SDK does not cause any breaking changes for apps that have already integrated with v1.0.4 of the Arcana Auth SDK. Install the latest version and upgrade your app.
### Same Wallet Address
Apps using Arcana Auth SDK v1.0.4 should see **no change** in the user wallet address irrespective of whether they continue to use the older version on upgrade to v1.0.5 release. This is true for all types of apps and supported frameworks, irrespective of whether they are using the global or app-specific keys. Apps deployed earlier will continue to work on the Arcana Testnet and Mainnet.
## New Release: What has Changed?
The latest SDK release has **no usage changes** in the former features. New features have been added that allow user onboarding via Steam and Firebase.
## How to Migrate to v1.0.5?
We highly recommend that Web3 apps that are integrated with v1.0.4 releases of the Arcana Auth SDK migrate to the latest Arcana Auth SDK v1.0.5 release.
Install the latest Arcana Auth SDK v1.0.5 release and upgrade your app. No other integration code changes are required.
Apps using older versions of the Arcana Auth SDK must refer to the [migration guides](../archives/) and upgrade to the latest release if they wish to enable Steam of Firebase user onboarding.
## What's New?
See [Arcana Auth SDK v1.0.5 release notes](../../relnotes/rn-main-auth-v1.0.5/) for details.
# Arcana Auth SDK v1.0.5 -> v1.0.6 Migration
This guide is meant for developers who have already integrated apps with v1.0.5 of the Arcana Auth SDK and deploy them using Arcana Testnet or Mainnet.
If you are new to Arcana Network, see Arcana Auth SDK Quick Start Guides to get started.
## Backward Compatibility
The latest release of the Arcana Auth SDK does not cause any breaking changes for apps that have already integrated with v1.0.4 of the Arcana Auth SDK. Install the latest version and upgrade your app.
### Same Wallet Address
Apps using Arcana Auth SDK v1.0.5 should see **no change** in the user wallet address irrespective of whether they continue to use the older version on the upgrade to the v1.0.6 release. This is true for all types of apps and supported frameworks, irrespective of whether they are using the global or app-specific keys. Apps deployed earlier will continue to work on the Arcana Testnet and Mainnet.
## New Release: What has Changed?
The latest SDK release has **no usage changes** in the former features. New features have been added that allow user onboarding via Steam and Firebase.
## How to Migrate to v1.0.6?
We highly recommend that Web3 apps that are integrated with v1.0.5 releases of the Arcana Auth SDK migrate to the latest Arcana Auth SDK v1.0.6 release.
Install the latest Arcana Auth SDK v1.0.6 release and upgrade your app. No other integration code changes are required.
Apps using older versions of the Arcana Auth SDK must refer to the [migration guides](../archives/) and upgrade to the latest release if they wish to enable Steam of Firebase user onboarding.
## What's New?
See [Arcana Auth SDK v1.0.6 release notes](../../relnotes/rn-main-auth-v1.0.6/) for details.
# Arcana Auth SDK v1.0.6 -> v1.0.7 Migration
This guide is meant for developers who have already integrated apps with v1.0.6 of the Arcana Auth SDK and deploy them using Arcana Testnet or Mainnet.
If you are new to Arcana Network, see Arcana Auth SDK Quick Start Guides to get started.
## Backward Compatibility
The latest release of the Arcana Auth SDK does not cause any breaking changes for apps that have already integrated with v1.0.6 of the Arcana Auth SDK. Install the latest version and upgrade your app.
### Same Wallet Address
Apps using Arcana Auth SDK v1.0.6 should see **no change** in the user wallet address irrespective of whether they continue to use the older version on the upgrade to the v1.0.7 release. This is true for all types of apps and supported frameworks, irrespective of whether they are using the global or app-specific keys. Apps deployed earlier will continue to work on the Arcana Testnet and Mainnet.
## New Release: What has Changed?
Besides a few enhancements Arcana wallet UI and bug fixes, there are **no usage changes** in the latest release.
## How to Migrate to v1.0.7?
We highly recommend that Web3 apps that are integrated with v1.0.6 releases of the Arcana Auth SDK migrate to the latest Arcana Auth SDK v1.0.7 release.
Install the latest Arcana Auth SDK v1.0.7 release and upgrade your app. No other integration code changes are required.
Apps using older versions of the Arcana Auth SDK must refer to the [migration guides](../archives/) and upgrade to the latest release if they wish to enable Steam of Firebase user onboarding.
## What's New?
See [Arcana Auth SDK v1.0.7 release notes](../../relnotes/rn-main-auth-v1.0.7/) for details.
# Arcana Auth SDK v1.0.7 -> v1.0.8 Migration
This guide is meant for developers who have already integrated apps with v1.0.7 of the Arcana Auth SDK and deploy them using Arcana Testnet or Mainnet.
If you are new to Arcana Network, see Arcana Auth SDK Quick Start Guides to get started.
## Backward Compatibility
The latest release of the Arcana Auth SDK does not cause any breaking changes for apps that have already integrated with v1.0.7 of the Arcana Auth SDK. Install the latest version and upgrade your app.
### Same Wallet Address
Apps using Arcana Auth SDK v1.0.7 should see **no change** in the user wallet address irrespective of whether they continue to use the older version on the upgrade to the v1.0.8 release. This is true for all types of apps and supported frameworks, irrespective of whether they are using the global or app-specific keys. Apps deployed earlier will continue to work on the Arcana Testnet and Mainnet.
## New Release: What has Changed?
Arcana Auth SDK release has no major changes, a few enhancements and a bug fix for email validation. **Usage** has not changed in the latest release. For details, see [Arcana Auth SDK v1.0.8 release notes](../../relnotes/rn-main-auth-v1.0.8/).
## How to Migrate to v1.0.8?
We highly recommend that Web3 apps that are integrated with v1.0.7 releases of the Arcana Auth SDK migrate to the latest Arcana Auth SDK v1.0.8 release.
Install the latest Arcana Auth SDK v1.0.8 release and upgrade your app. No other integration code changes are required.
Apps using older versions of the Arcana Auth SDK must refer to the [migration guides](../archives/) and upgrade to the latest release if they wish to enable Steam of Firebase user onboarding.
## What's New?
See [Arcana Auth SDK v1.0.8 release notes](../../relnotes/rn-main-auth-v1.0.8/) for details.
# Arcana Auth SDK v1.0.8 -> v1.0.9 Migration
New to Arcana Network? see Arcana Auth SDK Quick Start Guides to get started.
Using an older version and want to migrate? Read on...
## What has Changed?
This is a major release of the Arcana Auth SDK since the last release. The updates include:
- Arcana Auth SDK
- Global Keys feature does not require setting up social logins via the social provider's console
- Enhanced security to block clickjacking
- New auth-core SDK allows greater customization flexibility with custom Wallet UI
### Global Keys
Web3 apps using the **app-specific** keys (default) keyspace do not have to make any changes.
If the app developer selects [global keys](../../concepts/keyspace-types/) while configuring the app via the Arcana Developer Dashboard, the social auth settings for enabling the social login providers are **no longer** required.
For details, see [Arcana Auth SDK v1.0.9 release notes](../../relnotes/rn-main-auth-v1.0.9/).
## Backward Compatibility
The latest release of the Arcana Auth SDK does not cause any breaking changes for apps integrated with v1.0.11 of the Arcana Auth SDK. Install the latest version and upgrade.
Apps using older versions of the Arcana Auth SDK must refer to the [migration guides](../archives/) and upgrade to the latest release if they wish to enable Steam of Firebase user onboarding.
### Same Wallet Address
Apps migrating to the Arcana Auth SDK v1.0.11 should see **no change** in the user wallet address, irrespective of whether they continue to use the older version or upgrade to this latest release. This is true for all types of apps and supported frameworks, irrespective of whether they are using the global or app-specific keys. Apps deployed earlier will continue to work on the Arcana Testnet and Mainnet.
## How to Migrate to v1.0.9?
Install the latest Arcana Auth SDK v1.0.9 and upgrade your app with no changes to the integration code.
That's all!
# Migration Guide Archives
Always use the latest [Arcana Auth SDK](https://www.npmjs.com/package/@arcana/auth).
For those using an older version of the SDK, refer to the appropriate migration guide:
[Auth SDK v1.0.11 -> v1.0.12](../main-auth-v1.0.12-migration/)
[Auth SDK v1.0.10 -> v1.0.11](../main-auth-v1.0.11-migration/)
[Auth SDK v1.0.9 -> v1.0.10](../main-auth-v1.0.10-migration/)
[Auth SDK v1.0.8 -> v1.0.9](../main-auth-v1.0.9-migration/)
[Auth SDK v1.0.7 -> v1.0.8](../main-auth-v1.0.8-migration/)
[Auth SDK v1.0.6 -> v1.0.7](../main-auth-v1.0.7-migration/)
[Auth SDK v1.0.5 -> v1.0.6](../main-auth-v1.0.6-migration/)
[Auth SDK v1.0.4 -> v1.0.5](../main-auth-v1.0.5-migration/)
[Auth SDK v1.0.3 -> v1.0.4](../main-auth-v1.0.4-migration/)
[Auth SDK v1.0.2 -> v1.0.3](../main-auth-v1.0.3-migration/)
[Auth SDK v1.0.1 -> v1.0.2](../main-auth-v1.0.2-migration/)
[Auth SDK v1.0.0 -> v1.0.1](../main-auth-v1.0.1-migration/)
[Auth SDK v0.3.0 -> v1.0.0](../main-auth-v1.0.0-migration/)
[Auth SDK v0.2.x -> v0.3.0](../beta-auth-v0.3.0-migration/)
# Get Started: Auth+CA
Follow this guide to onboard users in a Web3 app via social login and enable chain abstracted transactions. It explains how *Web3 apps built using the [Wagmi](https://wagmi.sh/)* library can integrate with the Arcana SDKs for social login and chain abstraction.
- Integrate with the Arcana Auth Wagmi SDK to enable user onboarding via [social login](../../concepts/social-login/) in Web3 apps.
- Once authenticated, users can instantly access the in-app, built-in [Arcana wallet](../../concepts/anwallet/) to sign blockchain transactions.
- Integrate with the Arcana CA Wagmi SDK and let users spend on any chain with unified balance.
- The SDK implements Wagmi `useSendTransaction` and `useWriteContract` hooks so that the Web3 apps can seamlessly switch to using these same hooks from the Arcana CA Wagmi SDK for enabling chain abstracted transactions.
- It offers additional hooks to enable unified balance: `useBalance`, `useBalanceModal`.
- The `useCAFn` hook allows chain abstracted `bridge` and `transfer` functionality for [tokens](../../web3-stack/ca_stack/#tokens) on [supported chains](../../web3-stack/ca_stack/#chains).
## Prerequisites
Before installing and integrating with the Arcana Auth Wagmi SDK, developers need to configure the authentication settings.
- App must be [registered](../../setup/config-auth/register-app/) via the Arcana Developer Dashboard: Loading...
{address && ensName ? `${ensName} (${address})` : address}
Loading...
{address && ensName ? `${ensName} (${address})` : address}