leanSPHINCS on Ethereum Classic
Quantum-Secure Payments on Ethereum Classic
Meet skinnyCAT, a knock-off demo with a silly name. Alice and Bob are cats with leanSPHINCS keys made in this browser. Alice pays Bob. Bob is a skinny stray with no ETC to his name, and he pays her back anyway.
Until a quantum computer looks, an ECDSA key is fine and broken at the same time. A leanSPHINCS key is just fine.
A proof of concept and an experiment, built for fun. It isn't meant for real use. Nothing here is audited, so use tiny amounts only.
Quantum-secure here means a quantum computer can't spend the funds. Gas is still paid by an ordinary account, which only risks its own gas money. The cat is a quantum joke. Hash-based signatures protect the funds, and superposition has nothing to do with it.
The Demo
Two Cats, Two Keys
Each key is made in this browser and lives only here. Its scETC account is a hash of the public key, so no ECDSA key controls it. One key signs up to 230 times, more lives than any cat needs.
Alice
the well-fed oneNo key yet, so Alice is napping.
Bob
the skinny strayNo key yet, so Bob is napping.
The Cat Courier
Your browser wallet plays the cat courier. It pays the gas and carries Alice's ETC in. For Bob, it relays the note he signs and keeps the fee he signed for. It can't change a signed note, and it only risks its own gas money.
Looking for browser wallets.
Alice Deposits and Pays Bob
Bob Pays Back Without ETC
Bob never needs ETC. He's a stray, after all. He signs a note, and the cat courier submits it, pays the gas and earns the fee Bob signed for. The fee, the amount and the recipient are all inside the signature, so the courier can't change any of them.
How It Works
Alice pays Bob, Bob pays back without owning any ETC, then Bob takes ETC out to a fresh address. On this page one browser wallet plays both Alice's wallet and the relayer. A cat carries each message across so you can watch what moves. The arrows and labels are exact, and the cat doesn't touch what it carries.
Alice Pays Bob in One Transaction
- Alice signs “0.4 to Bob” with her leanSPHINCS key.
- Alice's browser wallet to scETC: transfer, with 1 ETC attached.
- scETC credits 1 scETC to Alice.
- scETC to Verifier: verify Alice's signature.
- Verifier to scETC: valid.
- scETC moves 0.4 scETC to Bob, emits the memo.
Bob Pays Alice Back Through a Relayer
- Bob signs “0.1 to Alice, fee 0.001”.
- Bob to Relayer: the signed message, off chain.
- Relayer to scETC: transfer.
- scETC to Verifier: verify Bob's signature.
- Verifier to scETC: valid.
- scETC to Relayer: pays the 0.001 ETC fee.
Bob Withdraws to a Fresh Address
- Bob to Relayer: signed withdraw of 0.2 to his fresh address.
- Relayer to scETC: withdraw.
- scETC to Verifier: verify.
- scETC to Bob's fresh address: sends 0.2 ETC.
Sixteen steps. Press play and a cat carries each message across, or step through with the arrows.
Every signed message covers the chain ID, the contract, the sender's nonce, the recipient, the amount, the fee, a deadline and the memo. A relayer can't change any of it, a signature can't be replayed, and a signature from another chain fails.
Explainer
How a Quantum-Safe Signature Works
Alice is a cat with coins to guard. Her signature is built from one thing, a blender that only runs forward. Six pictures show how.
01
The Magic Blender
Fruit goes in and a smoothie comes out. Anyone can blend the same fruit and check that it makes the same smoothie, but nobody can turn a smoothie back into fruit.
Three pieces of fruit drop into a blender, which spins and fills a glass with a cyan smoothie. The same fruit blended again fills a second glass with the same smoothie. A red arrow from the smoothie back to the fruit is crossed out.
But nobody can turn a smoothie back into fruit.
02
Secret Stairs
Alice hides a secret note at the bottom of each staircase, and the tops are public. Each step up is one more trip through the blender, so anyone can carry a note up and nobody can carry it down.
Four staircases, each with a locked note at the bottom and a cyan star on top. Notes appear at heights 2, 1, 2 and 2, which add up to 7, then climb to the tops and match. A masked cat pushes one note up a step, the total turns to 8 and goes red, and an arrow pointing down the stairs is crossed out.
To get back to 7 he would have to move a note down, and nobody can.
03
One Name Tag for Millions of Stairs
A set of stairs is safe for signing one thing only, so Alice builds millions of them. They blend together in pairs, level by level, into one name tag, her public key.
Eight small staircases in a row. Pairs join into colored dots, level by level, up to a cyan name tag. One staircase lights up, its neighbor at each level glows blue, and a cat climbs the lit path to the tag.
A signature shows one set of stairs and the neighbors it needs to climb to the tag.
04
The Message Picks the Stairs
Alice blends each message, and the smoothie points at the spot to sign from. She never keeps a list, and each spot can safely sign a few times, so one key signs about a billion times. That's more lives than any cat needs.
Alice drops a letter into a small blender, and a cyan beam points at one square in a big grid. More letters light more squares while a counter climbs to 1,073,741,824. Nine small hearts beside Alice stand for a cat's nine lives.
That's more lives than any cat needs.
05
Why a Quantum Computer Can't Help
A big quantum computer is great at picking one kind of math lock, the kind on today's ECDSA keys, and that lock is in trouble. Against the blender it can only guess faster, which still leaves about 264 guesses, far out of reach.
A quantum computer, drawn as a glowing chandelier, zaps a padlock marked ECDSA and the lock springs open. Then it throws fruit guesses at the blender, and every guess misses. A counter of guesses needed drops from 2 to the 128 to 2 to the 64 and stays out of reach.
That still leaves about 264 guesses. Far out of reach.
06
The Catch
Alice's signature is big, a long scroll next to today's sticky note, so it costs more gas. When a contract checks it, the box opens and the skinny cat jumps out.
A small yellow sticky note marked 65 bytes beside a long scroll that unrolls to 7,740 bytes. A gas bar for Alice's send grows to 14 times the bar for a plain transfer. The scroll drops into a box, the box opens and a skinny cat jumps out, its tail a lit path.
A contract checks the scroll. It's valid, so the box opens and the skinny cat jumps out.
Ready for the real thing?
The same signature, step by step, drawn from a real one.
Frame Transactions Instead of Meta-Transactions
ETC has no way for an account to pay its own gas with anything but an ECDSA signature, so scETC uses meta-transactions. Ethereum's draft answer is the frame transaction, EIP-8141.
- Bob signs a scETC transfer with his leanSPHINCS key.
- A relayer wraps it in an ordinary transaction and pays the gas.
- scETC checks Bob's signature, moves his balance and pays the relayer Bob's fee.
The signature hash is keccak256(0x06 ‖ rlp(tx)) with the signature left out, so Bob's signature covers the gas too. The Devcon workshop sends this kind of transaction on the Daisugi research testnet.
Aggregation With EIP-8288
In EIP-8288, block builders replace a block's leanSPHINCS signatures with one aggregate proof, about 33,000 gas per signature as written and no signature in calldata. It gives leanSPHINCS the scheme byte 0x10, which scETC already uses for its addresses. Aggregation below shows how it works.
What ETC Would Need
An ECIP and a hard fork, since frame transactions change what makes a transaction valid. EIP-8141's fee fields follow EIP-1559, which ETC doesn't have yet, and ECIP-1120 proposes a basefee market for it. Until then, meta-transactions are how ETC can do this.
| Aspect | scETC today | Frame transactions |
|---|---|---|
| fork needed | no | yes, an ECIP |
| who submits | a relayer | anyone, or Bob |
| ECDSA in the path | the relayer's key, gas money only | none |
| what Bob holds | scETC, wrapped ETC | ETC in his own account |
| gas paid by | the relayer, repaid from Bob's fee | Bob's account, or a paymaster |
| signature on chain | 7,740 bytes in calldata | 7,740 bytes, or an aggregate proof with EIP-8288 |
Aggregation
A leanSPHINCS signature is 7,740 bytes, about 119 times a 65-byte ECDSA signature, and on ETC every node stores and checks each one. Ethereum's plan, EIP-8288, keeps the signatures off chain and puts one proof in each block instead. None of it works on ETC yet.
Five steps, shown here at the end. Press play to watch six signatures fold into one proof, or step through with the arrows.
6 signatures, about 209,000 gas each today against about 33,000 with EIP-8288
- Today on ETC
- ≈1,254,000 gas
- 46,440 bytes of signatures in calldata
- With EIP-8288, as written
- ≈198,000 gas
- no signature bytes on chain
- Name the signatureEach transaction names its signature in a dependency frame, as a triple of the scheme byte (0x10 for leanSPHINCS), the hash that was signed and the 32-byte public key.
- Send it alongsideUsers send their transactions to the mempool with the 7,740-byte signatures alongside, outside the transactions themselves.
- Fold and gossipEvery second, each mempool node checks the signatures it has seen and folds them into one recursive STARK. Nodes pass their aggregates to peers, and each merges what it receives into its own.
- Build the blockThe block builder merges the aggregates for the transactions it includes and puts a single recursive STARK in the block header.
- Check one proofValidators check that one proof against the dependency triples of the block's transactions. No signature appears on chain.
The Plan on Ethereum
EIP-8288, “In-mempool signature and proof aggregation”, is a draft by Vitalik Buterin and Thomas Coratger from 2026-06-03. It starts from the cost.
Current proposals for hash-based signatures are in the range of ~2-3 kB and ~150,000 to 200,000 gas to verify.
Its answer is that the signatures never reach the chain. Instead
the block contains one single recursive STARK that proves their existence
The proof is hash-based too, so aggregation stays post-quantum. The dependency frame is a new frame mode for EIP-8141, so EIP-8288 needs frame transactions first.
The Cost, as Written
A transaction pays 3,000 gas per leanSPHINCS signature for its dependency frame, plus LEANSTARK_VERIFICATION_GAS, 30,000, per dependency. That's about 33,000 gas for one signature against about 209,000 on ETC today, with no calldata for the signature. The draft doesn't add it up itself. It does say why it's cheap.
It is much cheaper than the onchain costs for similar operations because the cost is only paid by the builder and the mempool, not by all validating nodes.
Still open in the draft are the recursion circuit, the dependency hash (BLAKE2s today, BLAKE3 the likely replacement), the aggregated verification key and more DoS exposure in the mempool.
What ETC Can Do
- Fork in both EIPsneeds a hard forkthe clean answer
EIP-8141 and EIP-8288 together, through ECIPs and a hard fork. Every client would also need STARK aggregation in its mempool, which is new work for all of them. A long way off.
- Sign a batch onceworks today, no forkone signer only
A signer signs the Merkle root of many messages, so each transfer carries the 7,740-byte signature once per batch and a short Merkle path per item. It helps an exchange or a payroll, not many users.
- Relay many in one transactionworks today, no forka small saving
A relayer submits several signed scETC transfers in one call. That saves the 21,000 base cost per transaction, and each signature still costs its full calldata and verification.
- Prove the batch with a STARK on chainworks today, no forkdoesn't fit
EIP-8288 puts such proofs at 128 KB to 512 KB. That's 2 to 8 million gas of calldata alone, against ETC's 8,000,000 gas block limit.
- Wrap it in a SNARKworks today, no forkruled out
A Groth16 proof on ETC's BN254 precompiles verifies for a few hundred thousand gas. It rests on elliptic-curve pairings, which a quantum computer breaks, so the result is no longer quantum-secure.
So for now skinnyCAT pays full price for every signature, and we say so.
Current Limitations
- The account that submits a transaction isn't quantum-secure. A quantum attacker who breaks it can spend its gas money and nothing else.
- Nothing here is audited.
- Each signature is 7,740 bytes, so a send costs about 290,000 gas, around 14 times a plain transfer. ETC can't aggregate signatures yet.
- All scETC sits in one contract, so a bug there affects every holder.
- leanSPHINCS isn't final. A new version means a new verifier and a new scETC.
- Keys live in this browser's local storage, which suits small amounts only.
The Spec
leanSPHINCS as EthLib specifies it, at commit dce7a2d. We follow the current version because its authors stand behind it, it uses the FIPS 205 hash layout, and its test vectors let us check our verifier and signer byte for byte.
- hash
- Keccak-256, truncated to 16 bytes
- public key
- 32 bytes
- signature
- 7,740 bytes
- lifetime
- 2^30 signatures, no signer state