HIGH-3 host side. The always-on 0x9999 settlement precompile resolves its halt +
pot-seeding authority from contract.AtomicState.GovernanceController(); this is the
production wiring that supplies it — a per-network governance CONTRACT, never a
hardcoded mnemonic-derivable EOA.
- dex_value_wiring.go (installDEXValuePath): bind rt.GovernanceController =
dexGovernanceFor(networkID) onto the chain runtime at boot (the ONE production
site), alongside the asset resolver + native D client, and log it. dexGovernanceFor
is the genesis-set per-network governance-contract seam: it returns ids.ShortEmpty
for every network TODAY (no Governor/Timelock is deployed at a known address on any
Lux network yet), so every network runs FAIL-CLOSED (no halt authority — provably no
single key can DoS the DEX) until its real governance CONTRACT address is wired in,
per net. The directive is explicit: each entry MUST be a governance contract, NEVER a
dev-mnemonic EOA, and NEVER the retired 0x9011…94714. The boot log makes an unset
authority loud ("<unset: halt/seed FAIL-CLOSED — deploy + wire a governance contract>").
- core/precompile_overrider.go + precompile/registry/bridge.go: accessibleStateAdapter
and accessibleStateBridge implement GovernanceController() (ids.ShortID→common.Address,
exact 20-byte conversion); the internal twin interface gains the method. Returns the
zero address (fail-closed) when the runtime/atomic capability is absent.
- precompile/contract/atomic.go (evm-internal twin): AtomicState gains GovernanceController().
Builds clean (CGO off) across plugin/evm, core, precompile/registry; the dexsettle_guard
parity test passes. Normal trading is unaffected (halt switches are emergency controls,
off by default); only the ability to halt is gated — which previously only a mnemonic-EOA
holder had (a vuln), so no legitimate capability is lost and a censorship/DoS vector is removed.
Wire the EVM side of the always-on DEX settlement money path 0x9999. It is ACTIVE
on every chain from genesis with NO config entry — neither a genesis-inlined
precompile nor a precompileUpgrades timestamp. Zero per-net config, one way.
Activation is DISPATCH-only (genesis state is consensus-critical and immutable):
- params.GetExtrasRules injects every modules.AlwaysOnModules() entry into the
enabled precompile set unconditionally (every chain, every timestamp). This is
what PrecompileOverride.IsPrecompileEnabled consults, so 0x9999 runs for a
tx-to-0x9999, a low-level CALL/STATICCALL, and the 0x9010 V4 forward.
- ApplyPrecompileActivations writes NO genesis state for always-on modules. An
EXTCODESIZE marker at genesis would change the genesis hash and FORK existing
networks (a fresh-syncing node would disagree with the committed genesis). The
real lux-mainnet genesis hash is preserved (TestSkipPostMergeFieldsGenesisHash).
- The always-on module's Configurator is never invoked (no activating config).
DChainID runtime resolution (THE crux): contract.AtomicState gains DChainID(); the
EVM adapter (accessibleStateAdapter) resolves it from the consensus context via
runtime.GetBCLookup().Lookup("D") — the dexvm "D"/"dex"/"dexvm" alias the node
registers in initChainAliases before any chain bootstraps. Identical on every
validator and re-execution; ids.Empty on a network with no dexvm (seam stays closed,
fail-secure). The registry bridge forwards DChainID across the internal/external
AtomicState surfaces. modules.Module gains AlwaysOn (+ AlwaysOnModules()), bridged
from github.com/luxfi/precompile.
deps: precompile v0.5.51 -> v0.5.52 (DChainID + AlwaysOn + always-on settle module).
Tests: core suite green incl. the real-mainnet genesis-hash guards. New
core/precompile_alwayson_test.go: 0x9999 registers AlwaysOn, is dispatch-enabled with
NO config at genesis + far-future ts, and writes NO genesis state (genesis-hash
immutability). (Two pre-existing unrelated failures: params/config_test.go references
a removed DurangoTimestamp field; mainnet upgrade.json aiMining/warp timestamp guards
— both fail identically on pristine main.)
The host side of the 0x9999 native C<->D atomic seam, and the consensus-liveness
fix Red found.
THE BUG: Block.Accept applied the staged atomic ops to shared memory FIRST
(sm.Apply, no batch -> committed immediately) and advanced the node-local seq
marker LATER, in a separate versiondb.Commit(). atomic.SharedMemory.Apply is NOT
idempotent (duplicate Put errors). A crash BETWEEN them left shared memory
mutated but the marker unadvanced; on restart the same parent->current window
re-collected, sm.Apply re-applied the present Put, errored, and Accept returned
fatal -> the chain HALTED.
THE FIX (mirrors chains/dexvm commitAtomic): flushDexAtomic -> stageDexAtomic
stages the advanced dexAtomicSeqKey marker INTO the versiondb in-memory layer and
returns (reqs, sm). Block.Accept snapshots the versiondb (marker + lastAccepted)
via CommitBatch() and passes it to sm.Apply(reqs, batch) — its WriteAll commits
the shared-memory mutation AND the batch in ONE database write. The marker advance
and the SM mutation are now all-or-nothing: a crash applies-and-marks both or
neither, and a re-accept of an applied window sees an advanced marker -> empty
window -> no duplicate Put -> no halt. With no atomic ops the plain
versiondb.Commit() path is unchanged.
Also: core/precompile_overrider.go wires CallIndex() through the EVM accessible-
state adapter; precompile/registry/bridge.go + precompile/contract/atomic.go
forward the optional contract.AtomicState capability to luxfi/precompile.
Regression for the closed halt window lives in precompile
native_haltwindow_test.go (unit). The live-path test (real versiondb + crash
injection) is CI-only (CGO + luxfi/accel LUXCPP). Local symbol-resolution proof:
CGO_ENABLED=0 go build ./plugin/evm/ compiles clean.
Updates dependencies:
- github.com/luxfi/vm v1.0.22 → v1.0.23 (adds ZAP transport Serve)
- github.com/luxfi/log v1.3.0 → v1.4.1 (fixes module path declaration)
- github.com/luxfi/consensus v1.22.53 → v1.22.56
- github.com/luxfi/crypto v1.17.39 → v1.17.40
- github.com/luxfi/database v1.17.38 → v1.17.39
- github.com/luxfi/geth v1.16.69 → v1.16.73
- github.com/luxfi/p2p v1.18.7 → v1.18.8
- github.com/luxfi/warp v1.18.4 → v1.18.5
The vm package now provides a ZAP-based Serve function by default,
eliminating the need for the grpc build tag for VM plugins.
Also includes various improvements to validators, warp service,
and precompile interfaces.
- Change Go version from 1.24.6 to 1.22.8 (stable version)
- Ensure all build scripts have executable permissions
- Fix covdata issue by using stable Go version
- CI should now pass all checks
- Updated auth and bind interfaces for improved transaction handling
- Enhanced network configuration and database wrappers
- Improved validator state management and uptime tracking
- Updated sync client and gossip test implementations
- Fixed mock interfaces and handler implementations
- Updated dependencies in go.mod/go.sum
- Updated go:generate comments to use luxfi/geth instead of ethereum/go-ethereum
- Fixed GitHub issue/PR references to point to luxfi repositories
- Updated comments referencing the Lux geth fork
- Part of the migration to unified EVM architecture with Lux consensus
- Update imports from luxdefi/node to luxfi/node
- Replace libevm interfaces with direct go-ethereum imports
- Add placeholder interface files for missing dependencies
- Update go.mod to use local luxfi/node path
- Fix merge conflicts in multiple files
- Create stub implementations for missing packages
This allows the project structure to align with v0.7.5 requirements
but the build still needs additional work to be fully functional.
Updated all copyright headers from "Lux Partners Limited" to "Lux Industries Inc" and updated the year to 2025 to reflect the new holding company structure.
- Localized mockgen commands in the package where they are needed
- Generate mocks from your IDE directly
- Platform independent way of generating mocks
- Check automatically mocks are kept up to date with their matching interfaces
- Check automatically mocks all have a matching source controlled generation command
- Remove license headers for generated mocks
- Generating mocks section added in contributing document
- Use same mockgen version as specified in go.mod
zeekay
