Last updated
Was this helpful?
Last updated
Was this helpful?
A key can be a of a supported system , , or an ID of a . The corresponding algorithm generates public and private keys which are unique to one another. The public key can be shared and visible to other network users in a or . The 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.
The choice between ECDSA and ED25519 keys primarily depends on your specific use case:
Note: Hedera wallets such as support both key types.
Hedera supports the following key structure types:
🔔 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 .
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.
A key in Hedera can be a of a supported system such as , , or an ID of a . The corresponding algorithm generates public and private keys which are unique to one another. The public key can be shared and visible to other network users in a or REST APIs. The is kept secret and grants access to the owner to modify entities (accounts, tokens, etc.).
ECDSA
Ed25519
Use Cases
Ideal if you want to use MetaMask or need support for more EVM developer tooling. Suited for apps interfacing with Ethereum or EVM-compatible networks due to the associated EVM address.
Preferred if key length, security, and performance are important. ECDSA public keys are twice as long for the same level of security.
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 is required to sign for the account.