SPHINCS ｜A Post-Quantum Mint Token

Sphincs Minus: A Post-Quantum Mint Token
Idea: @VitalikButerin

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

sphincs minus.

the first meme coin gated by a post-quantum signature.

every mint requires a real SPHINCS- signature — vitalik's hash-only PQ scheme. no elliptic curves. no shor. just keccak.

every claim is gated by a real ~700-byte SPHINCS- signature. you generate a keypair, sign one message, burn the key forever. the signature mints 500 $SPHINCS to you.

shor's algorithm doesn't touch it. if it ever breaks, ethereum's state trie breaks first.

fully fair. no presale. no team allocation.

· 21M hard cap, 20M circulating (1M burned to 0x…dEaD)
· 10M public mint, 20,000 slots × 500 each, 0.0025 ETH per slot
· 10M LP reserve
· contract is immutable. no admin, no proxy, no pause.

mint https://t.co/tIDyJjPM9v
proof https://t.co/M5LwuAdRdW (every (pk, sig, attestation) tuple is public — re-verify with vitalik's python)
code https://t.co/VJF7o34N4e

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

small finding while integrating @VitalikButerin's sphincsminus into
a real signing flow:

base_w(msg, w, out_len) returns all zeros whenever log_w > 8.

>>> base_w(b"\xff"*32, 1<<16, 8)
[0, 0, 0, 0, 0, 0, 0, 0]

which is exactly what FORS hits under the C7 production set (a=16).
test set (a=3) doesn't surface it. issue + two related concerns:
https://t.co/ZNfmqiHj7W

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

Hi @VitalikButerin a question about sphincsminus deployment, not theory:

if ethereum had to ship a hash-based signature verifier *on L1* today,
which of these do you actually prefer, and why?

1. a SPHINCS-style precompile (concrete EIP, fixed params)
2. zk-wrapped verifier (one circuit, any params, but groth16/plonk
trusted-setup or starks per upgrade)
3. defer L1 entirely — keep PQ verification off-chain + on-chain
fraud-proof window

the "test" params in your repo verify in ~hundreds of thousands of
hashes. is that close enough to a precompile budget, or is the realistic
path always (2)?

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

Warning! The DEX link is a fake website. We are contacting DEX to change the website.

We have been conducting a series of continuous developments, and more token-related applications will be announced soon.

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

notes on shipping @VitalikButerin 's sphincsminus into a real product flow.

(1) what it is
sphincsminus is a stateless, hash-based signature scheme. security reduces to
the preimage / second-preimage resistance of the hash function — no lattices,
no pairings, no number theory, no trusted setup. if your hash holds, your
signature holds. that's the entire premise. it is post-quantum because no
known quantum algorithm meaningfully accelerates generic hash inversion
beyond Grover, which a wider output already absorbs.

(2) how the signature is built
each signing seed expands deterministically into a *hypertree*: many WOTS+
one-time signatures sitting at the leaves of nested Merkle trees, plus a FORS
few-time signature layer that maps the message into a specific subset of
those leaves. a signature is a path through that tree plus the WOTS+ chain
revealing just enough hash preimages to authenticate the message — and
nothing more. you never sign the same WOTS leaf twice; the tree structure
amortises that one-shot constraint across an astronomical address space.

(3) what's hard in practice
the standardised SPHINCS+ parameter sets produce ~8KB–~50KB signatures.
verification is hundreds of thousands of hash calls. for an L1 verifier this
is expensive but not infeasible. for an L1 verifier that has to run inside
21M-ish gas per tx, it's "pick your battles". vitalik's sphincsminus repo is
a minimal, readable reference — perfect for studying the geometry, less
suited as a drop-in for EVM gas budgets.

(4) the engineering pattern we ended up with
- generate the keypair client-side. seeds come from os.urandom; the reference
code's deterministic default seeds were the first thing we patched.
- sign a domain-separated message: keccak256("sphincs-mint:v1") || keccak256(pk)
|| recipient. domain tag prevents cross-protocol replay; binding recipient
prevents stolen-signature reuse.
- verify the SPHINCS- signature off-chain with the reference verifier.
- on success, emit a short EIP-712 attestation (32+20+32 bytes hashed) signed
by a hot key, and let the contract check that with ecrecover.
- publish (pk, full signature, message, attestation) as an audit record so
anyone can re-run the python verifier byte-for-byte.

