Hashing - c8ntinuum Docs

Hashing precompiles provide native implementations for hash functions used by commitments, proof systems, interoperability protocols, and data structures. They are useful when Solidity-only hashing would be too expensive or when the application needs a hash family that is not built into the EVM.

Surfaces

Surface	Address	Use it for
Gnark hash	`0x0000000000000000000000000000000000000705`	gnark-crypto aligned hash utilities for proof-system integrations.
SHA3 hash	`0x0000000000000000000000000000000000000706`	SHA-3 family hashing for standardized commitments.
BLAKE2b hash	`0x0000000000000000000000000000000000000707`	BLAKE2b hashing for high-performance protocol integrations.
Poseidon hash	`0x0000000000000000000000000000000000000711`	ZK-efficient hashing aligned with proving systems.

When to use

Use native hashing when a contract needs a hash family that Ethereum does not expose as a standard opcode or precompile.
Use Poseidon or gnark-aligned utilities when the off-chain proof system expects those hash semantics.
Use SHA-3 or BLAKE2b when integrating with external protocols that commit data using those functions.

Implementation notes

Concern	Guidance
ABI details	Use Precompile ABI Reference for method signatures and return values.
Gas	Variable-length stateless precompiles use a base-plus-word formula; confirm constants against the canonical ABI reference and tests.
Test vectors	Applications should keep test vectors for every hash function used in a protocol boundary.
Encoding	Hashes are only as stable as the byte encoding passed into them; define serialization explicitly.