SELEN: sealed now,
sealed after Q-day

Version 0.1 · describes the code running on selen-testnet-1 · BSD-3-Clause

1The problem: store now, open later

A ledger is replicated by design. Nothing published to it can be withdrawn, and anyone can keep a complete copy indefinitely at negligible cost. Privacy on such a ledger therefore has to resist not only today's adversary but every adversary who will ever hold that copy.

In a typical private payment, the sender publishes an ephemeral public key R = r·G with each output, and the receiver recognises the payment by computing b·R with their private view key b. Security rests on the hardness of discrete logarithms. Shor's algorithm computes discrete logarithms efficiently on a sufficiently large quantum computer. Given a receiver's published view key B, such a machine recovers b and, with it, the ability to scan any archived chain for every payment to that receiver and decrypt the amounts.

Not every part of a private transaction leaks in that way. Hiding commitments to amounts are information-theoretically hiding; nothing can open them later. The weak point is payment detection: the step that tells a receiver which outputs are theirs. SELEN replaces that step.

2Design goals

1. Privacy is mandatory. There is no transparent transaction type to fall back to, and so no anonymity set split between users who opted in and users who did not.
2. Receivers and amounts survive Q-day. A complete archive of the chain, combined with a future quantum computer, should not reveal who received a payment sent to a quantum address, or how much.
3. No trusted setup. Every proof verifies against public parameters derived by hashing.
4. No privileged signers. Ordering comes from proof of work; there is no key whose theft or coercion lets someone rewrite blocks.
5. Verifiable by anyone. Every transfer can be re-checked in a browser from data the node serves.

3Keys and addresses

A wallet is a 32-byte seed. The spend scalar a, the view scalar b and an ML-KEM-768 key pair are derived from it with domain-separated SHA-512. The group is ristretto255; G is its base point and H a second generator obtained by hashing to the group, so its discrete logarithm with respect to G is unknown.

A quantum address encodes A = a·G, B = b·G and the 1,184-byte ML-KEM public key. A classic address encodes only A and B and exists for compatibility and shorter strings; payments to it are private today but not sealed against Q-day.

4Outputs

For each output, the sender obtains a 32-byte shared secret ss. For a quantum address, ss comes from ML-KEM encapsulation and the 1,088-byte ciphertext ("capsule") is published with the output. For a classic address, ss is the encoding of r·B and R is published. From ss the sender derives the one-time key P = H_s(ss)·G + A, the blinding factor y, an 8-byte encrypted amount and a one-byte view tag. The commitment is C = y·G + v·H.

The receiver tests each new output by decapsulation (or by computing b·R). ML-KEM decapsulation with the wrong key returns a pseudorandom value under implicit rejection, so non-matching outputs simply fail the view-tag and key checks. The spend secret for a matching output is x = H_s(ss) + a.

5Transfers

A transfer lists inputs, outputs, a public fee, one range proof per output and one signature per input.

Rings. Each input references sixteen existing outputs by global index, sorted ascending. The signer proves, with an MLSAG signature over the rows (P_j) and (C_j − C′), that it knows x for one P_π and the opening of C_π − C′ at the same position, where C′ is a fresh pseudo-output commitment to the same amount.

Key images. The signature exposes I = x·H_p(P_π). Since I depends only on the spent output, a repeated key image is a double spend and is rejected.

Balance. The signer picks pseudo-output blinding factors that sum to the sum of the output blinding factors, so that ΣC′ = ΣC + fee·H holds as a group equation that any node can check.

Range proofs. Each output commitment is decomposed into 48 bit commitments whose blinding factors sum to y. Each bit carries a two-key ring signature proving it commits to 0 or 1. Amounts are therefore confined to [0, 2⁴⁸), which rules out values that wrap modulo the group order.

The signed message is a hash over the full transfer prefix, including the range proofs, so no component can be swapped after signing.

6Consensus

Blocks are ordered by Argon2id proof of work over the header, using 2 MiB of memory per evaluation. The memory requirement keeps commodity CPUs, including browsers through WebAssembly, within reach of specialised hardware. Difficulty is retargeted every block by a linearly weighted moving average over 45 blocks, aiming at one block every 30 seconds. Nodes follow the valid chain with the greatest cumulative work.

The coinbase pays the block reward plus fees to a one-time key of the miner's choosing. Its amount is public, so that total supply can be audited from the chain; its receiver is hidden in the same way as any other output.

7Security against a quantum adversary

We consider an adversary that holds a complete archive of the chain and, at some future time, can compute discrete logarithms in ristretto255.

• Receivers on quantum addresses remain hidden. Linking an output to an address requires ss, which is protected by ML-KEM-768. Computing discrete logarithms of P or A does not help: for any candidate address, P − A has some discrete logarithm, and nothing on chain distinguishes the right one without ss.
• Amounts remain hidden. Pedersen commitments are perfectly hiding, the bit commitments in range proofs are perfectly hiding, and two-key ring signatures are perfectly anonymous. The encrypted amount is keyed by ss.
• Spend anonymity does not survive. With discrete logarithms the adversary can compute the key image of every ring member and so identify the real input. This links the spent output to the transfer; it does not reveal its owner or value.
• Soundness does not survive. Knowing log_G(H) breaks the binding of commitments, which would allow inflation. This matters only once such a machine exists, and is addressed by Perigee.

We consider this the right order of work. What leaks from an archive leaks permanently and to everyone, so the receiver and amount are sealed first. Soundness can be upgraded by a protocol change when needed; recorded privacy cannot.

8Perigee

Perigee is the planned upgrade that moves spend proofs off elliptic curves. Its goals: membership proofs over the entire output set rather than a ring of sixteen, built from hash-based commitments and proof systems whose security rests on collision resistance; and a binding commitment scheme that does not depend on discrete logarithms. The specification, implementation and review will happen in public before mainnet, which will start from a fresh genesis with Perigee active from the first block.

9The token

$SELEN is a token on Robinhood Chain that funds development through testnet, Perigee and mainnet. The testnet coin tSELEN is distinct and has no value.

10Status and limitations

The public testnet runs the construction described above. The implementation is new and unaudited. Ring members are chosen by the wallet from a mix of recent and historical outputs; better decoy selection is an open item. Quantum addresses are long because they carry a full ML-KEM public key. The browser wallet downloads every output and scans locally, so the node never learns which outputs belong to it; when spending, it requests only the sixteen ring members together, the same set the transfer later publishes.

Comments and review are welcome.