The hash checks out. The chain hasn't seen it yet

We tested two steps that usually show up stacked in the same sentence: computing the SHA-256 and registering a hash on a blockchain. The first passed. The second hasn't happened yet. Let's not call transaction preparation an on-chain proof.

What passed the test

The Hash Notary computes SHA-256 in the browser itself. The text is converted to UTF-8 bytes and processed by Web Crypto; the page doesn't send or store it. NIST FIPS 180-4 describes the Secure Hash Standard, which includes SHA-256.

We used the known vector abc. The browser's result and the check with node:crypto were equal:

node -e 'console.log(require("node:crypto").createHash("sha256").update("abc").digest("hex"))'

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

That's a reproducible test of the computation — not a proof of authorship. And the detail of the bytes matters: a space, an accent, a line break, or any other change in the input can change the digest.

What a hash proves — and what it doesn't

With the original content in hand, recomputing and getting the same digest is a good way to check that the bytes being compared are identical, assuming a secure hash was chosen and the reference digest came from a trusted channel. The reverse is not a promise: SHA-256 doesn't encrypt the text and can't be used to recover it.

A digest, on its own, doesn't identify who wrote the content, when it was created, whether it's true, or whether it has legal validity. A later transaction can show that a key published that digest in that transaction; it doesn't turn the key into a civil identity, nor prove the text's origin.

Nor should you publish sensitive data on a blockchain. The Memo Program records text visible in the logs and indexable by explorers; even a hash can reveal short or predictable content if someone tests candidates and compares the results.

Where the Solana step stopped

To test this part, we prepared a throwaway key and built a Memo instruction on Devnet, a test network with no market-value SOL. The signature was validated locally in dry-run mode; the transaction was not sent.

Helius's RPC responded to the version and balance queries. The requestAirdrop request, however, returned HTTP 500; the next query still showed a zero balance. Without a balance, there's no fee to pay. So, in this experiment, there is no confirmed transaction signature, no recorded Memo, and no explorer link to check. Helius's documentation describes requestAirdrop for requesting test SOL; Solana's quick start advises using the web faucet when the airdrop fails due to a rate limit or another error.

This is a funding block on the test wallet, not a failure of SHA-256. The next test, once there's Devnet SOL, is to send only the Memo with the test digest and then fetch the transaction from the RPC to check that the text reappears in the logs — exactly the flow described in Solana's documentation on Memo. Only after that can you publish the receipt and say the hash was registered on-chain.

Sources and limits

• NIST — FIPS 180-4, Secure Hash Standard
• Solana — Payment with Memo
• Solana — Quick Start and Devnet Faucet
• Helius — requestAirdrop

This is an educational experiment on a test network, not a stamping service, a legal opinion, or a recommendation to store secrets on a blockchain.