E46 chain design (draft 1)¶

Date: 7 October 2026 Status: Draft 1, parameters confirmed by the project owner on 7 Oct 2026 (section 6). No code yet; nothing here is audited. Values marked “retune after prototype” may change once measured. Scope: an experimental testnet, launched from zero hashrate, to complement established chains and invite people to test new algorithms. It is not a competitor to Bitcoin, has no value and makes no promise of value.

0. Names¶

Name	Meaning
E46	the coin (testnet units)
E46 / Tessera	the toolkit and art (`ART/`)
Radium / Rad	the collision-event feature of each block
Z-level	a Rad’s radiation level: how many leading bits its two hashes share
E46 Life Tokens	the per-miner record of earned Z-level, usable for staking rewards
Refracting Light v3	the proof-of-work hash
QTL	optional wallet-file lock, test data only

Names and tickers must be checked for conflicts before any announcement (RAD may be in use; an older “Radium” coin may exist).

1. Primitives: experiment where a break is survivable¶

Job	Primitive	Status
Proof-of-work	Refracting Light v3 (`REFRACTING-LIGHT-SPEC.md`)	Experimental. Passed Phase 3, including real truncated collisions up to 64 bits at the ideal birthday cost (`PHASE3-RESULTS.md` §K). No external cryptanalysis yet
Transaction and block IDs, Merkle roots, shared addresses, domain hashing	SHAKE256 (SHA-3 family, FIPS 202), 256-bit output (decided)	Standard
No SHA-2 anywhere	SHA-256 and SHA-256d are not used by the chain (decided 7 Oct 2026)	Policy
Single-owner addresses	RL v3 128 ‖ SHAKE256 128 (section 2a)	256-bit payload; preimage ≈ 2^128 classical and quantum
Rad IDs	Refracting Light v3, 128-bit	Labels only
Signatures	SLH-DSA-SHAKE-128s, FIPS 205 (stateless, hash-based, no lattices, no SHA-2)	Standard. Signature size ≈ 7.9 KB (verify against FIPS 205 before publishing)
Wallet-file protection (optional)	QTL v2 guarded (`QTL-V2-ANTI-LOCKOUT.md`)	Experimental, test data only

The project’s “inverse” theme: Bitcoin is preparing to defend against quantum attacks (Shor). This project explores quantum entanglement as inspiration for classical tools. Nothing here uses or claims real quantum hardware.

2. Blocks and timing¶

Parameter	Value
Target block time	150 s (576 blocks/day)
Block size limit	4 MB (≈ 3 tx/s with one SLH-DSA-128s signature per transaction)
Header PoW	`RL_v3(header) ≤ target`, header hash as a 256-bit big-endian integer
Difficulty	defined directly from the 256-bit target (not Bitcoin’s difficulty-1 constant)
Difficulty algorithm	ASERT (exponential), half-life ≈ 2 h (≈ 48 blocks)
Genesis difficulty	one-laptop level (≈ 2^24.6 expected hashes: 120-byte headers at an estimated 44k per second per core, 4 cores; section 2b), so the first block arrives in about 150 s, not years
Minimum-difficulty fallback rule	none. Bitcoin testnet3’s 20-minute rule was abused for block storms

ASERT, integer form (as in Bitcoin Cash’s aserti3-2d):

next_target = anchor_target × 2^((parent_time − anchor_parent_time − 150 × (height − anchor_height)) / half_life)

