Unity V2 Migration Guide

A comprehensive guide for migrating your Unity application from Okto SDK V1 to Okto SDK V2.

This guide provides a detailed walkthrough for migrating your unity application from Okto SDK V1 to Okto SDK V2. While the core functionality remains the same, V2 introduces a more decentralized architecture that enhances security and provides comprehensive developer controls.

Key Changes Overview

AreaChanges
ArchitectureMoved to a more decentralized system with smart contracts on the Okto chain
AuthenticationOAuth-first approach with session key implementation
Wallet ManagementAutomated wallet creation across all enabled chains
Package StructureMigration to scoped packages under OKTOSDK namespace

Migration Steps

Note

This guide assumes that you have already set up a fully functional unity dapp using Okto SDK V1.

1. Installing Dependencies

Okto SDK V2 adopts a scoped package structure under the OKTOSDK namespace, providing enhanced access control and enabling private package distribution when required. This approach aligns with modern best practices in package management, ensuring a more organized, and scalable package structure.

Previously, it was UnitySdk_1.0.unitypackage; it has now been updated to: unityoktov2sdk_0.1.unitypackage

2. Environment Configuration

In Okto V1, only one environment variable was needed: OKTO_CLIENT_API_KEY. However, in V2, Okto has moved to a decentralized approach where even the client is a smart contract on the Okto chain.

_clientConfig = new ClientConfig
{
    ClientPrivKey = config.ClientPrivateKey,
    ClientPubKey = GetPublicKey(config.ClientPrivateKey),
    ClientSWA = config.ClientSWA
};
Warning:Essential Setup Required
Show

Before you begin, set up your developer dashboard by making sure you have :

If you need help, reach out to us on our troubleshooting form and we will contact you.

3. Setting Up the GoogleAuth Provider

Note

This setup is optional and required only when using Google Authentication.

The setup for Google OAuth remains the same in both versions:

Here’s your code formatted in a code block:

public async Task<(string result, Exception error)> LoginGoogle()
{
#if GOOGLE_LOGIN
    GoogleSignIn.Configuration = configuration;
 
    try
    {
        GoogleSignInUser user = await GoogleSignIn.DefaultInstance.SignIn();
        if (user != null)
        {
            Debug.Log($"Signed in successfully! Welcome: {user.DisplayName}");
            Debug.Log($"ID Token: {user.IdToken}");
            OktoAuthExample.LoginWithGoogle(user.IdToken, "google");
 
            // Use the ID token to authenticate with your backend
            return (user.IdToken, null); // Returns (AuthDetails, Exception)
        }
    }
    catch (AggregateException ex)
    {
        foreach (var innerException in ex.InnerExceptions)
        {
            if (innerException is GoogleSignIn.SignInException signInError)
            {
                Debug.LogError($"Google Sign-In Error: {signInError.Status} - {signInError.Message}");
                return (null, signInError);
            }
        }
    }
    catch (Exception ex)
    {
        Loader.DisableLoader();
        Debug.LogError($"Unexpected Error: {ex.Message}");
        return (null, ex);
    }
 
    Debug.Log("Sign-In was canceled.");
    return (null, null); // Return null if sign-in is canceled
#else
    Debug.LogWarning("Google Sign-In is not enabled. Please add GOOGLE_LOGIN to scripting define symbols.");
    return (null, null);
#endif
}

4. OktoProvider Setup

In V1, the provider required OKTO_CLIENT_API_KEY and buildType as parameters. In V2, this approach has been simplified by consolidating all necessary values into a single config parameter. This config object now holds the client’s private key, client SWA, and environment, making integration more streamlined and easier to manage.

_clientConfig = new ClientConfig
{
  ClientPrivKey = config.ClientPrivateKey,
  ClientPubKey = GetPublicKey(config.ClientPrivateKey),
  ClientSWA = config.ClientSWA
};

5. Authentication Implementation

In V1, Okto supports multiple authentication methods, including Google-Auth (GAuth), email-OTP, phone-OTP, and JWT-custom-auth. Upon successful authentication, Okto generates an AuthToken, which is used for delegated access.

In V2, authentication remains backward-compatible with V1.

  • Using Google Authentication (Google OAuth); V2 continues to support direct authentication with Google OAuth, maintaining seamless integration with Google's trusted authentication infrastructure within the Okto unity SDK.
  // Using Google OAuth
  LoginWithGoogle(_instance.idToken, "google");
  • Using Other Authentication Methods; All authentication methods from V1 remain supported in V2. The authToken retrieved from successful authentication in V1 can still be used in V2 without modification.
var authData = new AuthData
{
    IdToken = idToken,
    Provider = provider
};
AuthenticateResult authSessionData = await _instance._oktoClient.LoginUsingOAuth(
authData,
(session) =>
{
   Debug.Log($"Login successful! Session created for user: {session.UserSWA}");
}
);

Wallet Creation in V2

In V1, wallets had to be manually created using createWallet(). In V2, after successful authentication:

  • A session is created for the user and client, with a default validity of 7 days. However, this duration can be customized as needed
  • Wallets are automatically retrieved for the user or created if none exist
  • Users automatically have wallets in all enabled chains of the client
  • A User SWA (Smart Wallet Address) is created/fetched on/from the Okto chain
  • The current session is registered to the user's Smart Wallet Account (SWA).
Note:V1 AuthToken vs V2 Session Keys
Show

In V1, the AuthToken was a combination of the user login method and the client API key, providing delegated access to the client. In V2, authentication results in a session key pair that is:

  • Generated client-side and unique for each user login and client SWA.
  • Acts as the authority for the User SWA within policy limits.

SDK Function Migration References

Explorer Functions

V1 FunctionV2 FunctionChanges
getWallets()getAccount()- Now returns enhanced wallet details
- Includes network symbol and comprehensive chain data
getSupportedNetworks()getChains(oktoClient)- Renamed for clarity
- Retrieves the list of all blockchain networks supported by Okto
getSupportedTokens()getTokens(oktoClient)- Returns supported token list
getPortfolio()getPortfolio(oktoClient)- Now retrieves the user's aggregated portfolio data
-getPortfolioActivity(oktoClient)- Get user's portfolio activity
-getPortfolioNFT(oktoClient)- Get user's NFT portfolio
-getNftCollections(oktoClient)- Retrieves NFT collection metadata
-getOrdersHistory(oktoClient, filters?)- All order history functions are now combined into one
- Retrieves order history for token transfers, NFT transfers, and raw transactions using filter parameters

Intent Functions

All intents are available in both abstracted and detailed flows. In the detailed flow, intents can be converted into a user operation (UserOp), signed, and executed on the Okto chain as separate calls. In the abstracted flow, these three steps are combined into a single call for a more seamless experience.

V1 FunctionV2 FunctionChanges
transferTokens(data)tokenTransfer(oktoClient, data)- Switched to UserOp-based transfer model
- Added transaction simulation
- Improved gas optimization options
transferNft(data)nftTransfer(oktoClient, data)- Converted to UserOp-based transfer model
- Consolidated multiple NFT functions into one
- Added chain compatibility checks
executeRawTransaction()evmRawTransaction(oktoClient, data)- Now creates a UserOp for executing raw EVM transactions.

V2 Functions

FunctionDescription
signUserOp(userop)- Signs user operations
- Validates operation parameters
- Includes policy checks
executeUserOp(userop)- Executes signed operations
- Handles transaction bundling

On this page