Pulls the validator-count clamp that scales an oversized consensus committee
down to the live set (fixes testnet finality wedge where TestnetParams K=11/α=8
was unsatisfiable with 5 validators; also protects mainnet from the same brick
when it runs fewer than 21 validators).
Kills the bug CLASS behind the α-of-K finality wedge (v1.30.65), not just the
one Gossip instance. The chain router (node/chain_router.go) forwards an inbound
message only if message.ToConsensusOp maps it, then dispatches on the router op;
the node op table and the consensus router op enum are two halves of ONE routing
contract. When they diverged — router.Gossip existed but no node op mapped to it
— every broadcast vote was dropped as "unhandled message op" and finality
wedged, with nothing to catch it.
- ToConsensusOp now returns the router constants (byte(router.Get) ...) instead
of 0..11 magic numbers, so values cannot drift and the table reads as the
correspondence it is. Bumps consensus v1.25.29 -> v1.25.30 (adds router.NumOps,
the single source of truth for the op count).
- message/ops_test.go TestToConsensusOp_TableAlignedWithRouter is now EXHAUSTIVE
and BIDIRECTIONAL: it reconstructs the inverse mapping over the whole node op
space and requires a bijection onto [0, router.NumOps). A router op with no
node preimage (the original bug), a collision, a wrong target, or a stray
mapping all go RED. Pinned to router.NumOps, so a future op added to one table
but not the other fails the test instead of at runtime. Proven RED against the
original bug (drop the GossipOp case -> router.Gossip loses its preimage ->
fail); folds in the old Gossip-specific and hand-listed table checks.
Build rc=0 (GOWORK=off go build ./...); message tests green; finality fix
(GossipOp -> router.Gossip -> blockHandler.Gossip) unchanged and still covered.
Genericize the external-consumer example to a white-label tenant's
network-bootstrap tooling; the the tenant repo path belongs only in that
tenant's own repo, never in a lux repo.
The α-of-K quorum vote/cert transport rides on app-gossip (GossipOp), but
GossipOp was never added to the chain router's consensus-op table
(message.ToConsensusOp) nor to blockHandler.HandleInbound's switch. So every
inbound vote was dropped at node/chain_router.go as "unhandled message op"
before it could reach blockHandler.Gossip -> engine.HandleIncomingVote. Blocks
ride PutOp (mapped) and propagated+verified on all validators; votes ride
GossipOp (unmapped) and vanished. Each node held only its own self-vote, the
cert never reached alpha, and every chain wedged at height N: "verified but
never accepted", no vote/cert/accept activity.
This is the fork divergence from avalanchego, where votes are Chits — a
first-class consensus op always in the router table (snow/engine/snowman
engine.go Chits -> voter -> topological.RecordPoll -> accept). Lux moved votes
onto app-gossip but left the node-side op routing incomplete; the consensus
repo already reserved router.Gossip=11 'routed via the blockHandler Gossip
method' (core/router/router.go) — only the node wiring was missing.
Fix (node-only; safety core untouched — this is purely liveness):
- message.ToConsensusOp: map GossipOp -> 11 (router.Gossip)
- blockHandler.HandleInbound: add case handler.Gossip -> b.Gossip(...)
b.Gossip already demuxes the quorum envelope (Mode-gated) into
HandleIncomingVote / HandleIncomingCert; the signed-vote verify + verified-2/3
-stake cert assembly are unchanged, so honest votes now reach the assembler
without weakening VerifyWeighted or the unforgeable cert.
Regression guard (message/ops_test.go): GossipOp must map to router.Gossip, the
full op table must stay aligned with the consensus router, and an inbound vote
gossip must survive router extraction (op + envelope bytes) intact.
evm v1.99.40's go.mod pins luxfi/chains v1.3.19, whose dexvm/registry was an
incomplete refactor (forbidden.go deleted) -> AssertNoForbiddenAssetRefs / toHex /
fromHex / looksLikeASCIITickerID undefined -> EVM plugin won't compile. Force
chains@v1.3.21 (forbidden.go restored), matching node's go.mod + the chain-VM
plugin stage. This is the 2nd build blocker after the go.sum re-strip (v1.30.63);
together they should green the build (v1.30.59 -> v1.30.64).
The pre-download strip (line 69) fixed go.sum, but `COPY . .` then restored the
committed stale go.sum, so the build hit a SECURITY ERROR when a luxfi/* module was
re-tagged (luxfi/age v1.5.0 here). Re-strip first-party lines right before the build
so -mod=mod re-records current cache hashes. Self-heals every future re-tag.
(v1.30.59 built; v1.30.60/61/62 failed on exactly this.)
X-Chain was on an undriven, unconfigured DAG engine (test-ID/height-0 vertices, a
handler that dropped every inbound consensus message) — no certificate finality,
no parity with C/D/P. It now runs the same linear consensuschain path as every
other chain: deterministic 2/3-stake BFT certificate finality (AcceptWithCert),
the BFT overlap-bound floor, and the epoch-pinned validator set.
vms/xvm/vm.go: conform *VM to block.ChainVM / consensuschain.BlockBuilder
(Connected/Shutdown/WaitForEvent/HealthCheck), remove GetEngine() and the dead
DAG methods, add the compile-time asserts. X already had a real linear builder
(embedded blockbuilder.Builder, wired in Linearize) — nothing faked.
vms/xvm/health.go: HealthCheck -> chain.HealthResult. vms/xvm/tx.go: deleted
(dead dag.Tx wrapper).
chains/manager.go: linearize DAG-native VMs (X-Chain) into linear block mode
before SetState, wired to the REAL toEngine the cert runtime reads from.
Interface-gated — only VMs implementing Linearize are affected; C/D/P/Q untouched.
With no production VM exposing GetEngine, the undriven DAG dispatch is dead.
vms/dexvm/dexvm.go, vms/types/fee/policy.go: doc corrections (dexvm is
plugin/optional/NFT-gated, linear cert finality; X-Chain UTXO fee is a deliberate
exception to the account-model FlatPolicy floor).
Full node builds; vms/xvm + chains tests green. Parity holds by construction for
C/D/X/Q/Z: one cert path, one finality authority.
v1.25.29 carries the fetch-on-unknown-vote self-heal (c9a70880a) — buffer votes
for untracked blocks, fetch the block, never drop — which fixes the QC-assembly
finality wedge; plus L-1 (dedup buffered votes by NodeID, fail-closed). crypto
v1.19.26 to match consensus' requirement. Completes the v1.30.60 finality set:
α-of-K node wiring (already on main) + engine lifetime-ctx (C1) + engine self-heal.
chains/manager.go started the consensus engine with a 30s-timeout context;
engine.Start parents all four long-running loops (poll/vote/pipeline/re-poll)
to it, so they died ~30s after each chain started and the quorum cert never
assembled — the finality wedge fixed in v1.30.55 (8b3785c6c1). Restore
Start(context.Background()). Applied on origin/main (full α-of-K wiring intact),
NOT the stale side-branch. Pairs with consensus v1.25.29 self-heal below.
cpuBLSVerify / cpuMLDSAVerify previously did length checks and returned true for
any well-formed input — a no-GPU node would ACCEPT FORGED signatures once LP-210
wires the GPU pipeline into block-accept. Now they perform REAL verification via
luxfi/crypto pure-Go primitives:
- BLS: bls.Verify after PublicKeyFromCompressedBytes/SignatureFromBytes
(enforces exact length, on-curve, subgroup membership; malformed => false).
- ML-DSA: pub.VerifySignature (FIPS-204 nil-context), pk 1952, sig 3309.
- Corona + ZK: FAIL CLOSED (return false) — luxfi/crypto has no pure-Go verifier
and the Corona GPU kernel is the known-wrong-prime BLOCKED kernel; never
rubber-stamp an unverified signature.
ML-DSA signature size corrected 3293 (stale round-3 Dilithium3) -> 3309 (FIPS-204
ML-DSA-65) in MLDSAWork doc + gpuMLDSAVerify flatten width, so the CPU oracle and
GPU path size the signature identically; pinned by TestMLDSA_WorkStructSizeIsCanonical.
Tests rebuilt to carry REAL valid BLS/ML-DSA signatures (was random bytes the old
format-only check accepted). TestCPUVerify_RealOracle proves: valid accepted,
forged rejected, Corona+ZK fail closed. All green.
go.sum: 7 luxfi modules (chains, keys, kms, sdk, staking, zap) had their content
hashes refreshed to the canonical registry values after an upstream re-tag (same
versions, same go.mod — source re-tag only). 'go mod verify' = all modules
verified. Surgical patch (7 lines), minimal go.sum preserved.
(cherry picked from commit e40f04b112f8b5d15223325199db4b981f05878c)
v1.19.23 adds the canonical crypto/poi package — the Freivalds compute-proof
verifier (over F_p, p=2^61-1, on the exact int8 accumulator) that the aivm
settlement / aivmbridge precompile path consumes. Purely additive: makes the
PoAI verifier available to luxd. Mirror of hanzo-engine/src/poi.rs.
Closes the node build break: consensus v1.25.20 called corona v0.7.9's
Round1 single-value but v0.7.9 returns (*Round1Data, error). v1.25.21
threads the error through all quasar round-signer sites.
ONE declarative flow for both lux release artifacts, on platform.hanzo.ai +
self-hosted arcd — NO GitHub Actions:
- hanzo.yml: node image build (matrix linux/{amd64,arm64}, native long-poll
dispatch onto lux-build-* pools, tag-pattern {{git.branch}} -> :vX.Y.Z).
Validated against the platform parsePlatformConfig.
- scripts/publish_plugin_set.sh: extracts the 12 baked VM plugins from the
node image + SHA256SUMS, uploads to s3://lux-plugins-<env>/<pluginset>/
(operator pluginSource), round-trip sha-verified. DRY — no second compile.
- RELEASE.md: the ONE canonical build+publish runbook; lists the .github
workflows to retire (docker.yml, release.yml, build*.yml, ci.yml, ...).
- LLM.md: points at RELEASE.md as the canonical release path.
Proof (no GitHub): node:v1.30.40 provenance == 37b2a4a10c (reused, not
rebuilt); evm@v1.99.37 + dexvm@v1.5.15 rebuilt natively on the spark fleet
(go1.26.4, CGO=0) and the full 12-plugin set published to
s3://lux-plugins-staging/ (round-trip verified). neo's lux-plugins-devnet
prefix untouched.
luxfi re-tagged crypto v1.19.22 (and others) after node go.sum was recorded,
causing 'checksum mismatch / SECURITY ERROR' at the node binary build step and
a cascading -mod=mod fallback to a corona pseudo-version with the old 2-value
Round1 API. Apply the same first-party go.sum strip the EVM/chains/dex plugin
stages already use, so -mod=mod re-records current content hashes for the
re-published modules at their pinned versions (integrity repair, no version drift).
config/flags.go + staking/kms.go: the StakingKMSSecretPath example string
referenced a brand-specific devnet path; replaced with the generic
/staking/devnet/node-0 form (lux surfaces carry no white-label brand
tokens). tools/go.sum: corrected the stale charmbracelet/x/ansi v0.9.2 h1
checksum to the canonical value (verified via go mod download).
Generates the ML-DSA-65 (FIPS 204) staking key + ML-KEM-768 (FIPS 203)
handshake key a strict-PQ local network needs, writing PEM blocks with the
exact types the node config loader expects. Pairs with the SchemeGate /
PQ-handshake path: a strict-PQ chain needs an ML-DSA identity before any
peer can present the gate's pinned scheme.
The per-chain peer.SchemeGate is now built under profileRequiresPQHandshake,
not merely SecurityProfile != nil. Load-bearing: the gate's pinned scheme
byte (SigSchemeMLDSA65) only becomes presentable once the application-layer
ML-KEM+ML-DSA handshake establishes the ML-DSA identity. A permissive /
classical-compat profile still presents secp256k1 cert schemes, which
SchemeGate.Classify refuses unconditionally — building a gate there would
refuse every peer with no PQ handshake to recover (the 0-peers / 'TLS
upgrade failed' stall). One axis, one predicate: gate + handshake + ML-DSA
identity are built together or not at all.
Publishes the consensus quorum-finality cascade into node:
- consensus v1.25.19 -> v1.25.20 (chain quorum-cert finality, LocalBFTParams)
- crypto v1.19.21 -> v1.19.22 (BLS deserialization/aggregation hardening)
- chains v1.3.17 -> v1.3.18, runtime v1.1.1 -> v1.1.3 (value-path tags)
selectConsensusParams now routes explicitly-local dev networks (devnet 3 /
localnet 1337, EXACT IDs not a range) to consensus.LocalBFTParams (K=4/α=3,
f=1) — the minimal real-BFT committee. Default K=20 is unsatisfiable on a
few localhost validators (α=14 unreachable -> P-Chain freezes at height 0).
K=4 makes quorum reachable while still clearing ValidateForValueNetwork and
the CRITICAL-2 multi-node-is-BFT regression. A custom value L1 (high
networkID) keeps the large Default set. precompile resolves to v0.5.56
(MVS-correct: chains v1.3.18's own requirement; node has no evm/dex dep).
go mod verify: all modules verified; chains quorum params tests green.
Closes the receive-side gaps the b2 build-side stamping (a37f0e1075) left
open. The build-side epoch stamp max(currentH, parentH) is PROPOSER-ONLY;
a follower must independently re-gate every gossiped block. Three fixes,
one per gap, in the transport wrapper pchain_height_vm.go:
HIGH-1 (predicate b — RECENCY, upper bound). ParseBlock now rejects a
framed block whose stamped P-chain epoch H exceeds THIS node's live
P-chain height by more than pChainHeightRecencySlack (256) — an
absurd-future epoch a Byzantine proposer claims for a set the network
has not reached. Rejected fail-closed (errPChainHeightNotRecent): the
block is dropped, never tracked or voted. This is the UPPER half of the
epoch bound; the engine-side monotone gate (consensus 7cabd6faa) is the
LOWER half (>= parent's recorded epoch), so a tracked block's epoch is
pinned to [parentEpoch, localH+slack]. Fail-soft when no P-chain view
exists (nil state -> admit; the verifier still fails closed at
set-resolution) — a defensive path, not a mode.
MEDIUM-3 (heights-map DoS — WATERMARK PRUNE, not blind LRU). ParseBlock
runs before the engine dedup/Verify, so a peer can stream distinct
unverified blocks, each adding a permanent heights entry. Each entry now
carries its value-chain height; Accept advances a finalized-height
watermark and prunes every entry at/below it (a finalized block never
needs a GetBlock epoch re-attach), so the map plateaus under steady
finality. A hard cap (4096) backstops a sustained unverified flood,
evicting HIGHEST-height-first so the near-tip pending band survives — a
still-pending block's epoch is never evicted (a blind LRU could reset it
to 0 = re-freeze).
LOW-2 (frame magic DISCRIMINATOR). The 4-byte magic collides at 2^-32
with the raw hash-prefix some VMs use as Bytes() (dexvm/dchain serialize
parentID[0:32]||...). A magic match alone no longer means "framed": the
inner re-parse of the framed payload must ALSO succeed. On re-parse
failure ParseBlock falls back to a raw whole-block parse — removing the
bootstrap stall a collision used to cause (mis-framed -> inner decode
fails closed -> stall on that chain).
TDD pchain_height_hardening_test.go (all pass, CGO_ENABLED=0):
far-future epoch REJECTED; honest within-slack skew (P-chain advance
during a staking change) ACCEPTED; nil-state admits; magic-colliding raw
parses RAW; genuine frame still parses; heights map plateaus at the
watermark; a pending block is never evicted by the prune; a flood is
capped preserving the near-tip band. The b2 build-side finality proofs
still pass (no regression to delivered-epoch stamping).
THE BUG. A K>1 quorum chain pins its weighted validator set to a P-chain epoch
height (set-root, 2/3-by-stake tally, per-voter pubkey resolution all read at that
one height). The engine reads that height off the VM block via pChainHeightOf,
asserting block.SignedBlock.PChainHeight() — but every plugin VM block (C-Chain
EVM, dexvm) exposes none, so pChainHeightOf returns 0 and the set resolves at
P-chain height 0: the GENESIS set. That is safe (non-empty, identical on every
node, <= current) and unbricks finality, but FREEZES the epoch at genesis: a
validator that JOINED post-genesis is absent from set@0 -> its vote is dropped and
its stake uncounted -> finality cannot track a DYNAMIC validator set, and a
departed genesis majority could collude.
THE FIX (Option b: rpcchainvm zap boundary, NOT a chain-creation-switch rewrite).
pChainHeightVM wraps the chain BlockBuilder so the block the engine sees carries
the proposer's live P-chain epoch height H = max(GetCurrentHeight, parentH),
WITHOUT changing the inner VM's block format, IDs, or ledger state:
- BuildBlock stamps H and frames the gossiped bytes [magic|H|innerBytes];
- ParseBlock splits the frame so every follower ADOPTS the identical H (never
recomputes it from its own skewing P-chain view) -> determinism: every honest
node derives the SAME epoch height from the SAME signed block, so the cert
set-root they recompute matches and a post-genesis validator's vote+stake
count. Raw (unframed) bytes parse with H=0 = the safe genesis fallback.
This is consensus-TRANSPORT framing, not a chain/ledger fork: inner bytes, block
IDs, and execution state are byte-identical -> no re-genesis, only a coordinated
node upgrade. Installed ONLY on K>1 chains (a K==1 chain has no cert/epoch).
Also wires the height-indexed P-Chain validators.State as the SINGLE source of
epoch truth for all four reads (verifier pubkey, stake, total stake, set-root),
all keyed on the block's P-chain height, and FAILS CLOSED if a K>1 chain is built
without a live height-indexed state (a silent permanent-stall wiring bug becomes a
loud refuse-to-start).
TDD (CGO_ENABLED=0, the canonical purego BLS path = ACTUAL production quorum
sources, not an ed25519 stand-in):
- TestPChainHeightVM_DeliversRealHeight: pChainHeightOf(builtBlock)==H and
==H again after a ParseBlock round-trip of the gossiped bytes; a bare inner
block reads 0 (pins why the wrapper is load-bearing).
- TestPChainHeightVM_FinalizesAtGenesis: K>1 finalizes against set@0.
- TestPChainHeightVM_FinalizesAfterStakingChange: validators that JOINED at
epoch 7 cast the deciding 2/3 votes+stake and the block FINALIZES; the cert
verifies stake-weighted at 7 and FAILS at 0; the production verifier rejects a
joiner at height 0 but accepts it at 7. Proven to FAIL without the fix (stamp
0 -> joiners dropped at set@0 -> VM.Accept never runs = permanent stall).
MEDIUM-1 liveness regression: validatorSetRootSource.ValidatorSetRoot
ignored the height argument and hashed the Manager's CURRENT GetMap()
snapshot. During a validator-set change (P-chain / L1 staking), the
current map propagates ASYNC relative to a value-chain block-H vote, so
the signer and the assembler held different current maps -> different
set-roots -> the canonical SIGNED message differed -> signatures FAILED
verification -> votes dropped -> finality stalled at every staking change.
The epoch-binding (set-root in the signed message) made this bite.
FIX: read the HEIGHT-INDEXED set from validators.State.GetValidatorSet(
ctx, height, netID) — deterministic across nodes at a given value-chain
height, independent of async current-map skew. The engine already threads
the block height to ValidatorSetRoot(height) via the sole position builder
blockPositionLocked, so sign-side and verify-side read the SAME
height-pinned set.
The stake source (Weight/TotalStake) is pinned to the SAME height too, so
the tally is measured at the same epoch as the signed membership — a
validator whose vote is in a height-H cert contributes its height-H
weight, closing the second skew (a current-map weight read could drop a
legitimately-signed quorum). validatorSetAtHeight is the single shared
epoch read; hashValidatorSet is the single (byte-unchanged) set-root
encoding.
The vote verifier keeps the current-map pubkey lookup (a separate, milder,
self-healing axis — not MEDIUM-1; disclosed for review).
TDD:
- TestValidatorSetRoot_CrossNodeAgreesDespiteSkew — TWO nodes with a
set-change in flight (divergent current maps) compute the IDENTICAL
set-root at height H (the missing cross-node test).
- TestValidatorSetRoot_HeightSelectsEpoch — root is a deterministic
function of height.
- TestValidatorStakeSource_HeightPinned — tally read at the cert height.
- TestHashValidatorSet_ByteStability — golden, wire format unchanged.
- TestValidatorSetRoot_FailSoftIsUniform — Empty fallback is uniform.
Supply the node side of the consensus epoch-binding fix:
- validatorSetRootSource: a deterministic commitment (SHA-256 over the set
sorted by NodeID, each as nodeID||light||len(pk)||pk) to the chain's active
weighted validator set. Wired via NetworkConfig.ValidatorSetRoot so the engine
stamps it into every vote/cert position — a cert is cryptographically pinned to
the exact set it was certified under, closing cross-epoch cert laundering.
Empty/absent set => ids.Empty (the unbound answer).
- validatorStakeSource: corrected the misleading "height is advisory" comment.
The node Manager is single-epoch (no GetValidatorSet(height); that is on
validators.State), so the source honestly returns CURRENT-epoch weights — which
is exactly the live in-epoch finality answer (a cert is verified in the same
epoch it is created). Cross-epoch soundness is enforced at the witness layer by
the set-root binding above, NOT by guessing unavailable historical stake.
TDD: TestValidatorSetRootSource_DeterministicAndSetSensitive (determinism,
insertion-order independence, weight/membership sensitivity, network scoping,
empty/nil -> Empty) and TestValidatorStakeSource_CurrentEpochWeights.
CRITICAL-2: selectConsensusParams picks a Byzantine-fault-tolerant set for every
sybil-protected (multi-node) net (Mainnet K=21 / Testnet K=11 / Default K=20) —
NEVER LocalParams (K=3/α=2, f=0, single-validator-forkable). Asserted with
ValidateForValueNetwork; chain creation FAILS CLOSED on a non-BFT set.
HIGH-4: networkGossiper implements QuorumGossiper (BroadcastVote/GossipCert over
app-gossip); blockHandler.Gossip demuxes a quorum envelope into the engine's
HandleIncomingVote/HandleIncomingCert (gated on ModeQuorumFinality). The engine
is wired with a BLS VoteVerifier (validator-set pubkey + bls.Verify), a BLS
VoteSigner (staking key), and a validator-stake StakeSource (HIGH-3) for K>1.
Adapters proven against the local consensus engine + real BLS + a real
validators.Manager (standalone module): verifier round-trip/rejections, a real
3-of-4 BLS cert verifies weighted, envelope round-trip, param selection never
K=3 for multi-node. (Full node module compile is blocked on pre-existing,
unrelated sibling go.sum staleness — kms@v1.11.3 / aml consensus@v1.25.17.)
evm v1.99.37 (precompile v0.5.57) wires the 0x9999 ERC-20 Call surface to the
DEX settlement precompile (2cf30e43d) and gates it to the 0x9999/0x9996 settle
family (9579f2e34). Before this a CALL into 0x9999's ERC-20 settle path saw a
nil PrecompileEnv and could not resolve the token-transfer Call seam. v0.5.57
adds the CALL-only DELEGATECALL guard (feeaab5a0). Deps converge to latest
patch within v1.x.x (threshold v1.9.9, crypto v1.19.21, database v1.20.3,
geth v1.17.12, vm v1.2.5, api v1.0.15). Money path (V4 swap ABI, marker
install, dated DexSettleActivationTime fork) byte-unchanged.
Pairs with the baked DEX_REF v1.5.15 (D-Chain committed-state read RPC) for
one coordinated image: native-fill matcher + read RPC + ERC-20 env fix.
Also: harden the lux-accel fetch to authenticate with the ghtok BuildKit
secret (luxcpp/accel is private -> lux-private/accel; unauthenticated 404)
and make it best-effort (matches the cevm/lpm contract) since the GPU lib is
linked only at CGO_ENABLED=1 and the canonical build is CGO_ENABLED=0 pure-Go.
Image: ghcr.io/luxfi/node:v1.30.40 (patch from v1.30.39).
v1.5.15 adds the D-Chain read surface (clob_get_trades/orders/markets/book over
/ext/bc/D/dex/<method>, pkg/dchain/read.go): read-only JSON of the committed
trade log, resting book, and markets, served beside the write methods via
VM.CreateHandlers with zero consensus impact.
Needed to (1) VERIFY a native fill replicated identically across the validator
set — query clob_get_trades on every node and diff the trade rows + accepted
head root — and (2) feed markets-display, since native fills are D-Chain trade:
rows (not C-Chain 0x9999 DEXFills).
Plugin VM id unchanged (mDVT5EWMumBp3LCqvKwuyZQeY1VXr1jvjGNAt8nL4UFiXvqXr); the
change is additive read endpoints, no consensus/state-transition change.
dex v1.5.14 consumes luxfi/database v1.20.4, which fixes prefixdb
NewIteratorWithStartAndPrefix synthesizing a pre-prefix start for a nil-start
prefix scan -> ZERO rows over a prefixdb-wrapped chain DB. This stranded the
native D-Chain: rebuildBookFromDB iterated order:<pool> alongside other
sub-prefix rows, folded an EMPTY book, and every taker cross produced 0 fills
despite durably-committed asks. Only the dexvm slot is rebuilt this run (devnet
D-Chain scope); the same database fix likely benefits the other plugin VMs and
is a separate follow-on bump.
dex v1.5.13 indexes processing blocks so the plugin transport's ID-only Accept
(GetBlock(builtID)) resolves the just-built block. Without it the native
D-Chain's self-finalize Accept is a silent no-op, the clob submitTx waiter hangs,
and NO D-Chain blocks are produced — orders submitted to /ext/bc/D/dex/clob_*
never match. Required for native trading to actually produce fills.
dex v1.5.12 persists the head block so the native D-Chain VM survives a restart
once advanced past genesis — without it the first validator to restart fails VM
init ('get last accepted block: not found') and the D-Chain goes down. Required
for a 5-validator rolling restart of the native matcher.
dex v1.5.11 wires CLOB order ingestion over the node HTTP router
(pkg/dchain VM.CreateHandlers -> /ext/bc/D/dex/<method>). An order POSTed to
/ext/bc/D/dex/clob_submit flows submitTx -> mempool -> consensus -> BuildBlock
-> Verify(match) -> Accept; the chain is the matcher, no venue, no keeper.
Plugin stage rebuilds (ARG change invalidates the dexvm slot cache); node
go.mod is unaffected (the plugin is built from dex's own module, -mod=mod).
The D-Chain runs as a PluginDir plugin loaded by luxd at the dexvm vmID
(mDVT5EWMumBp3LCqvKwuyZQeY1VXr1jvjGNAt8nL4UFiXvqXr). Until now that slot was
built from chains/dexvm/cmd/plugin — the STATELESS PROXY that relayed clob_*
frames over ZAP to a standalone dchain-venue (DexZapEndpoint). Matching did
NOT happen in luxd consensus; it happened in the external venue's single-node
sealer.
Build the dexvm slot from github.com/luxfi/dex@v1.5.10 ./cmd/dchain instead:
the NATIVE VM (pkg/dchain, block.ChainVM) that runs the lx.OrderBook matcher
INSIDE luxd consensus — BuildBlock drains the mempool, Block.Verify matches
against a versiondb overlay, Block.Accept commits. The trade IS the D-Chain
state transition, sequenced by luxd's multi-validator engine. No
DexZapEndpoint, no standalone venue in the trading path.
cmd/dchain wraps the VM in the same rpc.Serve plugin harness luxfi/evm uses
and is pure-Go (CGO=0); same GOFLAGS/go.sum-heal pattern as CHAINS_REF. The
other 10 chains VMs still build from chains. New ARG DEX_REF=v1.5.10; a FATAL
guard fails the build if the native D-Chain plugin is missing. Verified: a
fresh v1.5.10 clone builds ./cmd/dchain CGO=0 -mod=mod in Docker-like
isolation; native VM suite (TestLocalnetVenueE2E/TestFourPath/conservation)
passes.
The CI Docker build failed reading hanzoai/vfs@v0.4.1's go.mod via the public
sum.golang.org (404 — it's a cross-org module not registered there), same class
as luxfi/*. Added github.com/hanzoai/* to GONOSUMCHECK/GONOSUMDB/GONOPROXY.
Verified: clean 'go mod download hanzoai/vfs@v0.4.1' 404s without the exclusion,
succeeds with it. Unblocks ghcr.io/luxfi/node image builds (v1.30.30/31 failed).
The dexvm plugin gains the C<->D keeper RPC seam: dex.submitTx (mempool entry for
ImportTx + settling RelayOrderTx) and dex.getSettlement (D->C proceeds coordinate
for Phase-B). Bumps go.mod luxfi/chains v1.3.15->v1.3.16 AND Dockerfile CHAINS_REF
v1.3.14->v1.3.16 so the bundled dexvm plugin is rebuilt with the new RPC. go mod
verify clean; dexvm plugin builds from the v1.3.16 tag (CI mode).
The routing + insteadOf fixes got goreleaser onto lux-build with git auth,
but it still failed: 'could not read Password ... exit 128' fetching
luxfi/{container,crypto,database,proto}. github.token is repo-scoped and
cannot read OTHER private luxfi repos. Switch to the same cross-org PAT
docker.yml uses (GH_TOKEN/UNIVERSE_PAT) so cross-repo module fetches
authenticate. node already carries UNIVERSE_PAT as a repo secret.
goreleaser shells out to go build, which fetches private luxfi modules
(container, crypto, proto, ...). setup-go-for-project sets GOPRIVATE but
only wires git auth when passed a github-token (build.yml passes none), so
the fetch hit 'could not read Username for https://github.com' and the job
failed even on lux-build. Add the same explicit 'Configure Git for private
modules' step ci.yml uses (git config url.insteadOf with github.token).
This is the real root cause of the 'Build on supported platforms' red-X;
the routing-to-lux-build commit was necessary but not sufficient.
The v1.30.28 docker.yml run published node:v1.30.28 (sha-fbc6afd) fine on
the in-cluster lux-build ARC pool, but two sibling workflows red-X'd:
- build.yml 'goreleaser' (runs on every push)
- release.yml 'validate-version' (cascaded skips to every platform build)
Root cause: both pinned runs-on: ubuntu-latest. This org disables
GitHub-hosted runners (NO GITHUB BUILDERS) — ubuntu-latest jobs never get a
runner and fail at provisioning, not at compile. Source is sound:
GOWORK=off CGO_ENABLED=0 go build ./... is clean and the cross-layer
dexsettle_guard test passes (extras.DexSettleActivationTime ==
dex.DexSettleActivationTime == 1766704800 = 2025-12-25T23:20:00Z).
Route goreleaser, validate-version, and create-release to lux-build (the
org-scoped autoscalingrunnerset in lux-k8s that already builds the image).
GoReleaser cross-compiles every GOOS/GOARCH from one linux/amd64 host with
CGO disabled, so a single amd64 runner suffices.
(The per-platform binary reusables build-{ubuntu,linux,macos,win}-* still
pin classic [self-hosted,linux,amd64]/windows-2022 labels — a pre-existing
routing issue tracked separately; the node *image* path is unaffected.)
EVM_VERSION v1.99.33 -> v1.99.34 (precompile v0.5.53 -> v0.5.54). v1.99.34 fixes
the ONE HIGH from Red's review of the 0x9999 dated-fork activation that blocked
the production deploy: the EVM dispatch gate read a process-global timestamp
(last-writer-wins across concurrent goroutines), so on the relaunch path
(admin.importChain of a pre-fork RLP snapshot on a live, RPC-serving post-fork
node) a concurrent post-fork eth_call could make a pre-fork block see 0x9999
ENABLED and dispatch settlement during plain-account execution -> state
divergence. The gate now reads the overrider's own per-EVM (chainConfig,
timestamp). Also: SubBalance fallback fails closed (no silent native mint) and
the genesis-config builders skip AlwaysOn modules (0x9999 can't get a
timestamp-0 genesis config that bypasses the dated fork). Money path
byte-for-byte unchanged. This unblocks the production deploy.
Bundle the C-Chain EVM plugin built from luxfi/evm v1.99.33 (precompile v0.5.53):
0x9999 DEX settlement now activates at a SINGLE canonical dated fork
(extras.DexSettleActivationTime = 1766704800, Dec 25 2025) instead of the v1.99.32
unconditional always-on. At the fork it BOTH enables dispatch AND installs the
EXTCODESIZE marker forward (never in historical genesis), so:
- eth_getCode(0x9999) != 0x and typed Solidity IPoolManager(0x9999).swap(...)
passes the contract-existence guard from the activation block onward;
- pre-Dec-25 history replays byte-identically (the ~/work/lux/state RLP snapshot
via admin.importChain) — a pre-fork value transfer to 0x9999 hits a PLAIN
account, not the precompile, so canonical pre-activation state is preserved;
- the C-Chain genesis hash is unchanged (no genesis-time marker).
0x9010 is REMOVED entirely (not a registered precompile, no dispatch, no forward);
0x9999 is the SOLE canonical DEX precompile. Runtime DChainID via the "D" alias and
the built-in DAO-treasury protocolFeeController are unchanged.
deps: indirect precompile v0.5.52 -> v0.5.53 (go.sum tidied: stale v0.5.52 hashes
dropped; v0.5.53 hash matches the evm/precompile repos byte-for-byte). node main
builds clean GOWORK=off; go mod verify OK; go mod tidy is a no-op on go.mod.
Bump the bundled C-Chain EVM plugin to v1.99.32 (precompile v0.5.52): the native
0x9999 DEX settlement money path is now ALWAYS-ON. It is active on the C-Chain from
genesis with ZERO per-net config — no dexSettleConfig genesis/upgrade entry anywhere.
Booting luxd = 0x9999 live on the C-Chain, on every Lux network.
Activation is dispatch-only (no genesis state write → genesis hash unchanged → no
fork of any existing network). The D-Chain (dexvm) peer the atomic seam routes to is
resolved at RUNTIME from the consensus-context "D" alias the node already registers in
initChainAliases (chains/manager.go BCLookup), via contract.AtomicState.DChainID().
The protocolFeeController is the built-in DAO treasury. Nothing per-net to configure.
Dockerfile: ARG EVM_VERSION v1.99.31 -> v1.99.32 (the plugin is built from this tag).
go.mod/go.sum: indirect luxfi/precompile v0.5.51 -> v0.5.52 (keeps node's transitive
graph in lockstep with the plugin; node main builds clean GOWORK=off, go mod verify OK).
The bundled C-Chain EVM + 11 VM plugins were pinned at stale defaults
(EVM_VERSION=v0.19.4, CHAINS_REF=v1.3.11) decoupled from node's go.mod, so every
node image shipped the OLD DEX (no native 0x9999) even after the cascade bumped
node->chains v1.3.14. Pin both to the native-atomic seam + document the coupling.
No node code change vs v1.30.23.
zeekay