← All proposals

Status

Final. This is a status / audit document, not a Standards Track LP.

No wire change, no precompile slot, no consensus rule. The activation

marker is the same Quasar Edition genesis used by every wire-and-state

LP in the new final Lux network. The numbers in this document reflect

the state of the canonical main branches at the date in the

created field; the methodology stays valid forward — re-running the

audit at any later commit is a one-shot grep.

This LP is one of the contexts allowed by TAXONOMY.md §"Historical

references — preserved" to mention upstream names directly. It compares

luxd against avalanchego; the upstream name is qualified everywhere it

appears.

TL;DR

luxd main at v1.30.3 (2026-06-06) carries zero files with an

"Ava Labs" copyright header, zero avalanche or ava-labs literal

references in source, zero imports of google.golang.org/grpc,

and zero packages from the github.com/ava-labs/* namespace. The

last bridge — luxfi/codec, a transitional shim derived from

avalanchego's codec.Manager — was ripped from go.mod on v1.30.0

(commit 1e284093a0). The luxfi/p2p package, the final upstream

shape that survived into Quasar Edition, is in active removal in

favour of QUIC + ZAP under LP-201 (13 remaining imports, all leaf

sites). Once those are flipped, the audit returns zero on every

dimension.

luxd's binary is 35 MB at bin/luxd. avalanchego's release build

is 61 MB at build/avalanchego-release. luxd's source tree is

274,124 Go LOC across 1,444 files; avalanchego is **623,940 Go LOC

across 2,785 files**. Both numbers are measured by `find . -name

'*.go' -not -path './.git/*' | wc -l and wc -l` against the same

file set, on the canonical main of each repo at the date of this LP.

The structural reasons for the win — no codec marshal hops, no grpc,

no reflection registry, LE-end-to-end wire, ZapDB instead of LevelDB,

QUIC + ZAP instead of TCP + Protobuf, Quasar finality instead of

Snowball confidence accumulation — are catalogued in §3. The

classical-only consensus profile that lets benchmarks compare

apples-to-apples (BLS-only validator identity, classical TLS, BLS

threshold sigs, no PQ overhead) is documented in §4. Real-workload

throughput / latency / memory numbers are TBD; §5 gives the methodology

and the location at which numbers will live (benchmarks.lux.network).

We do not invent numbers we have not measured.

1. What's left of avalanchego in luxd

1.1 Method

Four orthogonal greps against the working tree of ~/work/lux/node at

commit d58699bbd8 (v1.30.3, 2026-06-06):

# Literal upstream references in source
grep -rln 'ava-labs' --include='*.go' .                  # → 0 files
grep -rln -i 'avalanche' --include='*.go' .              # → 0 files

# Upstream copyright headers
grep -rln 'Copyright.*Ava Labs\|(c) Ava Labs' \
  --include='*.go' .                                     # → 0 files

# gRPC imports
grep -rln '"google.golang.org/grpc"' --include='*.go' .  # → 0 files

# Upstream package paths
grep -rln '"github.com/ava-labs/' --include='*.go' .     # → 0 files

# Last upstream-shape bridge: luxfi/p2p (in flight)
grep -rln '"github.com/luxfi/p2p"' --include='*.go' .    # → 13 files

Same script run against ~/work/ava/avalanchego at commit

9f8b9461cf (2026-05-14):

grep -rln 'Copyright.*Ava Labs\|(c) Ava Labs' \
  --include='*.go' .                                     # → 2,665 files
grep -rln '"google.golang.org/grpc"' --include='*.go' .  # → 26 files

1.2 Findings

The Go LOC ratio (274 k luxd vs 624 k avalanchego) understates the

divergence: avalanchego's 624 k LOC includes ~120 k LOC of generated

gRPC stubs (*.pb.go, *_grpc.pb.go) that have no analog in luxd.

Stripping generated code, avalanchego is closer to 500 k LOC of

human-written source. Even at that ratio, luxd is roughly **55 % of

upstream's source mass** for the canonical equivalent feature set

(P-Chain, C-Chain equivalent, X-Chain equivalent, plus seven Lux-only

VMs that avalanchego doesn't have).

1.3 Per-subsystem audit

What replaced what, layer by layer:

The audit's headline: no Avalanche surface has survived in shape.

Every named upstream subsystem has either been replaced wholesale or

shipped only in luxd. The single transitional residue documented in

LP-200's "What's NOT yet decomplected" section — luxfi/p2p and its

12 codec-bridged Tx.Sign call sites — is in active removal under

LP-201. All 12 of those sites speak ZAP on either side of the bridge;

the bridge itself is the last upstream-derived control-flow shape, and

it is leaf, not load-bearing.

1.4 The genesis cut

The Quasar Edition genesis (2025-12-25 16:20 PST, unix 1766708400) is

the line under which the legacy Lux network — itself a 2020-vintage

fork of avalanchego — is out of scope. There is no migration path

because the new network starts from genesis with the ZAP stack. The

pre-Quasar Lux network's chain bytes are not readable by a v1.30.x

luxd binary (LE-only build; the legacy BE-encoded P-chain state is

explicitly out of scope per LP-200).

Operationally this means: the only upstream code that ever ran in

production Lux Network is the 2020-vintage pre-Quasar mainnet. That

network's last block was committed before genesis-2025. The post-

genesis network is byte-isolated from it. There is no shared state, no

shared block hash, no shared validator set.

2. Three layers of architectural separation

2.1 Network layer

Avalanchego: TCP + TLS 1.3, Protobuf messages framed by length-

prefixed envelopes, gRPC for VM-plugin IPC (rpcchainvm), gRPC-

gateway for the public API. Classical-only key exchange (X25519 or

ECDHE-P-256), classical-only authentication (ECDSA-secp256k1 cert

chain). Harvest-now-decrypt-later viable against any captured stream.

luxd: QUIC streams carrying ZAP frames. Handshake is X-Wing:

X25519 classical ECDH ⊕ ML-KEM-768 (FIPS 203) post-quantum KEM, with

a single shared secret derived via SHAKE256-based KDF over a typed

transcript. Constant: SuiteX25519MLKEM = 0x01 in

~/work/lux/zap/handshake/labels.go; suite-byte negotiation, single

admitted suite in v1. Authentication uses ML-DSA-65 over a transcript

hash that the responder cannot precompute (deterministic-sign mode

disabled outside KAT tests; rejection of malformed transcripts is one

KAT row).

This is harvest-resistant: even given a recorded session and a

quantum break of X25519, the attacker still needs to break ML-KEM-768

to recover the shared secret. NIST level 1 + level 3 hedged in one

suite.

Source: ~/work/lux/zap/handshake/ (initiator.go, transcript.go,

labels.go, identity.go). The frames_test.go, kat_test.go, and

protocol_test.go files lock the wire format byte-for-byte.

2.2 Wire format layer

Avalanchego: codec.Manager is a runtime registry of versioned

type-codec pairs. Each (struct, codec-version) pair is registered at

init() time. Marshal reflects over the struct, walks the field

list, dispatches to the per-field marshaller, and produces a byte

stream prefixed with the codec version (big-endian uint16). Unmarshal

does the inverse — reflect, dispatch, allocate the struct, populate

fields. Every Sign and Verify call goes through this path. Every block

parse goes through this path. Every state read goes through this path.

The marshaller is ~3 μs per allocation on a typical tx; the

unmarshaller is ~1 μs; both allocate one Go object per encoded type

and the GC pays for it.

luxd: there is no Marshal. There is no Unmarshal. There is no

runtime codec registry. There is no reflection. Per-VM hand-rolled

serializers live in vms/pcodecs/ and consume the ZAP buffer directly.

The wire layout for each tx kind is declared once in a per-fx

wire.go (e.g. ~/work/lux/utxo/wire/secp256k1fx/wire.go). Sign and

Verify read offsets into the ZAP buffer; no struct allocation

intermediates a verify call. The byte order is little-endian — native

on every modern CPU; no byte-swap on load.

Performance characteristic from LP-200's microbenchmarks:

Compose this across a validator running consensus, admitting txs, and

writing state, and the wins multiply rather than add. See §5 for the

full-node benchmark methodology.

2.3 State layer

Avalanchego: LevelDB or BadgerDB underneath a versiondb wrapper.

The wrapper serializes each value via the legacy codec, prefixes the

key with the database version, and persists. State reads go

key → bytes → codec.Unmarshal → struct. State writes go

struct → codec.Marshal → bytes → key. Both pay the codec roundtrip.

luxd: ZapDB. A Badger fork built under the !grpc build tag with

native pb_zap.go encoders that consume ZAP buffers directly. The

ZAP buffer that arrives over the wire goes into the mempool by

reference, lands in a block by reference, persists to ZapDB by

reference, and streams out to the age-encrypted snapshot by reference.

The buffer is the value, transitively, at every layer.

Source: ~/work/lux/zapdb/. See LP-200 §1 layer 1 for the architectural

contract.

3. New components with no Avalanche analog

These are luxd's net-new surfaces — no upstream ancestor, no port from

avalanchego, no LP corresponds to "we kept their thing":

None of these have an upstream equivalent. avalanchego has no GPU

path, no FHE, no PQ wire, no atomic L1 spawn, no threshold VM, no Wave

finality driver, no ZapDB snapshot streaming, no STARK-FRI verifier

precompile, no ZK rollup as a first-class chain class.

4. Optional classical-only profile

4.1 What it is

The default Lux Network is post-quantum throughout (LP-217 cert

mode PQ-strict or PQ-heavy). The validator identity is ML-DSA-65

hybrid. The handshake is X-Wing. The threshold legs in the

QuasarCert include Pulsar (Module-LWE) and optionally Corona (Ring-

LWE) and Magnetar (SLH-DSA hash-family). This is the production wire

on mainnet.

A classical-only profile is supported for two operational

purposes:

1. Apples-to-apples benchmarking against avalanchego, on equal

cryptographic footing. avalanchego has no PQ stack — benchmarking

luxd in PQ-strict against avalanchego measures both the

architectural difference *and* the PQ overhead. The classical-only

profile removes the PQ overhead so the architectural difference is

isolated.

2. Educational / research deploys where operators want a "what

does ZAP + Quasar give us, independent of post-quantum cost?"

answer.

The classical-only profile does not revert any other architectural

choice. ZapDB stays. ZAP wire stays. Quasar consensus stays. GPU-EVM

stays. The only thing that flips is the cryptographic suite: BLS-only

validator identity (no ML-DSA leg), classical TLS 1.3 X25519 handshake

(no ML-KEM-768 leg), BLS-only threshold signatures in the QuasarCert

(no Pulsar / Corona / Magnetar legs). Think of it as "post-Avalanche-

snow-consensus but pre-PQ": the architecture wins are intact, the PQ

overhead is gone.

4.2 LP-217 cert-profile mapping

The classical-only profile maps to LP-217's PQ-off cert mode:

Activation: per-network setting baked into the spawn tx

(CreateSovereignL1Tx's pq_profile field, LP-018). Mainnet is

strict-PQ at genesis. Localnet and devnet may be classical (or any

intermediate) for testing. The profile is observable on-chain via the

network's spawn record.

4.3 Engaging the classical-only profile

For benchmarking against avalanchego, the operator-side knob is a

Network CR field (LP-018):

apiVersion: lux.cloud/v1
kind: Network
metadata:
  name: lux-classical-bench
spec:
  networkID: 1337            # localnet
  consensus:
    profile: PQ-off          # LP-217 cert mode
  validators: [...]

The luxd binary is the same. The genesis-time PQ-profile selector

configures: validator-identity verifier (BLS-only), handshake suite

(classical TLS), QuasarCert verifier (BLS-leg only). No build-time

flag, no separate binary.

4.4 What this is NOT

The classical-only profile is not "avalanchego in luxd shape". It

is luxd in classical crypto shape. ZAP wire stays, ZapDB stays,

QUIC transport stays, Quasar consensus family stays, GPU-EVM stays,

multi-VM topology stays. The benchmark measures: at equal crypto cost,

what does ZAP + ZapDB + QUIC + Quasar give us over Protobuf + LevelDB

+ TCP + Snowman?

A "true classical baseline" — i.e., disabling ZAP and falling back to

the legacy codec — is not supported. The legacy codec is gone from

go.mod; there is no compile path back. This is intentional. ZAP is

not a feature flag; it's the architecture.

5. Performance — claimed wins + benchmark methodology

5.1 What we have measured

These are the numbers we will defend. The 35 MB / 61 MB binary

measurement, the 274 k / 624 k LOC measurement, and the 0 / 26 grpc-

import measurement are reproducible from ~/work/lux/node and

~/work/ava/avalanchego main branches at the date of this LP and

will not move materially. The LP-200 microbenchmarks are reproducible

via go test -bench against the named packages.

5.2 What we have NOT measured — methodology for closing the gap

The marketing-flavor claim "luxd is light-years faster than

avalanchego, with much less memory" is unsubstantiated until full-node

benchmark numbers exist. This section lays out exactly what to measure,

how, and where the numbers will live. No fabricated numbers.

5.2.1 Throughput (tx/s, sustained)

Hypothesis: at the classical-only profile (LP-217 PQ-off,

matching avalanchego's classical crypto footing), luxd sustains

≥ 3× the tx throughput of avalanchego at the same hardware budget. The

3× lower bound is the per-tx parse win compounded by the elimination

of mempool re-marshal and state re-encode hops.

Method:

• 5-validator cluster, identical bare-metal hardware (Mellanox

ConnectX-7 NIC, AMD EPYC 9554, 256 GB RAM, NVMe gen4)

• Load generator: 100 k-tx blast per round, simple value transfer +

smart-contract call (50/50 split), warm pool of pre-signed txs

• Networks: avalanchego mainnet-clone genesis vs luxd

classical-only profile localnet genesis (LP-018 spawn with

pq_profile: PQ-off)

• Measurement: peak tx admission rate over 60 s sustained, 5-validator

consensus, no thrashing

• 5 runs per side, report median + p99 + standard deviation

Where the numbers live: `~/work/lux/benchmarks/avalanchego-vs-

luxd/throughput/` (to be created); CI job posts the run on every

tagged release; results page at benchmarks.lux.network/throughput.

5.2.2 Block-to-finality latency

Hypothesis: Quasar's Wave + Focus + Sink composition reaches

local finality in fewer rounds than Snowman's confidence-counter

β-accumulation. Wave gives a per-round threshold vote (single round

trip among the committee); Focus accumulates β consecutive Wave

successes for finality. Snowman accumulates β confidence over per-

preference repeated polls. At committee size 64, β=20, network RTT

50 ms intra-AZ: luxd's Wave round-trip is two committee passes

(~5 ms + handshake-amortized 50 ms); Focus over 20 rounds is ~1 s.

Snowman at same parameters polls ~25–50 rounds at ~50 ms each

(1.25–2.5 s) before reaching β confidence.

Method:

• Single tx, single block, fully consumed pool; measure

block_received_at_proposer → block_committed_local for each

validator

• 5 validators, identical inter-AZ latency profile, identical hardware
• p50, p99 over 1000 blocks
• Same classical-only LP-217 PQ-off profile on the luxd side

Where the numbers live: same as above, `benchmarks.lux.network/

latency`.

5.2.3 Memory (runtime steady-state RSS)

Hypothesis: luxd's runtime heap is smaller than avalanchego's at

the same workload, because (a) no reflection-tagged codec registry,

(b) no Protobuf descriptor table, (c) no gRPC service registry, (d)

ZAP buffer pool (sync.Pool over fixed-size slices) bounds the

allocation profile.

Method:

• Same 5-validator cluster
• Steady-state load: 1000 tx/s sustained for 30 min
• Measure: cat /proc/$LUXD_PID/status and

cat /proc/$AVALANCHEGO_PID/status for VmRSS and VmSize at

5-minute intervals

• pprof heap profile (go tool pprof) at end of run for both;

publish the heap-by-package breakdown

• Report RSS p50, p99 + heap-by-package top-20

Expected concrete savings on binary, before RSS measurement:

• No google.golang.org/grpc (~12 MB stripped, ~5 MB heap import side

effects at boot)

• No google.golang.org/grpc/grpc-gateway/v2 (~5 MB stripped)
• No go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc

(~3 MB stripped)

• No connectrpc.com/grpcreflect (~1 MB stripped)
• No github.com/grpc-ecosystem/go-grpc-prometheus (~0.5 MB stripped)

That's ~21 MB of grpc-toolchain dead weight that luxd does not link.

That accounts for ~80 % of the binary-size gap (35 vs 61 MB → 26 MB

delta; 21 MB is grpc-toolchain).

Where the numbers live: benchmarks.lux.network/memory.

5.2.4 CPU profile / hot path

Hypothesis: avalanchego's CPU profile under sustained load is

dominated by codec.linearcodec.Unmarshal and proto.Unmarshal

called from gossip, consensus, and state. luxd's CPU profile has no

such hot frame because the offset-read accessors are inlined arithmetic

into the buffer.

Method: 30 s CPU profile at steady-state 1000 tx/s; publish flame

graphs for both binaries side-by-side; report top-10 self-time frames

for each. Expected top frames for luxd: BLS verify, secp256k1 verify,

ZAP frame parse (~50 ns/call), Pebble I/O. Expected top frames for

avalanchego: linearcodec reflect dispatch, proto.Unmarshal, GC

mark, TLS handshake.

Where the numbers live: benchmarks.lux.network/cpu-profile.

5.3 What we explicitly do not claim

• We do not claim X× throughput, Y× latency, or Z MB memory until

§5.2.1–§5.2.4 have published numbers. Today the answer is **TBD,

methodology in §5.2**.

• We do not claim parity with avalanchego under PQ-strict — that

benchmark would mix the architectural delta with the PQ overhead

and is not informative. The PQ-strict number is reported separately,

against the classical-only luxd number, to surface the PQ cost.

• We do not claim binary-size wins at runtime expansion (UPX,

dynamic loading) — we measure stripped-static binary on Linux

amd64, ldflags -s -w -trimpath, no UPX, no stripping after-the-

fact. Both binaries built with go 1.26.3.

5.4 Bench harness location

The bench harness will live at `~/work/lux/benchmarks/avalanchego-vs-

luxd/` once authored. It is not yet in tree at the date of this LP.

The taxonomy convention: scripts under that root, results posted by

CI on tag push to benchmarks.lux.network (a static site under

hanzoai PaaS). LP-301 will not update with numbers; instead a sibling

LP-302 will publish the bench results once they exist and cross-

reference back here.

6. Migration status as of 2026-06-06

6.1 go.mod rip lineage

The pre-v1.30 series (v1.28.x, v1.29.x) carried the codec / grpc

bridge as transitional shims. The Wave 2D codec rip (commits

d5bbfb23f8, 71d6fd9d7d, 868ce085c0, beeaf621a9, d867ae46ed,

60f7266e73) migrated 73 files across xvm, evm, example,

proposervm, platformvm, and rpcchainvm to vms/pcodecs. Wave 2G-

Cascade (833b9b2a3d, 987633893c) was the last upstream-symbol

sweep. By v1.30.0 the luxfi/codec package was unreferenced and

deletable.

6.2 Production deployment

Mainnet at the date of this LP is running **5 validators on luxd

v1.28.29, C-Chain head 1,082,780**, P-Chain healthy. v1.30.x has

been tagged but not deployed: the LE-only build cannot read the

pre-LP-023 BE-encoded P-chain state, so the rollout plan is **fresh

bootstrap** (a Quasar Edition mainnet relaunch from genesis-2025).

Genesis cutover ran 2025-12-25 16:20 PST; the post-cutover network

is fresh from block 0. Pre-cutover state is preserved at archive

mainnet for historical query only.

6.3 Residual upstream-shape work

Per LP-200 §"What's NOT yet decomplected":

• 12 codec.Manager imports remain in luxd. The Tx.Sign cascade

in platformvm and xvm routes through codec.Manager for the

signing step. Wire on either side is ZAP; the bridge is a

transitional shim. Sign migration is leaf; no architectural lift.

• ~/work/lux/codec/ not yet archived. Transitively pulled via

luxfi/vm/chains/atomic. Module deletion is gated on Tx.Sign.

• luxfi/p2p still imported in 13 files. LP-201 replaces with

QUIC + ZAP + mDNS + DHT. The replacement is in flight, not landed.

• service/info blocked on luxfi/p2p upstream codec/jsonrpc.

Public API still speaks legacy jsonrpc envelope on top of

luxfi/p2p. Replaced when LP-201 lands.

These four items are the entire residual upstream-shape inventory.

None mutates the architecture. Once LP-201 lands, the residual list

collapses to zero and the audit returns clean on every dimension.

7. Why luxd is faster — the structural reasons

This section translates the marketing claim ("light-years faster")

into specific mechanical reasons. Each row is testable; the test

either confirms or refutes.

7.1 No codec.Marshal() on the hot path

The single biggest hot-path cost in avalanchego is `codec.Manager.

Marshal() / Unmarshal()` called per-block per-tx per-validator.

luxd does not have this call. The ZAP buffer that arrives over the

wire goes directly into the mempool (one buffer-pool pointer). It

goes into the block (a list of buffer-pool pointers). It persists to

ZapDB (one Badger write of the same buffer). The block ID is

sha256(block.Bytes()) where block.Bytes() is the concatenation

of the already-existing buffers; no re-marshal.

Measurable: profile a luxd validator under load; look for

Marshal in the top-100 self-time frames. Result: not present. (See

LP-200 §"Performance Characteristics" — 3.6×–13.4× per-op win is the

direct measurement of this absence.)

7.2 No reflection in the wire format

Avalanchego's linearcodec reflects over every Go struct it

encodes. Reflection in Go is ~10× slower than direct field access

and forces interface-typed allocations. luxd's accessors are

arithmetic — buf[8:12] for a 4-byte field at offset 8. Inlined,

no allocation, no GC pressure.

Measurable: heap allocs per tx-parse. LP-200 reports luxd at

1 alloc/op (the buffer itself); avalanchego at 2–6 allocs/op (one

per reflected field group). Inspect with `go test -bench -

benchmem`.

7.3 LE-end-to-end

Avalanchego is big-endian on wire. luxd is little-endian. On x86-64

and ARM64, native byte order is LE; BE-on-wire requires a byte-swap

on every load. The swap is fast (bswap instruction, one cycle), but

the cumulative cost over millions of field reads per block is real.

Measurable: not easily; the win is small per-op (~1 ns) but

compounds. We report this as a contributing factor, not a headline

number.

7.4 ZapDB instead of LevelDB

ZapDB is a Badger fork with a !grpc build tag and native

pb_zap.go encoders. It stores ZAP buffers as-is — no key-value

serialization layer, no versiondb wrapper, no codec roundtrip on

read or write. Snapshot streaming is one age-encrypted streaming

write of the buffer pool; no re-encode.

Measurable: snapshot write-amplification. LP-200 reports ~10×

reduction (qualitative). State write throughput at the validator

level: TBD per §5.2.1.

7.5 QUIC instead of TCP + TLS

QUIC's 0-RTT handshake is faster than TCP + TLS 1.3's 1-RTT (or

2-RTT cold start), and QUIC's stream multiplexing eliminates the

head-of-line blocking that TCP suffers under packet loss. For a

mempool gossip workload where every validator is concurrently

gossipping to every other validator over many small messages, QUIC

wins on tail latency.

Measurable: tx-gossip latency under 1 % packet loss. TBD per

§5.2.2.

7.6 Wave / Focus finality vs Snowman confidence

Snowman's confidence counter is monotonic — every successful poll

increments confidence on the preferred block by 1, every poll

preferring a different block resets it to 0. Reaching β confidence

takes β consecutive successes from the same preferred block.

Wave's threshold vote in one round gives a 2f+1 commitment; Focus

accumulates β consecutive Wave successes. The committee structure

in Wave (k-of-N Fisher-Yates sample under Photon) means each

round's vote is a fresh sample, not a repeated poll on the same

validator subset.

The end-of-round result: luxd reaches local finality in O(β) round

trips, where the constant is small (~5 ms per round trip intra-AZ,

under PQ-strict; ~2 ms classical-only). Snowman reaches β confidence

in O(β·k) round trips because each round trip is a single-peer poll,

not a committee vote.

Measurable: block-to-decision latency per §5.2.2. TBD; the

hypothesis is luxd ~3× faster at committee size 64, β=20, 50 ms RTT.

7.7 No grpc

google.golang.org/grpc is ~12 MB of compiled code and ~5 MB of

import-side-effect heap at boot. Avalanchego links it; luxd does

not. The 26 grpc-importing files in avalanchego are the gRPC service

definitions, the gRPC-gateway adapters, the otlp gRPC trace

exporter, and the rpcchainvm gRPC plugin host. luxd's rpcchainvm

speaks ZAP transport directly (vms/rpcchainvm/zap/), no gRPC.

Measurable: binary size. Done — luxd 35 MB vs avalanchego 61 MB,

26 MB delta, ~21 MB of which is grpc-toolchain dead weight.

8. References

8.1 Source paths (luxd at v1.30.3, commit d58699bbd8)

• ~/work/lux/node/ — luxd canonical
• ~/work/lux/node/consensus/quasar/ — Quasar consensus engine
• ~/work/lux/node/consensus/zap/ — DID layer
• ~/work/lux/node/vms/pcodecs/ — per-VM hand-rolled wire serializers
• ~/work/lux/node/vms/rpcchainvm/zap/ — ZAP-native VM plugin IPC
• ~/work/lux/node/vms/{platformvm,xvm,evm,proposervm,dexvm,thresholdvm,mldsafx,example}/ — per-VM implementations
• ~/work/lux/zap/handshake/ — X-Wing handshake (SuiteX25519MLKEM = 0x01)
• ~/work/lux/zapdb/ — Badger fork with ZAP-native encoders
• ~/work/lux/evmgpu/ — GPU-native EVM (622 .go files)
• ~/work/lux/fhe-coprocessor/ — FHE-GPU precompile + F-Chain
• ~/work/lux/crypto/{bls,mldsa,slhdsa,kem/xwing}/ — luxfi crypto suite
• ~/work/lux/keys/service_identity.go — BIP-44 NodeID derivation
• ~/work/lux/magnetar/ — threshold SLH-DSA

8.2 Comparison paths (avalanchego at commit 9f8b9461cf, 2026-05-14)

• ~/work/ava/avalanchego/ — upstream main
• ~/work/ava/avalanchego/snow/ — Snowball/Snowflake/Snowman/Avalanche engines
• ~/work/ava/avalanchego/codec/ — runtime codec registry
• ~/work/ava/avalanchego/build/avalanchego-release — 61 MB stripped binary
• ~/work/ava/coreth/ — upstream EVM (libevm fork)

8.3 Git lineage

• luxd tag v1.30.0 1e284093a0 — grpc + luxfi/codec rip
• luxd tag v1.30.2 3d5b8d1c12 — forward-only ZAP, BE-fallback rip
• luxd tag v1.30.3 d58699bbd8 — LE end-to-end
• Wave 2D codec migration: d5bbfb23f8, 71d6fd9d7d, 868ce085c0, beeaf621a9, d867ae46ed, 60f7266e73
• Corona → Corona rename: 078077baf1

8.4 LP cross-references

• LP-009 — GPU-native EVM
• LP-010 — Block-STM parallel execution
• LP-011 — GPU crypto acceleration
• LP-012 — PQ crypto on GPU
• LP-013 — FHE-GPU precompile
• LP-014 — Multi-EVM topology
• LP-015 — Validator key management (BIP-44 hash-of-hash NodeID)
• LP-017 — Quasar Consensus + Polaris Cert Profile (historical; superseded codenames per LP-217)
• LP-018 — Atomic L1 spawn primitive
• LP-020 — Quasar Consensus 3.0
• LP-022 — ZAP wire protocol
• LP-023 — P-Chain ZAP wire
• LP-027 — Wave protocol
• LP-028 — FPC consensus
• LP-070 — ML-DSA (FIPS 204)
• LP-073 — Pulsar (Module-LWE threshold ML-DSA-65)
• LP-075 — BLS
• LP-134 — Lux Chain Topology (authoritative source for chain/VM names)
• LP-141 — Threshold-VM substrate
• LP-181 — Magnetar threshold SLH-DSA
• LP-200 — ZAP Stack (wire = mempool = state = ZapDB)
• LP-201 — QUIC + ZAP + mDNS + DHT P2P (replaces luxfi/p2p)
• LP-204 — Network of Blockchains
• LP-210 — Block-STM
• LP-217 — Cert profile modes (PQ-off / PQ-fast / PQ-strict / PQ-heavy)
• LP-218 — ZAP-P3Q PQ rollup
• LP-220 — P3Q Corona / Magnetar
• LP-300 — Schema Registry

8.5 Methodology references

• TAXONOMY.md — naming rules (Photon not Snowball, Nova not

Snowman, Nebula not avalanche-protocol, luxd not avalanchego)

• LP-200 §"Performance Characteristics" — microbenchmark table
• LP-200 §"What's NOT yet decomplected" — residual migration list

9. Activation marker

activates: 2025-12-25T16:20:00-08:00
activates-unix: 1766708400

Same marker as every Quasar Edition wire-and-state LP. Set once; does

not move. The audit numbers in this LP are dated 2026-06-06 against

the post-genesis main branch; the numbers move as the residual

migrations (§6.3) land. The architectural claim — no Avalanche shape

survives — was true at genesis and remains true forward.