In order to achieve a distributed signing for blockchain algorithms, it may be required to change the key generation (e.g., generating a private-public keypair) and/or signing protocols without, for example, affecting the public verification protocol with validating a signature on a message using the public key.

Distributed key generation protocols may involve two main parts: a local secret data being generated (similar to the original centralized key generation protocol) by each of the parties, and communication between the participating parties to provide the necessary view to all other parties to compute the composed public key (and resulting address), and also later generate the signatures.

Distributed signing may occur only after the key generation and usually involves interactive protocol for each party: receiving a message to sign, and applying local computation on the message using local data previously generated on the key generation protocol to distribute the results and compute signature locally.

In case of a central service that holds the customer's private keys, it is susceptible to attacks on the private keys' confidentiality and availability. Using multiple keys to sign a blockchain transaction (often named ‘MultiSig’) is typically considered to be a safe way to manage private keys. The splitting of the signature responsibility between multiple parties, and specifically between server and client, can eliminate the single point of failure confidentiality problems associated with the atomic private key, by, for example, effectively splitting the private key to client share and server share. However, this splitting can introduce multiple points of failure to the key availability, since if one of the shares is lost the customer cannot longer sign.