HIP-222: Support ECDSA(secp256k1) keys Source

AuthorMichael Tinker
Needs Council ApprovalYes
Review period endsMon, 29 Nov 2021 07:00:00 +0000
TypeStandards Track


The only kind of public key that may currently appear in a Hedera key structure is a Ed25519 public key. It follows that users can only secure their transactions using Ed25519 signatures.

We propose to enable support for ECDSA(secp256k1) cryptography by,

  • Extending the Hedera API protobufs with new fields for ECDSA(secp256k1) keys and signatures.
  • Clearly documenting how users will populate these new protobuf fields.
  • Updating the node software to support ECDSA(secp256k1) keys and signatures wherever their Ed25519 equivalents are currently supported.

There are three design proposals in this HIP that, while fairly standard, deserve emphasis:

  1. Public keys are to be given in their compressed 33-byte form.
  2. The signing algorithm is to be keccak256-with-ECDSA; that is, clients will sign the keccak256 hash of the bytes in their SignedTrasaction#bodyBytes field.
  3. The signature bytes in the SignaturePair for a ECDSA(secp256k1) key are to be the raw 64-byte encoding of the (r, s) values of the ECDSA signature.


Some users might prefer to use ECDSA(secp256k1) keys as on the Bitcoin and Ethereum networks; for example, to simplify reuse of existing client code and tooling.


The protobuf specification below is the only natural extension of the existing Hedera API protobufs. We propose using 33-byte compressed public keys instead of uncompressed keys because the compressed form reduces both network usage and state size. We propose using the keccak256-with-ECDSA signing algorithm because this is standard on the Ethereum network.

User stories

  • As a smart contract developer, I want to use existing tools that assume ECDSA(secp256k1) keys.
  • As an owner of a Hedera account, I want to secure transactions involving my account with a ECDSA(secp256k1) key.
  • As the creator of a Hedera token, I want the supply manager role to be controlled by a ECDSA(secp256k1) keys.


Only two protobuf changes are required. To the Key message type, we need to extend the oneof key with a new choice:

message Key {
    oneof key {
         * Compressed ECDSA(secp256k1) public key bytes
        bytes ECDSA_secp256k1 = 7;

To the SignaturePair message type, we need to extend the oneof signature with a new choice:

message SignaturePair {
    oneof signature {
         * The 64-byte ECDSA(secp256k1) signature of the keccak256 hash of the body bytes, with
         * the (r, s) values of the signature concatenated in unsigned big-endian form.
        bytes ECDSA_secp256k1 = 6;

When a user is creating or updating a Hedera key structure to include a ECDSA(secp256k1) public key, they should set the bytes of the Key.ECDSA_secp256k1 field to the compressed form of the public key. (That is, the first byte should be 0x02 if the y-coordinate of the key is even, and 0x03 if the y-coordinate is odd; and the following 32 bytes should be the x-coordinate as an unsigned 256-bit integer.)

For example, if the uncompressed public key of the user’s key pair is,


Then the hex-encoded bytes of the Key.ECDSA_secp256k1 field should be,


When a user is providing an ECDSA(secp256k1) signature in a SignaturePair.ECDSA_secp256k1 field, it should be the 64-byte “raw” encoding of the (r, s) values that result from from signing the keccak256 hash of the SignedTransaction.bodyBytes from the top-level Transaction with the relevant ECDSA(secp256k1) private key. (That is, the signature bytes should be the concatentation of the r and s values in unsigned big-endian form.)

For example, if the user is signing the keccak256 digest,


with the private key,


Then the signature bytes should be,


Backwards Compatibility

This HIP does not make any breaking changes. Clients that continue to use Ed25519 keys and signatures will be unaffected.

Security Implications

If we observe a significant performance impact when verifying ECDSA(secp256k1) signatures compared to Ed25519 signatures, we will need to throttle transactions with ECDSA(secp256k1) signatures at a lower TPS.

How to Teach This

In one sentence: “Allow Hedera entities to be secured using ECDSA(secp256k1) keys and signatures.”

Reference Implementation


Rejected Ideas

No other designs seemed natural.

Open Issues

Signature verification is done through the Platform SDK, so the node software depends on the SDK being updated to also verify ECDSA(secp256k1) signatures with acceptable performance.



This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)


Please cite this document as: