Keys and Signatures

Understand ECDSA secp256k1 and Ed25519 keys on Hedera: when to use each, public and private key roles, signature verification, and EVM compatibility.

Key Types: ECDSA vs Ed25519

A key can be a public key of a supported type — ECDSA secp256k1 or Ed25519 — or an ID of a smart contract. The corresponding algorithm generates a public and private key pair that are unique to one another. The public key can be shared and is visible to other network users in a Network Explorer or REST APIs. The private key is kept secret by the owner and grants access 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.

ECDSA secp256k1 (Recommended)

ECDSA secp256k1 is the recommended key type for all new accounts and applications on Hedera. It is the same cryptographic curve used by Ethereum and the broader EVM ecosystem, which means:

• ECDSA accounts should set an EVM Address from Public Key, an EVM address derived from the ECDSA public key. It is the rightmost 20 bytes of the 32-byte Keccak-256 hash of the ECDSA public key, calculated in the manner described by the Ethereum Yellow Paper. Note that the recovery ID is not formally part of the public key and is not included in the hash. The EVM address is also commonly known as the public address. On mainnet, the corresponding account ID is 0.0.<evmAddress>.
• The EVM Address from Public Key enables full compatibility with Solidity smart contracts, msg.sender checks, and EVM-based tooling such as MetaMask, Hardhat, and Foundry.
• ECDSA keys work seamlessly with wallets and dApps built for EVM-compatible networks.

For maximum compatibility with Solidity and smart contracts, set the EVM Address from Public Key when creating an account by using setECDSAKeyWithAlias(). This ensures the account’s EVM address is derived from its ECDSA public key, so msg.sender in a contract resolves correctly to the account’s EVM address.

// Generate a new ECDSA key for the account
const accountPrivateKey = PrivateKey.generateECDSA();
const accountPublicKey = accountPrivateKey.publicKey;

const txCreateAccount = new AccountCreateTransaction()
  .setECDSAKeyWithAlias(accountPublicKey);

Key rotation trade-off: The EVM Address from Public Key is permanently bound to the original ECDSA public key and does not change when the key is rotated. If your operational model requires key rotation, use setKeyWithoutAlias() at creation, and the account will fall back to its EVM Address from Account ID (long-zero form). See the Create an Account reference for details.

Ed25519 (Supported)

Ed25519 is a supported key type on Hedera. It does not produce an EVM Address from Public Key, so Ed25519 accounts cannot use EVM tooling, MetaMask, or Solidity’s native ECRECOVER function directly. However, Ed25519 accounts can interact with smart contracts through the HIP-632 system contract functions (isAuthorized and isAuthorizedRaw), which enable on-chain verification of Ed25519 signatures.

Ed25519 is appropriate for HCS-based applications, Hedera-native workflows, and scenarios where EVM compatibility is not required

Comparison

	ECDSA secp256k1	Ed25519
Recommendation	✅ Recommended for all new accounts and applications	Supported, not recommended for new development
EVM Address (alias)	Yes. Set at account creation using setECDSAKeyWithAlias(), derived from the Keccak-256 hash of the ECDSA public key	No. Ed25519 accounts have no EVM address
Smart Contract Compatibility	Full. Works with msg.sender, ECRECOVER, Solidity, and EVM tooling	Limited. Requires HIP-632 system contract functions (isAuthorized/isAuthorizedRaw) for on-chain signature verification. Not compatible with ECRECOVER or standard EVM tooling
Wallet Support	MetaMask, HashPack, and all EVM-compatible wallets	HashPack and Hedera-native wallets only
Use Cases	All use cases, especially dApps, DeFi, smart contracts, and EVM-compatible integrations	HCS-based applications, Hedera-native workflows, and scenarios where EVM compatibility is not required

Note: Hedera wallets such as HashPack support both key types.

Key Structures

Hedera supports the following key structure types:

	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.

🔔 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.

FAQ

What is a key in Hedera?

A key in Hedera can be a public key of a supported type — ECDSA secp256k1 (recommended) or ED25519 — or an ID of a smart contract. 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 Network Explorer or REST APIs. The private key is kept secret and grants access to the owner to modify entities (accounts, tokens, etc.).

Which key type should I use?

Use ECDSA secp256k1 for all new accounts and applications. ECDSA keys are compatible with Ethereum and the EVM ecosystem, can be assigned an EVM Address from Public Key at account creation using setECDSAKeyWithAlias(), and work with tools like MetaMask, Hardhat, and Solidity smart contracts. Ed25519 is supported but does not provide an EVM address and is not compatible with EVM tooling. Ed25519 accounts can still interact with smart contracts through HIP-632 system contract functions.

What is an EVM Address from Public Key and why does it matter?

The EVM Address from Public Key is the rightmost 20 bytes of the 32-byte Keccak-256 hash of the ECDSA public key of the account, calculated in the manner described by the Ethereum Yellow Paper. The recovery ID is not formally part of the public key and is not included in the hash. To set it, use setECDSAKeyWithAlias() when creating the account. This address is what Solidity contracts see as msg.sender, and it enables full compatibility with smart contracts and EVM-based tooling. See ECDSA secp256k1 (Recommended) above for the full derivation details.

What happens if I lose my private key?

Private keys can only be recovered once lost if created with an associated recovery phrase that you can access. It’s crucial to keep your private keys safe and secure as they grant access to modify your Hedera entities, like accounts and tokens.