Skip to main content

​
Overview

Migrating to Hedera’s EVM implementation involves understanding key differences in account models, signature verification, and key types. On Ethereum, addresses are derived from ECDSA public keys, and ECRECOVER is commonly used to validate signatures. Hedera, however, supports both ECDSA and ED25519 (Hedera-native account) keys, with dynamic key rotation and aliases that may not directly align with Ethereum’s static address model. This section helps you navigate ECDSA and ED25519 signature workflows, introduces the isAuthorized function from the system contract from HIP-632, and clarify how different account key scenarios map onto Hedera’s environment.

​
Understanding Account Models and Aliases

Hedera’s account model supports both ED25519 and ECDSA keys by identifying accounts by aliases instead of static addresses. This allows dynamic key rotation without changing an account’s ID, unlike EVM’s static ECDSA-only approach. Signature validation varies accordingly: ED25519 keys use isAuthorized or isAuthorizedRaw, while Hedera’s ECDSA accounts with aliases can still rely on ECRECOVER.

​
Clarifying Account ID vs. EVM Address

Hedera accounts have a native Account ID (e.g., 0.0.xxxx) and can also have an EVM Address from Public Key (a 20-byte address like Ethereum’s, derived from the ECDSA public key). The EVM Address from Public Key makes the account compatible with ECRECOVER and other familiar EVM tools. For more details, see the Smart Contract Addresses page.

​
Working With ECDSA Accounts in Testing

If you are writing an Ethereum smart contract and need to interact with an ECDSA Hedera account identified by its Account ID, reference it by its EVM Address so that functions like ECRECOVER resolve the correct account, as long as the EVM Address is correctly set from the account’s public key. Here are some considerations:
  • 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.
This flexibility enables interoperability and more robust security models than standard EVM environments.

​
Using ECRECOVER for ECDSA Accounts on Hedera

Hedera supports ECDSA accounts, allowing EVM developers to validate ECDSA signatures using familiar tools like ECRECOVER. ECDSA accounts on Hedera use aliases derived from Keccak-256(publicKey), ensuring compatibility with Ethereum’s signature workflows. Example: Verifying ECDSA Signatures Using ECRECOVER 
function verifyECDSASignature(bytes32 messageHash, uint8 v, bytes32 r, bytes32 s) public pure returns (address) {
    return ecrecover(messageHash, v, r, s);
}
Key Considerations:
  • 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

Hedera’s native key type is ED25519, which is not compatible with ECRECOVER. To accommodate ED25519 (Hedera-native) accounts and more complex configurations, HIP-632 introduces Hedera Account Service system contract functions:
  • isAuthorized: Validates multiple signatures, supporting threshold or multi-key accounts.
  • isAuthorizedRaw: Validates a single raw ED25519 signature, analogous to ECRECOVER but for ED25519 keys.
Example: Validating ED25519 Signatures 
function verifyED25519Signature(address accountAlias, bytes32 messageHash, bytes memory signatureBlob) public returns (bool) {
    (bool success, ) = address(0x167).call(
        abi.encodeWithSignature(
            "isAuthorizedRaw(address,bytes32,bytes)",
            accountAlias,
            messageHash,
            signatureBlob
        )
    );
    return success;
}
Why This Matters for EVM Developers:
  • 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.
Note: For detailed parameter formats, consult the HIP-632 specification and the Hedera Account Service documentation. Ensure that accountAlias, messageHash, and signatureBlob adhere to the required formats outlined there.

​
Practical Use Case: Multi-Key Verification

Hedera supports advanced account configurations like multi-sig and threshold accounts, which may include both ECDSA and ED25519 keys. Using isAuthorized, you can enforce complex signing requirements, such as requiring multiple parties to sign before executing a contract operation. Example: DAO Governance Using Multi-Sig 
function validateDAOProposal(address accountAlias, bytes memory proposalData, bytes memory signatureBlob) public returns (bool) {
    (bool success, ) = address(0x167).call(
        abi.encodeWithSignature("isAuthorized(address,bytes,bytes)", accountAlias, proposalData, signatureBlob)
    );
    return success;
}
This example demonstrates how you might require multiple signatures to approve a DAO proposal, enhancing the security and trustworthiness of your governance mechanisms.

​
Key Rotation: Adapting to Hedera’s Dynamic Model

Standard EVM addresses are static since they are derived from a public key hash. Hedera, by contrast, supports dynamic key rotation, letting you update the keys controlling an account without changing the account’s address. Why This Matters for EVM Developers:
  • Your applications must dynamically validate the current set of keys each time rather than relying on a static key-to-address mapping.
  • By rotating keys, you can enhance security without migrating to a new address.
Example: Key Rotation in Smart Contracts 
contract KeyRotationHandler {
    address public trustedSigner;

    constructor(address initialSigner) {
        trustedSigner = initialSigner;
    }

    function updateTrustedSigner(address newSigner) public {
        require(msg.sender == trustedSigner, "Not authorized");
        trustedSigner = newSigner;
    }
}
This simple pattern allows you to change the trusted signer as needed, reflecting real-world operational needs such as periodic key rotation to mitigate security risks.

​
Additional References and Resources