Signature generation via MPC

Signature Generation

The primary use of the MPC network for us is secure signature generation.

Currently, we support the following signature formats:

• ECDSA — used in Bitcoin, EVM chains, BNB, Polygon

• EdDSA — used in Solana, NEAR, Polkadot

The MPC network is developed in collaboration with NEAR One. Some details can be found here.

While on-chain smart contracts are used for signature generation on the NEAR blockchain, we focus primarily on the off-chain signing API, which offers higher bandwidth and lower latency.

What is an HOT account?

As we work with chain agnostic identities, we have to explicitly define what identity is.

Identity is a wallet_id: [u8; 32] , some 32 bytes, which is a hash of some uid

Suffice to say at the moment, that uid coming from a random source.

Key Derivation Function

We have to associate a key pair with an identity.

All accounts are created on top of MPC network. The MPC network has its own master key, from which all keys are derived. This process is described as Key Derivation Function:

Thus, a set of public keys associated with wallet_id comes from uid too.

Important note: at any point of time no one knows MPC's Secret Key , nor Derived Secret Key , though Public Key and its derivations are well known.

Nevertheless, it is still possible to sign a message with Derived Secret Key , thanks to MPC technology.

But, if one wants to sign a message on behalf of specified uid, they have to prove ownership of that uid – which is the same of proving ownership of wallet_id, which is the identity.

Authorization of Signature Generation

We must ensure that only messages explicitly authorized by the user are signed — not arbitrary requests.

Here's the abstract authorization flow, which can be used for any purpose. We will look at the specific examples (bridge use-case, mutlichain usage) later.

1. User sends a signature request to the MPC network

The off-chain signing API accepts the following data:

JsonValue {
  uid: [u8; 32],
  message: [u8],
  proof: JsonValue
}

• uid – unique identifier for the user. Then we simply calculate wallet_id = hash(uid)

• message – message to be signed

• proof – data used to authorize the signature for the given uid

1. MPC Network before initiating a signing algorithm, starts the validation procedure

Formally, the interpretation of proof is determined by each MPC node. In practice, all nodes follow a unified validation process

3-4. Get authroization methods for the wallet

We ask an account registry, which stores authorization methods for each wallet_id In theory, arbitrary logic can be placed in authorization method. In practice it's a contract on some blockchain which implements specific API.

1. Check each authorization method

For each validation method we call a view method of the specified contract on its chain. In return we receive true/false as a result whether validation method passed.

6-7. Proceed with the signature generation

If all verifiaction methods succeeded, we move on to the cryptographic protocol for message signing.

1. User get desired signature