Key Architecture Overview

Non-custodial Design

"Not your keys, not your crypto!"

What really is the difference between custodial and non-custodial when dealing with digital funds? With more and more non-custodial WAAS products rolling out, you will want to throughly evaluate their key architecture in order to ensure that the product meets your standards for non-custodial. Custody comes down to two core criteria: where are wallet keys stored and who can access them?

Storage

Before developing Wallaby, we found most wallet providers were comfortable storing private keys if they were encrypted first and stored in a secure environment. Our team felt strongly about avoiding the scaling security risk associated with centralized key storage, but still wanted to enable all the same out of the box capabilities of standard noncustodial wallet providers.

Access

Some wallet providers identify as non-custodial based on the premise that they are unable to access your private keys without your involvement. However, in some designs you may also find that wallet holders are unable to access their own keys independently of the provider.

We've designed a system without product lockup and with interoperability at core. We believe that a system where the wallet holder is unable to access their private keys independently falls into a gray area and has the potential to introduce unnecessary risks.

Core Key Architecture Design

Our architecture combines two cryptographic standards:

1. Our key architecture for transaction signing is based on BIP-32: A hierarchical deterministic wallet standard that ensures interoperability between wallet providers

2. Our authentication and key transport is based on the secure remote password (SRP) protocol which is a form of zero knowledge authentication allowing the wallaby backend system to authenticate clients/frontends without needing them to reveal any form of private data.

Together these two standards enable us to provide wallet capabilities without storing any private keys, not even in an encrypted format.

Wallet Keys

To provide multichain capabilities while preserving interoperability with other wallet providers, we chose to follow BIP-32: a hierarchical deterministic wallet standard. This standard utilizes a mnemonic to generate a root parent key. This root parent key is used to generate child keys used for transaction signing.

When creating a wallet, we create child keys for supported blockchains that share a single master seed phrase. When signing, we generate the keys on demand from the seed phrase in a secure enclave.

In addition to interoperability and multichain capabilities, this structure also results maximizes flexibility with regards to account design for your end user. We can generate new addresses as needed, introduce additional blockchains over time, and roll external accounts up into our existing structure where it makes sense.

Authentication Keys

To authorize the user's device to use our system and secure the seed phrase in transport and storage, we utilize the secure remote password (SRP) protocol.

This protocol utilizes two key pairs generated when authenticating with Wallaby:

1. one pair generated by your application held on the wallet holders' device referred to as the "client auth keys"

2. one pair generated on our platform held within our secure enclave referred to as the "Wallaby auth keys"

When signing up or signing in to our platform, you provide us with the "client auth public key" to enable us to transport data FROM our system. In return, we will provide you with the "Wallaby auth public key" used for transporting data TO our system.

When creating a wallet or recovering a wallet, we send you the seed phrase encrypted with the "client auth public key" that was originally generated client side. When it is received, you can decrypt with the "client auth private key" to present it to the end user. When it is no longer needed, you can encrypt it with the "Wallaby auth public key" and any additional encryption factors. Then store it as needed.

When signing, we require you return the seed phrase encrypted with the "Wallaby auth public key" and when it arrives in our secure enclave, we will decrypt it to generate the signing keys needed to perform the requested tx.