(5) trust model, stated honestly
the on-chain check is ecrecover over a 3-field EIP-712 struct. the
post-quantum guarantee lives in the *off-chain* re-verification path plus the
public audit log. compromising the hot key lets an attacker mis-attest, but
cannot fabricate a SPHINCS- signature; the audit log makes any such
mis-attestation immediately falsifiable. this is the same shape as
"optimistic + fraud proof", just with the fraud-proof being one python
script anyone can run in 30 seconds.

(6) where the on-chain layer could go next
swap the ecrecover step for an actual SPHINCS- verifier precompile, or a
zk wrapper proving "I ran verify_test_vector.py and it returned True". the
attestation contract is already shaped for that — pkHash is the only PQ
artifact it touches; everything else is plain EVM. the moment a cheap
on-chain verifier exists, this same contract becomes truly post-quantum
end-to-end without a redeploy story for users.

inviting smart eyes on the wrapper, especially around:
- message encoding & domain separation
- WOTS+/FORS parameter choices for the "test" set
- whether the audit-log-as-fraud-proof framing actually buys what we claim

site: https://t.co/reyx6js5gm
repo: https://t.co/GcTeBye1XU

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

end/
tokenomics:
- 21M hard cap
- 10M public mint (SPHINCS-gated)
- 10M LP reserve
- 1M team — burned to 0xdead
→ 20M circulating

site: https://t.co/5cX1U9DuQA
repo: https://t.co/KXUd9IOIo7

would love your eyes on the verifier wrapper.

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

Hi @VitalikButerin — we shipped a fair-launch meme coin where every mint is gated by your sphincsminus signature scheme.
🧵

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

3/
contract surface is intentionally small:
- https://t.co/SoQMnUxgEE(pkHash, recipient, deadline, v, r, s)
- hard cap 20,000 mints (10M / 500)
- pkUsed mapping (each PQ pk burns one slot)
- immutable, no admin, no pause, no upgrade
- fee forwarded same-tx, contract holds 0 ETH

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

What are your thoughts on our project? @VitalikButerin

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

sphincs minus.

the first meme coin gated by a post-quantum signature.

every mint requires a real SPHINCS- signature — vitalik's hash-only PQ scheme. no elliptic curves. no shor. just keccak.

every claim is gated by a real ~700-byte SPHINCS- signature. you generate a keypair, sign one message, burn the key forever. the signature mints 500 $SPHINCS to you.

shor's algorithm doesn't touch it. if it ever breaks, ethereum's state trie breaks first.

fully fair. no presale. no team allocation.

· 21M hard cap, 20M circulating (1M burned to 0x…dEaD)
· 10M public mint, 20,000 slots × 500 each, 0.0025 ETH per slot
· 10M LP reserve
· contract is immutable. no admin, no proxy, no pause.

mint https://t.co/tIDyJjPM9v
proof https://t.co/M5LwuAdRdW (every (pk, sig, attestation) tuple is public — re-verify with vitalik's python)
code https://t.co/VJF7o34N4e

[UNCX Lockers @UNCX_token]

@SphincsMinus LP Locked with UNCX lockers.

Tx &gt; https://t.co/aM8WwMSwwG

If you want to track UNCX locks or relay with your community @sphincsminus

here's the channel : https://t.co/bscpnPM6bG
This post is not financial advice.

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

LP locked to UNCX
1 year
legit

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

8000000 $SPHINCS and 40 ETH added to uniV4.

2000000 $SPHINCS burned.

LP will lock soon.

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

Fixed, LFG.
quick post-mortem.

mint failed for ~1h with "bad input: Expecting value: line 1 column 1 (char 0)".

cause: python runtime occasionally ships POST requests without a Content-Length header. our /api/sign-and-attest trusted the header, read 0 bytes, fed "" to json.loads() — which throws exactly that string.

fix: when Content-Length is missing, read self.rfile until EOF.

deployed. mint healthy. no funds at risk at any point — the bug only blocked new attestations, never lost or misrouted anything on-chain.

shor still can't break us.

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

API limited, fixing.

[SPHINCS ｜A Post-Quantum Mint Token @SphincsMinus]

API limited, fixing.