Keys and Signatures

A key can be a public key of a supported system ED25519, ECDSA secp256k1, or an ID of a smart contract. Public and private keys are generated by the corresponding algorithm and are unique to one another. The public key can be shared and visible to other network users in a Network Explorer or REST APIs. The private key is kept secret from the owner and grants access to the owner to modify entities (accounts, tokens, etc.).

Private keys can only be recovered once lost if created with an associated recovery phrase that you can access. Keys are mutable and can be updated once set for an entity. Generally, you will need the current key to sign the transaction to update the keys. Hedera supports the following key structure types:

Key Type	Description	Example
Simple Key	A single key on an account.	Account Key { Key 1 } Only one key is required to sign for the account.
Key List	All keys in the key list are required to sign transactions involving the account.	Account Key KeyList (3/3) { Key 1 Key 2 Key 3 } All three keys in the list are required to sign for the account.
Threshold Key	A subset of keys defined as the threshold are required to sign the transaction that involve the account out of the total number of keys.	Account Key ThresholdKey (1/3) { Key 1 Key 2 Key 3 } One out of the three keys in the key list are required to sign for the account.

Key structures can be nested. This means you can have a more complex key system with key lists inside of threshold keys, threshold keys inside keys lists, etc. An example of a nested key list can be viewed here.

All transaction types support the above key structures that specify a key field. For a transaction to be successful, the provided signatures must match the defined key structure requirements.