Hedera Account Service
Last updated
Was this helpful?
Last updated
Was this helpful?
EVM developers should note that ECRECOVER natively supports ECDSA accounts on Hedera. Aliases for these accounts, derived using Keccak-256(publicKey), are fully compatible with Ethereum's ECRECOVER logic. This enables seamless interaction with ECDSA accounts on Hedera using ECRECOVER, just like standard Ethereum accounts.
To verify an ECDSA signature, developers can call ECRECOVER(messageHash, r, s, v) in Ethereum smart contracts. If the recovered address matches the alias of a Hedera account, the signer is confirmed to control the account. No special integration is needed—ECRECOVER functions as a standard EVM precompiled contract on Hedera
To extend Hedera’s compatibility with Ethereum’s EVM, introduced two new precompile functions for signature validation: isAuthorizedRaw and isAuthorized. These precompiles enable smart contracts on Hedera to validate both ED25519 and ECDSA (secp256k1) Hedera account signatures, making it easier for developers to build applications that operate across Hedera-native and EVM-based ecosystems.
Additionally, these functions allow developers to verify account authorization directly within smart contracts. This extends the capabilities of Ethereum’s ECRECOVER by supporting:
Simple raw signature verification for both ED25519 and ECDSA keys, similar to how Ethereum's ECRECOVER checks the signature against the provided message hash.
Account authorization verification for ECDSA accounts, confirming that the account associated with the signature is authorized to execute transactions without being restricted to ECRECOVER.
Comprehensive account authorization using protobuf signature maps, which allows for a more complex and flexible account validation process, ensuring compatibility with Hedera's advanced account model. May include multi-sig or threshold key structure.
By addressing these use cases, HIP-632 provides a seamless way for developers to handle authorization and signature validation across both Hedera and EVM-compatible environments.
Validates whether a given ED25519 or ECDSA signature is valid for a message against the public key associated with the specified account alias.
Operates similarly to Ethereum's ECRECOVER for single key structure but supports both secp256k1 (Ethereum) and ED25519 (Hedera) cryptography.
Returns true if the signature is valid and linked to the account, otherwise false.
Extends isAuthorizedRaw by validating that the specific Hedera account (referenced by either an account number alias or EVM address alias) is authorized to execute the transaction.
Supports Hedera’s complex account key structures, including multi-sig and threshold key requirements.
Provides a way to confirm authorization based on Hedera’s advanced account-based key management.
Returns true if the signature is valid and linked to the account, otherwise false.
address
A 20-byte identifier used to represent an account on the Hedera network or an EVM-compatible account.
message
The original plaintext data or payload that the signature is derived from. This is the information that was signed to produce the signature.
messaHash
A cryptographic hash of the message, calculated using an algorithm like SHA-256 or Keccak-256. This is typically what is signed instead of the raw message.
signatureBlob
A concatenation of the digital signature components, typically including r, s, and v values for ECDSA, or the equivalent data for ED25519 signatures.
Both functions return a boolean indicating whether the signature is valid and is authorized for the account.
These methods incur gas costs proportional to the computational resources required for signature validation, including cryptographic hashing of the message and verifying the signature against the public key.
The additional gas charge varies depending on the type of cryptographic operation (ED25519 vs. ECDSA) and the size of the associated key structures.
Reference:
