BLAKE3

BLAKE3 is a cryptographic hash function, it takes any amount of input data and produces a fixed-size fingerprint (256 bits, typically) such that changing even one bit of the input produces a completely different fingerprint, and finding two different inputs that hash to the same output is computationally infeasible. Its headline property relative to older hash functions (SHA-2, SHA-3) is speed: BLAKE3 is built around an internal Merkle-tree structure that parallelizes across CPU cores and SIMD instructions, making it dramatically faster on modern hardware while still being built from the same well-studied compression-function ideas as its BLAKE2 predecessor.

Hash functions like this are the quiet workhorse underneath almost everything else in this Lexicon: a transaction is hashed before it's signed (see Ed25519 / EdDSA), a Merkle tree is a tree of hashes, and a document's integrity can be checked by hashing it and comparing. Solidus uses BLAKE3 specifically for computing the canonical "signing bytes" of a transaction, the exact byte sequence that gets hashed and then signed, on both the chain (Rust) and the SDK (TypeScript) sides.

Where it comes from

BLAKE3 was designed by Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, and Zooko Wilcox-O'Hearn, published in 2020. It descends from BLAKE2 (Aumasson, Neves, Wilcox-O'Hearn, and Winnerlein) and the original BLAKE (Aumasson, Henzen, Meier, and Phan), one of the finalists in NIST's SHA-3 competition. None of this lineage is Solidus's work.

Solidus status

Shipped and in active use: the Rust node computes transaction signing bytes with the blake3 crate; the TypeScript SDK computes the same bytes with @noble/hashes/blake3. The hash function itself isn't the risk here, BLAKE3 is public, fast, and has no known practical attacks. The actual engineering risk is Solidus-specific and mundane: two independent implementations, in two different languages, have to compute byte-for-byte identical output for the same transaction, or a transaction that looks valid to the SDK will silently fail to verify on-chain. That's the kind of bug this stack has to guard against directly: it is not something the hash function's own security properties protect against.

As with everything in this Lexicon: this runs on Solidus's public testnet, and the protocol as a whole is unaudited.

Proof you can run yourself: BLAKE3's official test vectors are published in the algorithm's own reference repository and are implementation-independent, run them against the plain blake3 Rust crate and the plain @noble/hashes/blake3 TypeScript library (both third-party, open-source, nothing Solidus-specific) and confirm they agree with the standard, with zero need to trust Solidus's account of it.