1. What is Overwallet ?

Overwallet serves as the backend for Authorise (also known as TSR), acting as an intermediary between Authorise and both AWS KMS and Fireblocks' Direct Custodial Wallet. It enables seamless key generation and transaction signing through AWS KMS and Fireblocks while ensuring that private keys remain always securely within the custody, with no possibility of extraction.

Overwallet provides unified APIs for wallet services, regardless of the underlying blockchain network or custody provider. Essentially, Overwallet aims to achieve blockchain interoperability specific for transaction signing by allowing Authorise to sign any transaction's native data through a single API. This API interacts with either AWS KMS or Fireblocks, enabling Authorise to manage multiple keys across various DLT assets on Quant Connect efficiently.

2. Key features of Overwallet

Overwallet was developed with inspiration from Fireblocks' Direct Custodial Wallet, which is based on the Hierarchical Deterministic (HD) BIP-44 wallet structure. While AWS KMS does not natively support HD wallets, Overwallet is designed to make AWS KMS function as if it does. To effectively use Overwallet, it is essential to understand the principles of BIP-44 Derivation Path. When generating a key using Fireblocks, each asset on the mainnet has a unique derivation path.

2.1 What is BIP-44 Derivation Path ?

              m / purpose / coin_type / account / change / address_index

• The first value of the path is the constant m, representing the master key. All private keys are derived from this single master key. To put it simply, it’s comparable to the seed phrase you get when setting up MetaMask on your local machine—where all private keys are derived from that seed phrase. MetaMask is an example of an HD wallet.
• The second value of the path is the constant 44.
• The third value of the path is coin_type. In the mainnet, the coin_type values are as follows. On the testnet, it is a common practice to set the coin_type for any asset to the number 1.

    Ethereum (ETH): 60
    Polygon (MATIC): 966
    Avalanche (AVAX): 9000
    XDC Network (XDC): 550
    Bitcoin (BTC): 0
    Polkadot (DOT): 354
    Ripple (XRP): 144
    Solana (SOL): 501
    Algorand (ALGO): 283

• The fourth value of the path is referred to as account (e.g., 1, 2, 3, 4, …). In Overwallet, this value is renamed to hdAccountId.
• The fifth value of the path is change, which is always set to 0 in Fireblocks for all assets.
• The sixth value of the path is address_index: For account-based assets, it is always 0. For UTXO-based assets, it is incremental, as Fireblocks supports multiple addresses for the same UTXO asset within the same account.

For example, when hdAccountId = 107 (i.e., account = 107) is assigned to a Quant clientId, multiple assets on the mainnet can be efficiently managed using this hdAccountId. Each asset is assigned a unique derivation path, distinguished primarily by the coin_type value. This approach allows the application identified by clientId on Quant Connect to manage multiple assets seamlessly and effectively.

• Ethereum mainnet: m / 44 / 60 / 107 / 0 / 0
• Polygon mainnet: m / 44 / 966 / 107 / 0 / 0
• Bitcoin mainnet: m / 44 / 0 / 107 / 0 / 0
• Polkadot mainnet: m / 44 / 354 / 107 / 0 / 0
• Solana mainnet: m / 44 / 501 / 107 / 0 / 0

Therefore each asset has a unique private key derived from such a different derivation path, but all keys are ultimately derived from the same master key.

2.2 Mapping Quant's Location to Fireblocks' assetId

To generate a key for a DLT asset stored in Fireblocks' custody and use it for signing transactions, we need to manage the derivation path. Alternatively, Fireblocks simplifies and streamlines this process by providing an assetId to uniquely identify a specific asset on different DLT networks.

Overwallet utilizes this assetId and hdAccountId along with Quant's Location, which consists of Technology and Network, to generate a key and sign transactions with Fireblocks.

For the xdc apothem testnet, Overwallet interacts with Fireblocks using a derivation path since Fireblocks does not natively support the xdc apothem testnet. Similarly, Overwallet can generate keys and sign transactions for the Hyperledger Besu permissioned blockchain through a derivation path with Fireblocks.

2.3 Derivation Path on Testnets

On testnets, BIP-44 specifies that the coin_type is set to 1 for any DLT assets. With the example we used above, for hdAccountId = 107, the derivation paths are as follows.

• Ethereum Sepolia testnet: m / 44 / 1 / 107 / 0 / 0
• Polygon Amoy testnet: m / 44 / 1 / 107 / 0 / 0
• Bitcoin testnet: m / 44 / 1 / 107 / 0 / 0
• Polkadot westend: m / 44 / 1 / 107 / 0 / 0
• Solana testnet: m / 44 / 1 / 107 / 0 / 0

