Accounts, Signature Verification & Keys (ECDSA vs. ED25519)

Overview

Understanding Account Models and Aliases

Clarifying Account ID vs. EVM Address

Working With ECDSA Accounts in Testing

• During testing, use the EVM Address returned by the account object, not the Account ID (e.g., 0.0.xxxx). If the account was created with setECDSAKeyWithAlias(), that value is the EVM Address from Public Key (the 20-byte Keccak-256(publicKey) form) and works with EVM tools like Hardhat and Truffle and with ECRECOVER. If no alias was set at creation, the account falls back to the EVM Address from Account ID (the long-zero form), which is not compatible with ECRECOVER. Confirm which form your account uses before deploying.
• Including this conversion step in your test setup saves time and confusion, ensuring your EVM-compatible smart contracts can reliably work with Hedera’s ECDSA accounts.

Key Permutations & Scenarios on Hedera

• ECDSA Accounts:
  • Behave similarly to standard EVM accounts.
  • Allow validation of ECDSA signatures with ECRECOVER.
  • Provide smooth interoperability with EVM tools and dApps.
• ED25519 Accounts:
  • Require isAuthorized or isAuthorizedRaw for signature validation.
  • Support complex configurations like multi-key or threshold-based approval.
  • Enhance security and adaptability, but differ from EVM’s static address.

Using ECRECOVER for ECDSA Accounts on Hedera

function verifyECDSASignature(bytes32 messageHash, uint8 v, bytes32 r, bytes32 s) public pure returns (address) {
    return ecrecover(messageHash, v, r, s);
}

• ECDSA accounts on Hedera behave just like EVM accounts when validating signatures with ECRECOVER.
• Use ECDSA accounts when interacting with EVM-compatible dApps, wallets, or bridges for minimal friction.

Using System Contract Functions for ED25519 Accounts

• isAuthorized: Validates a protobuf SignatureMap against the account’s full key, supporting threshold or multi-key accounts.
• isAuthorizedRaw: Validates a single ED25519 or ECDSA signature over a 32-byte hash, analogous to ECRECOVER but also for ED25519 keys.

// SPDX-License-Identifier: Apache-2.0
pragma solidity ^0.8.24;

interface IHederaAccountService {
    function isAuthorizedRaw(address account, bytes memory messageHash, bytes memory signature)
        external
        returns (bool authorized);

    function isAuthorized(address account, bytes memory message, bytes memory signature)
        external
        returns (int64 responseCode, bool authorized);
}

contract SignatureVerifier {
    IHederaAccountService internal constant HAS = IHederaAccountService(address(0x16a));
    int64 internal constant SUCCESS = 22;

    // Returns true only if the signature over messageHash is valid for the account's key
    function verifyED25519Signature(address account, bytes32 messageHash, bytes calldata signature)
        public
        returns (bool)
    {
        return HAS.isAuthorizedRaw(account, abi.encodePacked(messageHash), signature);
    }
}

• Hedera-Native Accounts:
  Most Hedera accounts use ED25519 keys, so isAuthorizedRaw is essential for verifying their signatures.
• Multi-Key and Threshold Accounts:
  Use isAuthorized for scenarios requiring multiple signatures, ensuring only properly authorized actions occur.

Practical Use Case: Multi-Key Verification

// Add to the SignatureVerifier contract above.
// signatureMap is a serialized protobuf SignatureMap with one signature per key.
function validateDAOProposal(address account, bytes memory proposalData, bytes memory signatureMap)
    public
    returns (bool)
{
    (int64 responseCode, bool authorized) = HAS.isAuthorized(account, proposalData, signatureMap);
    return responseCode == SUCCESS && authorized;
}

Key Updates and EVM Addresses

• The EVM Address from Public Key is immutable. Updating an account’s keys with CryptoUpdateTransaction does not change it; the address stays bound to the original ECDSA public key. After a key update, the account can no longer send EVM transactions: the network rejects a JSON-RPC transaction signed with the old key (INVALID_SIGNATURE, because it no longer matches the account’s key), and a signature from the new key recovers to a different address that does not belong to the account. ECRECOVER checks against the address still accept the old key.
• Recover by migrating, not by rotating. If an ECDSA key is compromised or must be replaced, create a new ECDSA account with a new EVM address and migrate assets and state to it. Do not rely on key rotation to keep the same EVM identity.
• isAuthorized follows the account’s current key. Contracts that verify an account through isAuthorized check whatever key the account holds at call time, so they accept the new key after an update.
• If you expect to rotate keys soon after creation, consider not setting the EVM Address from Public Key at creation. This is a trade-off: the account then uses its EVM Address from Account ID (the long-zero form), and it cannot send transactions from EVM wallets or through JSON-RPC at all, because the network finds the sender of an EVM transaction by the address its signature recovers to. It also does not work with ECRECOVER. Native SDK transactions and isAuthorized checks keep working.

contract TrustedSignerRegistry {
    address public trustedSigner;

    constructor(address initialSigner) {
        trustedSigner = initialSigner;
    }

    // Called by the current signer to hand control to a newly created account
    function updateTrustedSigner(address newSigner) public {
        require(msg.sender == trustedSigner, "Not authorized");
        trustedSigner = newSigner;
    }
}

Additional References and Resources

• Hedera SDKs
• Hedera Account Service
• HIP-632 Specification
• Hedera Account Service System Contract