Key Management

OKX wallet support 2 different key management options:

Standard HD Wallet

Responsibility

A single user is responsible for managing the private key (secp256k1key pair in this case). We’ll discuss the key generation process in detail in the next section.

Storage

where is the key stored in: - browsers - mobile devices (iOS, Android) The passkey is generated by the device’s Secure Enclave (in case of iOS devices) or similar modules (in case of Android devices). The passkey is locally stored on the device’s Secure Enclave (in case of iOS devices) or similar modules (in case of Android devices).

Access

The user can access Secure Enclave (in case of iOS devices) or similar modules (in case of Android devices) in order to perform different operations without the passkey ever leaving the Secure Enclave.

MPC Wallet

Responsibility

A single user is responsible for managing the private key (secp256k1key pair in this case). We’ll discuss the key generation process in detail in the next section.

Storage

where is the key stored in: - browsers - mobile devices (iOS, Android) The passkey is generated by the device’s Secure Enclave (in case of iOS devices) or similar modules (in case of Android devices). The passkey is locally stored on the device’s Secure Enclave (in case of iOS devices) or similar modules (in case of Android devices).

Access

The user can access Secure Enclave (in case of iOS devices) or similar modules (in case of Android devices) in order to perform different operations without the passkey ever leaving the Secure Enclave.

Account Management

Clave does not support Externally Owned Accounts (EOAs) but it does support Smart Contract Accounts (SCAs).

Clave’s SCA Implementation

Clave maintains their own SCA implementation.

Registry

Clave maintains their own and ModuleManager and HookManager.

Modules

Clave also has 2 module implementations: SocialRecoveryModule and CloudRecoveryModule.

• SocialRecoveryModule: The Social recovery module allows clave users to assign guardians to their account who can help recovery your wallet.

  1
  struct RecoveryConfig {
  2
    uint128 timelock; // Recovery timelock duration
  3
    uint128 threshold; // Recovery threshold
  4
    address[] guardians; // Guardian addresses
  5
  }

  Copy code

  Each account has a RecoveryConfig which defines:

  1. timelock defines the duration of the recovery period (see recovery section for more context).
  2. threshold defines the minimum number of guardians that need to approve the recovery of an account. Note that the threshold will always be less than or equal to the number of guardians associated with the account.
  3. guardians is an array of guardian addresses associated with an account.

  We’ll discuss how this module is used for recovery in this section.

• CloudRecoveryModule: The cloud recovery module recovers an account using a key stored in iCloud or other similar clouds. This module is no longer used in the current Clave app because passkeys can sync with different user devices.

Processes

OKX has the following processes in place:

Key generation

A random number selected from the secp256k1 elliptic curve serves as the private key. This key is then multiplied by a predefined point on the curve to generate the public key. The Ethereum address is derived from the last 20 bytes of the hashed public key. The 'seed phrase' is usually introduced for human-readable backup, enabling the deterministic derivation of private and public keys.

By creating a wallet, the OKX transforms a single private key into three separate shares. Share 1 is stored in the OKX server, share 2 is stored on user’s device local storage, and share 3 is generated by device, encrypted and can be backed up to the device’s preferred cloud services, like Google Cloud, iCloud and Huawei Cloud.

Transaction process

Signing Transactions: A transaction, containing details such as nonce(a sequential number), amount, gas price, and recipient address, is signed using the private key. This process, involving the ECDSA, a digital signature algorithm that uses elliptic curve cryptography and adopts secp256k1 as the curve, generates a signature consisting of values (r, s, v). The signature and the original transaction are then broadcast on the network.

Verifying Transactions: Once a transaction reaches Ethereum nodes, it undergoes a validation process in the node's mempool. To verify the signer, the nodes use the signature and hashed transaction to derive the sender's public key and confirm the transaction's authenticity by matching the derived address with the sender's.

Signing Transactions: This follows a standard 4337 flow, where the user uses an EOA to sign user ops.

Verifying Transactions: This also follows a standard 4337 flow, where the signed user ops and sent to a bundler which bundles the user ops to create bundles and sends them to the mempool as a normal ethereum transaction. This transaction invokes the handleOps function on the Entrypoint contract and the validity of the user op is checked using the validateUserOpfunction.

Signing Transactions: When signing a transaction, individual parties (in this case, OKX and user’s device) generate partial signatures or 'signature shares' using their secret shares (in this case, share 1 and share 2). These signature shares are then combined to produce a single final signature. The process of combination is typically handled by the TSS protocol and ensures that the final signature is valid for the original message as if it was signed by a single private key. This way, the TSS allows for a distributed way of signing a message without ever reconstructing the entire private key. You can refer to the documentation for more specific implementation details here .

Verifying Transactions: Once the transaction message is signed, it’s sent to the mempool just as any other EOA signed transaction.

Once a transaction reaches Ethereum nodes, it undergoes a validation process in the node’s mempool. To verify the signer, the nodes use the signature and hashed transaction to derive the sender’s public key and confirm the transaction’s authenticity by matching the derived address with the sender’s.

Account Recovery process

It’s highly recommended to back up your Share 3 to your device’s cloud (iCloud, Google Drive, or Huawei Cloud) to prevent the loss of your assets. To back up your Share 3 data, go to your device’s cloud service and set your password for encryption. Share 3’s data will be uploaded to your device’s cloud and it’ll be removed from your device to secure your private key shares.

If you didn’t backup your Share 3’s data to your device’s cloud and your device is lost, you can’t access your assets permanently as you only have Share 1 remaining on your wallet’s server.

Once you have backed up Share 3, you can recover your MPC account if you lose the access to your device with Share 2.

You can restore your wallet via cloud backup using Share 1 and Share 3 data even if you have lost your device. All the 3 secret codes will be reset to secure your asset and prevent the risk of Share 2 data being leaked. It’ll not affect your wallet address or your assets.

TODO(vasa): Explain further

TODO(vasa): Explain further

TODO(vasa): Explain further

TODO(vasa): Explain further

Migrating from another wallet

You can migrate to okx wallet in following ways

• import seed phrase (seed format supported: 12/18/24)
• import private key
• Hardware wallet

Migrating to another wallet

You can export your private key/seed phrase and import that to any other compatible wallet.

You should be able to transfer all your assets to any other address in a single transaction.

Unfortunately, you cannot export the keyless wallet to any other wallet directly. The MPC algorithm is not yet supported by institutional-level security devices, and the majority of keyless wallets are customized. Since you have two private key shares, you may utilize Shares 2 and 3 to retrieve the entire private key without the assistance of OKX. The keyless wallet will then be transformed into a traditional wallet that is managed by a private key or seed phrase, which can subsequently be imported to other wallets. Your keyless wallet in the OKX App will no longer be valid following this procedure in order to avoid any liability conflicts.

What happens to the wallet if okx servers/platform is down?

You should be able to access your wallet and the assets within it even if the okx platform is down.

You should be able to access your wallet and the assets within it even if the okx platform is down.

Your assets in the keyless wallet will be safe if OKX is unavailable. When creating a keyless wallet, the private key is split into three pieces and stored on the OKX server, a user device, and either iCloud or Google Drive. You can obtain the full signature and use the wallet by using two of the private key shares when signing the transaction.

If OKX or other platforms are unavailable, you can utilize the 'Emergency escape' function to recover the entire private key by using Shares 2 and 3 of the private key, which will allow you to restore the wallet and transfer assets. The initial keyless wallet will no longer be valid at this time; instead, it will be changed into a conventional wallet that is managed by the private key.