How it works, and what it rests on

One scheme, one hash function, and no curve anywhere. This page is the whole of it. Everything stated as a figure is imported from the module that defines it, so this page cannot disagree with the code.

The scheme

Identifier, bound into every digestephapax/wots-sha256/w16/h8/v1
HashSHA-256, 32-byte output
Winternitz parameterw = 16, so 4 bits per chain
Message chains64
Checksum chains3
Chains in total67
Signature67 x 32 = 2,144 B
Merkle heighth = 8
One-time keys per identity256, and never more
Authentication path8 x 32 = 256 B
Full attestation2,436 B
Hashes a verifier walks45 at best, 990 at worst

None of those are choices. A 256-bit digest at 4 bits per chain needs 64 chains; the checksum can reach 64 x 15 = 960, which takes 3 more. 67 is forced, and lib/scheme.ts refuses to load if the arithmetic ever stops holding.

Signing, and why one key means one

A secret value per chain is derived from a seed. Each is hashed 15 times to make the public key. To sign, the digest is cut into 4-bit pieces and chain i is released at step d[i] rather than 15. A verifier walks the remaining 15 − d[i] steps and must land exactly on the public key.

Anyone holding a signature can walk a chain forward, which raises a nibble for free. The checksum is the sum of (15 − d) over the message chains, so raising one always lowers the checksum, and lowering a checksum nibble means walking a hash chain backwards. That is the entire security argument, and it is attacked directly in scripts/probe-crypto.mts rather than asserted here.

Two signatures under one key leak enough to forge a third. That is a property of the scheme and nothing in software can remove it. An identity has 256 keys, each spent once, and this site prints how many are left rather than letting a leaf be used twice quietly.

Why it cannot go on chain in one transaction

An attestation is 2,436 bytes. A Solana transaction is capped at 1,232. The two numbers are not close, so any product claiming to put a full hash-based signature into one transaction is claiming something the chain will not do.

The only honest arrangement is to stage the signature across several writes into a buffer account and have a program verify the buffer. That is what will be built here. It is not built yet, no program is deployed, and no page on this site says one verifies anything.

Where the keys come from

Seeds are derived from a signature your wallet makes over a fixed sentence, and are never stored or sent anywhere. The same wallet rebuilds the same identity in any tab, and a breach of this site leaks no key material because none ever arrived.

The honest limit: that signature is ed25519. An adversary who can break ed25519 can forge it and rederive the identity, so a wallet-derived identity is post-quantum for everyone except someone who has already broken your wallet. A hardened identity mixes in a secret the wallet never saw, and only that one is free of the assumption. The two are labelled differently everywhere on this site, and the first is never called quantum-secured.

The four things that would make this false

These are rendered on the landing page too, beside the claims they qualify, because a disclosure that lives only in documentation is a disclosure the reader of the claim never sees.

  1. 01 · Only SHA-256 stands behind a key here
    Grover's algorithm halves that, so the honest figure is about 128 bits against a quantum adversary, not 256.
  2. 02 · Each key signs exactly once
    Two signatures under one key leak enough to forge a third. The identity has 256 keys and the page prints how many are left.
  3. 03 · A program will verify the signature on chain
    None is deployed today. When one is, whoever holds its upgrade authority can replace it, so until that authority is set to none this page names the key that can.
  4. 04 · A root can be anchored on Solana
    Anchoring is a separate, optional transaction. An identity that has not been anchored says so, and no page counts it as if it had.

Checking one yourself

The verify page runs in your browser and calls nothing. It imports the same four library files the rest of the site uses. Load the tampered sample before the real one: a verifier that cannot be made to say no is not telling you anything when it says yes.

The same files run under node with no bundler, which is why every import in them carries an explicit .ts extension. A scheme that can only be executed inside somebody's build system is a scheme nobody can check.

What is live

EPHAPAX is not launched. ephapax.fun was measured free on 2026-10-10 and is not registered. There is no coin, no deployed program, and no registered identity. Every page says so where it would otherwise read as though there were.