Every entity (for instance, an account, a file, a smart contract) maintained in Hedera state has an associated set of public keys - it will be the corresponding private keys that must sign any transaction attempting to change that entity. Nodes will verify the signatures on a transaction against the defined key structure on the appropriate entity when processing the transaction to enforce the corresponding authorization policy. Hedera supports a flexible m-of-n and hierarchical key structure and so supports a powerful permissioning model for changes to entities in state.

The simplest model is that an entity has a single public key associated with it and so only the corresponding private key can make changes to that entity. For instance, if a cryptocurrency account had only a single public key specified when the account was created, then only transactions signed by the corresponding private key will be authorized to transfer hbars out of that account. Whoever has possession of the private key has sole control over the funds within the account (with associated risk of loss of control and access to those funds if the private key is lost, stolen, or forgotten).

Optionally, the account creator can also stipulate that the same private key be used to sign transactions that move hbars into the account – this mechanism providing protection to the account owner from receiving hbars from an illegal or inappropriate sender. An ICO might want the ability to guard against receiving hbars from an account that wasn’t KYC’d and by requiring that they sign any transaction depositing hbars into their account they would have a means to allow that check.

Account – an entity maintained on the Hedera ledger to represent the amount of hbars a particular user owns. The public key(s) associated with the account determine the permissions for changes to the account. For example, transferring hbars in or out. Only transactions signed by the corresponding private keys will be approved by nodes when processing those transactions.

Wallet – a software program that allows users to manage their accounts. For example, a wallet stores private keys used to sign transactions, provides a UI by which hbars can be spent, or attaches an identity claim to the account, query the balance of an account, etc. Wallets manage accounts through the submission of a transaction signed with the appropriate private keys to the ledger.

More complex key models, and so permission models, are possible. Instead of a single key being specified, multiple public keys can be specified, along with a defined threshold as to how many corresponding private keys must sign a transaction for it to be authorized. For instance, if 5 public keys are listed and the threshold is defined as 3, then a transaction would need to be signed by any 3 of the 5 associated private keys.

Furthermore, it is possible to define hierarchies of keys, in which any key in a list can itself be a list, with its own threshold. In this way, permissions of arbitrary complexity that can reflect the realities of real life and corporate structures can be defined.

Example key models and the corresponding authorizations are represented below:

How It Works

Unlike many other public ledgers, Hedera’s multi-sig capabilities are native to the platform and do not require a smart contract or script to enforce the m-of-n logic.

When an account (or more generally any entity) is created in the Hedera state, the desired permissions for that entity are defined through the specification of a set of public key(s) and thresholds.

When in the future a transaction requests that the account or entity be changed, the necessary signatures are coordinated and collected off-ledger. Once the necessary threshold has been achieved, the transaction is submitted to the network. When that transaction is received by the nodes, the signatures on that transaction are verified and tested against the defined permissions. If the signatures are all valid and meet the defined requirements, then the transaction will be approved and the account changed accordingly.

The same logic is applied to changes to the permissions on the account by changing the keys associated with the account. Only transactions with the required signatures will be allowed to change the keys. If the transaction is changing the keys, then the transaction must be signed by both the old key(s) as well as the new key(s). The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover.

Use Cases

We list below representative use cases that leverage the above permissioning model.

LiveHashes
By default, a crypto account on Hedera is pseudonymous. If the owner of that account chooses to, then they can logically attach an identity to that account, and so associate that identity with the transactions in and out the account. For instance, if a user were to undergo a KYC check, then the verified identity could be bound to a particular account, thereby allowing other parties to know the account is that of a known and valid individual. The binding is achieved by adding a hash of the identity credential (known as a livehash) to the account via a transaction. Both parties (the authority and the owner of the account) must sign the transaction that adds the livehash, but either can individually subsequently remove that livehash from the account. If the claim is removed by the authority, then the implication is that the authority no longer believes the identity is verified. If the livehash is removed by the account owner, then the implication is that they no longer wish that account to be associated with a known identity.

Social Key Recovery
When Alice creates her Hedera crypto account she specifies the public keys of three of her friends Bob, Carol, and Dave along with her own. Via the key structure, she stipulates that either she herself, or two of her three friends will have authority over the account. Of course, two of her friends could collude to steal the funds in the account – her calculation is that this would be unlikely, either because they are close friends or perhaps don’t know each other. If she is less trusting, then she could specify a wider group of friends, and a higher threshold. For example, four of five.

A year later, when Alice loses her phone on which her private key was stored, and cannot remember her seed phrase, she reaches out to her friends and asks for their help in setting a new key pair for her account. She generates a new key pair, and then asks Bob, Carol, and Dave to sign a CryptoUpdate transaction that switches the new public key for the old. Carol does not respond in time but Bob and Dave do, and both apply their signature to the transaction. The wallets of the friends facilitate this shared signature collection.

Alice submits the signed transaction to Hedera, where it is placed into consensus. All nodes check that the signatures of Bob and Dave satisfy the original policy that Alice set when she created the account. As they do, nodes authorize the transaction and attach the new public key (for which Alice has the private key) to the account.

Alice buys Bob and Dave a coffee with her hbars the next time she sees her friends. She replaces Carol on the list with a more reliable friend.

Private Key Protection
To mitigate the risk of her private key being compromised and hbars being stolen from her retirement account, Carol stipulates that all transactions out of the account be signed by both her private key and that of her lawyer, Trent. As the account’s transactions are infrequent, Carol is willing to bear the burden of coordinating signatures when she wants to make a purchase from the account.

As the signature threshold is two of two, Trent cannot move hbars without Carol’s participation. And should Carol’s private key be hacked, even with that key the thief would be unable to access Carol’s hbars without the participation of Trent. The presumption is that the likelihood of both Carol’s and Trent’s keys being compromised at the same time is small.

Trent will not sign a transaction before certain checks. For example, compliance checks, Carol’s authentication status, etc are performed. Trent’s own key is actually itself a one of two authorization model – with one key hot and online and the other stored in a cold vault. In this way, even if the hot key is lost, then the cold key can be brought out of storage and used.

Carol pays Trent for the peace of mind from knowing that the security of her Hedera account is not solely dependent on how she protects her private key. This could be combined with social key recovery, to also handle the case of lost keys.

Binding Arbitration For Smart Contracts
On Hedera, when a developer deploys a smart contract (that is, submits a transaction to the network with the compiled bytecode), they have a choice to make on the contract’s subsequent mutability. The default choice is that it will have the same guarantee of immutability as on other DLT’s, specifically, that it will forever be impossible for anyone to change its bytecode.

The other choice is for the developer to deploy the smart contract with a threshold key containing several public keys of arbitrators. In that case, the arbitrators have the authorization to subsequently edit the contract code, and so to fix bugs or add features or reverse specific transactions. Once a contract’s bytecode is deployed with such a stipulation, if the designated arbitrators subsequently agree that the contract should change, then a transaction with the new contract bytecode, signed by the keys of those arbitrators, will be approved by the network, and the change will be implemented.

This smart contract arbitration model is explored in more detail in the "Code is law, but what if the law needs to change?" post.

Summary

Hedera enables a flexible and dynamic permissioning model for entities in consensus state via a hierarchical m-of-n transaction signature based authorization model. The ability to require multiple signatures for operations on entities in state is critical for security and usability of public ledgers. Permissions can be defined that ensure that control of entities in Hedera state can both reflect the complexity of real-world business relationships, as well as protect users from the challenges of private key protection and management.