Which Hash Function Secures Your Wallet? There Are Two, in Different Layers

The question assumes one answer. There are two, and which one applies depends on whether you are asking about the chain or about a credential.

Where each one is used

The chain uses BLAKE3. Your transaction's signing hash is BLAKE3 over the public key, the nonce and the payload. Your address is the first twenty bytes of a BLAKE3 hash of your public key. It appears across eighteen files of the chain crates.

The credential layer uses SHA-256. The hash helper in the credential package accepts that algorithm and throws on anything else, which is a stronger position than quietly defaulting.

A control makes the split real rather than an accident of imports: CONTROL that makes the split real rather than an accident of imports: the two live in different packages and neither appears in the other's role. This is a division by layer, not a codebase that happens to contain both.

Why the credential layer had no choice

Because the format specifies it. A selective-disclosure credential's digests are defined by the specification, and an implementation that used a different hash would produce something no other implementation could verify.

You do not get to pick a hash inside a standard format, and that constraint is the whole reason the credential layer is interoperable at all.

Why the chain could choose, and what it chose

A chain defines its own transaction format, so it picks. Ours picked BLAKE3.

What that buys: a modern design built on well-studied primitives, with a tree structure that parallelises, and a single function rather than a family of variants.

What it costs, and this is the part usually left out: one of these two is a long-published standard with decades of public analysis behind it, and the other is not. BLAKE3 is not a government-published standard, and for a system that hopes to be used in regulated environments that is a real consideration rather than a theoretical one.

We are not saying it is weak. We are saying that "widely analysed" and "formally standardised" are different properties, and a procurement process frequently asks about the second.

What we are not going to tell you

No speed figure. BLAKE3 is commonly described as fast, and we have never measured it in this system, so any number here would be borrowed from somebody else's benchmark on somebody else's hardware.

What is already built, because absences alone would misdescribe us

Both choices are consistent and enforced. The credential helper rejects an unexpected algorithm rather than assuming, and the chain's layout is pinned by tests that assert byte-parity with the Rust implementation. Neither is improvised, and the fact that the two layers differ is a consequence of one of them following a specification rather than of nobody deciding.

And the fragility is not in the hash

Worth stating because it is where attention should go: the signing hash covers a JSON serialisation of the payload, and JSON key order and whitespace are free.

Two correct serialisers can disagree about bytes, and the hash faithfully reports that they disagree. The hash function is doing its job perfectly; the input construction is the brittle part. That mitigation exists as cross-language parity tests, and it is the thing to watch rather than the choice of algorithm.