Exact consensus rule (decision #16, 8 Oct 2026): BCH aserti3-2d, E46 numbers.

anchor            = genesis: anchor_height 0, anchor_bits = genesis bits, anchor_parent_time = genesis.time − 150
time_diff         = parent.time − anchor_parent_time            (signed 64-bit)
height_diff       = parent.height − anchor_height
exponent          = ((time_diff − 150 × (height_diff + 1)) × 65536) / 7200     (division truncates toward zero)
shifts            = exponent >> 16                                (arithmetic shift, floors)
frac              = exponent & 0xFFFF
factor            = 65536 + ((195766423245049·frac + 971821376·frac² + 5127·frac³ + 2^47) >> 48)
next              = (anchor_target × factor) shifted by `shifts` (left if ≥ 0, right if < 0), then >> 16
if next == 0          → next = 1
if next > MAX_TARGET  → next = MAX_TARGET     (decide this BEFORE shifting in fixed-width math: an overflowed
                                               256-bit value wraps to a small number = a near-impossible target)
bits              = canonical compact(next)

Constant	Mainnet	Testnet
MAX_TARGET (pow limit)	`0x1d7fffff` = 0x7fffff × 256^26 ≈ 2^231 (25 leading zero bits, 2^25 expected hashes)	same
Genesis bits	= MAX_TARGET (re-measure on the launch machine)	same

Compact bits are accepted only in canonical form; negative, overflowing, zero-mantissa or above-MAX_TARGET values are invalid.

It is evaluated with fixed-point integer arithmetic only. Floating point is forbidden in consensus code.

2a. Addresses and IDs (decided 7 Oct 2026)¶

All addresses and IDs use Bech32m (BIP-350): a readable prefix, the separator 1, a version character, the payload, and a 6-character checksum that always catches a mistyped character. Bech32m is case-insensitive, so case never distinguishes networks: every network has its own prefix. The version character names the hash version: q = v0 (today), p = v1 (reserved for a future hash switch).

Kind	Mainnet	Testnet	Payload (v0)	Bits
Single-owner address	`e46`	`te46`	`RL_v3_128("E46-address\0" ‖ public key) ‖ SHAKE256_128("E46-address\0" ‖ public key)`	256
Shared address (k-of-n)	`tes` (tessera)	`tess`	`SHAKE256("E46-shared\0" ‖ k ‖ sorted public keys)`	256
Transaction ID	`e46tx`	`te46tx`	`SHAKE256("E46-txid\0" ‖ transaction without witnesses)`	256
Witness transaction ID (wtxid)	none: raw 32 bytes / plain hex only, never shown to users (#15). `e46wtx` / `te46wtx` reserved, unused		`SHAKE256("E46-wtxid\0" ‖ full transaction)`	256
Block ID	`e46blk`	`te46blk`	`SHAKE256("E46-block\0" ‖ header)`	256
Rad ID	`e46rad`	`te46rad`	`RL_v3_128(collision pair)`	128

Examples (stand-in public key; real SLH-DSA keys will differ):

e46     e461qd8q86chzlafsxsvwsnstt99leappd9m9u03txle073k5u70dgaqqnjq8w0
te46    te461qd8q86chzlafsxsvwsnstt99leappd9m9u03txle073k5u70dgaqq7kqphr
tes     tes1q8l5y4uynd5pjkdgqfu8rkddvsnyuazdpmetha7xc42ny2r739suqm2c32j
tess    tess1q8l5y4uynd5pjkdgqfu8rkddvsnyuazdpmetha7xc42ny2r739suqtyerjz
e46tx   e46tx1q6gmauc2zmel9p2mmxg3dg9lw0ayhmfm5q8u287vu4hw32wxtp4pqyjwz62
te46tx  te46tx1q6gmauc2zmel9p2mmxg3dg9lw0ayhmfm5q8u287vu4hw32wxtp4pq5azwqr
e46blk  e46blk1qjun46mpt0zvnczlqsm8whz9acjscgtzwtjuwrv9e0m4e4w4zgxeq6ujsrs
te46blk te46blk1qjun46mpt0zvnczlqsm8whz9acjscgtzwtjuwrv9e0m4e4w4zgxeqmx7gu3
e46rad  e46rad1qhjj0xzkudmyw5r67uc7qfjntmvjjqd40
te46rad te46rad1qhjj0xzkudmyw5r67uc7qfjntmv0smf2q

Rules and reasons:

Single-owner addresses (S12, decided: Option 1). The Refracting Light half keeps the hash visible in every address. The SHAKE256 half means a thief must find a preimage of both halves at once: about 2^128 classically and about 2^128 with Grover, compared with about 2^64 for a 128-bit address.
Shared addresses, tx and block IDs and Merkle roots use SHAKE256 from the start. These need collision resistance; SHAKE256 at 256 bits gives about 2^128 classically and about 2^85 with the BHT quantum algorithm. SHA-3 is a completely different design from SHA-2 (a Keccak sponge), so a SHA-2 break doesn’t carry over.
Domain tags ("E46-address\0", "E46-shared\0", "E46-txid\0", "E46-block\0") keep every kind of hash separate.
No double hashing. SHAKE256 is a sponge with no length-extension weakness, so Bitcoin’s SHA-256d workaround isn’t needed.
Prefixes must be checked against other projects before the ANN.

2b. Block header, Merkle roots and the genesis block (proposed for review)¶

Header: 120 bytes, fixed serialization¶

Field	Size	Encoding	Notes
version	4	uint32 little-endian	soft-fork signalling bits, as in Bitcoin
prev_block	32	bytes	block ID of the parent (SHAKE256)
merkle_root	32	bytes	transaction Merkle root
event_root	32	bytes	event Merkle root (Rads and Block QTL commitments, section 2f); all zero bytes until events are enabled
time	8	uint64 little-endian	Unix seconds; 64-bit because the chain is designed for 100+ years (Bitcoin’s 32-bit field ends in 2106)
bits	4	uint32 compact target	Bitcoin’s compact form, written by ASERT
nonce	8	uint64 little-endian	larger than Bitcoin’s 32 bits, so miners rarely need an extra-nonce

Proof-of-work: RL_v3(header) ≤ target, comparing the 128-bit folded digest with the top 128 bits of the 256-bit target. 120 bytes is 1,512 RL v3 steps; the estimated speed is about 44,000 headers per second per M1 core.
Block ID: SHAKE256("E46-block\0" ‖ header), 256 bits. The PoW hash and the ID are deliberately different functions, the way Litecoin pairs scrypt PoW with SHA-256d IDs.
Transaction ID: SHAKE256("E46-txid\0" ‖ transaction without signatures), so signatures can’t change an ID. A separate ID (wtxid) covers the signatures, for relay.

Merkle roots: tagged, no duplication¶

leaf(x)       = SHAKE256( "E46-merkle\0" ‖ 0x00 ‖ x )         x = txid (or Rad leaf bytes), 256-bit output
node(L, R)    = SHAKE256( "E46-merkle\0" ‖ 0x01 ‖ L ‖ R )
odd count     : the last node is carried up unchanged (never duplicated)
tree_root     = the root of the tree above
bound root    = SHAKE256( "E46-merkle\0" ‖ 0x02 ‖ u64 leaf_count (LE) ‖ tree_root )   if leaf_count > 0
              = 32 zero bytes                                                    if leaf_count = 0
merkle_root   = bound root over the block's txids in block order (coinbase first)
event_root    = bound root over event leaves (type ‖ body; 0x02 Rad, 0x03 Block QTL commitment), sorted by type then ID
proofs        = (leaf, index, leaf_count, siblings); the verifier recomputes the bound root, so a wrong count fails

Why the count is bound (approved 7 Oct 2026, found during WO-03): with the odd node carried up, a tree’s shape depends on its leaf count, and a Merkle path alone can’t prove the count. Binding the count into the root lets a light wallet verify proofs from headers alone. Tag 0x02 keeps this wrapper distinct from leaves (0x00) and nodes (0x01), in the spirit of RFC 6962/9162, which also commit to the tree size.

Why this differs from Bitcoin: Bitcoin duplicates the last node on odd levels, which allowed two different transaction lists to give the same root (CVE-2012-2459). It also uses the same hash for leaves and inner nodes, which makes 64-byte transactions ambiguous. The 0x00/0x01 tags (the RFC 6962 convention) and carrying the odd node up instead of duplicating it remove both problems.

Genesis block¶

Item	Rule
pszTimestamp	`"E46 <launch date> <headline>"`, chosen by the project owner on launch day. It may span one or two consecutive Data outputs (each payload ≤80 bytes); the timestamp is their payloads concatenated in order with no added bytes. For the WO-10 testnet fixture, split the full NASA Oct. 8, 2026 headline at the comma into 56-byte and 33-byte payloads. Like Bitcoin’s `"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"`, it anchors the first block to public text from that date
Coinbase	one null-prevout input; one or two 0 E46 Data outputs (type 0x03) carry pszTimestamp, followed by the 0 E46 witness commitment Data output (type 0x03) as the final output. Genesis has two or three outputs. No premine, and anyone can verify that
Block 1	the first spendable reward (43.87 E46), open to anyone who mines it
prev_block	32 zero bytes
bits	one-laptop level: about 2^24.6 expected hashes, the first block in about 150 s on a 4-core M1 (estimate; re-measure on the launch machine)
time	the actual time of mining, which must be after the headline’s date
Genesis hashing function	`e46/golden/genesis_miner.py`: build the coinbase from pszTimestamp, compute `merkle_root`, then search nonce = 0, 1, 2, … until `RL_v3(header) ≤ target`. Output the transaction, header, nonce, block ID and `merkle_root` for the chain parameters. Deterministic and published, so anyone can reproduce the genesis block from the headline
ASERT anchor	the genesis block (height 0, its time and its target)

2c. Checkpoints (proposed for review)¶

Hard-coded checkpoints: each client release lists (height, block ID) pairs. The node rejects any chain that contradicts one. This protects a young, low-hashrate chain against someone rewriting deep history with rented CPUs.
Policy: a new checkpoint is added in each release, at a block at least 1,000 blocks (about 42 hours) deep. Checkpoints are listed publicly in the release notes.
No automatic rolling checkpoints. Nodes that refuse deep reorganizations on their own can split the network permanently if they see different chains.
Honest trade-off: checkpoints mean trusting whoever publishes the release. That is acceptable for a testnet and is stated plainly in the ANN.

2d. Chain parameters (chainparams)¶

Parameter	Mainnet	Testnet
Address / ID prefixes	`e46`, `tes`, `e46tx`, `e46blk`, `e46rad`	`te46`, `tess`, `te46tx`, `te46blk`, `te46rad`
Target spacing	150 s	150 s
ASERT half-life	7,200 s	7,200 s
Max block size	4,000,000 bytes	4,000,000 bytes
Coinbase maturity	100 blocks (≈ 4.2 h)	100 blocks
Median time past	median of the last 11 blocks; a new block’s time must be later	same
Max future block time	node’s adjusted time + 15 min (6 block intervals)	same
Decay epoch	17,280 blocks	17,280 blocks
k / T / NEUTRINO	20 / 46,000,000 E46 / 1 base unit	same (testnet coins have no value)
Reward split / N / Z / L	80-10-10 / 576 / 0.1 / 200	same
Genesis	from `genesis_miner.py` with the mainnet pszTimestamp	separate genesis with its own pszTimestamp
Checkpoints	per release	per release
Soft-fork activation	version bits (BIP-9 style)	same
Network magic, ports, seeds	deferred to the peer-to-peer section (last)	deferred

2e. Transactions, coinbase, public keys and scriptPubKey (proposed for review)¶

UTXO model, as in Bitcoin: coins live in unspent outputs, and a transaction spends whole outputs and creates new ones.

Public keys and signatures¶

Item	Value
Scheme	SLH-DSA-SHAKE-128s (FIPS 205), stateless, hash-based, built on SHAKE (no SHA-2)
Public key	32 bytes
Private key	64 bytes (never leaves the wallet)
Signature	7,856 bytes
Library	a maintained implementation (liboqs or equivalent); never custom code
Wallet keys	32-byte `master_seed`; `account` and `index` are unsigned 32-bit little-endian values. `seed_i = KMAC256(K=master_seed, X=ASCII("E46-key") ‖ account ‖ index, S=empty, L=48 bytes)` (NIST SP 800-185). Split bytes 0–15 as `SK.seed`, 16–31 as `SK.prf`, and 32–47 as `PK.seed`, then use for SLH-DSA-SHAKE-128s deterministic key generation (FIPS 205 order). Backing up the master seed backs up every key. (Decision #18, 8 Oct 2026.)

Sizes follow FIPS 205. Hash-based keys have no Bitcoin-style public derivation (BIP32 xpub), so a watch-only wallet needs its addresses precomputed by the full wallet.

Transaction format¶

transaction
  version     uint32 LE
  inputs[]    prev_txid (32) ‖ prev_index (uint32 LE) ‖ sequence (uint32 LE)
  outputs[]   value (uint64 LE, base units) ‖ type (uint8) ‖ payload (length-prefixed bytes)
  lock_time   uint64 LE        (block height if < 500,000,000, else Unix time)
  witnesses[] one per input, kept separate: public key(s) ‖ signature(s)

txid  = SHAKE256( "E46-txid\0"  ‖ version ‖ inputs ‖ outputs ‖ lock_time )   -- signatures excluded: no malleability
wtxid = SHAKE256( "E46-wtxid\0" ‖ whole transaction including witnesses )    -- for relay and the witness commitment

What a signature signs (sighash): SHAKE256("E46-sighash\0" ‖ version ‖ all inputs ‖ all outputs ‖ lock_time ‖ input index ‖ the value, type and lock payload of every coin being spent) (exact bytes in §2g). Committing to the spent values means a wallet can’t be tricked about the fee (a lesson from Bitcoin’s Taproot design). Launch supports one mode only: sign everything.

Size check: 1 input + 1 output ≈ 8.0 KB, almost all of it signature. That is about 500 transactions per 4 MB block, about 3.3 per second at 150 s blocks.

scriptPubKey: fixed output types, no general script at launch¶

Each output’s type byte selects a template. A general-purpose script language is left for a later soft fork, so launch has far less to get wrong.

Type	Name	Payload (scriptPubKey)	To spend (witness)
0x00	Single-owner (`e46`/`te46`)	256-bit address payload: RL v3 128 ‖ SHAKE256 128	public key whose hash matches + signature
0x01	Shared k-of-n (`tes`/`tess`)	`SHAKE256("E46-shared\0" ‖ k ‖ sorted public keys)`	the n public keys + k signatures; n ≤ 15
0x02	Stake lock	owner payload ‖ origin height	not spendable by signature; released by consensus at the collision block (with any N-pool payout) or at timeout L
0x03	Data (OP_RETURN)	≤ 80 bytes, value must be 0	never spendable (genesis pszTimestamp, notes)
0x04	Block QTL single-owner (`e461z…` / `te461z…`, version 2)	same 256-bit payload as 0x00	public key + signature, and a matching commitment at least 6 blocks deep (section 2f)
0x05–0xFF	reserved	—	valid in consensus but not relayed, so future soft forks can define them

Coinbase transaction (first transaction of every block)¶

Rule	Reason
Exactly one input: prev_txid = 32 zero bytes, prev_index = 0xFFFFFFFF	marks it as new coins
`lock_time` must equal the block height (u64). The coinbase witness holds `extranonce[8] ‖ up to 100 free bytes` (decision #20)	the height is inside the txid, so every coinbase txid is unique. Bitcoin once had duplicate coinbase txids (fixed by BIP30/BIP34)
Genesis: one or two leading 0-E46 Data outputs (type 0x03, each payload ≤80 bytes) contain the pszTimestamp parts; concatenate their payloads in order with no added bytes. The final output is the witness commitment	the full headline is inside the txid, so `merkle_root` seals it into block 0 (decisions #20 and #23)
Miner outputs: total ≤ miner share (80% of reward) + all transaction fees	the miner chooses the addresses
Pool outputs at collision blocks: the N-pool and Z-pool payouts as consensus-computed outputs, sorted by recipient payload	every validator recomputes them and rejects the block if they differ
The last coinbase output is the witness commitment: type 0x03, value 0, payload exactly the 32-byte bound Merkle root of the block’s wtxids in block order, with the coinbase’s own wtxid replaced by 32 zero bytes (decisions #20a and #23)	validators have one fixed location to check; the zero placeholder avoids a circular definition, as in Bitcoin
Amounts (decision #20d): every output value ≤ T; all sums use checked arithmetic; a transaction whose outputs exceed its inputs, or any sum above T, is invalid	blocks Bitcoin’s 2010 value-overflow bug (184 billion BTC created)
Maturity: outputs spendable only after 100 blocks	a reorganized-away coinbase can’t have been spent already

Locks¶

Absolute: lock_time (height or time) on the whole transaction, exactly as in Bitcoin (decision #22): valid only in a block whose height (if lock_time < 500,000,000) or median-time-past (otherwise) is strictly greater than lock_time; ignored when every input’s sequence is 0xFFFFFFFF, so a wallet that wants the lock sets a sequence to 0xFFFFFFFE. The coinbase (lock_time = height, #20) is exempt. This is what makes post-dated payments possible.
Relative locks (Bitcoin’s BIP68/112 style) are left for a soft fork.
Stake locks are their own output type (0x02), so staking never relies on general scripts.

2f. Block QTL: commit–delay–reveal (opt-in, decided 7 Oct 2026)¶

The block-level version of the Quantum Time Lock. On a chain, block height is a clock everyone agrees on, so a delay measured in blocks is truly enforced. Based on the Guy Fawkes protocol (Anderson et al., 1998), as used in FawkesCoin (Bonneau and Miller, 2014).

Who uses it: coins held in a Block QTL address, output type 0x04, address version z (v2): e461z… on mainnet, te461z… on testnet. Ordinary e461q… addresses spend immediately, as before. (p, v1, stays reserved for a future hash switch.)

1. COMMIT (block h):
   C = SHAKE256("E46-commit\0" ‖ txid ‖ SHAKE256(witnesses) ‖ salt)        -- 32 bytes: no key, no signature
   event leaf = 0x03 ‖ C ‖ nonce,  valid only if  RL_v3("E46-commit-pow\0" ‖ C ‖ nonce) has ≥ Z_commit leading zero bits
   -> placed in event_root; no fee and no signature needed (the small proof-of-work is the spam fee)

2. DELAY:  d = 6 blocks (≈ 15 min at 150 s)

3. REVEAL (block ≥ h + 6):
   the full transaction with witnesses; valid only if a commitment C matching (txid, witnesses, salt) is in a block
   at least 6 and at most 2,016 blocks deep (expiry ≈ 3.5 days); the transaction also reveals salt

Rule	Purpose
The commitment hides the public key and signature	nothing to copy, forge or front-run while the spend is pending
Reveal needs a commitment ≥ 6 blocks deep	a forger who only sees the key at reveal time would have to backdate a commitment, which means rewriting 6+ blocks of history
Commitments expire after 2,016 blocks	no unlimited stockpiles of pending commitments
Commitment proof-of-work (Z_commit)	spam control without a fee: Rad-style RL v3 work, set to about 1 second of laptop time; adjusted by ASERT like Rads; per-block limit on commitment leaves
Ordinary double-spend rules apply to reveals	the first valid reveal in the chain wins

What it protects: mempool racing and front-running; future weaknesses in SLH-DSA or in the RL half of an address (a forger must also backdate a commitment); keys exposed by earlier spends. Cost: at least 6 blocks per spend and two steps (commit, then reveal). Opt-in, so ordinary payments stay fast.

2g. Serialization: exact bytes (proposed 7 Oct 2026, for review)¶

Bitcoin’s conventions unless stated otherwise. Every consensus structure has exactly one valid encoding; anything else is invalid.

Primitives

Name	Encoding
`u8 u16 u32 u64`	fixed width, little-endian
`CompactSize`	Bitcoin’s: `< 0xFD` → 1 byte; `0xFD` + u16; `0xFE` + u32; `0xFF` + u64. Must be minimal (a longer form than needed is invalid)
`bytes[n]`	exactly n raw bytes
`varbytes`	`CompactSize(length) ‖ bytes`
hashes and digests	stored as the raw output bytes (SHAKE256 output as produced; RL v3 in its canonical big-endian form). Hex display = byte order (no Bitcoin-style reversal)

Block

block       = header[120] ‖ CompactSize(tx_count) ‖ tx × tx_count ‖ CompactSize(event_count) ‖ event × event_count

Transaction

tx          = u32 version ‖ CompactSize(n_in) ‖ input × n_in ‖ CompactSize(n_out) ‖ output × n_out ‖ u64 lock_time
              ‖ witness × n_in                         -- one witness per input, in input order
input       = prev_txid[32] ‖ u32 prev_index ‖ u32 sequence
output      = u64 value ‖ u8 type ‖ varbytes payload   -- payload = the scriptPubKey for that type
txid        = SHAKE256("E46-txid\0"  ‖ tx without the witness section)     (32 bytes)
wtxid       = SHAKE256("E46-wtxid\0" ‖ full tx)                            (32 bytes)

scriptPubKey payloads (fixed per output type)

Type	Payload	Bytes
0x00 single-owner	`RL_v3_128("E46-address\0" ‖ pk) ‖ SHAKE256_128("E46-address\0" ‖ pk)`	32
0x01 shared k-of-n	`SHAKE256("E46-shared\0" ‖ u8 k ‖ u8 n ‖ pk₁ ‖ … ‖ pkₙ)`, keys sorted bytewise ascending, 1 ≤ k ≤ n ≤ 15, no duplicates	32
0x02 stake lock	`owner_payload[32] ‖ u64 origin_height`	40
0x03 data	0–80 bytes, value must be 0	≤ 80
0x04 Block QTL single-owner	same as 0x00	32

Witnesses (keys and signatures)

Spent type	Witness
0x00	`varbytes(pk) ‖ varbytes(sig)`; pk = 32-byte SLH-DSA-SHAKE-128s public key, sig = 7,856 bytes
0x01	`u8 k ‖ u8 n ‖ pk × n` (32 bytes each, sorted) `‖ varbytes(sig_or_empty) × n`: empty for keys that don’t sign, exactly k non-empty
0x04	as 0x00, then `salt[32]` (the Block QTL reveal)
coinbase input	`varbytes(coinbase_data)`, where coinbase_data = `extranonce[8] ‖ ≤ 100 free bytes` (the height lives in `lock_time`, decision #20/#20b)

Coinbase input: prev_txid = 32 zero bytes, prev_index = 0xFFFFFFFF. Private keys never appear on chain; the wallet key-export format is decided with the GUI.

Signature message (sighash)

sighash(i)  = SHAKE256("E46-sighash\0" ‖ tx without witnesses ‖ u32 i ‖ (u64 value ‖ u8 type ‖ varbytes payload) for every input's spent coin, in input order)   -- payload added by decision #20c

Events (event_root leaves)

rad_event         = u8 0x02 ‖ miner_payload[32] ‖ u64 window_index ‖ u64 nonce ‖ a[16] ‖ b[16] ‖ u8 Z
  a, b            = u64 LE index ‖ 8 zero bytes; index_a < index_b < S = 2^20 (else invalid); several distinct pairs from one nonce are all valid        (82 bytes)
  stamp           = SHAKE256("E46-rad\0" ‖ prev_block_id ‖ u64 window_index ‖ miner_payload ‖ u64 nonce)   (32 bytes)
  Rad ID          = RL_v3_128(stamp ‖ a ‖ b)                                                          (16 bytes)
commit_event      = u8 0x03 ‖ C[32] ‖ u64 nonce                                                         (41 bytes)
  Commitment ID   = C                                                                                  (32 bytes)
order             = ascending by (type byte, then ID bytes); a repeated (type, ID) makes the block invalid
event leaf        = the full serialized event (type byte included), hashed by the tagged Merkle rule (section 2b)

Still to define (later): peer-to-peer messages (with the P2P section, last) and signed-message format for “prove you own this address” (with the GUI).

3. Emission: monthly decay events (no halvings)¶

The block reward is constant within each decay epoch of 17,280 blocks (30 days at 150 s). At every epoch boundary a decay event lowers it along an exponential curve:

epoch(h)      = floor(h / 17,280)
E_0           = 0                                         -- coins emitted before epoch 0
remaining_e   = max( MAX_SUPPLY − E_e , 0 )               -- MUST clamp: E_e exceeds MAX_SUPPLY in the tail
r_e           = max( remaining_e >> k ,  NEUTRINO )        -- reward per block during epoch e
E_{e+1}       = E_e + 17,280 × r_e
reward(h)     = r_{epoch(h)}
NEUTRINO      = 1 base unit (10^-8 E46)                   -- the reward never reaches zero

Integer arithmetic only, so every node computes identical rewards. Each decay event lowers the reward by about 1.6% (k = 20).

Option	Half-life	First reward	After 10 y	After 50 y	After 100 y
k = 20, T = 46 M (confirmed)	3.46 y	43.87 E46	5.97 E46	0.00205 E46	≈ 10 base units
k = 20, T = 21 M (charted 7 Oct 2026)	3.46 y	20.03 E46	2.73 E46	0.00094 E46	≈ 3 base units
k = 21, T = 46 M	6.91 y	≈ 21.9 E46	—	—	—

The neutrino era: tail emission forever (Option A, chosen 7 Oct 2026). A neutrino (1 base unit) can’t be split, which shapes the ending (T = 46 M, k = 20):

Year	Event
~100	Reward falls below 10 base units. The 10% pool shares round to zero, so the N-pool and Z-pool stop receiving new coins; their remaining balances still pay out until empty
~114	The decay curve reaches zero; the neutrino floor takes over: every block pays exactly 1 base unit, all to the miner
~118	The last of T is emitted: the final decay event, which opens the neutrino era
forever	Every block pays 1 neutrino plus fees. Supply grows by about 0.0021 E46 per year (≈ 2.1 E46 per thousand years, about 0.0000046% of T per century)

There is no last neutrino, so miners always have a block reward and never depend on fees alone (Monero’s tail-emission reasoning, scaled down to a neutrino). Rejected alternatives: a hard stop at T with fees only (Bitcoin-style security-budget risk), and letting the final block’s type choose the ending (one miner would set monetary policy forever).

Implementation guard. remaining must be clamped at zero before the shift. In unsigned C or Rust, MAX_SUPPLY − E would otherwise wrap to an enormous value once the tail pushes E past T, and a block would mint billions. Consensus tests must cover the epochs around years 100, 114 and 118, and a 1,000-year simulation.

Decay events and miners. Miners know each step date in advance. The steps are small (~1.6%), so there is little to gain by timing, but the event is visible: suitable for the art and for announcements (“decay event #12”).

MAX_SUPPLY = T = 46,000,000 E46 × 10^8 base units (confirmed). Half-life: k = 20, 3.46 years (confirmed). Tail: the neutrino era (confirmed).

4. Radium: collision events (Rads) and Z-level¶

A Rad is a truncated collision found inside a block’s decay window:

window_prefix = SHAKE256( "E46-rad\0" ‖ prev_block_hash ‖ window_index ‖ miner_address ‖ nonce )
Rad          = (nonce, a, b)  with a < b, fixed length, and
               the top Z bits of RL_v3(window_prefix ‖ a) == the top Z bits of RL_v3(window_prefix ‖ b),  Z ≥ Z_base

Rule	Purpose
The prefix binds the previous block hash and the window	no precomputation; events expire with the window
The prefix binds the miner’s address	a published pair can’t be stolen: changing the address changes both hashes
Fixed puzzle size (decided 7 Oct 2026, #11): each nonce defines exactly S = 2^20 candidates, `a = u64 LE index ‖ 8 zero bytes` with index < S; a Rad is two indices i < j < S whose `RL_v3(stamp ‖ a)` match on the top Z bits. Verifiers check index < S and the zero bytes	each puzzle costs exactly S hashes, then the miner moves to the next nonce: memoryless and fair, Rads scale linearly with hashrate (a nonce alone would not limit the search)
Canonical form `a < b`, each pair counted once	no duplicates or trivial events
`Z_base` adjusted by ASERT so a typical window holds ~10–30 Rads	stable event rate

Z-level (rarity). Each extra matching bit beyond Z_base is half as likely: +1 is 1 in 2, +8 is 1 in 256. Energy of a Rad ≈ 1.25 × 2^(Z/2) hashes, matching the measured birthday cost. Anyone can verify a Rad with 2 hashes.

Rad tiers and collision blocks (decided 7 Oct 2026). Matches are counted on the leading bits only, never the tail. Tiers sit on byte boundaries: 8, 16, 24, 32, 40, 48, 56, 64, … bits, each 256× rarer than the one below; tiers are also the Life Token rarity classes. A collision block is a block containing at least one Rad whose leading-bit match reaches the next byte tier strictly above Z_base: collision_tier(Z_base) = 8 × (⌊Z_base / 8⌋ + 1) (decided 7 Oct 2026, #13). Z_base 41 → 48; Z_base 48 → 56. At Z_base = 128 the next tier is 136, which a 128-bit match cannot reach, so no wrap-around is defined. A Rad with Z_base ≤ Z below that tier is still a valid Rad (it earns Z-level) but does not by itself make a collision block. Collision blocks trigger the N-pool and Z-pool payouts.

Paradox A: the measured cost is not the mined cost (7 Oct 2026). Our collision measurements (PHASE3-RESULTS §K) used 12-byte messages in one big parallel search, so they look like Rads. But a real Rad hashes 48 bytes (stamp ‖ a, 3× more RL steps), a commitment stamp hashes 55 bytes (3.44×), and Rads are small independent nonce-bound puzzles whose cost depends on the puzzle size, not one big birthday search. Thresholds chosen from the measurements alone came out wrong (Z_base 46 gave 6.6 Rads per block, not 18.6). Rule: every difficulty constant is provisional until it is measured on the exact message format and puzzle shape the chain uses. WO-08 and WO-09 make those measurements.

Rad kinds. RRAD (regular Rad): a Refracting Light collision, the default from phase 2. QRAD (quantum Rad): Shor factoring, switched on later by consensus.

Block Z-level. The block’s total Z-level is the sum of its Rads’ normalized energies (normalization TBD). Each miner’s Z share is the fraction contributed by their own Rads.

Commitment. The header carries event_root, a tagged SHAKE256 Merkle root (section 2b) whose type-0x02 leaves are the window’s Rads. Each leaf is (miner_address, window_index, nonce, a, b, Z), provable with a short Merkle path like a transaction.

Built-in alarm. The network publicly observes Rad rates against the birthday bound. A sustained excess is visible evidence of a hash weakness.

Launch plan: blocks and ASERT first; Rads are enabled once the event rules are reviewed (a phase-2 fork), so a flaw in the new mechanism cannot halt the launch.

5. Supply partition, E46 Life Tokens and the two reward pools¶

5.1 T = Total: three shares of every block reward¶

Each block’s reward r (section 3) is split, using integer arithmetic only:

N_share = r / 10              -- N-pool: staking rewards     (10%)
Z_share = r / 10              -- Z-pool: Rad / Life Token rewards (10%)
miner   = r − N_share − Z_share   -- block miner            (80%, gets any rounding remainder)

T = 46,000,000 E46 (confirmed 7 Oct 2026). Over 100 years of monthly decay events (k = 20):

Share	Per block, year 0	Per decay epoch, year 0 (17,280 blocks)	Year 10 per block	Year 50 per block	100-year total	% of T
Miner	35.0952 E46	606,445 E46	4.7781	0.00164	36,800,000 E46	80%
N-pool (staking)	4.3869 E46	75,805.66 E46	0.5973	0.000205	4,600,000 E46	10%
Z-pool (Rads)	4.3869 E46	75,805.66 E46	0.5973	0.000205	4,600,000 E46	10%
T total	43.8690 E46	758,056.6 E46	5.9727	0.00205	≈ 45,999,999.89 E46	100%

The last ≈ 0.11 E46 of T is emitted after year 100, followed by the neutrino trickle (1 base unit per block). The pools never create coins. Each one only redistributes its share of the decay curve, and unclaimed amounts carry over in the same pool.

5.2 N-pool: staking rewards (N × subsidy)¶

At each collision block c:
  Pool_N(c) = N_shares accumulated since the previous collision block (+ carry-over)
  staker i locked s_i coins at origin block o, against their mining-earned Z share z_i at o
      s_i  ≤ N × subsidy(o)                      -- stake cap,  N = 576 (one day of blocks)
      w_i  = s_i × z_i
      p_i  = Pool_N(c) × w_i / Σ_j w_j          -- pro-rata
  lock timeout: no collision block within L blocks of o -> s_i unlocks, no payout

N = 576 stake cap	Year 0	Year 10	Year 25	Year 50
Max stake per staker	25,269 E46 (0.055% of T)	3,440 E46	173 E46	1.18 E46

5.3 Z-pool: Rad rewards for Life Token finders (Z × subsidy)¶

At each collision block c:
  Pool_Z(c) = Z_shares accumulated since the previous collision block (+ carry-over)
  finder j's energy e_j = Σ over their Rads in the window of 2^(Z_level − Z_base)
      q_j  = Pool_Z(c) × e_j / Σ_k e_k          -- pro-rata by Rad energy (rarer = bigger share)
      q_j  ≤ Z × subsidy(c)                      -- per-finder cap, Z = 0.1; excess stays in Pool_Z

At year 0, Z × subsidy = 4.387 E46 per finder per collision block. With a collision block about every 10 blocks, each Z-pool holds about one subsidy (≈ 43.9 E46), so the cap spreads it across at least about 10 finders. Both the collision interval and the energy normalization are to be measured on the Rad prototype; Z may be retuned afterwards.

5.3a Irradiated E46 (E46i): Rad rewards decay with a half-life (decided 7 Oct 2026)¶

Z-pool payouts are paid as irradiated outputs (E46i). Their spendable value halves at every monthly decay event (section 3) until they are spent:

paid at block h, in decay epoch e₀ = floor(h / 17,280), amount v
spendable at block h' (epoch e = floor(h' / 17,280)):   value = v >> (e − e₀)
spending (to anyone, including yourself) converts what remains into ordinary E46
the difference v − value is burnt

Epochs after payment	Remaining
0	100%
1 (≈ 30 days)	50%
2	25%
≈ 27 (≈ 2.2 years)	0 for a 1 E46i output

Only Rad rewards are irradiated. Ordinary E46 never decays.
Lazy evaluation: nodes never scan or time anything; the value is computed only when the output is spent (one subtraction, one bit-shift).
Independent of how soon or late the next collision block comes; aligned with the monthly decay events.
Burnt amounts are permanently removed, so the true supply can end slightly below T. Wallets show the next halving date of each E46i output.

Life Token fusion (decided 7 Oct 2026): two Life Tokens of the same tier can be fused into one token of the next tier; both inputs are burnt and no coins are created.

5.4 Worked example (staking)¶

Block 7483 has Z-level 1.2. Your Rads earned z = 0.0000012 of it. You lock 0.0001000 E46 (well under the cap). The next collision block is 7493: Pool_N = 10 blocks × 4.3869 ≈ 43.87 E46. If the total weight is 0.5, your payout is 43.87 × (0.0001 × 0.0000012 / 0.5) ≈ 0.0000000105 E46, and your 0.0001 E46 unlocks.

5.5 Rules¶

Not Proof of Stake consensus. Proof-of-work alone secures the chain. Staking only shares out the N-pool.
Sybil resistance. z and Rad energy are earned by mining work and can’t be split into more across addresses.
No lockout. The lock timeout L (200 blocks) guarantees every stake unlocks.
Wording. Testnet “points / experiment rewards”, never “yield” or “multiply your coins”.

Parameter	Value (confirmed 7 Oct 2026)
T (MAX_SUPPLY)	46,000,000 E46
Split miner / N-pool / Z-pool	80% / 10% / 10%
N (stake cap, N × subsidy)	576
Z (per-finder Rad cap, Z × subsidy)	0.1 (retune after prototype: depends on the measured collision-block rate)
L (lock timeout)	200 blocks

6. Decisions¶

Confirmed 7 Oct 2026

Decision	Value
Coin / feature names	E46 coin; Radium Rads; E46 Life Tokens; Z-level
Proof-of-work	Refracting Light v3
Signatures	SLH-DSA-128s (FIPS 205), no lattices
Block time / size	150 s / 4 MB
Difficulty	ASERT, 2 h half-life, one-laptop genesis, no min-difficulty fallback
Emission	monthly decay events (17,280 blocks), k = 20 (3.46 y half-life)
Total supply T	46,000,000 E46
Tail	neutrino era forever (1 base unit per block after year ~114)
Reward split	miner 80% / N-pool 10% / Z-pool 10%
N (stake cap)	576 × subsidy
Z (per-finder Rad cap)	0.1 × subsidy (retune after prototype)
L (lock timeout)	200 blocks
Irradiated E46 (E46i)	Z-pool (Rad) rewards halve at each monthly decay event until spent (value = v >> epochs elapsed); ordinary E46 never decays (section 5.3a)
Licence	MIT (same as Bitcoin Core)
Checkpoints / release signing	a dedicated offline release laptop holds the signing keys and is used for nothing else; reproducible builds so others can verify
Emergency forks	small changes: the project owner decides; big changes (anything touching supply, rewards or the proof-of-work hash): consensus of contributors
Genesis pszTimestamp	`"E46 <launch date> TESS <newest TOI designation or that day's TESS news headline>"`: NASA’s TESS satellite’s next discovery (a TOI number, e.g. TOI-7123) can’t be known in advance, so it proves the date. Predicted events such as eclipses cannot. Owner runs an AI monitoring task. E46 is not affiliated with NASA
Peer-to-peer privacy	Tor and I2P support kept in the source behind build flags (CMake / Makefile), off by default, not advertised
QTL dual delay	50/50: half the delay in the Shor lock (squaring), half in the hash-chain lock; applies to local and live testnet, revisit in test-production
Collision block	a block with ≥ 1 Rad whose Z reaches the next byte tier strictly above Z_base: 8 × (⌊Z_base / 8⌋ + 1), e.g. 41 → 48 (#13)
Rad puzzle size	S = 2^20 candidates per nonce (runtime parameter until calibrated); all distinct pairs accepted (#11)
Rad kinds	RRAD (regular, default) and QRAD (quantum, later by consensus)
Coin name	E46 (final, 7 Oct 2026)
Emergency / change decisions	testnet: the project owner decides all changes; revisit only if the chain ever carries value
Starting Rad difficulty	Z_base ≈ 41 bits (provisional, 7 Oct 2026, after #11): with S = 2^20 candidates per puzzle, ≈ 18.7 Rads per 150 s block on a 4-core M1 (one puzzle ≈ 2.6 s, ≈ 1 Rad per 3 puzzles, ≈ 20 MB). Collision-block trigger 48-bit tier (the next tier above Z_base, #13). Replaces 43, which assumed one big birthday search (“Paradox A”). WO-08 measures the final value
Commitment stamp	Z_commit = 18 leading zero bits (provisional): median ≈ 0.5 s on 4 cores, ≈ 2 s on 1 core for the real 55-byte stamp hash (744 RL steps). Corrected from 20; WO-08/09 measure the final value
Commitment limit	1,000 commitment leaves per block (≈ 45 KB)
Life Token fusion	yes: 2 tokens of one tier → 1 of the next, inputs burnt
Block QTL letter	`z` (v2)
Build order	Rad prototype first
Quantum Rads switch-on	by contributor consensus, activated as a version-bit soft fork
Hardware keys	FIDO2 optional in wallets, at the end of the GUI design
Hash upgrades	local testnet runs on RL v3 first; RL W only after that
Block QTL	opt-in commit–delay–reveal, address version `z` (`e461z…`), d = 6 blocks, commitment proof-of-work instead of a fee, expiry 2,016 blocks; second header root renamed `event_root` (section 2f)
IDs and addresses	Bech32m; `e46`/`te46` single (RL v3 128 ‖ SHAKE256 128), `tes`/`tess` shared, `e46tx`, `e46blk` (SHAKE256), `e46rad` (RL v3 128); version char `q` = v0
Hash policy	No SHA-2. SHAKE256 for IDs, Merkle, shared addresses, domain hashing; SLH-DSA-SHAKE; KMAC256 for key derivation

Still open

#	Decision	Notes
1	Peer-to-peer details	magic bytes, ports, seeds, fees (last)
2	Refracting Light W, shard variants	after the local testnet

The starting Rad and stamp values above come from measured collision data; the Rad prototype confirms them on real Rad puzzles before launch.

7. Security review checklist¶

Every item needs a reviewer before launch.

#	Threat	Mitigation in this design	Status
S1	51% / deep reorganization from rented CPUs or GPUs (no RL v3 ASICs exist; cloud CPUs are rentable). Bitcoin’s SHA-256 ASIC fleet cannot attack E46: those chips are hard-wired to SHA-256d	checkpoints (2c); recommend ≥ 30 confirmations (≈ 75 min) for anything meaningful; publish a hashrate monitor	proposed
S2	Timestamp games / timewarp to lower ASERT difficulty	median-time-past rule; 15-min future limit; ASERT uses the parent’s timestamp, so the gain is bounded	proposed
S3	Selfish mining	standard risk for any proof-of-work chain; documented, not solved	known
S4	Merkle malleability (CVE-2012-2459) and 64-byte transaction ambiguity	tagged leaves and nodes; odd node carried up, never duplicated (2b)	designed
S5	Refracting Light weakness	used only for proof-of-work and 128-bit addresses; the Rad rate is a public alarm; a pre-written emergency fork to switch proof-of-work to SHAKE256 is prepared before launch	proposed
S6	Supply bugs (Bitcoin’s 2010 value-overflow incident created about 184 billion BTC)	integer-only emission; clamp `remaining = max(T − E, 0)`; consensus tests at years 100, 114 and 118 plus a 1,000-year simulation; invariant miner + N + Z = reward every block	designed
S7	Pool accounting (N-pool, Z-pool)	pools never mint; carry-over balances tracked in consensus state; invariant Σ payouts ≤ Σ shares	designed
S8	Staking abuse (Sybil, grinding, locked funds)	z earned by mining; stake cap N × subsidy; lock timeout L; nonce-bound Rads	designed
S9	Genesis fairness	pszTimestamp; 0-E46 genesis output; published `genesis_miner.py`	designed
S10	Consensus determinism	fixed serialization; integer arithmetic; test vectors; two implementations must agree (Python reference and `rl_search.c` already match all v2/v3 vectors)	partly done
S11	Signatures	SLH-DSA-128s (FIPS 205), stateless, from a maintained library (liboqs); never a custom scheme	proposed
S12	Quantum preimage of 128-bit addresses (Grover ≈ 2^64)	decided: 256-bit payload RL v3 128 ‖ SHAKE256 128 (≈ 2^128)	decided
S13	Peer-to-peer (eclipse, denial of service, relay of 4 MB blocks)	deferred to the peer section (last)	deferred
S14	QTL wallet lock	test data only, never physical access; anti-lockout design (`QTL-V2-ANTI-LOCKOUT.md`)	designed
S17	RL v3 is ASIC-friendly: its multipliers 17, 257 and 65537 are a shift plus an add, rotations are free wiring, and there is no memory-hard step, so a custom chip would far outrun CPUs and GPUs	irrelevant while the chain has no value; a memory-hard proof-of-work layer (Argon2/RandomX style) is a possible later option and would need full testing	noted
S18	Seeded SLH-DSA keygen relies on an OpenSSL option documented “for testing purposes”: a future OpenSSL could change or remove it, and wallets could no longer re-derive their keys from the master seed	pinned OpenSSL version; NIST ACVP seeded-keygen KAT in CI and as a wallet startup self-test that refuses key generation on mismatch (decision #19)	testnet accepted; revisit before mainnet

S15: the E2 scenario (future universe: large quantum computers exist and SHA-2 collisions are broken).

#	Part	Algorithm	Bits	Classical cost	Quantum cost	In E2
1	Mining	RL v3	128	proof-of-work	Grover speeds up search; difficulty adjusts	works
2	Single-owner address	RL v3 128 ‖ SHAKE256 128	256	preimage ≈ 2^128	Grover ≈ 2^128	safe
3	Shared address	SHAKE256	256	collision ≈ 2^128	BHT ≈ 2^85	safe (no SHA-2 dependency)
4	Tx / block IDs	SHAKE256	256	collision ≈ 2^128	BHT ≈ 2^85	safe
5	Merkle roots	tagged SHAKE256	256	collision ≈ 2^128	BHT ≈ 2^85	safe
6	Signatures	SLH-DSA-SHAKE-128s	128-bit level	≈ 2^128	NIST category 1; Shor-immune	safe
7	Rad IDs	RL v3	128	collision ≈ 2^64	BHT ≈ 2^43	fine (labels)
8	Quantum Rads (E2 only)	factoring by Shor	grows	hard classically	solvable by quantum machines	reward stream, never a dependency
9	Key derivation	KMAC256	256	PRF	Grover ≈ 2^128	safe
10	QTL password	Argon2id (BLAKE2b inside)	256	memory-hard guessing	Grover on guesses only	strong password, later the 2FA key
11	QTL encryption	AES-256-GCM	256	2^256	Grover ≈ 2^128	safe
12	QTL time delay	dual delay (S16)	—	both locks sequential	Shor opens lock A only; lock B stays sequential	delay survives
13	Address checksum	Bech32m	30	error detection only	—	unchanged

The version character p (v1) stays reserved: if SHAKE256 itself ever weakened, IDs and addresses switch versions without changing the format.

S16: QTL dual delay, Shor-aware (proposed). The current QTL delay (RSW squaring mod N) is opened instantly by anyone who can factor N, which Shor does. Proposed replacement for the wallet lock:

Lock A (Shor hunt):   y_A = x^(2^T_A) mod N         -- creator: instant via the factors of N; others: T_A sequential squarings
                                                    -- a quantum attacker runs Shor (period finding) to factor N and skips Lock A
Lock B (search back): y_B = SHAKE256^(T_B)(seed)    -- a sequential hash chain; Shor gives no shortcut, Grover doesn't help
                                                    -- sequential work, so the attacker must walk the whole chain
K = KMAC256(Argon2id(password) ‖ y_A ‖ y_B, "E46-QTL-2")

Lock B has no creator shortcut: there is a proof (Mahmoody–Moran–Vadhan) that hash-only time locks can’t give the creator a trapdoor. The fix is a chain bank: while idle, the wallet precomputes a few chains with their checkpoints and stores them encrypted. Sealing then just takes the next banked chain, so creating a lock stays instant.
Checkpoints on both locks keep the anti-lockout guarantees (QTL-V2-ANTI-LOCKOUT.md): damage is caught early and progress can resume.
Split: for example half the target time in each lock, so a classical attacker faces the full delay and a quantum attacker still faces at least half.
Shor as an experiment, not a toy: a classical simulation of Shor’s period finding on small N, to show exactly what a quantum attacker does to Lock A, and real Quantum Rads (row 8) once quantum hardware outgrows classical factoring.
Status: design only; nothing built.

9. Planned: Refracting Light W (1024-bit state, 512-bit output)¶

Decided direction, 7 Oct 2026: expand Refracting Light from a 512-bit state with 128-bit output to a 1024-bit state folded to 512 bits (8 lanes instead of 4, the same step function). This replaces the idea of a 256-bit fold of v3.

	v3 (today)	W (planned)
Internal state	512 bits (4 lanes)	1024 bits (8 lanes)
Output	128 bits	512 bits
Hidden state bits	384	512
Collision (classical / quantum)	2^64 / ≈2^43	2^256 / ≈2^171
Preimage (classical / Grover)	2^128 / 2^64	2^256 / 2^256
256-bit address from it (Grover)	—	≈ 2^128
Speed	1×	≈ 2× slower

Throwaway sketch measurements (scratch, not project code): full mixing after 2 steps, avalanche 255.6 / 512 bits. W is not used anywhere until it passes the full Phase 3 suite, the step-reversal test and outside review. Until then the chain stays as decided: RL v3 for proof-of-work and Rad IDs, RL v3 128 ‖ SHAKE256 128 for addresses. Once W passes, it can take over addresses (version p) and possibly proof-of-work.

Security rule (section 7): collision ≈ min(output/2, hidden/2), preimage ≈ min(output, hidden/2). W meets both with room to spare.

Status: paused by the project owner on 7 Oct 2026. Nothing built.

8. What this document does not claim¶

No security proof, no audit, no external cryptanalysis of Refracting Light, no real quantum or nuclear process, no monetary value. Every throughput and timing figure is an estimate from the measurements in PHASE3-RESULTS.md and the C benchmark, to be re-measured on the prototype.