Master and Sub Key Generation

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.


Each party has a master key for managing a set of sub-keys that are used for signing transactions for different identity accounts.


Public key cryptography and digital signatures are used to identify accounts and authorise transactions submitted to a blockchain.


The use of a single key for all the transactions has privacy implications where the transactions could be correlated to expose the identity of the party. Alternatively, key management becomes a nightmare when different keys are used to sign different transactions. How can a party sign multiple transactions without potentially exposing his/her identity?


  • Identifiability – A party needs to create an identity to send transactions in the blockchain network.
  • Re-identification – Each party can have more than one identity in the real world. For example, one person is both a client of a bank and a patient of a hospital. When the party handles all the interactions with the same identity or a single key representing that identity, his/her privacy could be compromised as the transactions on a blockchain are transparent hence can be correlated.
  • Transparency – All the historical transactions on blockchain can be accessed by every participant within the same blockchain network. The transactions on a public blockchain are also accessible to everyone on the Internet.
  • Security – There is no standard approach to protect or recover a user’s secret key when exposed/compromised.


A user could use 2-levels of keys. One set of keys can be used to sign transactions as different identities. Another key can be used to protect the set of signing keys and their binding with identities. The first set of keys are called the sub-keys while the key that manages them is called the master key.

Master and sub-key pattern

Master and sub-key pattern

First, create a key for each identity of the user. Then track the (identity, sub-key) pair in a suitable form, e.g., store in an encrypted database, registry, or file. Use the master key to control the updates to (identity, sub-key) pairs. For example, a person can have a sub-key for the student identity and another sub-key for the intern at a company identity. Then link each sub-key to the student and intern identity, respectively. Store this mapping in an identifier registry such that it can be updated using only the master key.

In an extreme case, each transaction can have a separate identity and a corresponding private key. The master key must be well protected. The use of master-key must also be minimised (i.e., only used for controlling sub-keys) to prevent the possibility of linking or compromise.


  • Identifiability – Each sub-key maintains its own identity. The transactions sent under different identities are less likely to be mapped and correlated to re-identify the user.
  • Availability – If a sub-key is lost or compromised or lost, a new key can be created and mapped to the same identity using the master key.


  • Security – If the master key is lost or compromised, the identity owner loses control of all the sub-keys which means loss of control of all the owned identities. If a sub-key is compromised it may not be possible to recover the assets managed by that key
  • Scalability – Either the user or some software on behalf of the user still need to manage and protect a large number of keys.

Related patterns

  • Hot and cold wallet storage pattern is used to store frequently used keys in one waller and rarely used ones in another wallet (physically) seperated from each other.
  • Key shards pattern can be used to protect and recover keys.
  • The identifier registry pattern can be used to maintain (identity, sub-key) pairs.
  • Sub-keys can register identifiers for different identity relationships using multiple registration pattern.

Known uses

  • Trinity is a wallet application of IOTA ledger. Each account has a seed that acts as a master key to control multiple accounts and IOTA tokens of that specific account.
  • A uPort user interacts with application smart contracts via a proxy smart contract. Thus, the public key of the proxy contract is considered as a layer of indirection between the user’s private key and the target application contract.
  • ERC-725 is a blockchain-based identity standard for Ethereum. It proposes the use of proxy smart contracts that are controlled by multiple keys and other smart contracts. Those identity smart contracts act as uniquely identifiable proxy accounts that can be used by humans, groups, organisations, objects, and machines.