As a result, you might assume that all the assets mentioned above share the same private key on Fireblocks. However, Fireblocks supports two distinct cryptographic algorithms: (secp256k1, ECDSA) and (ed25519, EdDSA), as outlined in 2.5 Crypto Algorithms Supported by AWS KMS and Fireblocks. Each algorithm operates under a separate master key.

Thus:

• Ethereum Sepolia testnet, Polygon Amoy testnet, and Bitcoin testnet use masterKey-1, with (secp256k1, ECDSA).
• Polkadot westend and Solana testnet , on the other hand, use masterKey-2, with (ed25519, EdDSA).

Consequently:

• Ethereum Sepolia testnet, Polygon Amoy testnet, and Bitcoin testnet share privateKey-1 derived from masterKey-1.
• Polkadot westend and Solana testnet share privateKey-2 derived from masterKey-2.

You may have another question:

• Do Ethereum Sepolia testnet, Polygon Amoy testnet, and Bitcoin testnet share publicKey-1, which is derived from privateKey-1?
• Do Polkadot Westend and Solana testnet share publicKey-2, which is derived from privateKey-2?

The answer is Yes. However, there is a slight distinction:

• The public key for Ethereum Sepolia testnet and Polygon Amoy testnet is in uncompressed form (65 bytes), starting with 04 .
• The public key for Bitcoin testnet is in compressed form (33 bytes), starting with 02 or 03.

Despite this difference, the public key for Ethereum Sepolia testnet, Polygon Amoy testnet, and Bitcoin testnet is essentially the same.

Finally, you might ask: What about the addresses for all these assets?

The answer is that each asset has a different address because each blockchain uses its own cryptographic algorithm to derive an address from a public key. The only exception is that Ethereum Sepolia testnet and Polygon Amoy testnet share the same address since they are both EVM-based blockchains and use the same algorithm for address derivation.

All of this explanation above can be verified in the example provided in the API documentation for Get a list of assets .

2.4 Introducing an hdAcountId to AWS KMS

Here are key characteristics of AWS KMS to consider:

• Purpose: AWS KMS is primarily designed for key management and cryptographic operations, not as a full-featured wallet solution for blockchain applications.
• HD Key Derivation: KMS does not natively support hierarchical deterministic (HD) key derivation, such as BIP-44 standards.
• Key Management: KMS handles individual keys rather than the key hierarchies required for HD wallets.
• Blockchain Features: KMS lacks built-in capabilities for managing blockchain transactions or addresses.

However, by introducing the concept of an hdAccountId to AWS KMS within Overwallet's design, we have leveraged AWS KMS to provide similar benefits to managing multiple diverse DLT assets under the same hdAccountId. This design bridges the gap between traditional key management and the needs of blockchain interoperability when using AWS KMS.

From the example provided in the API documentation for Get a list of assets, it is evident that AWS KMS generates keys randomly, ensuring that each asset has a unique private key. Consequently, the public keys derived from these private keys are also distinct. However, all assets are efficiently organized under an hdAccount, enabling Authorise to manage multiple assets assigned to an application identified by a clientId on Quant Connect.

You can also confirm that, even when using AWS KMS:

• The public keys for Ethereum Sepolia testnet, Polygon Amoy testnet, Avalanche Fuji testnet, and XDC Apothem testnet are in uncompressed form (65 bytes), starting with 04.
• The public keys for Bitcoin testnet, XRP Ledger testnet, and Polkadot Westend are in compressed form (33 bytes), starting with 02 or 03.

2.5 Crypto algorithms supported by AWS KMS and Fireblocks

AWS KMS supports only the algorithm (secp256k1, ECDSA), while Fireblocks supports both (secp256k1, ECDSA) and (ed25519, EdDSA), making Fireblocks a more premium service.

Quant Connect currently supports only EVM-based blockchains (Ethereum, Polygon, Avalanche, and XDC), Bitcoin, XRPL, and Substrate, all of which use (secp256k1, ECDSA).

However, for any blockchain utilizing either (secp256k1, ECDSA) or (ed25519, EdDSA), Overwallet can be used to generate keys and sign transactions.

The table outlines the blockchains supported by Overwallet, along with the cryptographic algorithms used for key generation and transaction signing.

AWS KMS uses the notation ECC_SECG_P256K1, ECDSA_SHA_256 to represent (secp256k1, ECDSA).

Fireblocks, on the other hand, uses the notations MPC_ECDSA_SECP256K1 for (secp256k1, ECDSA) and MPC_EDDSA_ED25519 for (ed25519, EdDSA).