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 == 44b67b99a0 (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 (4c7bab464c) 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-c36527c) 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.
Bump to the clean-go.sum re-cascade so node, plugins, and all upstream modules
build identically in clean CI. No node code change vs v1.30.21. go mod verify
clean; full build green.
v1.30.20's go.sum carried stale consensus@v1.25.18 + geth@v1.17.11 hashes that a
locally-polluted module cache (modified extracted dirs) had produced — the in-CI
docker `go mod download` rejected them (checksum mismatch). Purged the modcache,
re-fetched fresh, and `go mod verify` is clean ("all modules verified"). No
go.mod/dep change vs v1.30.20; the node binary is identical. This is the first
buildable tag of this node code.
The evo classic self-hosted runner is offline and GitHub-hosted runners are
billing-blocked (and disallowed by the NO-GITHUB-BUILDERS policy). Point the
image build at the lux-build autoscalingrunnerset (lux-k8s, amd64 DOKS, DinD)
— it serves the whole luxfi org and matches on the scale-set name. No node
binary/dep change vs v1.30.19; this is a build-infra patch.
Append aivm(A)/graphvm(G)/keyvm(K) to genesis chainEntries after Z so the
existing X->C->D->B->T->Q->Z blockchain IDs are preserved; A/G/K take fresh
tail IDs. They carry a/g/kChainGenesis blobs and are deterministic genesis
chains per the no-CreateChainTx model (prior code deferred them to
post-genesis CreateChainTx). I/O/R have no blob and stay plugin-loaded.
ROOT FIX (B-Chain): chains v1.3.11 bridgevm/mpc.go blank-imports
github.com/luxfi/crypto/threshold/bls so the bls init() registers the BLS
threshold scheme, fixing the B-Chain VM init regression
(threshold.GetScheme(SchemeBLS): 'scheme not registered') that aborted the
v1.30.16 devnet roll. Verified bls init/RegisterScheme symbols + itab linked
into the bridgevm plugin binary.
go.mod: pin chains v1.3.10 -> v1.3.11 (no other version moves; MVS keeps
crypto v1.19.21, geth v1.17.11, consensus v1.25.18).
go.sum: re-record current content hashes for re-published luxfi modules
(geth/precompile/etc) at EXISTING pinned versions — integrity repair, no
version bump. Fixes clean-room 'go mod download' checksum drift.
Dockerfile plugin builds (embedded plugins ARE authoritative — devnet
startup does cp /luxd/build/plugins/* then --plugin-dir):
- EVM/C-Chain: EVM_VERSION v0.19.3 -> v0.19.4; heal dead upgrade
pseudo-version to released v1.0.1; recursive go.sum strip.
- chains VMs: CHAINS_REF default -> v1.3.11; recursive go.sum strip;
bridgevm build made FATAL (was best-effort) + presence assertion so the
image cannot ship without a working B-Chain plugin.
All 11 chains VM plugins + evm plugin verified to build (golang:1.26.4,
linux/amd64). lux-devnet only; testnet/mainnet stay v1.30.3.
Pick up the rpc.Serve plugin harness now opening chainstate via zapdb.New
(single-backend rule) instead of badgerdb.New — same on-disk format, drop-in.
Transitive api v1.0.14→v1.0.15 (within v1, no major bump). chains stays
v1.3.9. Verified: public 'go build ./node/' green; '-tags dchain' green;
public-purity 'go list -deps ./node/' has ZERO chains/dexvm|luxfi/dex; the
-tags dchain build DOES link the dexvm proxy (orthogonality holds).
Production node -tags dchain now links the released chains v1.3.8 (stateless atomic ZAP proxy +
the #9 consensus-fork fix), not the stale v1.3.6. Public build stays pure (zero dex/dchain/gpu
deps); dchain build links the 6 chains/dexvm proxy pkgs. Transitive: oracle v0.1.1->v1.0.0,
relay ->v1.0.0 (chains v1.3.8 requirements; first-stable, within v1).
zeekay