registry

const SettleOnlyActivationTimestamp uint64 = 1766704800 // 2025-12-25T23:20:00Z — see TODO above for the mainnet forward re-gate

SettleOnlyActivationTimestamp is the SINGLE Lux-protocol timestamp that gates the AlwaysOn DEX system precompile (0x9999). It is the analog of a fork timestamp — NOT per-network JSON config — so it applies uniformly with no genesisPrecompiles / precompileUpgrades entry. It couples TWO effects that are one event and must never disagree:

1. PRESENCE — the EXTCODESIZE marker is installed and Run dispatches only at timestamps >= this value (before it, 0x9999 is a plain account). This is also the genesis-injection gate: a chain genesised BEFORE it carries no 0x9999 in block-0 state, keeping the byte-identical genesis hash of every pre-2025 chain (Lux mainnet/testnet and Zoo mainnet block-0 are all Nov 2024); a chain genesised at/after it gets the 0x9999 marker in its genesis state.
2. BEHAVIOR — since luxfi/precompile v0.19.x (the settle-only decomplect that REMOVED the embedded in-block matcher op), whenever 0x9999 is present it behaves settle-only: a swap settles ONLY by consuming a D-committed atomic object; the old matcher entrypoints revert. Present ≡ settle-only in this build, so this one timestamp is BOTH the presence gate and the settle-only gate.

FLEET-SAFETY — WHY THIS MUST BE A FORWARD (near-future) TIMESTAMP, NEVER A PAST ONE: on boot a node re-processes its uncommitted block window. If this gate is in the PAST, that window contains blocks the OLD matcher build already produced with 0x9999 live-as-matcher; the settle-only build re-executes them, reverts the matcher calls (different gasUsed) → state-root divergence → "invalid gas used" → every node dies identically. A past gate cannot distinguish already-produced matcher blocks from new ones. A near-future gate replays all existing history under the SAME (pre-gate) semantics it was produced under, and applies settle-only only to NEW blocks at/after the gate.

TODO(coordinator) — set this to a NEAR-FUTURE timestamp before cutting the release. It is intentionally left at the ORIGINAL past value below so this prepared change is a pure no-op rename; DO NOT ship it unchanged. Moving it is this ONE line. Constraint:

• MUST be strictly greater than the timestamp of the last already-accepted block in the target chain's canonical history, so no already-produced block changes gasUsed on replay (and after the intended upgrade-rollout window).
• FRESH DEVNET (no matcher history): any near-future value works — small margin over genesis is fine.
• MAINNET / any chain with real history: read the last accepted block time and set the gate safely after it. The value DIFFERS per environment; it is an owner/coordinator decision, not a source default. Do not guess it here.

DEVNET-PROOF (coordinator call 2026-07-05): a FRESH net genesis'd NOW (July 2026, Unix ~1.783e9) is already AFTER this Dec-25-2025 gate, so 0x9999 settle-only is active FROM GENESIS on it — no value change needed, and the mainnet/testnet/zoo reproduce-tests (which require the gate to sit ABOVE those chains' existing 0x9999 matcher history) stay green. The fresh devnet's genesis timestamp MUST be >= this value (it will be — see deploy). MAINNET re-gate to a near-future forward value is the separate owner call in the TODO above.