AGENTS.md Implementation Journal (archived)

Archived 2026-05-17. This is the verbatim ## Current Phase journal that previously occupied the bulk of the root AGENTS.md. It was extracted so AGENTS.md stays operational — actionable rules plus a short current summary — rather than long-form documentation, which is the project’s own style rule.

Not authoritative for the current code state. It is preserved as historical evidence: the round-by-round narrative of the development arc (roughly R104 → R503). Older “open follow-up” wording in the dated entries is intentionally preserved verbatim and is in many places superseded by later rounds. For what is currently true, see:

Path references below predate the node/ → crates/node/ reorganisation and are deliberately left uncorrected — this is a frozen historical record.

  • Yggdrasil 1.0 closure: every confirmed-active code-level parity slice from the 2026-Q2 audit (docs/archive/AUDIT_VERIFICATION_2026Q2.md) is closed, including the runtime integrations originally tracked as follow-ups (multi-session BlockFetch via per-peer FetchWorkerPool, ChainSync observe_header(slot) density hook, HotPeerScheduling-driven mux egress weights), R238 Phase D.1 rollback sidecar hardening, and R239 cardano-base fixture refresh. R240 adds node/scripts/parallel_blockfetch_soak.sh so the remaining §6.5 multi-peer BlockFetch sign-off is a reproducible operator gate instead of manually assembled evidence; R241/R242 add short preprod/harness evidence; R243 refreshes the cardano-ledger documentary pin after upstream PR #5787’s import-only change; R244 closes Byron genesis-hash verification by mirroring upstream parseCanonicalJSON/renderCanonicalJSON hashing so startup preflight verifies all four preset genesis hashes; R245 refreshes cardano-ledger again and mirrors the Conway BBODY HeaderProtVerTooHigh testnet grace until Dijkstra while confirming local GOV hard-fork sequencing already uses accumulated proposals; R246 closes the observed preview Plutus replay blockers by matching upstream raw PlutusBinary handling, reference-input ordering, CEK memory accounting, protocol-aware validity intervals, arbitrary-precision Plutus Integer arithmetic, Plutus serialiseData CBOR shape, and legacy registration-certificate redeemer/witness collection through refscan slot 901725. R246 also fixes runtime resume so boundary-aware recovered StakeSnapshots and current-epoch pool block counts are preserved; existing temp preview checkpoints written before that fix can still stop at slot 1038978 with stale reward state and need clean/repaired replay for final evidence past that point. R247 fixes the verified-sync Origin BlockFetch prefix window so clean preview replay stores the initial Byron slots (including 0, 60, 300, and 320) and advances to slot 101100 instead of stopping on a missing UTxO lineage. The authoritative nonce/OpCert durable state is now the slot-indexed ChainDepState bundle under chain_dep_state/<slot-hex>.cbor; startup/reconnect and rollback use restore-and-replay from that history, LSQ uses exact acquired-point sidecars, and persistent non-origin rollback fails closed if the bundle history is missing. R249 (2026-05-05) refreshes 5 documentary pins (cardano-ledger, ouroboros-consensus, ouroboros-network, plutus, cardano-node) to live HEAD after a per-repo audit confirms the upstream changes are forward-looking only (Peras voting committees, Dijkstra MemoBytes BlockBody, post-Conway plutus universe additions and cost models D/E, StAnnTx Haskell-internal threading, internal submitTxToMempool API, cardano-testnet CLI restructure) — no active-era CBOR codec, validation rule, transition-system semantic, or wire-protocol change. R249 also lifts the local_server::tests ENV_LOCK to module scope so the floor-promotion test cannot leak YGG_LSQ_ERA_FLOOR into the parallel PV→era_index table-pinning test. All 6 documentary upstream pins are in sync with live HEAD; drift detector reports drifted=0. cargo fmt --all -- --check, focused R246/R247 tests, cargo build -p yggdrasil-node --release, cargo check-all, cargo test-all, and cargo lint pass after the latest patches. The remaining production-readiness gates are operator-side: the §6.5 parallel-fetch rehearsal, the §2–9 mainnet endurance run in docs/MANUAL_TEST_RUNBOOK.md, and clean/repaired preview replay past the stale-checkpoint reward stop. Default max_concurrent_block_fetch_peers = 1 keeps the legacy single-peer path active until §6.5 sign-off. R273-rename + R274–R308 (closed 2026-05-09) — strict 1:1 file-mirror & tech-debt arc. Refreshed the vendored upstream tree to policy tag 11.0.1; landed a strict 1:1 file-mirror CI drift-guard (scripts/check-strict-mirror.py, warn-only at R275 → fail-build at R288) so every production .rs either mirrors a single canonical upstream .hs file by snake_case basename or carries an explicit ## Naming parity docstring stanza ending in **Strict mirror:** none. plus the upstream symbol(s)/file(s) the helper surfaces. Per-file allowlist in docs/strict-mirror-audit.tsv (230 (a) DIRECT_MIRROR + 215 (c) NO_MIRROR_NEEDS_DOCSTRING = 445 graded files; zero (b) rename-needed; zero (d) clash-regrade). All production #[allow(dead_code)] sites + the lone production TODO resolved. New crates/cardano-cli/ workspace member (R289–R295) mirrors the full upstream Cardano.CLI.* surface (~237 Rust files mirroring 180 upstream .hs); concrete migration kicked off via R296 (Version) + R297 (ShowUpstreamConfig) with byte-equivalent output verified against .reference-haskell-cardano-node/install/bin/cardano-cli. docs/ trimmed from 23 → 11 top-level markdown files (5 archived under docs/archive/). Two new validators (scripts/check-fixture-manifest.py + scripts/check-reference-artifacts.py) joined the parity-flow surface at R303. R308 backfilled scripts/AGENTS.md and refreshed docs/PARITY_PROOF.md header. R310 fixed an over-broad .gitignore pattern that had silently swallowed 12 R294-era cardano-cli files; R311 hardened check-strict-mirror.py with an index-vs-tree drift check so the same failure class can no longer surface as an opaque CI module-resolution error. R313–R320 docstring-classification cleanup (2026-05-09): R313 census surfaced 41 misclassified (c) docstring present (unspecified) files; R314 promoted 24 to canonical **Strict mirror:** <upstream/path.hs> declarations; R315–R316 reclassified 11 to canonical synthesis form after content-vs-name audit; R317 merged multiplexer.rs into mux.rs as a 1:1 mirror of Mux.hs; R318 split handshake.rs into handshake/{type,version,codec}.rs matching upstream; R319 split inbound_governor.rs to mirror upstream InboundGovernor.hs + InboundGovernor/State.hs; R320 promoted the last 2 plutus partials (builtins.rs, machine.rs) to direct mirrors with sibling-file rationale. Audit state through R321: 262 (a) DIRECT_MIRROR + 186 (c) strict-none = 448 graded files; zero (c) strict-partial (peaked at 17, now empty). R322 + R323 + R324 follow-up cleanup: R322 backfilled CHANGELOG.md with R303-R321 entries. R323 eliminated the (a) auto sub-bucket (25 files): hand-audited each, 17 promoted to canonical strict-mirror with explicit upstream-path declarations, 8 reclassified to synthesis (basename-match was misleading). R324 eliminated the (a) auto (affinity-filtered) sub-bucket (18 files): 10 promoted, 8 reclassified to synthesis (kes.rs aggregator, cbor.rs workspace-helper, node-binary integration files). Audit state (post-R324): 246 (a) DIRECT_MIRROR + 202 (c) strict-none = 448 graded files; every production .rs carries an explicit declaration. Five gates clean throughout the arc; R325 test baseline 4,856 passing, 0 failing. R326–R336 sister-tools port arc Phase A skeleton milestone (closed 2026-05-09): 12 new sister-tool crates created (bech32, cardano-submit-api, cardano-testnet, cardano-tracer, db-analyser, db-synthesizer, db-truncater, dmq-node, kes-agent, kes-agent-control, snapshot-converter, tx-generator), each producing a deployable Rust binary with byte-equivalent –help/–version output captured from upstream. R331-R334 closed Phase A.1: bech32 reaches verified_11_0_1 with full encode/decode dispatch (drop-in byte-equivalent to upstream IntersectMBO/bech32 1.1.10 for all documented examples). 11 others currently partial pending per-tool implementation rounds (kes-agent R345+, cardano-tracer R361+, db-truncater R387+, etc. per the R326-R459 plan). Workspace metrics post-R336: 20 crates (was 8), 472 graded audit files (was 448), 9 upstream-pin SHAs (was 6), 4,982 tests passing (+126). R337–R497 sister-tool implementation arc (closed 2026-05-11): R338–R345 cardano-submit-api Phase A.2; R347–R350 db-truncater Phase B.1; R351–R359 typed-config sweep + R361–R367 typed-parser sweep (14 rounds, 7 tools at full argv→typed-config→run-dispatch); R369–R376 deeper-layer sub-arc (BenchmarkLedgerOps trio + HasAnalysis trait + per-tool extensions); R378–R394 cardano-tracer subsystem build-out (Time, Notifications, Logs/Journal, Handlers/System, Notifications/{Timer,Email,Send,Utils,Settings}, Logs/Utils, Metrics/Utils, Environment.hs TracerEnv 14-field record, Logs/Rotator); R395–R474 cardano-tracer DataPoint sub-protocol arc closure (R459–R460 mux integration, R461–R467 Logs/Rotator IO + trace-forwarder sink wiring, R468 TLS, R469–R470 DataPointRequestors registry, R471–R474 Protocol/DataPoint/{Forwarder,Acceptor} port + end-to-end integration test); R475–R497 db-analyser HasAnalysis arc closure (R475–R481 dispatch core + EBB registry + 7 handlers, R482 ImmutableStore::iter_after, R485 CheckNoThunksEvery permanent carve-out, R486 event-shape enrichment, R488–R497 the remaining 6 handlers TraceLedgerProcessing/BenchmarkLedgerOps/GetBlockApplicationMetrics/StoreLedgerStateAt/ReproMempoolAndForge closing 13/13 dispatch coverage, R494–R497 per-era Tx forensic-fidelity helpers including to_raw_tx_bytes closing the last MempoolEntry placeholder — 8/8 fields real). Five gates clean throughout the arc.
  • The long round-by-round notes below are historical evidence. Older “open follow-up” wording is intentionally preserved in those dated entries; the current closure state is the paragraph above plus docs/PARITY_SUMMARY.md, docs/PARITY_PROOF.md, and docs/UPSTREAM_PARITY.md.
  • crates/network now includes handshake + mux + peer lifecycle, all five mini-protocol state machines/wire codecs (ChainSync, BlockFetch, KeepAlive, TxSubmission, PeerSharing), typed client drivers, typed server (responder) drivers for all four data mini-protocols (KeepAliveServer, BlockFetchServer, ChainSyncServer, TxSubmissionServer) plus PeerSharingServer, and SDU segmentation/reassembly support for large protocol messages. PeerSharing protocol (mini-protocol 10): PeerSharingState state machine, PeerSharingMessage (MsgShareRequest/MsgSharePeers/MsgDone), SharedPeerAddress IPv4/IPv6 CBOR codec, client driver PeerSharingClient, server driver PeerSharingServer. Root-set provider layer is expanded with DNS-backed root-peer provider (re-resolves local-root, bootstrap, public-root access points with optional DnsRefreshPolicy TTL clamping 60s/900s and exponential backoff). Peer registry tracks PeerSource and PeerStatus per peer, reconciles root-provider snapshots plus ledger, big-ledger, and peer-share source sets while preserving unrelated sources and peer status. Ledger peer provider layer is complete: LedgerPeerProvider trait, LedgerPeerSnapshot normalization (deduplicates and enforces disjoint ledger/big-ledger sets), LedgerPeerProviderRefresh (combined/per-kind), apply_ledger_peer_refresh() helper, refresh_ledger_peer_registry() orchestration, and ScriptedLedgerPeerProvider for testing. Provider refreshes reconcile the PeerRegistry on crate-owned paths without node involvement. Peer governor module (governor.rs): pure decision engine with GovernorTargets (regular + big-ledger, upstream sanePeerSelectionTargets validation), LocalRootTargets (with trustable flag), GovernorAction (PromoteToWarm/PromoteToHot/DemoteToWarm/DemoteToCold/ForgetPeer/ShareRequest/RequestPublicRoots/RequestBigLedgerPeers/AdoptInboundPeer), evaluation functions for promotions/demotions/big-ledger-promotions/big-ledger-demotions/forget-cold-peers/forget-failed-peers/peer-share-requests/local-root valency plus upstream-style root/big-ledger request scheduling and known-peer discovery. Regular vs big-ledger accounting is fully disjoint (RegularPeerCounts helper excludes PeerSourceBigLedger). GovernorState with time-based exponential failure backoff and decay (PeerFailureRecord, failure_decay), signed request backoff state for public roots and big-ledger peers (RequestBackoffState, upstream publicRootBackoffs/bigLedgerPeerBackoffs semantics), inbound discovery timing (inbound_peers_retry_time, inbound_peers_retry_delay, max_inbound_peers), in-flight promotion tracking (in_flight_warm/in_flight_hot — upstream inProgressPromoteCold/inProgressPromoteWarm), in-flight demotion tracking (in_flight_demote_warm/in_flight_demote_hot — upstream inProgressDemoteWarm/inProgressDemoteHot), peer-sharing request budget (in_progress_peer_share_reqs/max_in_progress_peer_share_reqs — upstream inProgressPeerShareReqs/policyMaxInProgressPeerShareReqs), and two-phase churn cycle (ChurnPhase: Idle → DecreasedActive → DecreasedEstablished → Idle; apply_churn_to_targets() temporarily lowers active or established targets via churn_decrease() so standard evaluation functions produce bulk demotions, then restored targets produce fresh promotions). churn_decrease() implements upstream decrease v = max 0 $ v - max 1 (v div 5). Bootstrap-sensitive mode (PeerSelectionMode::Sensitive/Normal): requires_bootstrap_peers(), peer_selection_mode(), is_node_able_to_make_progress() implement upstream Cardano.Network.PeerSelection.Bootstrap logic; in sensitive mode governor_tick demotes non-trustable peers, filters promotions to trustable-only, and suppresses big-ledger promotions. Peer sharing requests are only generated in Normal mode. PeerRegistryEntry carries upstream knownPeerTepid (tepid: bool): set on hot→warm demotion, cleared on cold→warm promotion; promotion functions deprioritize tepid peers. GovernorState carries max_connection_retries: Option<u32> (upstream reportFailures maxFail); evaluate_forget_failed_peers forgets cold ephemeral peers exceeding the retry threshold while protecting local-root, bootstrap, ledger, and big-ledger sources. evaluate_forget_cold_peers now enforces the one-sided target_root floor by only forgetting public-root peers when regular root count is above target_root. evaluate_known_peer_discovery now follows upstream KnownPeers.belowTarget flow: coin-flip between inbound-adoption and peer-share requests, with 60s inbound retry gating and max 10 inbound peers per pick. evaluate_peer_share_requests generates ShareRequest actions when known < target_known and budget allows. filter_backed_off now filters both duplicate promotions and duplicate demotions for peers with in-flight actions. NodePeerSharing enum (PeerSharingDisabled/PeerSharingEnabled) mirrors upstream PeerSharing willingness flag from handshake version data; from_wire() maps handshake byte. AssociationMode enum (LocalRootsOnly/Unrestricted) mirrors upstream AssociationMode from Ouroboros.Network.PeerSelection.Governor.Types; compute_association_mode() implements upstream readAssociationMode logic from cardano-diffusion. In LocalRootsOnly mode (BP/hidden-relay), governor_tick in Normal mode suppresses big-ledger promotions and peer sharing requests. PeerSelectionCounters (upstream PeerSelectionView Int) provides structured governor counters across four peer categories (regular, big-ledger, local-root, non-root) with in-flight action counts from GovernorState; from_registry() implements upstream peerSelectionStateToView. OutboundConnectionsState (TrustedStateWithExternalPeers/UntrustedState) mirrors upstream trust health signal; compute_outbound_connections_state() branches on (AssociationMode, UseBootstrapPeers) to determine whether all established connections are trustable. FetchMode (FetchModeBulkSync/FetchModeDeadline) mirrors upstream block-fetch concurrency mode; fetch_mode_from_judgement() derives mode from LedgerStateJudgement. ChurnMode (Normal/BulkSync) derived from FetchMode via churn_mode_from_fetch_mode(). ChurnRegime (ChurnDefault/ChurnPraosSync/ChurnBootstrapPraosSync) derived from (ChurnMode, UseBootstrapPeers, ConsensusMode) via pick_churn_regime(). ChurnConfig carries bulk_churn_interval (900 s, upstream defaultBulkChurnInterval) and deadline_churn_interval (3300 s, upstream defaultDeadlineChurnInterval); interval_for_mode(FetchMode) selects the appropriate interval. Regime-aware churn: churn_decrease_active() (upstream decreaseActive) and churn_decrease_established() (upstream decreaseEstablished) vary decrease aggressiveness by ChurnRegime; BootstrapPraosSync is most aggressive. ConsensusMode (PraosMode/GenesisMode) mirrors upstream. PeerSelectionTimeouts groups upstream simplePeerSelectionPolicy time constants (find_public_root_timeout 5s, peer_share_retry_time 900s, peer_share_batch_wait_time 3s, peer_share_overall_timeout 10s, peer_share_activation_delay 300s, max_connection_retries 5, clear_fail_count_delay 120s, inbound_peers_retry_delay 60s, max_inbound_peers 10). ConnectionManagerCounters (upstream ConnectionManagerCounters from ConnectionManager.Types) tracks full_duplex_conns/duplex_conns/unidirectional_conns/inbound_conns/outbound_conns/terminating_conns with from_registry() approximated from PeerRegistry and field-wise Add (upstream Semigroup). Randomized peer selection via PickPolicy (upstream simplePeerSelectionPolicy PickPolicy callbacks): Xorshift64 embedded PRNG (no rand crate dependency), PickPolicy::pick(count, candidates) for uniform random subset selection, PickPolicy::pick_scored(count, candidates, metrics) for score-weighted selection (hot demotion), and coin_flip() for inbound-vs-peer-share branching. PeerMetrics tracks per-peer upstreamyness/fetchyness with combined_score() for hot demotion scoring (upstream hotDemotionPolicy). All evaluation functions now take &mut PickPolicy for randomized candidate selection; evaluate_hot_to_warm_demotions additionally takes &PeerMetrics. 171 governor tests. Connection manager type system (connection.rs): Provenance (Inbound/Outbound), DataFlow (Unidirectional/Duplex), TimeoutExpired, AbstractState (12 upstream variants), ConnectionState (10 runtime state-machine variants), ConnectionType, ConnStateId, ConnectionId, connection_state_to_counters(), verify_abstract_transition(), AcceptedConnectionsLimit, MaybeUnknown<S>, Transition, OperationResult, DemotedToColdRemoteTr, ConnectionManagerError (9 variants). Inbound governor types: RemoteSt (4 variants), InboundGovernorCounters, ResponderCounters, InboundGovernorEvent (10 variants). Timeout constants and inbound constants modules. 49 connection tests. Inbound governor decision engine (inbound_governor.rs): pure step-function processing all 10 InboundGovernorEvent variants into InboundGovernorAction (PromotedToWarmRemote/DemotedToColdRemote/ReleaseInboundConnection/UnregisterConnection). InboundGovernorState tracks per-connection InboundConnectionEntry (remote_st, data_flow, responder_counters, idle tracking), fresh/mature duplex peer maps, and counters. Event handlers: new_connection (RemoteIdleSt + duplex maturation), mux_finished (unregister), wait_idle_remote (→idle), awake_remote (→warm), promote/demote (warm↔hot), commit_remote (→release), matured_duplex_peers, inactivity_timeout. apply_commit_result() handles CM DemotedToColdRemoteTr response. mature_peers() promotes fresh duplex peers past 15-min threshold. update_responder_counters() derives IG events from counter changes. verify_remote_transition() validates upstream transition table. 43 inbound governor tests. Diffusion-layer types (diffusion.rs): TemperatureBundle<T> (hot/warm/established), ProtocolTemperature, MiniProtocolStart/MiniProtocolLimits/MiniProtocolDescriptor, OuroborosBundle, ntn_ouroboros_bundle()/ntc_ouroboros_bundle(), ControlMessage (Continue/Quiesce/Terminate), MuxMode, RateLimitDecision with rate_limit_decision(), ErrorCommand/RethrowPolicy/ErrorPolicyResult, PeerConnectionHandle, PeerStateAction (Establish/Activate/Deactivate/Close), RepromoteDelay. 28 diffusion tests.
  • node/ orchestration, CLI, and sync pipeline:
    • CLI: clap-based binary with run (connect + sync + governor + optional inbound serving + optional block producer), validate-config (operator preflight), status (on-disk inspection), default-config (emit JSON), cardano-cli (version, show-upstream-config, query-tip), and Unix-only query/submit-tx NtC subcommands. CLI flags override config file values. JSON-first configuration via NodeConfigFile (serde) with YAML fallback; PascalCase upstream key aliases supported (TargetNumberOfKnownPeers, MaxKnownMajorProtocolVersion, ShelleyGenesisHash, etc.).
    • Bootstrap: NodeConfig, PeerSession, bootstrap.
    • Raw sync: sync_step, sync_steps, sync_step_decoded, decode_shelley_blocks.
    • Typed sync: sync_step_typed, decode_shelley_header, decode_point, sync_steps_typed, sync_until_typed. Typed ChainSync header/point decode and Shelley BlockFetch batch decode now happen in yggdrasil-network; node/ keeps multi-era fetched-block decode.
    • Storage handoff: apply_typed_step_to_volatile, apply_typed_progress_to_volatile.
    • Intersection + batch: typed_find_intersect, sync_batch_apply. Typed ChainSync intersection, point/tip decode, and typed Shelley BlockFetch decode now happen in yggdrasil-network; node/ keeps multi-era and storage orchestration.
    • KeepAlive: keepalive_heartbeat.
    • Managed service: run_sync_service, SyncServiceConfig, SyncServiceOutcome.
    • Consensus bridge: shelley_opcert_to_consensus, shelley_header_to_consensus, verify_shelley_header, praos_header_to_consensus, verify_praos_header.
    • Multi-era decode: MultiEraBlock, decode_multi_era_block, decode_multi_era_blocks (Byron/Shelley/Allegra/Mary/Alonzo/Babbage/Conway — all seven era tags). Byron blocks are structurally decoded via ByronBlock::decode_ebb()/decode_main(), carrying epoch, slot, chain_difficulty, prev_hash, and raw header bytes for correct header hash computation. Alonzo (tag 5) uses dedicated AlonzoBlock (5-element format with invalid_transactions and TPraos header), distinct from the 4-element ShelleyBlock used for Shelley/Allegra/Mary (tags 2–4).
    • Header hash: ShelleyHeader::header_hash, PraosHeader::header_hash (Blake2b-256), ByronBlock::header_hash (Blake2b-256 of prefix + raw header), compute_tx_id.
    • Verified pipeline: multi_era_block_to_block, verify_multi_era_block (dispatches Shelley verifier for pre-Babbage, Praos verifier for Babbage/Conway; also performs BBODY-level validate_block_protocol_version era/version consistency check and MaxMajorProtVer guard), sync_step_multi_era, sync_batch_apply_verified, VerificationConfig. HeaderProtVerTooHigh follows upstream Conway BBODY policy: active on mainnet, temporarily suppressed on testnets until Dijkstra protocol major 12, and independent of the network-wide MaxMajorProtVer ceiling. validate_block_body_size checks declared vs actual serialized body size (reference: WrongBlockBodySizeBBODY). Both new validation errors are peer-attributable. NodeConfigFile.max_major_protocol_version (default 10, Conway-era upstream MaxMajorProtVer) wires through to both verified and unverified VerificationConfig paths. Non-verified multi-era BlockFetch decode now happens in yggdrasil-network; verified raw+decoded BlockFetch batch handling also uses network helpers while verification and body-hash policy remain in node/. FutureBlockCheckConfig wired at startup from ShelleyGenesis.system_start + slot_length + ClockSkew::default_for_slot_length; current_wall_slot() in genesis.rs computes wall-clock slot. OcertCounters::new() initialized at startup; batch/service/runtime functions thread &mut Option<OcertCounters> for per-pool OpCert sequence-number monotonicity enforcement across batches and reconnects; validate_block_opcert_counter_permissive() accepts first-seen pools without stake-distribution lookup.
    • Block body hash verification: verify_block_body_hash (Blake2b-256 of body elements vs header-declared hash), extract_header_block_body_hash (handles both 14-element Praos and 15-element Shelley header bodies), wired into sync_batch_apply_verified via VerificationConfig.verify_body_hash. compute_block_body_hash in ledger crate.
    • VRF data flow: bridge functions carry leader VRF proof/output (and nonce VRF for TPraos) through to consensus HeaderBody. verify_block_vrf + VrfVerificationParams enable per-block leader-proof verification when epoch nonce and stake data are available.
    • Nonce evolution wiring: apply_nonce_evolution extracts per-era VRF nonce contribution and prev_hash from MultiEraBlock and feeds NonceEvolutionState::apply_block. Byron blocks skipped.
    • Verified sync service: run_verified_sync_service, VerifiedSyncServiceConfig, VerifiedSyncServiceOutcome — async managed service using sync_batch_apply_verified with multi-era header/body verification, per-block nonce evolution tracking, and optional ChainState tracking. Reports final NonceEvolutionState, ChainState, and stable_block_count on shutdown.
    • Epoch boundary wiring: advance_ledger_with_epoch_boundary() in sync.rs detects epoch transitions via is_new_epoch() / slot_to_epoch() and calls apply_epoch_boundary() before the first block of each new epoch. LedgerCheckpointTracking optionally carries StakeSnapshots + EpochSize; when present, update_ledger_checkpoint_after_progress uses epoch-aware advancement. Automatically enabled when nonce_config provides epoch_size. Both ledger-advance functions accept Option<&dyn PlutusEvaluator> and call apply_block_validated().
    • Plutus evaluation wiring: plutus_eval.rs in node/src/ provides CekPlutusEvaluator implementing PlutusEvaluator using the yggdrasil-plutus CEK machine. Decodes upstream PlutusBinary/SerialisedScript bytes (CBOR bytestring containing Flat), applies datum (spending only), redeemer, and a version-aware ScriptContext built from the normalized ledger TxContext, then evaluates within declared ExUnits budget. ScriptContext encoding now has per-version parity with upstream Cardano.Ledger.Alonzo.Plutus.TxInfo / Cardano.Ledger.Conway.TxInfo: V1/V2 fee uses nested Value (transCoinToValue), V3 is plain Lovelace integer; V1/V2 mint prepends zero-ADA (transMintValue = transCoinToValue zero <> transMultiAsset), V3 does not; V1 datums/withdrawals are List-of-tuples (PV1), V2/V3 use Map; V1 TxOut is always 3-element (transTxOutV1), V2/V3 Babbage is 4-element (transTxOutV2); pre-Conway upper-only validity intervals use inclusive PV1.to, while Conway/PV9+ upper bounds use strict encoding; V1 guard rejects inline datums and reference scripts. TxInfo carries resolved inputs/reference inputs, structured Shelley-family TxOut addresses, fee, mint, withdrawals, certificates, signatories, redeemers, datums, tx id, Conway votes/proposals, and treasury fields. V1/V2 accept any non-error result; V3 requires Bool(true). Unsupported V3 certificate or proposal encodings now fail explicitly instead of fabricating placeholder integers. TxContext now carries protocol_version: Option<(u64, u64)> for version-dependent V3 cert encoding; PV9 Conway bootstrap phase omits AccountRegistrationDeposit/AccountUnregistrationDeposit deposit fields (upstream hardforkConwayBootstrapPhase, bug #4863). CekPlutusEvaluator carries optional system_start_unix_secs and slot_length_secs for slot-to-POSIX-millisecond conversion (upstream slotToPOSIXTime from Cardano.Ledger.Alonzo.Plutus.TxInfo); when configured, posix_time_range in ScriptContext encodes real POSIX timestamps instead of raw slot numbers. genesis.rs exposes slot_to_posix_ms() and the public chrono_parse_system_start() helper; VerifiedSyncServiceConfig.build_plutus_evaluator() wires genesis system_start through to the evaluator.
    • Genesis parameter loading (Phase 7): genesis.rs in node/src/ provides serde types for ShelleyGenesis, AlonzoGenesis, ConwayGenesis, and build_protocol_parameters() which assembles ProtocolParameters from genesis files. NodeConfigFile now exposes ShelleyGenesisFile, AlonzoGenesisFile, ConwayGenesisFile fields (matching official Cardano node config keys) and a load_genesis_protocol_params() method. Preset configs point to vendored genesis files. main.rs now centralizes genesis loading in a base-ledger-state helper and uses the resulting genesis-seeded LedgerState for startup peer-selection recovery, validate-config, status, and the resumed sync service, so fresh syncs and recovery/reporting paths all use the same network-derived thresholds instead of only the live sync path being seeded. ConwayGenesis also parses the constitution section (anchor + guardrails script hash) via GenesisConstitution / GenesisConstitutionAnchor. build_genesis_enact_state() and NodeConfigFile::load_genesis_enact_state() wire the genesis constitution into the base LedgerState’s EnactState at startup so governance validation uses the correct initial constitution and guardrails script hash.
    • NtC local socket server (local_server.rs): BasicLocalQueryDispatcher handles 18 LocalStateQuery tags: (0) CurrentEra, (1) ChainTip, (2) CurrentEpoch, (3) ProtocolParameters, (4) UTxOByAddress, (5) StakeDistribution, (6) RewardBalance, (7) TreasuryAndReserves, (8) GetConstitution, (9) GetGovState, (10) GetDRepState, (11) GetCommitteeMembersState, (12) GetStakePoolParams, (13) GetAccountState, (14) GetUTxOByTxIn, (15) GetStakePools, (16) GetFilteredDelegationsAndRewardAccounts, (17) GetDRepStakeDistr. Queries operate via LedgerStateSnapshot and return opaque CBOR. LocalTxMonitor is wired into SharedMempool. LocalTxSubmission uses staged apply_submitted_tx before mempool insertion.
    • Block production (Phase 2): block_producer.rs implements text-envelope credential loading (VRF, KES, OpCert, issuer cold verification key), BlockProducerCredentials (upstream PraosCanBeLeader), check_slot_leadership() (VRF Praos leader election), check_can_forge() (KES period validation), forge_block_header() (14-element Praos HeaderBody + SumKES signing), evolve_kes_key() / evolve_kes_key_to_period(), check_should_forge(), assemble_block_body(), forge_block(), and forged_block_to_storage_block(). forge_block() now derives canonical block_body_hash and block_body_size from serialized Conway body elements (all entries after the header), and forged header hash now follows on-wire Praos header CBOR hashing. forged_block_to_storage_block() preserves multi-era raw CBOR for downstream relay. NodeConfigFile carries ShelleyKesKey/ShelleyVrfKey/ShelleyOperationalCertificate/ShelleyOperationalCertificateIssuerVkey with --shelley-kes-key/--shelley-vrf-key/--shelley-operational-certificate/--shelley-operational-certificate-issuer-vkey CLI overrides. load_block_producer_credentials() verifies OpCert signatures against the configured issuer key and runtime forging uses that issuer key in headers. runtime.rs now includes run_block_producer_loop() with a 1s slot clock (SlotClock), per-slot leader checks, fee-ordered mempool body assembly, forged-block self-validation before persistence, volatile ChainDb insertion, mempool eviction of included txs, Node.BlockProduction trace events, and chain-tip notifications for inbound followers. run_node() now spawns the producer loop when credentials are configured, and resumed reconnecting sync can emit the same tip notifications after verified batch apply. 18 block_producer tests + runtime helper tests.
    • Runtime parity hardening (P1-P3): post-forge adoption checks are wired into run_block_producer_loop() (adopted vs not-adopted trace outcomes aligned with upstream NodeKernel.forkBlockForging); reconnecting sync now classifies peer-attributable validation failures as reconnect-and-punish with ChainDB.AddBlockEvent.InvalidBlock trace emission (upstream InvalidBlockPunishment intent); and far-future header rejection is enforced through consensus ClockSkew + FutureSlotJudgement (InFutureCheck) and surfaced as SyncError::BlockFromFuture.
    • Diffusion pipelining parity wiring: node runtime now threads shared TentativeState through resumed/reconnecting verified sync request/context (with_tentative_state), sync_batch_verified_with_tentative() sets tentative headers on roll-forward announcements and clears adopted/trap outcomes on success/failure, and inbound ChainSync serving now advertises tentative tips and rolls followers back to the confirmed tip when a served tentative header is trapped.
    • Plutus cost model calibration: crates/plutus::CostModel now exposes from_alonzo_genesis_params() which derives CEK step costs and per-builtin parameterized CPU/memory cost expressions from upstream named Alonzo/Babbage cost-model maps. builtin_cost() evaluates these per-builtin expressions against runtime argument ExMemory sizes, with flat fallback for any unmapped builtin. NodeConfigFile::load_plutus_cost_model() loads that calibrated model from alonzo-genesis.json, and when named maps are unavailable it now maps the live 251-entry Conway plutusV3CostModel array into the same named-parameter pipeline (up through byteStringToInteger-memory-arguments-slope) instead of using the earlier CEK-only structural fallback. VerifiedSyncServiceConfig carries the resulting model as plutus_cost_model, and checkpoint-tracked ledger replay uses a stored CekPlutusEvaluator built from it instead of recreating default-cost evaluators per batch. Remaining work is future Conway tail parameters beyond the current vendored 251-name surface. Cost-shape parity is now complete: all 18 CostExpr variants (Constant, LinearInX/Y/Z, AddedSizes, SubtractedSizes, MultipliedSizes, MinSize, MaxSize, LinearOnDiagonal, ConstAboveDiagonal, ConstBelowDiagonal, QuadraticInY/Z, LiteralInYOrLinearInZ, LinearInYAndZ, ConstOffDiag) match upstream builtin argument shapes.
    • ChainState integration: multi_era_block_to_chain_entry, track_chain_state, promote_stable_blocks. Wires consensus ChainState into the sync pipeline with stability window enforcement and stable-block promotion from volatile to immutable storage. All eras including Byron are tracked.
    • Genesis parameters: NodeConfigFile includes epoch_length (432000), security_param_k (2160), active_slot_coeff (0.05). CLI run command computes stability_window = 3k/f and builds NonceEvolutionConfig from config.
    • Network presets: NetworkPreset enum (Mainnet | Preprod | Preview) with FromStr/Display and per-network constructors. CLI --network flag selects preset. Configuration files for all three networks stored in node/configuration/.
    • Mempool eviction: extract_tx_ids, evict_confirmed_from_mempool.
  • crates/consensus/src/mempool now includes fee-ordered queue with TxId-based entries, duplicate detection, capacity enforcement, remove_by_id, remove_confirmed for block-application eviction, TTL-aware admission (insert_checked, purge_expired), iterator support, and relay-facing entry conversion to/from ledger MultiEraSubmittedTx with stored era + raw submitted-transaction bytes.
  • crates/consensus/src/mempool now includes fee-ordered queue with TxId-based entries, duplicate detection, capacity enforcement, remove_by_id, remove_confirmed for block-application eviction, TTL-aware admission (insert_checked, purge_expired), iterator support, relay-facing entry conversion to/from ledger MultiEraSubmittedTx with stored era + raw submitted-transaction bytes, epoch revalidation (purge_invalid_for_params) that sweeps all entries at epoch boundaries against new protocol parameters (fee, size, ExUnits), and post-block ledger revalidation (revalidate_with_ledger) that evicts entries failing ledger re-application with current state (upstream revalidateTxsFor from Ouroboros.Consensus.Mempool.Impl.Update.syncWithLedger). Runtime wiring in node/src/runtime.rs calls purge_invalid_for_params after each epoch boundary event and evict_mempool_after_roll_forward (combined confirmed + conflicting + expired + ledger-revalidation) after each batch apply. Reference: Ouroboros.Consensus.Mempool.Impl.Update — syncWithLedger.
  • crates/ledger:
    • LedgerState with dual UTxO: legacy ShelleyUtxo + generalized MultiEraUtxo, era-aware apply_block() dispatch (Shelley through Conway).
    • Submitted-transaction abstractions in tx.rs: compute_tx_id, ShelleyCompatibleSubmittedTx<TBody>, AlonzoCompatibleSubmittedTx<TBody>, and MultiEraSubmittedTx::from_cbor_bytes_for_era() for Shelley-based transaction relay boundaries. Both submitted-tx wrappers now preserve raw_body (original wire CBOR bytes of the body) for correct txIdTxBody hashing of non-canonically encoded transactions.
    • MultiEraUtxo with per-era apply methods, coin/multi-asset preservation, TTL/validity-interval checks.
    • MultiEraTxOut enum (Shelley/Mary/Alonzo/Babbage variants) with coin()/value()/address() accessors.
    • Allegra era types (AllegraTxBody, NativeScript).
    • Mary era types (Value, MultiAsset, MaryTxBody).
    • Alonzo era types (ExUnits, Redeemer, AlonzoTxOut, AlonzoTxBody, AlonzoBlock).
    • Byron envelope (ByronBlock) with structural header decode — epoch, slot-in-epoch, chain_difficulty (block number), prev_hash, raw header bytes. header_hash() computes Blake2b-256(prefix ++ raw_header_cbor) with variant-specific prefix (0x82 0x00 for EBB, 0x82 0x01 for Main).
    • Babbage era types (DatumOption, BabbageTxOut, BabbageTxBody, BabbageBlock with PraosHeader).
    • Conway era types (Vote, Voter, GovActionId, Constitution, GovAction (7-variant typed enum: ParameterChange/HardForkInitiation/TreasuryWithdrawals/NoConfidence/UpdateCommittee/NewConstitution/InfoAction), VotingProcedure, ProposalProcedure (typed GovAction), VotingProcedures, ConwayTxBody, ConwayBlock with PraosHeader).
    • Credential and address types (StakeCredential, RewardAccount, Address with Base/Enterprise/Pointer/Reward/Byron variants, AddrKeyHash, ScriptHash, PoolKeyHash type aliases). Strict validation now rejects invalid Shelley network ids and malformed pointer encodings, and exposes Byron bootstrap-address CRC32 verification through Address::validate_bytes().
    • Certificate hierarchy (Anchor, UnitInterval, Relay, PoolMetadata, PoolParams, DRep, DCert with 19 CDDL-aligned variants covering Shelley tags 0–5 and Conway tags 7–18).
    • Signed integer CBOR helpers.
    • TxBody keys 4–6 (certificates, withdrawals, update as typed ShelleyUpdate carrying typed ProtocolParameterUpdate deltas for Shelley–Babbage; Conway omits key 6).
    • WitnessSet keys 0–7 (vkey_witnesses, native_scripts, bootstrap_witnesses, plutus_v1_scripts, plutus_data (typed Vec<PlutusData>), redeemers (typed PlutusData payload), plutus_v2_scripts, plutus_v3_scripts). Typed BootstrapWitness. Conway map-format redeemers supported.
    • PlutusData AST (Constr/Map/List/Integer/Bytes) with full recursive CBOR codec including compact constructor tags 121–127, general form tag 102, and bignum encoding. Script enum (Native/PlutusV1/V2/V3), ScriptRef with tag-24 double encoding. BabbageTxOut.script_ref is now typed Option<ScriptRef>. DatumOption::Inline is now typed PlutusData (tag-24 double encoding). Redeemer.data is now typed PlutusData.
    • Full era type and block coverage from Byron through Conway is complete.
    • Ledger rule foundation modules: ProtocolParameters (CBOR map codec, Shelley/Alonzo defaults, min_lovelace_for_utxo(), apply_update()), ProtocolParameterUpdate (typed sparse CBOR-map delta for Shelley/Conway parameter proposals), fees.rs (linear fee + script fee calculation/validation + Conway tiered reference-script fees via tier_ref_script_fee() / conway_total_min_fee() / validate_conway_fee() matching upstream tierRefScriptFee and getConwayMinFeeTx with multiplier 1.2 / stride 25,600), native_script.rs (timelock evaluator + Blake2b-224 script hash), collateral.rs (Alonzo+ collateral validation), min_utxo.rs (per-output minimum lovelace enforcement using MultiEraTxOut::inner_cbor_size() matching upstream sizedSize), witnesses.rs (VKey witness sufficiency, Ed25519 signature verification via verify_vkey_signatures(), and required hash collection helpers). MultiEraTxOut::inner_cbor_size() measures era-specific inner output CBOR without the Rust enum wrapper. LedgerState carries Option<ProtocolParameters> (CBOR array element 10, backward-compatible with legacy 9-element).
    • Witness & native script validation wiring: Tx struct carries optional serialized witness bytes. All per-era apply_block() inner loops (Shelley through Conway) compute required VKey hashes from spending inputs, certificates, withdrawals, and required_signers (Alonzo+), then call validate_witnesses_if_present() which enforces both VKey hash sufficiency and real Ed25519 signature verification against the transaction body hash. Allegra through Conway additionally compute required script hashes and call validate_native_scripts_if_present() for native timelock evaluation. Address::payment_credential() extracts payment credentials for UTxO-driven hash collection. 12 integration tests cover VKey sufficiency (accept/reject/skip/empty), Ed25519 signature verification (forged signature, wrong body), and native script evaluation (ScriptPubkey, InvalidBefore, InvalidHereafter, ScriptAll multisig).
    • PPUP proposal validation (upstream Cardano.Ledger.Shelley.Rules.Ppup): validate_ppup_proposal() enforces three upstream PPUP checks — NonGenesisUpdatePPUP (proposer must be a genesis delegate), PPUpdateWrongEpoch (target epoch must match voting-period slot-of-no-return when PpupSlotContext provided, or relaxed current/current+1 check), PVCannotFollowPPUP (proposed protocol version must satisfy pv_can_follow — major+1 with minor=0 or same major with minor+1). Wired into all 10 block-apply + submitted-tx paths (Shelley through Babbage) with full PpupSlotContext derived from LedgerState.stability_window + slots_per_epoch (upstream getTheSlotOfNoReturn). LedgerState.stability_window set at node startup from 3k/f. 20 PPUP validation tests.
    • Epoch boundary processing (Phase 4): stake.rs (stake distribution snapshots — IndividualStake, Delegations, StakeSnapshot, StakeSnapshots three-snapshot ring with fee pot, PoolStakeDistribution, compute_stake_snapshot()), rewards.rs (epoch reward calculation — RewardParams, EpochRewardPot, EpochRewardDistribution, compute_epoch_rewards(), u128 fixed-point), epoch_boundary.rs (apply_epoch_boundary() NEWEPOCH/RUPD/MIR/SNAP orchestration, apply_mir_at_epoch_boundary() all-or-nothing MIR payout + pot-to-pot delta transfers, retire_pools_with_refunds(), remove_expired_governance_actions(), DRep inactivity detection, EpochBoundaryEvent). Governance action expiry follows the upstream Conway EPOCH rule: proposals whose expires_after epoch has passed are pruned at each epoch boundary and deposits are refunded to registered return accounts. DRep inactivity follows the upstream Conway drepExpiry rule: DReps whose last_active_epoch + drep_activity < current_epoch are counted as inactive but remain registered (excluded from ratification quorum). ProtocolParameters carries drep_deposit (key 31) and drep_activity (key 32) for Conway DRep governance parameters; genesis wiring maps ConwayGenesis d_rep_deposit/d_rep_activity into these fields. RegisteredDrep tracks last_active_epoch; activity is touched on registration, update, and vote via touch_drep_activity_for_certs() and apply_conway_votes(). DepositPot and AccountingState in state.rs track key/pool/drep/proposal deposits and treasury/reserves. LedgerState now 23-field struct with backward-compatible CBOR (9/10/12/15/16/18/19/20/21/22/23-element decode). num_dormant_epochs (element 22) tracks Conway dormant governance epochs (upstream updateNumDormantEpochs); epoch boundary increments when no proposals remain, resets to 0 when proposals exist. Per-tx update_dormant_drep_expiries() bumps DRep last_active_epoch by dormant count when proposals appear (upstream updateDormantDRepExpiries). apply_conway_votes() and touch_drep_activity_for_certs() adjust DRep activity by dormant offset (upstream computeDRepExpiry). blocks_made (element 23, upstream NewEpochState.nesBcur) tracks per-pool block production counts across the current epoch: record_block_producer() is called automatically from apply_block_validated() for non-Byron blocks, take_blocks_made() clears at epoch boundary. derive_pool_performance() in epoch_boundary.rs computes UnitInterval performance ratios from internal block counts + StakeSnapshot stake distribution; apply_epoch_boundary() uses internally derived performance when caller passes an empty performance map. PlutusEvaluator trait extended with is_script_well_formed() method (default true); validate_script_witnesses_well_formed() and validate_reference_scripts_well_formed() in witnesses.rs call the evaluator to detect malformed Plutus scripts at admission time (upstream validateScriptsWellFormed from Cardano.Ledger.Alonzo.Rules.Utxos), wired into all Alonzo+-era apply_block_validated paths. validate_outside_forecast() in utxo.rs implements upstream OutsideForecast infrastructure from Cardano.Ledger.Shelley.Rules.Utxo — marked as upstream-equivalent no-op because unsafeLinearExtendEpochInfo makes the check always pass. Conway deposit validation: IncorrectDepositDELEG (key deposit), IncorrectKeyDepositRefund, DrepIncorrectDeposit, DrepIncorrectRefund, WithdrawalNotFullDrain (exact-drain semantics). Conway proposal deposits included in UTxO value preservation (totalTxDeposits = certDeposits + proposalDeposits, upstream Cardano.Ledger.Conway.TxInfo). InstantaneousRewards (element 20) accumulates MIR DCert tag 6 (Shelley through Babbage only, removed in Conway) from reserves/treasury to reward accounts and pot-to-pot delta transfers via accumulate_mir_from_certs(), wired into all 10 pre-Conway block-apply and submitted-tx paths. MIR genesis quorum validation (validateMIRInsufficientGenesisSigs): genesis_update_quorum: u64 (element 21, default 5) from ShelleyGenesis.updateQuorum; validate_mir_genesis_quorum_if_present() and validate_mir_genesis_quorum_typed() enforce ≥ quorum genesis delegate witnesses on any tx with MIR certs; wired into all 5 block-apply + 5 submitted-tx paths (Shelley–Babbage); 8 quorum tests. MIR admission validation (MirValidationContext): all 7 upstream DELEG MIR checks enforced — MIRCertificateTooLateinEpochDELEG, MIRNegativesNotCurrentlyAllowed, MIRProducesNegativeUpdate, InsufficientForInstantaneousRewardsDELEG, MIRTransferNotCurrentlyAllowed, MIRNegativeTransfer, InsufficientForTransferDELEG; era-gated via alonzo_mir_transfers matching upstream hardforkAlonzoAllowMIRTransfer; wired at all 10 Shelley–Babbage call sites; Conway passes None; 8 MIR validation tests. LedgerState.utxos_donation (element 19) accumulates per-tx Conway treasury_donation (upstream utxosDonationL in Cardano.Ledger.Conway.Rules.Utxos); ZeroDonation validation rejects treasury_donation == 0 in both block-apply and submitted-tx paths (upstream validateZeroDonation); flush_donations_to_treasury() transfers accumulated donations to treasury at epoch boundary (upstream Cardano.Ledger.Conway.Rules.Epoch). validate_outputs_missing_datum_hash_alonzo() in plutus_validation.rs (upstream validateOutputMissingDatumHashForScriptOutputs) rejects Alonzo script-address outputs without datum_hash, wired into both block-apply and submitted-tx Alonzo paths. validate_unspendable_utxo_no_datum_hash() now supports CIP-0069 PlutusV3 datum exemption: Conway call sites pass V3 script hashes (from witness-set and reference-input script refs via collect_v3_script_hashes()), so V3-locked spending inputs skip the datum-hash requirement (upstream getInputDataHashesTxBody). validate_script_data_hash() is PV-aware: at PV >= 11 hash mismatches return ScriptIntegrityHashMismatch instead of PPViewHashesDontMatch (upstream Cardano.Ledger.Conway.Rules.Utxow). Cross-era value preservation now enforces the full upstream equation: consumed + withdrawals + refunds = produced + fee + deposits [+ donation for Conway] (reference: Cardano.Ledger.Shelley.Rules.Utxo, Cardano.Ledger.Conway.Rules.Utxo). apply_certificates_and_withdrawals() returns CertBalanceAdjustment { withdrawal_total, total_deposits, total_refunds } and all six per-era UTxO functions receive deposit/refund totals. Certificate processing tracks deposits across all 19 DCert variants. process_retirements() on PoolState.
    • Governance enactment (Phase 5): EnactState struct in state.rs tracks the enacted constitution, committee quorum threshold, and four purpose-lineage prev-action-ids (prev_pparams_update, prev_hard_fork, prev_committee, prev_constitution) matching upstream GovRelation. enact_gov_action() free function implements the Conway ENACT rule for all seven GovAction variants: InfoAction (no effect), NewConstitution (replace constitution + lineage), NoConfidence (remove all committee members + reset quorum + lineage), UpdateCommittee (add/remove members + set quorum + lineage), HardForkInitiation (update protocol_version + lineage), TreasuryWithdrawals (credit registered reward accounts from treasury), ParameterChange (apply typed ProtocolParameterUpdate to LedgerState.protocol_params + record lineage). Returns EnactOutcome enum. LedgerState carries enact_state: EnactState (element 16, backward-compatible). LedgerStateSnapshot mirrors the field. Enacted-root semantics wired into validate_conway_proposals(): prev_action_id = None is only valid when EnactState has no enacted root for that purpose; prev_action_id = Some(id) must match either the enacted root or a stored pending proposal of the same purpose. NoConfidence and UpdateCommittee share the Committee purpose group. Ratification tally engine: VoteTally, tally_committee_votes (equal-weight, filters resigned + expired members per upstream ccVotesSatisfied currentEpoch <= expirationEpoch), tally_drep_votes (stake-weighted), tally_spo_votes (pool-stake-weighted), drep_threshold_for_action/spo_threshold_for_action, accepted_by_committee/accepted_by_dreps/accepted_by_spo predicates, ratify_action combined predicate (reference: Cardano.Ledger.Conway.Rules.Ratify). CommitteeMemberState carries expires_at: Option<u64> (upstream per-member term epoch from committeeMembers); register_with_term() stores term epoch at UpdateCommittee enactment; backward-compatible CBOR (3-element new format, legacy null/2-element decode). PoolVotingThresholds (5 fields, CDDL key 25), DRepVotingThresholds (10 fields, CDDL key 26), min_committee_size (key 27), committee_term_limit (key 28) in ProtocolParameters. Epoch-boundary ratification is complete: ratify_and_enact() in epoch_boundary.rs implements full upstream ratifyTransition with iterative enactment, lineage checks, delay semantics, subtree pruning, and deposit refunds.
  • crates/storage now includes file-backed implementations (FileImmutable, FileVolatile, FileLedgerStore) with CBOR-based on-disk persistence (legacy JSON read compatibility), directory scanning on open, rollback-aware file deletion, re-open persistence, active crash recovery (stale dirty.flag detection removes incomplete .tmp files and clears the sentinel after successful recovery scan), and fsync durability (sync_all() on temp file before rename plus sync_dir() on parent directory after rename in all write paths; dirty sentinel creation also synced).
  • crates/consensus now includes SecurityParam (Ouroboros k), ChainState volatile chain tracker with roll-forward/roll-backward, max rollback depth enforcement, stability window detection (stable_count, drain_stable), and non-contiguous block rejection. HeaderBody carries VRF proof data (leader_vrf_output, leader_vrf_proof, optional nonce_vrf_output/nonce_vrf_proof for TPraos). OpCert field names aligned with CDDL (hot_vkey, sequence_number). Epoch nonce evolution state machine (NonceEvolutionState) implements UPDN + TICKN rules with era-aware VRF nonce derivation: NonceDerivation::TPraos uses simple Blake2b-256(output) (upstream hashVerifiedVRF), NonceDerivation::Praos uses Blake2b-256(Blake2b-256("N" || output)) (upstream vrfNonceValue from Ouroboros.Consensus.Protocol.Praos.VRF). derive_vrf_nonce() dispatches by derivation variant. apply_block() accepts NonceDerivation parameter. NonceEvolutionConfig carries epoch parameters. Era-aware VRF input construction via VrfMode (TPraos / Praos) and VrfUsage (Leader / Nonce): praos_vrf_input() produces Blake2b-256(slot_be8 || nonce_bytes) matching upstream mkInputVRF; tpraos_vrf_seed() produces base_hash XOR Blake2b-256(CBOR(tag)) matching upstream mkSeed with seedL/seedEta; check_leader_value() is mode-aware — TPraos uses raw 64-byte output with certNatMax = 2^512, Praos uses Blake2b-256("L" || output) range extension with certNatMax = 2^256 (upstream vrfLeaderValue / checkLeaderNatValue). Chain selection implements upstream Praos tiebreaker (comparePraos from ouroboros-consensus/Protocol/Praos/Common.hs): ChainCandidate with issuer_vkey_hash, ocert_issue_no, vrf_tiebreaker; select_preferred with VrfTiebreakerFlavor (unrestricted pre-Conway, restricted post-Conway). OcertCounters tracks per-pool OpCert sequence numbers (upstream PraosState.csCounters / currentIssueNo): rejects replayed or too-far-ahead counters, accepts same or +1. 108 consensus tests.
  • Upstream naming alignment is complete across ledger and consensus crates:
    • Ledger ShelleyHeaderBody: block_number, slot, issuer_vkey, vrf_vkey, nonce_vrf, leader_vrf, block_body_size, block_body_hash, operational_cert (with hot_vkey, sequence_number, kes_period, sigma). 15-element CBOR array (Shelley through Alonzo).
    • Ledger PraosHeaderBody: block_number, slot, issuer_vkey, vrf_vkey, vrf_result, block_body_size, block_body_hash, operational_cert. 14-element CBOR array with single VRF result (Babbage/Conway).
    • Ledger block fields: transaction_witness_sets (all eras), transaction_metadata_set (Shelley), auxiliary_data_set (Babbage/Conway).
    • Consensus HeaderBody: block_number, slot, issuer_vkey, vrf_vkey, leader_vrf_output, leader_vrf_proof, nonce_vrf_output (TPraos only), nonce_vrf_proof (TPraos only), block_body_size, block_body_hash, operational_cert.
    • Consensus OpCert: hot_vkey, sequence_number.
    • DCert variants aligned with CDDL certificate names: AccountRegistration, AccountUnregistration, DelegationToStakePool, PoolRegistration, PoolRetirement, GenesisDelegation, plus Conway-era AccountRegistrationDeposit through DrepUpdate.
  • CBOR golden round-trip parity tests cover ShelleyTxBody, ShelleyBlock, PlutusData, StakeCredential, MultiEraTxOut, and submitted-transaction round-trips for all seven eras (Byron TX, Shelley, Allegra, Mary, Alonzo, Babbage, Conway), plus MultiEraSubmittedTx and TX ID determinism. Cross-subsystem integration tests verify block→ChainState→storage and rollback flows.
  • tools/cddl-codegen now provides generate_module_with_codecs() which generates struct/enum definitions plus CborEncode/CborDecode implementations for integer-keyed maps (map encode/decode with key dispatch and optional field handling), string-keyed maps, array structs, and group-choice enums. 26 integration tests cover parsing, generation, and codec generation.
  • crates/ledger Byron transaction support is complete: ByronTxIn, ByronTxOut, ByronTx (with tx_id() via Blake2b-256), ByronTxWitness, ByronTxAux — all with full CborEncode/CborDecode handling CBOR tag 24 (CBOR-in-CBOR). ByronBlock::MainBlock carries transactions: Vec<ByronTxAux> decoded from block body tx_payload. Byron blocks now have real UTxO state transitions: apply_byron_block() decodes ByronTx from transaction body bytes, applies each atomically via MultiEraUtxo::apply_byron_tx() which validates input existence, non-negative implicit fee, and converts Byron inputs/outputs to the unified ShelleyTxIn/ShelleyTxOut representation. 15+ Byron-specific tests.
  • 3660 workspace tests pass across all crates, 0 failures.
  • 3710 workspace tests pass across all crates, 0 failures.
  • 3728 workspace tests pass across all crates, 0 failures.
  • 3732 workspace tests pass across all crates, 0 failures.
  • 3758 workspace tests pass across all crates, 0 failures.
  • 3773 workspace tests pass across all crates, 0 failures.
  • 3816 workspace tests pass across all crates, 0 failures.
  • 3823 workspace tests pass across all crates, 0 failures.
  • 3833 workspace tests pass across all crates, 0 failures.
  • 3839 workspace tests pass across all crates, 0 failures.
  • 3852 workspace tests pass across all crates, 0 failures.
  • 3857 workspace tests pass across all crates, 0 failures.
  • 3860 workspace tests pass across all crates, 0 failures.
  • 3866 workspace tests pass across all crates, 0 failures.
  • 3869 workspace tests pass across all crates, 0 failures.
  • 3889 workspace tests pass across all crates, 0 failures.
  • 3898 workspace tests pass across all crates, 0 failures.
  • 3902 workspace tests pass across all crates, 0 failures.
  • 3905 workspace tests pass across all crates, 0 failures.
  • 3916 workspace tests pass across all crates, 0 failures.
  • 3917 workspace tests pass across all crates, 0 failures.
  • 3922 workspace tests pass across all crates, 0 failures.
  • 3932 workspace tests pass across all crates, 0 failures.
  • 3954 workspace tests pass across all crates, 0 failures.
  • 3962 workspace tests pass across all crates, 0 failures.
  • 3966 workspace tests pass across all crates, 0 failures.
  • 3972 workspace tests pass across all crates, 0 failures.
  • 3977 workspace tests pass across all crates, 0 failures.
  • 3997 workspace tests pass across all crates, 0 failures.
  • 4021 workspace tests pass across all crates, 0 failures.
  • 4032 workspace tests pass across all crates, 0 failures.
  • 4035 workspace tests pass across all crates, 0 failures.
  • 4046 workspace tests pass across all crates, 0 failures.
  • 4057 workspace tests pass across all crates, 0 failures.
  • 4061 workspace tests pass across all crates, 0 failures.
  • 4066 workspace tests pass across all crates, 0 failures.
  • 4074 workspace tests pass across all crates, 0 failures.
  • 4087 workspace tests pass across all crates, 0 failures.
  • 4102 workspace tests pass across all crates, 0 failures.
  • 4108 workspace tests pass across all crates, 0 failures.
  • 4113 workspace tests pass across all crates, 0 failures.
  • 4114 workspace tests pass across all crates, 0 failures.
  • 4115 workspace tests pass across all crates, 0 failures.
  • 4116 workspace tests pass across all crates, 0 failures.
  • 4119 workspace tests pass across all crates, 0 failures.
  • 4123 workspace tests pass across all crates, 0 failures.
  • 4126 workspace tests pass across all crates, 0 failures.
  • 4128 workspace tests pass across all crates, 0 failures.
  • 4131 workspace tests pass across all crates, 0 failures.
  • 4137 workspace tests pass across all crates, 0 failures.
  • 4141 workspace tests pass across all crates, 0 failures.
  • 4200 workspace tests pass across all crates, 0 failures.
  • 4208 workspace tests pass across all crates, 0 failures.
  • 4210 workspace tests pass across all crates, 0 failures.
  • LocalStateQuery NtC server expanded with 3 new upstream tags: (18) GetGenesisDelegations returns the active gen_delegs map as CBOR { genesis_hash_bytes => [delegate_hash_bytes, vrf_hash_bytes] } mirroring upstream dsGenDelegs (Cardano.Ledger.Shelley.LedgerState.DPState); (19) GetStabilityWindow returns the configured 3k/f window as a u64 or CBOR null when unset (upstream Ouroboros.Consensus.HardFork.History.Util stability-window derivation); (20) GetNumDormantEpochs returns the consecutive dormant-epoch counter as a u64 (upstream csNumDormantEpochs from Cardano.Ledger.Conway.Governance.DRepPulser). LedgerStateSnapshot extended with three new fields (gen_delegs, stability_window, num_dormant_epochs) populated from LedgerState::snapshot() plus matching read-only accessors. Three new unit tests in node/src/local_server.rs lock in the on-wire CBOR ({} → 0xa0, unset window → 0xf6, zero dormant → 0x00). BasicLocalQueryDispatcher now serves 21 distinct upstream Ouroboros.Consensus.Shelley.Ledger.Query tags (0–20).
  • 4203 workspace tests pass across all crates, 0 failures.
  • TxSubmission inbound shared-state byte accounting parity: crates/consensus/src/mempool::tx_state now mirrors upstream Ouroboros.Network.TxSubmission.Inbound.V2.State byte tracking. PeerTxState carries in_flight_sizes: HashMap<TxId, SizeInBytes> + inflight_bytes: u64 (upstream requestedTxsInflightSize); TxState carries inflight_bytes_total: u64 (upstream inflightTxsSize). New API surface: type alias SizeInBytes = u32, sized variant mark_in_flight_sized(peer, &[(TxId, SizeInBytes)]), accessors peer_inflight_bytes(peer) / inflight_bytes_total(), all mirrored on SharedTxState. Existing lifecycle methods (mark_received, mark_not_found, mark_confirmed, unregister_peer) all decrement per-peer + global byte totals when the entry was sized. node/src/server.rs::run_txsubmission_server now threads the already-collected advertised_sizes into mark_in_flight_sized so per-peer byte totals reflect what each peer advertised; previously bytes-in-flight were untracked and unbounded. 3 new tx_state tests bring the module total to 14: per-peer + global byte accounting across the full lifecycle, unregister-decrements-bytes, sized round-trip on SharedTxState. The unsized mark_in_flight() API is preserved for backward compatibility.
  • 4206 workspace tests pass across all crates, 0 failures.
  • TxSubmission per-peer in-flight byte budget enforcement (Ouroboros.Network.TxSubmission.Inbound.V2.Policy maxTxsSizeInflight): node/src/server.rs::run_txsubmission_server now gates MsgRequestTxs dispatch on the per-peer byte counter introduced last slice (SharedTxState::peer_inflight_bytes). New MAX_TXS_SIZE_INFLIGHT_PER_PEER = 64 KiB constant (matches upstream policy default). After filter_advertised returns the to_fetch set, a new pure helper select_within_byte_budget(candidates, sizes, budget_remaining) -> (admitted, deferred) greedily admits a prefix while cumulative advertised bytes stay at or below budget_remaining = MAX - peer_inflight_bytes(peer), always admitting the first candidate to guarantee forward progress (mirrors upstream collectTxs behaviour where a single oversize tx still gets requested). Deferred candidates are NOT acknowledged on the wire: ack is now advertised_count - deferred instead of unconditionally txids.len(), so the peer keeps deferred TxIds in its outbound queue and re-advertises them once prior fetches drain the per-peer byte counter via mark_received/mark_not_found/mark_confirmed. Already-known TxIds (filtered by cross-peer dedup) continue to be acked in full. 4 new helper tests cover oversize-first-admit, greedy-prefix-then-defer, zero-budget-still-admits-one, and missing-size-treated-as-zero. Crate boundary preserved: byte counters live in crates/consensus/src/mempool, wire-level enforcement lives in node/.
  • 4210 workspace tests pass across all crates, 0 failures.
  • TxSubmission inbound unacknowledged-set leak fix (Ouroboros.Network.TxSubmission.Inbound.V2.State.PeerTxState): crates/consensus/src/mempool::tx_state::TxState::filter_advertised previously inserted EVERY advertised TxId into peer_state.unacknowledged, including items immediately classified as already_known via cross-peer dedup. Already-known items are acked on the wire and never enter the per-peer fetch lifecycle, so they were never removed from unacknowledged and the set grew unboundedly across rounds for every duplicate advertisement. After the fix, only to_fetch items are added to unacknowledged; already_known items skip the per-peer set entirely. Two new accessors (TxState::peer_unacked_count(peer) and SharedTxState::peer_unacked_count(peer)) expose the per-peer count, mirroring upstream unacknowledgedTxIds length. 1 new regression test (already_known_advertisements_do_not_leak_into_unacknowledged) verifies the count stays at 0 across repeated duplicate advertisements from a second peer after the first peer has already confirmed the same TxId.
  • 4211 workspace tests pass across all crates, 0 failures.
  • TxSubmission per-peer outstanding-TxIds cap (Ouroboros.Network.TxSubmission.Inbound.V2.Policy maxUnacknowledgedTxIds): node/src/server.rs::run_txsubmission_server now clamps the requested batch size on each MsgRequestTxIds so the per-peer outstanding (advertised-but-not-yet-finalized) TxIds count stays at or below MAX_UNACKNOWLEDGED_TXIDS_PER_PEER = 64 (mirrors upstream policy default surface). Computation is req = min(TXSUBMISSION_BATCH_SIZE, MAX_UNACKED - (peer_unacked_count - ack)).max(1), where the wire-level ack is subtracted from local peer_unacked_count to model the peer-side decrement that the ack will cause, and .max(1) guarantees the loop always makes forward progress when the peer has any capacity. Acts as a safety bound on the per-peer unacknowledged set so a peer cannot indefinitely starve a slot by repeatedly advertising deferred TxIds that never get fetched. Builds on the prior peer_unacked_count accessor and the byte-budget gate.
  • 4211 workspace tests pass across all crates, 0 failures.
  • TxSubmission unacked-cap clamp extracted to pure helper (node/src/server.rs::clamp_request_count): the inline req computation from the previous slice is now a free function clamp_request_count(peer_unacked_count, ack, batch, max_unacked) -> u16 that returns the post-ack-headroom-clamped batch size with a .max(1) floor for forward progress. The loop body in run_txsubmission_server now calls the helper directly. 4 new focused unit tests lock in the arithmetic at the boundaries: full-batch when headroom > batch, partial when headroom < batch, single-tx forward-progress floor at peer-cap, and the upstream-required ack widening (peer at cap with ack=batch must request a full new batch, not 1).
  • 4215 workspace tests pass across all crates, 0 failures.
  • TxSubmission per-peer in-flight TxIds count accessor (Ouroboros.Network.TxSubmission.Inbound.V2.State.PeerTxState requestedTxsInflight set size): crates/consensus/src/mempool::tx_state::TxState::peer_inflight_count(&peer) -> usize and the matching SharedTxState::peer_inflight_count proxy now expose the per-peer count of TxIds that have been requested via MsgRequestTxs but not yet finalized (received / not-found / confirmed). Mirrors the upstream set whose size is consulted by Decision.txDecision for fairness/limit checks; complements the existing per-peer byte (peer_inflight_bytes) and unacked (peer_unacked_count) accessors so the per-peer view of in-flight work is now complete in the three upstream dimensions (count, byte total, outstanding-TxIds count). Single regression test exercises the full lifecycle (mark_in_flight_sized → mark_received → mark_not_found → mark_confirmed → unregister_peer) plus the unknown-peer-reads-as-zero edge case and the SharedTxState proxy.
  • 4216 workspace tests pass across all crates, 0 failures.
  • TxSubmission global aggregate in-flight byte budget enforcement (Ouroboros.Network.TxSubmission.Inbound.V2.Policy maxTxsSizeInflight, sibling of the per-peer txsSizeInflightPerPeer): node/src/server.rs::run_txsubmission_server now caps cumulative bytes in flight across ALL peers via the new MAX_TXS_SIZE_INFLIGHT_TOTAL = 64 KiB * 32 = 2 MiB constant. The per-iteration budget_remaining is now min(per_peer_remaining, global_remaining) where global_remaining = MAX_TXS_SIZE_INFLIGHT_TOTAL.saturating_sub(SharedTxState::inflight_bytes_total()). Bounds aggregate runtime memory consumption when many peers concurrently advertise large transaction backlogs even if no individual peer is near its own per-peer cap. Existing MAX_TXS_SIZE_INFLIGHT_PER_PEER constant comment corrected to cite upstream txsSizeInflightPerPeer (the per-peer policy field) instead of the global field. Reuses the existing select_within_byte_budget helper and inflight_bytes_total() accessor; no new state, no new tests required (helper arithmetic and accessor lifecycle are already covered).
  • 4216 workspace tests pass across all crates, 0 failures.
  • TxSubmission per-peer in-flight TxIds COUNT cap (sibling of the per-peer byte cap, expressed as a count rather than bytes): node/src/server.rs::run_txsubmission_server now also bounds the per-peer requestedTxsInflight set size via the new MAX_TXS_REQUESTED_PER_PEER = 32 constant (mirrors upstream Ouroboros.Network.TxSubmission.Inbound.V2.State.PeerTxState.requestedTxsInflight whose size is consulted by Decision.txDecision). New pure helper clamp_to_count_budget(candidates, budget_remaining) -> (admitted, deferred) greedily truncates to a count budget with a first-admit forward-progress guarantee mirroring select_within_byte_budget. Wired into the request loop BEFORE the byte-budget step so a peer advertising many small transactions cannot monopolize the per-peer fetch slot even when bytes-in-flight remain low; total deferred = count_deferred + byte_deferred so wire-level ack correctly reflects what is consumed from the peer’s outbound queue. Wires the previously-unused peer_inflight_count accessor (added two slices ago) into runtime enforcement. 4 new helper tests cover under-cap full admission, truncation to remaining headroom, single-tx forward progress at peer-cap, and empty-input no-op. Also corrects a residual-bound off-by-one in the pre-existing global_cap_composes_min_with_per_peer_cap test (<= 1500 → <= 1500 + chunk) since the test loop stops one chunk short of target_global_used rather than landing exactly on it.
  • 4221 workspace tests pass across all crates, 0 failures.
  • TxSubmission inbound peer-state leak fix on MsgRequestTxIds error path (upstream bracketTxSubmissionPeer cleanup parity in Ouroboros.Network.TxSubmission.Inbound.V2.Server): node/src/server.rs::run_txsubmission_server previously propagated request_tx_ids errors via the ? operator without first calling tx_state.unregister_peer(peer_addr) on the shared dedup state — a transport / protocol error on the blocking MsgRequestTxIds would leak the peer’s PeerTxState entry along with any inflight_bytes and inflight_count it had recorded, causing repeated reconnects to inflate inflight_bytes_total and peer_inflight_count indefinitely (eventually saturating both the per-peer and global byte budgets). Now the call is destructured: on Err(e) the peer is unregistered before return Err(e), mirroring the existing cleanup blocks on the three downstream error paths (request_txs error, request_txs timeout, and the consumer-rejected branch). No new state, no behaviour change on the success path; the four lifecycle accessors (peer_inflight_bytes, peer_inflight_count, peer_unacked_count, inflight_bytes_total) now correctly drain on every error path.
  • 4221 workspace tests pass across all crates, 0 failures.
  • TxSubmission inbound partial MsgReplyTxs reply handling fix (upstream Ouroboros.Network.TxSubmission.Inbound.V2.Server partial-reply parity): node/src/server.rs::run_txsubmission_server previously called tx_state.mark_received(peer_addr, &to_request) on EVERY response regardless of whether the peer actually delivered all requested bodies. When the peer returned fewer txs than requested (e.g. its mempool dropped some between MsgReplyTxIds and MsgRequestTxs), the missing TxIds were still inserted into the shared known ring — poisoning it with TxIds whose body never arrived and permanently blocking ANY peer from supplying them. The per-peer in_flight count and bytes were also incorrectly drained as if the bodies had been received. Fixed: on length mismatch (txs.len() != to_request.len()) the entire batch is now routed through mark_not_found instead, which (1) drains per-peer count/bytes counters correctly, (2) removes the TxIds from global_in_flight so another peer may supply them, and (3) does NOT poison known with TxIds whose body never arrived. Mirrors upstream behaviour where missing bodies in MsgReplyTxs are routed back through the not-acknowledged pathway for re-fetch from another peer. The exact-length success path is unchanged. Reuses the well-tested mark_not_found lifecycle in crates/consensus/src/mempool::tx_state (mark_not_found_frees_for_another_peer test confirms the cross-peer dedup release).
  • 4221 workspace tests pass across all crates, 0 failures.
  • ChainSync reconnect parity: synchronize_chain_sync_to_point() in node/src/runtime.rs now issues MsgFindIntersect with the locally-tracked from_point immediately after every bootstrap_with_attempt_state() (initial coordinated-storage resume + 3 reconnecting inner loops). Without this call, freshly-bootstrapped peers default their read pointer to Origin and return a full MsgRollBackward to genesis on the first MsgRequestNext, causing the in-memory ledger to be reset and re-replayed across volatile/immutable storage on every disconnect. With the fix, live preprod soak demonstrates a peer disconnect at slot 112440 followed by a re-established session that resumes from slot 112620 (180 slots later) and continues forward past slot 136420; previously the next checkpoint after the same disconnect was at slot 15122 (full Byron replay). On MsgIntersectNotFound the helper resets from_point to Point::Origin so the next batch starts a clean genesis sync (matching upstream chainSyncClientPeer behaviour). Verified-batch test mocks in node/tests/runtime.rs accept an optional MsgFindIntersect prelude before MsgRequestNext, responding with MsgIntersectFound for the requested point. Reference: Ouroboros.Network.Protocol.ChainSync.Client.chainSyncClientPeer.
  • 4172 workspace tests pass across all crates, 0 failures.
  • KeepAlive parity: two related fixes in crates/network/src/protocols/keep_alive.rs and node/src/runtime.rs. First, the KeepAliveMessage CBOR codec had MsgDone and MsgKeepAliveResponse tags swapped relative to upstream — the on-wire encoding now matches Ouroboros.Network.Protocol.KeepAlive.Codec: MsgKeepAlive=[0,cookie], MsgKeepAliveResponse=[1,cookie], MsgDone=[2]. Without this fix every server reply decoded as CBOR type mismatch (expected major 0, got 1), causing the new keepalive driver to tear down the connection on every heartbeat. Second, the three reconnecting verified-sync inner loops in node/src/runtime.rs now send a MsgKeepAlive heartbeat every 20 s of wall-clock against session.keep_alive via a shared KeepAliveScheduler helper (KEEPALIVE_HEARTBEAT_INTERVAL constant), so peers no longer close the connection due to upstream keepAliveTimeout (~97 s default). A keepalive_cbor_wire_tags_match_upstream integration test locks in the on-wire byte mapping. Live preprod soak result with both fixes applied: 30 minutes wall-clock, 0 disconnects, 0 keepalive errors, 0 panics, 0 unexpected errors, sustained sync to slot 517,640 (well past the Byron→Shelley boundary at slot 86,400) with all four Byron epoch boundaries (newEpoch=1..4) cleanly applied — previously a 600 s soak suffered a ChainSync/BlockFetch disconnect every ~97 s and never reached the Shelley region cleanly.
  • 4175 workspace tests pass across all crates, 0 failures.
  • 4189 workspace tests pass across all crates, 0 failures.
  • 4195 workspace tests pass across all crates, 0 failures.
  • 4198 workspace tests pass across all crates, 0 failures.
  • 4199 workspace tests pass across all crates, 0 failures.
  • BlockFetch pool runtime lifecycle wiring (node-side helpers in node/src/runtime.rs, pool data + decision logic remain in crates/network::blockfetch_pool): pool_register_peer() invoked after every successful bootstrap_with_attempt_state() so each connected peer gets an explicit BlockFetchPool entry (upstream addNewFetchClient/bracketFetchClient from Ouroboros.Network.BlockFetch.ClientRegistry); pool_update_fragment_head() called after every successful verified-batch record_verified_batch_progress() so PeerFetchState.fragment_head tracks the live current_point per peer (upstream setFetchClientFragment from Ouroboros.Network.BlockFetch.ClientState); pool_should_demote_peer() consulted in the Err branch of every batch — when consecutive failures exceed DEFAULT_FAILURE_DEMOTION_THRESHOLD (=3, upstream maxFetchClientFailures) the runtime emits a Net.BlockFetch.PoolDemote warning trace before the existing BatchErrorDisposition demotes the peer through the governor; pool_unregister_peer() called on every batch-error teardown to free the per-peer slot for the next reconnection (upstream removeFetchClient). All four helpers tolerate Option<&BlockFetchInstrumentation> (default None preserves existing single-peer behaviour byte-for-byte) and are wired into all three reconnecting verified-sync loops (resumed-from-disk, fresh sync, in-memory). Pre-existing per-peer counters (note_dispatch/note_success/note_failure) plus the new lifecycle wiring give the pool a complete FetchClientStateVars-equivalent runtime view ready for follow-up multi-peer fan-out work. Integration test runtime_verified_sync_records_blockfetch_pool_per_peer_counters extended with two new assertions — explicit pool-entry presence (proves pool_register_peer ran) and fragment-head presence (proves pool_update_fragment_head ran).
  • BlockFetch pool runtime instrumentation wired (crates/network::BlockFetchInstrumentation = Arc<Mutex<BlockFetchPool>>). VerifiedSyncServiceConfig.block_fetch_pool: Option<BlockFetchInstrumentation> (re-exported as yggdrasil_node::sync::BlockFetchInstrumentation) is threaded through sync_batch_apply_verified → sync_batch_verified → sync_batch_verified_with_tentative and into the verified-sync fetch site so per-peer dispatch / success / failure are recorded synchronously around each MsgRequestRange round-trip (no .await held under the std Mutex). BlockFetchPool gains pool-level convenience wrappers note_dispatch(peer) / note_success(peer, blocks, bytes, now) / note_failure(peer) plus peer_state(peer) accessor — all auto-register the peer entry on first touch so the runtime does not need to manage the registry lifecycle separately. All 11 VerifiedSyncServiceConfig construction sites updated; default remains None so existing single-peer concurrency is unchanged. Mirrors upstream bumpFetchClientStateVars and FetchClientStateVars in Ouroboros.Network.BlockFetch.ClientState. 3 new pool tests bring the module total to 23.
  • BlockFetch pool extended (crates/network::blockfetch_pool) with peer_failure_should_demote() + DEFAULT_FAILURE_DEMOTION_THRESHOLD=3 (upstream maxFetchClientFailures) and pure split_range(lower, upper, n_chunks) slicer that produces N contiguous sub-ranges (first chunk uses real lower, last chunk uses real upper, intermediate boundaries carry placeholder HeaderHash for the runtime to resolve via ChainSync candidate-fragment lookup before issuing MsgRequestRange). 6 new tests cover demotion threshold, single-range fallback, Origin-lower fallback, contiguity, short-span fallback, and end-to-end split → distinct-peer scheduling. Mirrors upstream selectForkSuffixes slicing in Ouroboros.Network.BlockFetch.Decision.
  • Multi-peer concurrent BlockFetch foundation laid in crates/network::blockfetch_pool (per upstream split — Ouroboros.Network.BlockFetch.{Decision,ClientRegistry,ClientState,State} all live in ouroboros-network, not cardano-node). Pure data structures + decision logic, no I/O, no protocol clients held: FetchMode (BulkSync/Deadline) selects per-peer concurrency cap (upstream bfcMaxConcurrencyBulkSync=2 / bfcMaxConcurrencyDeadline=1); PeerFetchState tracks in_flight, blocks_delivered, bytes_delivered, consecutive_failures, last_success, fragment_head; BlockFetchPool registers peers and runs schedule(ranges) returning Vec<Option<RangeAssignment>> with global MAX_REQUESTS_IN_FLIGHT=10 cap, per-peer concurrency gating, fragment-head coverage check, and lowest-(in_flight, -blocks_delivered, recency) tiebreaker; ReorderBuffer<B> accepts out-of-order delivered ranges, releases them in ascending lower-slot order strictly past the current head (Origin head holds until set_head is called, preventing premature release on from-genesis sync). Wiring into node/src/runtime.rs + node/src/sync.rs is a follow-up slice gated on a runtime config so the proven single-peer pipeline remains the default. 14 unit tests in crates/network/src/blockfetch_pool.rs.
  • PlutusData decode hardening: PlutusData::decode_cbor now dispatches through decode_with_depth(&mut Decoder, depth_remaining) with a MAX_DECODE_DEPTH = 256 budget that decrements at every container boundary (List, Map entries, Constr fields, indefinite variants). Exceeding the cap returns the new LedgerError::CborNestingTooDeep { max } cleanly instead of letting a malicious or malformed Alonzo+ block CBOR overflow the runtime stack via unbounded recursion. Two integration tests cover the boundary: one nested MAX_DECODE_DEPTH + 32 deep returns the depth error without panicking; one nested MAX_DECODE_DEPTH - 1 deep decodes successfully and round-trips. Mirrors the defensive bound used in upstream Plutus’ lazy CBOR decoder; the value is well above any real-world Cardano PlutusData while still bounding worst-case recursion.
  • Code-quality sweep: cargo clippy --workspace --release --no-deps is now warning-free (8 prior format/clone/match warnings fixed in node/src/sync.rs and crates/network/src/blockfetch_client.rs via shared bytes_to_hex helper, if let Ok(_), collapsed nested if, and dropped Copy clone). cargo doc --workspace --no-deps --release is now warning-free (49 prior unresolved-link warnings fixed across plutus, ledger, storage, node, and 10 network protocol drivers by switching [name] references to either [Self::method], fully qualified paths, or backtick code spans). No behavior changes.
  • Baseline-restoration slice: two related fixes that put the workspace back to a clean cargo check-all / cargo lint / cargo test-all triple. (1) node/src/main.rs was referencing inbound_tx_state outside the if let Some(listen_addr) block where it was previously declared, so the binary did not compile when the inbound listener path was disabled; the shared SharedTxState::default() is now created unconditionally before the inbound branch and cloned into the spawned accept loop, mirroring how the same handle is threaded into the reconnecting sync request. (2) crates/ledger::PlutusData decode and destruction were recursive at MAX_DECODE_DEPTH = 256, so the two existing depth-boundary tests (decode_pathologically_deep_list_rejected_without_overflow and decode_list_at_max_depth_succeeds) overflowed the default 2 MB Rust thread stack in debug builds. decode_with_depth is now an iterative work-stack decoder (heap-resident Vec<Frame> with Frame::Seq { kind: List | Constr(alt), remaining, children } / Frame::Map { remaining, entries, pending_key } variants and a frame_complete predicate that folds completed definite-length frames upward; indefinite-length frames fold when the CBOR break marker appears). The depth bound now caps stack.len() rather than native call-stack depth, so the iterative decoder runs in constant native stack regardless of input shape and MAX_DECODE_DEPTH = 256 is now a pure policy limit (well above any realistic on-chain Plutus payload). The auto-derived recursive Drop for Vec<PlutusData> survives at this depth in debug builds because per-Drop frames are far smaller than the old per-decode_with_depth frames. Reference: defensive bound — upstream Haskell relies on lazy CPS for stack-safe PlutusData decoding, the Rust port now achieves the same property explicitly. 4221 workspace tests pass across all crates, 0 failures.
  • PlutusData encoder iterative-rewrite (symmetric counterpart to the iterative decoder slice): <PlutusData as CborEncode>::encode_cbor is now an explicit depth-first traversal driven by a heap-resident Vec<&PlutusData> work stack, mirroring upstream Haskell’s stack-safe lazy CPS encoding. Children are pushed in reverse order so pop ordering produces the exact same byte sequence as the previous recursive pre-order encoder; for Map entries the value is pushed before the key so the next pop yields the key first, preserving upstream key, value emission order. Closes the symmetric stack-overflow gap with the decoder: any value the iterative decoder accepts up to MAX_DECODE_DEPTH = 256 can now also be re-serialised for relay without risk of native-stack overflow. New regression test encode_deeply_nested_list_does_not_overflow builds a MAX_DECODE_DEPTH - 1 deep List value from the inside out and asserts the canonical byte sequence ([0x81] * (MAX_DEPTH - 1) + 0x00) plus a round-trip through the iterative decoder. Reference: Cardano.Ledger.Plutus.Data.Data — upstream encoding stack-safety. 4222 workspace tests pass across all crates, 0 failures.
  • NativeScript stack-safety hardening (sibling slice to the PlutusData decoder + encoder rewrites): crates/ledger::eras::allegra::NativeScript is recursive in three places (CBOR decoder, CBOR encoder, and the timelock evaluator in crates/ledger::native_script::evaluate_native_script); all three are now iterative with explicit heap-resident work stacks so adversarially-deep witnesses cannot blow the runtime stack on decode, re-serialise, or evaluation. Decoder gains a MAX_DECODE_DEPTH = 256 policy bound mirroring PlutusData::MAX_DECODE_DEPTH; exceeding it returns LedgerError::CborNestingTooDeep cleanly. The decoder stacks Frame { kind: ScriptAll | ScriptAny | ScriptNOfK(n), remaining, children } entries and folds them when each frame’s expected-children count reaches zero; the encoder is a depth-first, in-order traversal that pushes children in reverse so pop order produces the exact same byte sequence the previous recursive pre-order encoder did; the evaluator splits each tree node into an Eval(node) action that expands children into more Eval actions plus a trailing Combine { kind, child_count } action that consumes the right number of leaf booleans from a results stack and folds them into one. Note: the evaluator no longer short-circuits (the original iter().all() / iter().any() / take(required) did) but the returned boolean is identical because every branch is pure and side-effect-free. New tests deeply_nested_script_all_round_trips_iteratively (encode/decode/evaluate at MAX_DECODE_DEPTH - 1 nesting) and pathologically_deep_native_script_rejected_without_overflow (decoder rejects MAX_DECODE_DEPTH + 16 deep input cleanly). Reference: Cardano.Ledger.Allegra.Scripts — Timelock codec; evalTimelock. 4224 workspace tests pass across all crates, 0 failures.
  • Plutus flat decoder depth bound (third stack-safety slice in this series): crates/plutus::flat previously had no bound on the recursive decode_term / build_type / build_applied_type / decode_constant chain that walks attacker-controlled UPLC bytes from witness sets; a malicious script with deeply nested Apply / LamAbs / Constr / List / Pair could overflow the runtime stack on flat decode well before the CEK machine ever ran. New pub const MAX_TERM_DECODE_DEPTH: usize = 128 is now threaded through the recursive path as decode_term_with_depth, decode_type_list_with_depth, build_type_with_depth, build_applied_type_with_depth, and decode_constant_with_depth; each entry checks depth_remaining == 0 and returns MachineError::FlatDecodeError cleanly with a descriptive message before recursing further. The bound is sized for the recursive decoder’s per-frame footprint (debug-build frames hold local Box<Term> allocations + large match scaffolding so 256 overflows the default 2 MB Rust thread stack at ~256 frames, while 128 fits with comfortable headroom and still sits well above any realistic on-chain script). Public decode_term() is preserved as a wrapper for the existing 15 test call sites; the other depth-aware variants are crate-internal to keep the API surface minimal. New regression test test_decode_term_rejects_pathologically_deep_lambda_chain builds a MAX_TERM_DECODE_DEPTH + 16 chain of LamAbs Flat tags + a final Error tag and asserts the depth-budget error fires cleanly. Reference: PlutusCore.Untyped.Flat upstream; defensive bound. 4225 workspace tests pass across all crates, 0 failures.
  • TxSubmission outbound RequestTxs lookup performance fix (node/src/runtime.rs::serve_txsubmission_request_from_mempool): the previous implementation did mempool.iter().find(|entry| entry.tx_id == txid) once per requested id, producing O(n*m) work for each MsgRequestTxs round-trip (mempools commonly hold thousands of entries; a 100-tx batch did ~500k comparisons). The reply now builds an O(n) one-pass index HashMap<TxId, &Vec<u8>> filtered to just the requested set, then walks the requested order with O(1) lookups, bringing the per-call cost to O(n + m) without changing the on-wire reply order or the missing-id silent-skip semantics. Reference: Ouroboros.Network.TxSubmission.Outbound.txSubmissionOutbound. 4225 workspace tests pass across all crates, 0 failures.
  • Mempool membership-index slice (crates/consensus/src/mempool::Mempool): added a tx_ids: HashSet<TxId> field so duplicate detection in insert, presence check in contains, and absence-short-circuit in remove_by_id all run in O(1) instead of the prior O(n) entries.iter().any(...) scans. The fee-ordered Vec<IndexedMempoolEntry> queue stays the source of truth for ordering and fee-best iteration; the index stores no positional information so it survives the full per-insert resort. Every mutator path (insert, pop_best, remove_by_id, remove_confirmed, remove_conflicting_inputs, purge_expired, revalidate, purge_invalid_for_params, revalidate_with_ledger) now keeps the index in sync. remove_by_id also includes a self-healing fallback that scrubs a stale index entry if the entries scan disagrees, so the invariant cannot drift even under partial-write surprises. New regression test membership_index_stays_in_sync_across_full_lifecycle exercises insert / pop_best / remove_by_id (present and absent) / remove_confirmed / re-insert / purge_expired and locks in contains semantics across each step. Reference: Ouroboros.Consensus.Mempool.Impl.Common — duplicate-id rejection. 4226 workspace tests pass across all crates, 0 failures.
  • TxSubmissionClient outstanding-txid membership index (crates/network::TxSubmissionClient): the duplicate-advertisement check in reply_tx_ids previously did outstanding_txids.iter().any(|t| *t == item.txid) once per advertised id, costing O(N*M) where N = batch size and M = outstanding FIFO depth (both up to the upstream policy cap of 64, so a few thousand comparisons per round-trip in steady state). Added outstanding_txid_set: HashSet<TxId> mirroring the FIFO membership; the duplicate check is now O(1) per id while the FIFO retains its insertion order for ack draining. Both mutating paths (reply_tx_ids push_back and apply_acknowledgements pop_front) update the set in lockstep with a debug_assert_eq!(fifo.len(), set.len()) guard so any future drift fails immediately in dev / test builds. The post-served re-advertisement case stays correctly rejected because the set is only drained on ack, not on MsgRequestTxs (which only drains requestable_txids). Reference: Ouroboros.Network.TxSubmission.Inbound.unacknowledgedTxIds. 4226 workspace tests pass across all crates, 0 failures.
  • MempoolSnapshot lookup index slice (crates/consensus/src/mempool::MempoolSnapshot): the snapshot’s mempool_lookup_tx_by_id and mempool_has_tx previously did entries.iter().find/any(...) so the TxSubmission outbound serve_txsubmission_request_from_snapshot_reader path was O(M*N) per MsgRequestTxs round-trip (M = batch size up to the policy cap, N = mempool size). Added tx_id_to_pos: HashMap<TxId, usize> built once during Mempool::snapshot() (one extra O(n) pass alongside the existing Vec clone) so per-call lookups are O(1) and the outbound batch becomes O(M + N). Snapshots are short-lived and immutable so no in-sync maintenance is needed beyond construction; the index references the cloned entries Vec by position so it cannot drift. The peer-side serve_txsubmission_request_from_mempool was already fixed for the non-snapshot path in the prior slice; this closes the symmetric gap for the snapshot-reader variant used by run_txsubmission_service / run_txsubmission_service_shared. Reference: Ouroboros.Network.TxSubmission.Mempool.Reader. 4226 workspace tests pass across all crates, 0 failures.
  • Doc-link cleanup: the four iterative-codec slices earlier in this session referenced private items from public Rustdoc (FlatDecoder::decode_term, Self::decode_with_depth, <Self as CborDecode>::decode_cbor), which cargo doc --workspace --no-deps flags as unresolved-link warnings. Switched the offending docstrings in crates/plutus/src/flat.rs and crates/ledger/src/{plutus.rs, eras/allegra.rs} to backtick code spans (or rephrased into the trait-level reference) so the doc build is now warning-free again, matching the prior code-quality sweep that took cargo doc --workspace --no-deps --release to zero warnings. No behaviour change. 4226 workspace tests pass across all crates, 0 failures.
  • Upstream config-key alias slice (node/src/config.rs::NodeConfigFile): the six governor target peer count fields (governor_target_known / _established / _active plus the three _big_ledger variants) now accept the official cardano-node PascalCase keys (TargetNumberOfKnownPeers, TargetNumberOfEstablishedPeers, TargetNumberOfActivePeers, and the *BigLedgerPeers siblings) as serde aliases, so an operator-supplied config.json from upstream can be loaded directly instead of needing to be hand-translated into the Rust crate’s snake_case keys. Extends the same alias pattern already used for peer_sharing (PeerSharing) and consensus_mode (ConsensusMode). Reference: cardano-node/configuration/cardano/mainnet-config.json TargetNumberOfKnownPeers etc. New regression test config_parses_upstream_target_peer_count_aliases locks in the binding for all six fields. 4227 workspace tests pass across all crates, 0 failures.
  • Upstream config-key alias slice (continued): node/src/config.rs::NodeConfigFile.max_major_protocol_version now also accepts the upstream operator-config key MaxKnownMajorProtocolVersion (verified present in the vendored node/configuration/mainnet/config.json), so an unmodified upstream config.json can be loaded directly. Extends the same alias pattern used for the six governor target peer counts in the prior slice. New regression test config_parses_max_known_major_protocol_version_upstream_alias. Reference: cardano-node/configuration/cardano/mainnet-config.json MaxKnownMajorProtocolVersion. 4228 workspace tests pass across all crates, 0 failures.
  • Genesis hash verification slice (operator-trust parity, upstream Cardano.Node.Configuration.POM.parseGenesisHash): the Rust port previously parsed *GenesisFile paths but silently ignored the operator-declared *GenesisHash keys, so a wrong genesis file (typo, supply-chain swap, partial download) would silently corrupt all subsequent ledger state. New crates/node::genesis::compute_genesis_file_hash(path) -> [u8;32] reads the file and computes Blake2b-256, matching upstream’s hashing for Shelley / Alonzo / Conway (raw-file hash). New verify_genesis_file_hash(path, expected_hex, field) -> Result<(), GenesisLoadError> parses the expected hex digest (rejecting non-hex / wrong-length input as InvalidHashHex) and compares; mismatches surface as the new GenesisLoadError::HashMismatch { path, expected, actual }. NodeConfigFile gains four optional Option<String> hash fields with PascalCase serde renames (ShelleyGenesisHash, AlonzoGenesisHash, ConwayGenesisHash, ByronGenesisHash) so unmodified upstream config.json files are now parsed. New NodeConfigFile::verify_known_genesis_hashes(base_dir) originally walked the three Shelley-family pairs and short-circuited on the first mismatch; R244 supersedes that partial state and verifies Byron too using upstream Canonical JSON rendering before Blake2b-256. The verification is wired into main.rs::strict_base_ledger_state() BEFORE any genesis content is loaded, so a wrong file aborts startup cleanly with a typed error rather than silently producing a corrupted base LedgerState. The three preset constructors mainnet_config() / preprod_config() / preview_config() now ship the canonical hashes from node/configuration/{network}/config.json; an integrity check against the vendored files therefore runs on every --network <preset> startup. New tests: compute_genesis_file_hash_matches_blake2b_256_of_raw_bytes, verify_genesis_file_hash_accepts_correct_hash, verify_genesis_file_hash_rejects_mismatch, verify_genesis_file_hash_rejects_invalid_hex (genesis module); config_parses_upstream_genesis_hash_aliases, verify_known_genesis_hashes_passes_when_files_match, verify_known_genesis_hashes_short_circuits_on_first_mismatch, and the end-to-end vendored_preset_hashes_match_vendored_genesis_files_end_to_end which exercises verify_known_genesis_hashes against each preset’s vendored node/configuration/<network>/ directory (verified at that slice: 9/9 Shelley-family hashes matched; R244 extends this to all 12 preset genesis hash/file pairs). 4236 workspace tests pass across all crates, 0 failures.
  • Genesis hash verification — preflight integration: node/src/main.rs::validate_config_report (the validate-config operator preflight) now calls verify_known_genesis_hashes and surfaces any mismatch as a non-fatal warning in the report so an operator running the preflight scan sees the corruption flag alongside other warnings (storage uninitialized, peer snapshot missing, etc.) rather than only seeing the first error. Crucially, the actual run path still bails on mismatch via strict_base_ledger_state so a misconfigured node cannot start; the preflight is purely diagnostic. New regression test validate_config_report_warns_on_genesis_hash_mismatch builds a temp dir + dummy genesis files, points a config at them with deliberately-wrong hashes, and asserts the warning surfaces in the report. 4237 workspace tests pass across all crates, 0 failures.
  • Two missing upstream config keys modeled (RequiresNetworkMagic, MinNodeVersion): both keys appear in all three vendored node/configuration/{mainnet,preprod,preview}/config.json files but were silently ignored by serde because deny_unknown_fields is intentionally not set. Now: RequiresNetworkMagic is a typed enum { RequiresNoMagic, RequiresMagic } (matching upstream Cardano.Crypto.ProtocolMagic.RequiresNetworkMagic) with default_for_magic(network_magic) -> Self returning RequiresNoMagic only for the canonical mainnet magic 764824073 and RequiresMagic for everything else (mirrors Cardano.Chain.Genesis.Config.mkConfigFromGenesisData defaults). NodeConfigFile gains requires_network_magic: Option<RequiresNetworkMagic> and min_node_version: Option<String> fields with PascalCase serde renames; both are documentation-only at this point (no semantic action) but unblock byte-for-byte compatibility with upstream operator configs and provide typed access for any future consumer. New tests config_parses_requires_network_magic_and_min_node_version (mainnet RequiresNoMagic + version, testnet RequiresMagic + no version) and requires_network_magic_default_for_magic_matches_upstream (canonical mainnet → no magic, every other magic → magic). 4239 workspace tests pass across all crates, 0 failures.
  • Four more upstream config keys modeled (Protocol, LastKnownBlockVersion-Major, LastKnownBlockVersion-Minor, LastKnownBlockVersion-Alt): all four appear in every vendored node/configuration/{mainnet,preprod,preview}/config.json but were silently ignored by serde. Each gets a typed Option<String> / Option<u32> field on NodeConfigFile with PascalCase serde renames (the hyphenated LastKnownBlockVersion-* keys round-trip exactly via individual rename annotations). All four are documentation-only — Protocol is always "Cardano" for our purposes and the Byron LastKnownBlockVersion-* triplet has been superseded by the Shelley+ protocol_versions field in our model — but unblock byte-for-byte upstream operator-config compatibility. New regression test config_parses_last_known_block_version_and_protocol_upstream_keys. With this slice the only PascalCase keys present in the vendored mainnet config.json that the Rust port still does not model are CheckpointsFile / CheckpointsFileHash (checkpoint pinning, separate feature) and the LedgerDB subtree (alternate storage backend selection, separate feature). 4240 workspace tests pass across all crates, 0 failures.
  • Two more upstream config keys modeled (CheckpointsFile, CheckpointsFileHash): present in vendored node/configuration/mainnet/config.json but previously silently ignored. Now exposed as Option<String> fields on NodeConfigFile with PascalCase serde renames. Currently parse-tolerant only; the upstream “checkpoint pinning” feature (treat (slot, header_hash) pairs from checkpoints.json as authoritative chain anchors that no rollback may cross — see Cardano.Node.Configuration.Checkpoints) is a separate slice. After this change the only PascalCase key in the vendored mainnet config.json the Rust port still does not model is the LedgerDB subtree (alternate storage backend selection — separate feature). New regression test config_parses_checkpoints_file_upstream_keys. 4241 workspace tests pass across all crates, 0 failures.
  • MempoolSnapshot by-idx index slice — closes a real O(N²) block-forge path. crates/consensus/src/mempool::MempoolSnapshot::mempool_lookup_tx(idx) was O(n) (entries.iter().find(|e| e.idx == idx)), and node/src/runtime.rs::mempool_entries_for_forging calls it once per snapshot entry to assemble the forged block body — making the whole forge prep O(N²) per block (for a 5000-tx mempool that’s ~25M comparisons every slot the node is leader). Added idx_to_pos: HashMap<MempoolIdx, usize> alongside the existing tx_id_to_pos index, populated in the same Mempool::snapshot() constructor pass; both indexes are O(N) construction + O(1) lookup. Block-forge body assembly is now O(N) per block instead of O(N²). New regression test snapshot_idx_index_returns_same_results_as_linear_scan checks the typed lookup against the previous linear-find semantics across the full known-idx set plus the unknown-idx → None edge case. Reference: Ouroboros.Network.TxSubmission.Mempool.Reader lookup helpers. 4242 workspace tests pass across all crates, 0 failures.
  • Mempool block-apply eviction perf slice — two more quadratic paths fixed. (1) Mempool::remove_confirmed(&[TxId]) did confirmed_tx_ids.contains(&entry.tx_id) per mempool entry, so every confirmed block did O(Nm) work (mempool size × block-tx count; ~100k comparisons for a 5000-tx mempool + 20-tx block); the check now builds an HashSet<TxId> once upfront and does O(1) membership tests, making the whole path O(N + m). (2) Mempool::remove_conflicting_inputs(&[ShelleyTxIn]) did consumed_inputs.contains(inp) for every input of every mempool entry, so each block apply did O(NkI) work (mempool size × inputs-per-tx × block-consumed-input count; ~400k comparisons for the same shape); the same HashSet-of-inputs optimization brings it to O(Nk + I). Both helpers fire after every successful block apply (and twice in paths that combine confirmed + conflict eviction), so this tightens a fundamental hot path in the sync + relay loops. Existing remove_confirmed_* tests cover the behavior; no semantics change. Reference: upstream Ouroboros.Consensus.Mempool.Impl.Update revalidation pass. 4242 workspace tests pass across all crates, 0 failures.
  • LocalStateQuery tag 21 GetExpectedNetworkId: added to BasicLocalQueryDispatcher in node/src/local_server.rs. Returns the configured reward-account network id as a CBOR unsigned (1 for mainnet, 0 for test networks) when set, or CBOR null (0xf6) when no expectation has been wired (e.g. unit tests or configs without a genesis-derived expectation). Lets LSQ clients (wallets, explorers, the query CLI subcommand) verify they are connected to a node on the expected network before issuing further queries. The dispatcher doc-table comment was also expanded to list tags 14–21 which were implemented but previously absent from the table. Reference: upstream Cardano.Ledger.Api.Tx.Address network-id encoding in reward / Shelley addresses. Two new regression tests (returns_null_when_unset, returns_mainnet_id) lock in the CBOR byte encoding. 4244 workspace tests pass across all crates, 0 failures; BasicLocalQueryDispatcher now serves 22 distinct upstream Ouroboros.Consensus.Shelley.Ledger.Query tags (0–21).
  • LocalStateQuery tag 22 GetDepositPot: added to BasicLocalQueryDispatcher in node/src/local_server.rs. Returns the four Conway-era deposit categories as a 4-element CBOR array [key_deposits, pool_deposits, drep_deposits, proposal_deposits] (all u64). Tag 13 GetAccountState already exposes the scalar sum via DepositPot::total(); this query breaks out the individual buckets so explorers and stake-pool operators can reconcile per-category obligation growth across epochs — key registrations, pool registrations, DRep registrations, and open governance proposal deposits. Reference: upstream Cardano.Ledger.Shelley.Rules.Pool (pool deposits), Cardano.Ledger.Conway.Governance (DRep + proposal deposits), Cardano.Ledger.Obligation (Obligations sub-components of sumObligation). Two new regression tests (test_basic_dispatcher_get_deposit_pot_default_is_all_zeros locking in the raw [0x84, 0x00, 0x00, 0x00, 0x00] wire bytes; test_basic_dispatcher_get_deposit_pot_preserves_bucket_order populating each bucket with a distinct value and round-tripping through the decoder to assert ordering). 4246 workspace tests pass across all crates, 0 failures; BasicLocalQueryDispatcher now serves 23 distinct upstream Ouroboros.Consensus.Shelley.Ledger.Query tags (0–22).
  • LSQ tags 21 + 22 CLI exposure — node/src/main.rs::QueryCommand now includes ExpectedNetworkId and DepositPot variants so the two tags added in the prior slices are actually reachable from the command line (yggdrasil-node query expected-network-id / yggdrasil-node query deposit-pot). Both the encode_ntc_query (emits [21] / [22]) and decode_ntc_result (parses the server’s 4-element deposit-pot array into a structured JSON object with a derived total_lovelace field; handles the null-expected-network-id case by emitting "expected_network_id": null) helpers are wired. Existing integration tests cover the full path; no new test required — the dispatcher-side tests already assert the wire bytes for each tag. Reference: cardano-cli query commands. 4246 workspace tests pass across all crates, 0 failures.
  • CLI-side parity with the dispatcher — nine remaining LSQ tags are now reachable from yggdrasil-node query: tags 8 (Constitution), 9 (GovState), 10 (DrepState), 11 (CommitteeMembersState), 12 (StakePoolParams { pool_hash }), 13 (AccountState), 18 (GenesisDelegations), 19 (StabilityWindow), 20 (NumDormantEpochs) now all have QueryCommand variants wired through encode_ntc_query (emits the correct [tag] / [tag, param] CBOR) and decode_ntc_result (parses primitive shapes into structured JSON — AccountState returns the 3-field treasury_lovelace / reserves_lovelace / total_deposits_lovelace object; StabilityWindow / NumDormantEpochs return typed u64 fields or null; complex Conway types like Constitution / GovState / DrepState / CommitteeMembersState / GenesisDelegations / StakePoolParams surface the raw CBOR as a hex blob for client-side decoding, matching the pattern already used for tag 4 UtxoByAddress). After this slice all 23 LSQ tags the dispatcher serves are reachable from the CLI, closing the tool-side parity gap. No new tests required — the dispatcher-side tests lock in the wire bytes for each tag and the CLI encode/decode are thin formatting wrappers. Reference: cardano-cli query commands. 4246 workspace tests pass across all crates, 0 failures.
  • Ledger-state container ergonomics + new LSQ tag 23 GetLedgerCounts built on them: PoolState, RewardAccounts, and StakeCredentials (in crates/ledger::state) all expose iter() but previously lacked len() / is_empty() — consumers had to fall back to iter().count() which on impl Iterator return types erases the underlying ExactSizeIterator and becomes O(n). Added O(1) len() + is_empty() delegates to the underlying BTreeMap on all three (DrepState and CommitteeState already had them). With those in place, node/src/local_server.rs::BasicLocalQueryDispatcher now serves GetLedgerCounts as tag 23 — a 6-element CBOR array [stake_credentials, pools, dreps, committee_members, gov_actions, gen_delegs] built entirely from O(1) container .len() calls so the query is cheap enough for per-second monitoring dashboards. The corresponding QueryCommand::LedgerCounts CLI variant parses the 6-tuple into a structured JSON object ({"stake_credentials": …, "pools": …, …}) for the yggdrasil-node query ledger-counts tool path. New regression test test_basic_dispatcher_get_ledger_counts_default_is_all_zero locks in the [0x86, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00] wire bytes from a fresh LedgerState::new(Era::Conway). BasicLocalQueryDispatcher now serves 24 distinct LSQ tags (0–23), all reachable from the CLI. 4247 workspace tests pass across all crates, 0 failures.
  • Genesis-hash verification positive-path trace event: the integrity check was previously silent on success (only mismatches surfaced as bails). Added node/src/main.rs::trace_genesis_hashes_verified which emits a Node.GenesisHash.Verified / Notice trace immediately after strict_base_ledger_state returns, reporting per-file booleans (shelleyVerified, alonzoVerified, conwayVerified), an explicit byronHashDeclaredButCanonicalCborPending flag for the then-deferred Byron hash path, plus an aggregated verifiedCount. R244 supersedes this field with byronVerified after porting upstream Canonical JSON hashing. Gives operators a visible audit-trail confirmation that the integrity check actually ran on every startup, not just on misconfiguration. The trace fires only on the run path (not validate-config, which already has its warnings-only semantics). 4247 workspace tests pass across all crates, 0 failures.
  • status subcommand ledger-counts enrichment: StatusReport now carries an optional ledger_counts: LedgerCountsReport field (the same 6-tuple exposed by LSQ tag 23 GetLedgerCounts — stake_credentials / pools / dreps / committee_members / governance_actions / gen_delegs). Populated from the recovered LedgerState when status successfully replays from disk, None when storage is uninitialized or recovery fails. The field serializes via #[serde(skip_serializing_if = "Option::is_none")] so pre-existing operator-tooling that consumes the yggdrasil-node status JSON sees no breaking change when the data is absent, and sees a nicely-nested object when present. Uses the O(1) .len() accessors added in the prior slice. Existing status_report_shows_initialized_when_storage_exists test extended to assert all six counts are zero on a fresh node. 4247 workspace tests pass across all crates, 0 failures.
  • Preflight numeric-config validators — node/src/main.rs::validate_config_report now hard-bails on three additional zero values that would cause silent runtime misbehaviour: (1) security_param_k == 0 (zero collapses the 3k/f stability window and makes Praos non-functional), (2) epoch_length == 0 (divide-by-zero in slot-to-epoch conversion), (3) byron_epoch_length == 0 but only when byron_to_shelley_slot is set (the Byron prefix is ill-formed in that case; networks without a Byron prefix such as preview are unaffected). Complements the pre-existing active_slot_coeff ∈ (0, 1] and protocol_versions non-empty checks. Four new regression tests: _rejects_zero_security_param_k, _rejects_zero_epoch_length, _rejects_zero_byron_epoch_length_with_boundary_set, and _allows_zero_byron_epoch_length_without_boundary (which asserts the Byron bail does NOT fire on preview-style configs). Reference: Cardano.Ledger.Shelley.PParams field invariants. 4251 workspace tests pass across all crates, 0 failures.
  • Preflight keepalive-interval sanity check — validate_config_report now emits a preflight warning when keepalive_interval_secs is outside the safe range. Values >= 97 collide with the upstream NtN KeepAlive client timeout (crates/network::protocol_limits::keepalive::CLIENT = 97s) so the peer’s inactivity timer fires before the next heartbeat and tears the connection down — a silent root cause of “every peer drops us” reports if not flagged. Value 0 is called out as wasteful (heartbeats fire as fast as the runtime schedules them). The sensible operator-tuned range documented in the warnings is 10-60 seconds (upstream defaults to ~30). Two new regression tests — _warns_on_unsafe_keepalive_interval (hits both the >= 97 path at 120s and the == 0 path, asserting both produce warnings) and _accepts_sensible_keepalive_interval (asserts a 30s value produces no keepalive-related warning). 4253 workspace tests pass across all crates, 0 failures.
  • Preflight governor validation — validate_config_report gains two more governor-specific warnings: (1) governor_tick_interval_secs == 0 (would busy-spin the governor loop at runtime-scheduler resolution and pin a CPU core), and (2) the upstream sanePeerSelectionTargets invariant check. The check wires the existing GovernorTargets::is_sane() predicate (already used at the run path but not at preflight) against the six config-derived targets — violations such as target_active > target_established, target_known > 10_000, etc. now surface as a preflight warning with the exact configured values so operators can diagnose “governor churns forever” misconfigurations before startup rather than observing symptoms post-hoc. Reference: Ouroboros.Network.PeerSelection.Governor.Types.sanePeerSelectionTargets. Two new regression tests (_warns_on_zero_governor_tick, _warns_on_insane_governor_targets). 4255 workspace tests pass across all crates, 0 failures.
  • Preflight KES + protocol-version validators — validate_config_report gains two more hard-bails and one warning: (1) slots_per_kes_period == 0 bails (KES evolution math ill-defined; header verification blocked), (2) max_kes_evolutions == 0 bails (every KES period immediately expired → all operational certs rejected → no block production + no block verification), (3) max_major_protocol_version < 2 is a warning (pre-Shelley, every Shelley-era+ block is rejected; an operator legitimately pinned to Byron for replay/audit can still proceed). Three new regression tests (_rejects_zero_slots_per_kes_period, _rejects_zero_max_kes_evolutions, _warns_on_pre_shelley_max_major_protocol_version). The validate-config preflight now catches: div-by-zero, stability-window collapse, Byron-prefix ill-formedness, KES math ill-formedness, pre-Shelley PV floor, genesis hash mismatch, keepalive-timeout collision, governor busy-spin, and insane peer-selection targets — 11 independently-exercised failure modes. Reference: upstream Cardano.Ledger.Crypto.KES evolution invariants + MaxMajorProtVer in Ouroboros.Consensus.Protocol.Abstract. 4258 workspace tests pass across all crates, 0 failures.
  • status subcommand era + epoch fields: StatusReport gains current_era: Option<String> and current_epoch: Option<u64>, populated from the recovered LedgerState via its existing current_era() / current_epoch() accessors. Complements the chain_tip_slot / chain_tip_hash / ledger_counts fields so a single yggdrasil-node status invocation now surfaces: where we are on the chain (slot + hash), which era we’re operating in, what epoch that places us in, and the cardinality of every major ledger-state bucket — no NtC round-trip required. Both new fields serialize via #[serde(skip_serializing_if = "Option::is_none")] so pre-existing operator-tooling sees no breaking change when the fields are absent (storage uninitialized / recovery failure). Existing status_report_shows_initialized_when_storage_exists test extended to assert current_era == "Byron" and current_epoch == 0 on a fresh node. 4258 workspace tests pass across all crates, 0 failures.
  • mempool_tx_added / mempool_tx_rejected Prometheus counters fixed — real orphaned-metric bug. Both NodeMetrics::inc_mempool_tx_added() and inc_mempool_tx_rejected() were defined and exported via MetricsSnapshot + the Prometheus text endpoint but NEVER incremented anywhere in the codebase (confirmed by a repo-wide search) so operators consuming the Prometheus endpoint saw these counters permanently stuck at zero. Wired via SharedTxSubmissionConsumer::with_metrics(Arc<NodeMetrics>) (a new optional builder-style setter mirroring the existing .with_evaluator() pattern) + a match result loop in consume_txs that increments the added counter for each MempoolAddTxResult::MempoolTxAdded(_) result and the rejected counter for each MempoolTxRejected(..). main.rs now wires the node’s existing Arc<NodeMetrics> handle into the consumer on construction, so NtN inbound TxSubmission admissions now correctly flow into the two counters. Regression-test pragmatics: a full integration test of the increment path requires a valid CBOR transaction + chain_db + recovered ledger state fixture which is heavyweight; the inline match pattern is a one-line-per-variant check that’s obviously correct by inspection, and the existing consume-txs integration tests exercise the full path. Reference: Ouroboros.Network.TxSubmission.Inbound admission pipeline. 4258 workspace tests pass across all crates, 0 failures.
  • /metrics/json HTTP routing bug fix — real dead-code regression. node/src/main.rs::metrics_http_response dispatched routes via starts_with(...) prefix matches but in an order that tested "GET /metrics" BEFORE "GET /metrics/json", so every JSON request matched the shorter Prometheus-text prefix first and /metrics/json silently returned Prometheus text (not JSON) despite being documented as the JSON endpoint in the node AGENTS.md. Callers hitting /metrics/json (including the operator-tooling use case spelled out in the docstring) never got JSON. Fixed by: (1) reordering the dispatch so JSON-specific prefixes (GET /metrics/json, GET /debug/metrics/json, GET /debug/metrics with trailing space, GET /debug ) are tested BEFORE any Prometheus-text prefix; (2) added the missing GET /debug/metrics/json alias for consistency with GET /debug/metrics/prometheus; (3) inline comment explaining the order invariant so it doesn’t regress. New regression test metrics_http_response_routes_json_before_prometheus pins down four distinct routes (/metrics/json = JSON, /metrics = Prometheus, /debug/metrics/json = JSON, /debug/metrics/prometheus = Prometheus) against the raw content-type byte prefix. The three pre-existing alias tests (_debug_json_alias, _debug_prometheus_alias, _debug_health_alias) still pass unchanged. 4259 workspace tests pass across all crates, 0 failures.
  • Regression-test tightening — status_report_shows_uninitialized_when_storage_absent now asserts that the three optional ledger-derived fields introduced in recent slices (current_era, current_epoch, ledger_counts) are both None in the typed report AND absent from the JSON serialisation. Locks in the backward-compatibility promise from slice 30 (#[serde(skip_serializing_if = "Option::is_none")]) so a future regression that forgets the annotation surfaces as a failing test rather than as an unexpected breaking change for pre-existing operator tooling. 4259 workspace tests pass across all crates, 0 failures.
  • CLI encoder tag-drift regression test — encode_ntc_query_emits_expected_tag_bytes locks in the exact on-wire CBOR byte sequence (0x81 <tag>) for every simple QueryCommand variant that maps to an LSQ tag the dispatcher serves. Without this test a future refactor could silently emit a wrong tag from the CLI side and the error would only surface as “query returned empty / wrong results on real mainnet” — impossible to reproduce without a running node. Now the encoder and the server-side dispatcher arm numbers are pinned together at CI time. #[derive(Debug)] added to QueryCommand so the test’s assert_eq! failure messages are legible. Covers all 19 no-parameter variants that map to tags 0–23 (tags 4, 6, 12, 14, 16 take parameters and are already pinned by the dispatcher-side tests). 4260 workspace tests pass across all crates, 0 failures.
  • CLI decoder tag-drift regression test — decode_ntc_result_shapes_typed_json_for_new_queries is the decoder-side counterpart to encode_ntc_query_emits_expected_tag_bytes. Locks in the raw-CBOR → structured-JSON shape for every typed variant added in recent slices: AccountState (3-field object with treasury_lovelace / reserves_lovelace / total_deposits_lovelace), StabilityWindow (typed u64 field OR null round-trip), NumDormantEpochs, ExpectedNetworkId (typed u64 OR null), DepositPot (4-bucket object with derived total_lovelace), LedgerCounts (6-bucket object). Without this test a CLI-side decoder refactor could silently change the JSON key names or drop the total_lovelace convenience field and the only way to find out would be to diff the yggdrasil-node query ... output against a reference run. Together with the prior encoder test this pins the full request/response round-trip for every LSQ tag reachable from the CLI. 4261 workspace tests pass across all crates, 0 failures.
  • Preflight checkpoint-cadence sanity — validate_config_report now warns when checkpoint_interval_slots > epoch_length. A cadence longer than a full epoch means a crash after an epoch rotates the stake snapshots but before the next checkpoint lands forces replay of the entire prior epoch on restart (wasteful at best, recovery-stalling at worst). Common shape for this mistake is typo-shifted units: operator means “every 1 epoch” and writes epoch_length * N by accident. Warning cites both values + the recommended ceiling so the typo is immediately apparent. Two new tests: _warns_when_checkpoint_interval_exceeds_epoch (sets the interval to epoch_length * 10 and asserts the warning fires) and _accepts_checkpoint_interval_at_epoch_length (asserts the boundary value interval == epoch_length passes silently — the warning reads “at most one per epoch” so equal-to is safe). Reference: upstream Cardano.Node.Configuration.POM does not expose this ratio but the operational impact on restart-replay time is well-documented in the ChainDB storage docs. 4263 workspace tests pass across all crates, 0 failures.
  • Preflight checkpoint-cadence floor — rounds out the checkpoint-interval validators with a soft-floor warning at 32 slots (matching upstream’s per-block snapshot batch size). Completes the trio: == 0 → “effectively unbounded”, < 32 → “fsync bandwidth steal”, > epoch_length → “prior-epoch replay on crash”. Each case has its own recommendation string so an operator sees immediately which direction to adjust. New test _warns_on_too_small_checkpoint_interval fires the soft-floor path at interval=1. 4264 workspace tests pass across all crates, 0 failures.
  • NtC LocalTxSubmission mempool metrics parity — closes the second half of the observability gap from slice 31. Slice 31 wired mempool_tx_added / mempool_tx_rejected for the NtN inbound path via SharedTxSubmissionConsumer::with_metrics; the matching NtC run_local_tx_submission_session path (driven by local wallets / CLI submit-tx) had no metrics parameter at all, so every local admission or rejection silently bypassed the Prometheus counters. The session now takes Option<Arc<NodeMetrics>>, bumps mempool_tx_added on MempoolTxAdded, and bumps mempool_tx_rejected on three distinct rejection paths: MempoolTxRejected, decode failure (MultiEraSubmittedTx::from_cbor_bytes_for_era), and ledger-recovery failure. Threaded through run_local_client_session and run_local_accept_loop and wired at the main.rs bootstrap site (ntc_metrics = Some(Arc::clone(&metrics))). #[allow(clippy::too_many_arguments)] on run_local_accept_loop since it is a thin orchestration entry-point where each parameter is a shared handle rather than a decomposable input. New integration test ntc_local_tx_submission_rejection_bumps_metrics spawns the real accept loop with a shared NodeMetrics handle, submits malformed CBOR through a typed LocalTxSubmissionClient, and asserts the counter strictly transitions from {added: 0, rejected: 0} to {added: 0, rejected: 1} — proving both that the rejection path increments the right counter and that it does not spuriously increment the accepted counter. With this slice the Prometheus view is now authoritative across both wire entry-points for mempool admissions. 4265 workspace tests pass across all crates, 0 failures.
  • NtC handshake-level observability — adds the previously missing connection-level counter pair for the NtC local Unix socket surface. Before this slice run_local_client_session silently discarded ntc_accept errors (Err(_e) => return None), so wallet/tool handshake failures — wrong network magic, unsupported protocol version, early client disconnect — were completely invisible server-side and operators only saw “connection reset” on the client side with no counterpart signal in Prometheus. New ntc_connections_accepted / ntc_connections_rejected fields on NodeMetrics with matching incrementers (inc_ntc_accepted / inc_ntc_rejected), MetricsSnapshot struct entries, and Prometheus text formatters (yggdrasil_ntc_connections_accepted / yggdrasil_ntc_connections_rejected counters with HELP lines that call out the typical failure shape “magic mismatch, unsupported version, early disconnect”). Kept DISTINCT from the pre-existing NtN inbound_connections_* pair — conflating the two would mask the wrong class of issue since NtN rejections are overwhelmingly rate-limit-driven while NtC rejections are overwhelmingly configuration-driven. The counters fire in run_local_client_session right after the ntc_accept branch returns Ok (accepted) or Err (rejected), before any protocol tasks are spawned, so every handshake outcome is accounted for regardless of whether downstream sessions subsequently error out. Two new integration tests: ntc_handshake_success_bumps_accepted_metric (connects with correct magic, asserts {accepted: 1, rejected: 0}) and ntc_handshake_wrong_magic_bumps_rejected_metric (connects with TEST_MAGIC + 1, asserts {accepted: 0, rejected: 1}). The tests are also cross-asserting — each one proves the opposite counter did NOT move — so a future regression where both paths incorrectly increment accepted (or a rename swap) would surface as two simultaneous failures instead of one silent miscounting. 4267 workspace tests pass across all crates, 0 failures.
  • Preflight RequiresNetworkMagic cross-field sanity — closes another byte-for-byte-parsed-but-not-sanity-checked upstream config key. RequiresNetworkMagic was added to NodeConfigFile in a prior slice so vendored config.json files parse cleanly, but no validator caught the common copy-paste bug where a mainnet template is repurposed for a testnet (or vice versa) without also flipping this field. Upstream Cardano.Chain.Genesis.Config.mkConfigFromGenesisData derives the canonical value from the magic alone — mainnet magic 764_824_073 → RequiresNoMagic, every other magic → RequiresMagic — and Byron-era header decoding rejects mismatched shapes at handshake time. We already model that canonical mapping in RequiresNetworkMagic::default_for_magic(magic); validate_config_report now compares an explicit override against that canonical default and warns (not bails, since pure Shelley+ test environments may never exercise Byron decoding) with the recommended value inlined so the fix is immediately obvious. None-case (i.e. field absent, default inferred from magic) stays warning-free — so existing vendored configs remain valid. Three new tests: _warns_on_mainnet_requires_magic_override (mainnet + RequiresMagic → warn), _warns_on_testnet_requires_no_magic_override (magic=2 + RequiresNoMagic → warn), and _accepts_canonical_requires_network_magic which covers two positive paths (mainnet + RequiresNoMagic explicit; and field = None). 4270 workspace tests pass across all crates, 0 failures.
  • Preflight CheckpointsFile integrity verification — extends the slice-24 genesis-hash integrity story to the upstream CheckpointsFile / CheckpointsFileHash key pair. Those keys were parsed for config.json compatibility (prior slice) with a doc-note that verification would land “once the underlying checkpoint loader exists” — but the raw-bytes Blake2b-256 digest is loader-agnostic, so doing the integrity check now means the declared hash cannot regress once checkpoint pinning itself is wired up. validate_config_report now: (1) warns when CheckpointsFile points at a path that does not exist (checkpoint pinning would otherwise be silently disabled at runtime — a supply-chain-style failure mode the operator needs to see); (2) when both fields are set, calls the era-agnostic genesis::verify_genesis_file_hash(path, expected_hex, "CheckpointsFileHash") helper already in the tree and surfaces any mismatch / invalid-hex as a warning. All-None (no CheckpointsFile declared) stays warning-free so existing vendored configs are untouched. The checkpoints_file_hash rustdoc was updated from “Will be wired into … once the underlying checkpoint loader exists” to an accurate description of the current verification behavior and where the remaining pinning work lives. Three new tests: _warns_on_missing_checkpoints_file (file path absent → warn), _warns_on_checkpoints_file_hash_mismatch (wrong hash → warn), _accepts_matching_checkpoints_file_hash (computes Blake2b-256 over a known byte string and asserts the correct-hash path produces zero CheckpointsFile warnings — the cross-assertion pins the happy path so a future regression that falsely warns on correct hashes also fails). 4273 workspace tests pass across all crates, 0 failures.
  • Preflight protocol_versions vs max_major_protocol_version consistency — catches the config footgun where an operator advertises a major version their own node would reject as ObsoleteNode. Upstream MaxMajorProtVer (consulted in Cardano.Protocol.Praos.Rules.Prtcl.headerView) is applied as a hard <= ceiling on incoming header protocol-versions; a forged block whose major exceeds it is rejected at verification time. So a node that proposes major 99 but has max_major_protocol_version = 10 would forge a block and then fail to apply its own block. validate_config_report now scans protocol_versions for any entry strictly greater than the accepted ceiling and warns with the exact offending entries surfaced inline so the fix is obvious (raise the ceiling OR drop the offending entries). Boundary <= behavior matches upstream — protocol_versions = [10] with max_major_protocol_version = 10 is explicitly fine. Two new tests: _warns_on_protocol_versions_exceeding_max_major (mixes legal and illegal entries [10, 13, 99] with cap 10, asserts the warning names both 13 and 99) and _accepts_protocol_versions_at_or_below_max_major (boundary case [9, 10] with cap 10, asserts zero exceeds-max warnings — pins the happy path so a future off-by-one regression that flags the equal-to boundary also fails). 4275 workspace tests pass across all crates, 0 failures.
  • Consensus-crate ObsoleteNode parity — the canonical upstream Cardano.Protocol.Praos.Rules.Prtcl.headerView rule rejects a header whose major protocol version strictly exceeds the operator-configured MaxMajorProtVer with ObsoleteNode, signaling “this node is too old to continue validating the chain”. The check lives in the PRTCL (consensus) rule upstream, not in the sync-decoder pipeline. Our sync layer already enforces the cap via SyncError::ProtocolVersionTooHigh in validate_protocol_version_for_era, but the consensus crate lacked the matching canonical helper + error type — so third-party callers reaching into yggdrasil-consensus for header validity had no way to consult the rule and would silently treat obsolete headers as valid. New check_header_protocol_version(header_major, max_major_protocol_version) -> Result<(), ConsensusError> pure helper in crates/consensus/src/header.rs returns ConsensusError::ObsoleteNode { header_major, max_major } on ceiling breach and Ok(()) at or below the ceiling (boundary <= matches upstream). Public re-export from crates/consensus/src/lib.rs. Three new unit tests cover at-ceiling (safe), below-ceiling (safe), and above-ceiling (ObsoleteNode with both fields populated and asserted individually) — the error-field cross-check pins the semantics so a future regression that swaps header_major ↔ max_major in the constructor also fails. Intentionally kept as a standalone rule rather than folded into verify_header: the ceiling is an operator-configured value not a per-header crypto property, and upstream models it the same way (PRTCL rule vs. BHBody verification). ConsensusError::ObsoleteNode is added to the existing all_variants_are_displayable smoke test so the Display impl is exercised. 4278 workspace tests pass across all crates, 0 failures.
  • Correction: slice 42’s protocol_versions vs max_major_protocol_version cross-check was wrong and has been reverted. The two fields live in completely different number spaces: protocol_versions: Vec<u32> is the NtN HANDSHAKE protocol-version list (mux-layer, e.g. [13, 14] — passed into HandshakeVersion(v as u16) at main.rs:980), while max_major_protocol_version: u64 is the BLOCK HEADER protocol-version major cap (Conway = 10). The original slice would have fired "protocol_versions contains [13, 14] which exceeds max_major_protocol_version = 10" on every valid mainnet config. The two unit tests the slice introduced were removed; the surrounding infrastructure (validate_config_report, the other preflight checks) is unchanged. A new regression guard test validate_config_report_does_not_cross_check_handshake_versions_against_block_major pins the default mainnet pair ([13, 14] / 10) so any future attempt to revive this cross-check fails at CI time. Lesson: any preflight that compares two Vec<u32>/u64 fields needs an explicit note about which semantic namespace each field lives in before the comparison is added — consulting both field docstrings in isolation is insufficient. 4277 workspace tests pass across all crates, 0 failures (net -1 test vs. slice 43: removed two incorrect slice-42 tests, added one regression guard).
  • Wire consensus-crate check_header_protocol_version into sync — slice 43 added the canonical upstream ObsoleteNode rule to yggdrasil-consensus but the sync layer still used its own inline major > max comparison in validate_protocol_version_for_era. With two independent implementations of the same ceiling rule there would be no protection against them drifting (e.g. a future refactor flipping one to < while leaving the other >). This slice makes the consensus helper the single source of truth: validate_protocol_version_for_era now calls yggdrasil_consensus::check_header_protocol_version(major, max) and converts ConsensusError::ObsoleteNode { header_major, max_major } into the existing SyncError::ProtocolVersionTooHigh { major, max } so the peer-attribution error surface at the sync layer is unchanged (no API break). Subtle parity gain: any future refinement of the consensus-layer rule (e.g. adding a PV-specific exemption during hard-fork transitions upstream adds) now lands in exactly one place. New test max_major_guard_delegates_to_consensus_obsolete_node_rule cross-asserts the two layers together — sync returns ProtocolVersionTooHigh{15,10} at the same input where the consensus helper returns ObsoleteNode{header_major:15, max_major:10}, and both agree on the <= boundary (10 vs 10 is Ok). Pins the delegation so a future inlined comparison would break the test at CI time. The pre-existing protocol_version_constraints_enforce_max_major_guard test continues to pass unchanged, confirming the sync-layer surface is preserved. 4278 workspace tests pass across all crates, 0 failures.
  • Preflight syntax check for ByronGenesisHash — at this historical slice, Byron content verification was still deferred and verify_known_genesis_hashes skipped the Byron pair. R244 supersedes that status: upstream hashes Canonical JSON rendering, and the Byron pair is now content-verified. The declared hex value itself was still checkable then — typos, wrong-length pastes, non-hex input are real operator mistakes that otherwise would surface much later as garbled “hash mismatch” messages once the content path landed. Factored the inline hex+length validation out of verify_genesis_file_hash into a new reusable parse_blake2b_256_hex(expected_hex, field) -> Result<[u8;32], GenesisLoadError> helper in the genesis module. verify_genesis_file_hash is now a trivial wrapper over it (unchanged behavior — existing tests _accepts_correct_hash, _rejects_mismatch, _rejects_invalid_hex still pass). validate_config_report calls the new helper on byron_genesis_hash when it is Some(..) and surfaces InvalidHashHex as a format warning, so the operator sees the problem at preflight time instead of at first-use time. Three new tests: _warns_on_malformed_byron_genesis_hash (2-byte “abcd” → warn), _warns_on_non_hex_byron_genesis_hash (“zzz…” × 64 → warn), _accepts_well_formed_byron_genesis_hash (64-char all-zeros → no format warning). The happy-path test is deliberately permissive because content verification was still deferred in that slice; it only pins the syntax gate — so the cross-assertion specifically asserts “no format warning” rather than “no ByronGenesisHash warning at all”. 4281 workspace tests pass across all crates, 0 failures.
  • Preflight LastKnownBlockVersion triplet atomicity — upstream Cardano.Chain.Update.Proposal.LastKnownBlockVersion carries the Byron-era block-version triplet (Major, Minor, Alt) as a single logical value, and operator configs declare it atomically (all three appear together or none of them do). Our NodeConfigFile exposes them as three independent Option<u32> fields so they round-trip the exact upstream JSON key shape (LastKnownBlockVersion-Major etc.), which means an operator who hand-edits the config and forgets a sibling (the common copy-paste bug where the major override is added without its twins) silently ends up with a partial triplet the runtime can’t interpret. validate_config_report now counts how many of the three are Some(..) and warns when the count is 1 or 2, surfacing the exact set / missing pattern per field so the fix is obvious (“Major: set, Minor: missing, Alt: missing”). Both all-absent (default for all three presets) and all-present configurations remain warning-free. Three new tests cover the full matrix: _warns_on_partial_last_known_block_version_triplet asserts the warning fires for the Major-only case AND that the Some/None pattern is surfaced exactly (cross-checks all four pattern substrings in one assertion so a future regression that drops the per-field naming still fails); _accepts_full_last_known_block_version_triplet pins the 3-of-3 positive path; _accepts_absent_last_known_block_version_triplet pins the 0-of-3 positive path and by proxy confirms every preset still validates clean. Live validate-config --network mainnet output was spot-checked to confirm no false positive is introduced. 4284 workspace tests pass across all crates, 0 failures.
  • Preflight MinNodeVersion format sanity — upstream vendored configs (mainnet / preprod / preview all set "10.6.2") use dotted-numeric version strings. Our field is currently parsed and carried through verbatim but never validated, so a typo like "10,6.2" (comma-for-dot) or "ten.six.two" (non-numeric words) silently persists. Deliberately kept narrowly scoped: we do NOT cross-compare the declared version against our own CARGO_PKG_VERSION because yggdrasil’s version namespace is independent of cardano-node’s (a claim of 100% parity does not mean we inherit cardano-node’s version numbers), so a cross-check would be false-positive-prone in the same way slice 42 was. Instead the preflight only asserts the string’s shape: non-empty, split on . yields non-empty segments that are each pure ASCII digits. Three new checks inside a single test (_warns_on_non_dotted_numeric_min_node_version runs the check against "10,6.2", "ten.six.two", and "" — each time re-reads the fresh report so earlier warnings don’t mask later ones) and a positive-path test (_accepts_well_formed_min_node_version loops over "10.6.2", "1", "1.2.3.4.5", "0.0.0" asserting none produce the shape warning). Live mainnet-config validate-config run was spot-checked to confirm the vendored "10.6.2" produces no false positive. 4286 workspace tests pass across all crates, 0 failures.
  • Preflight Protocol sanity — upstream Cardano.Node.Configuration.POM.nodeProtocolModeP accepts a small set of block-producer-family tags (Cardano, Shelley, Byron, RealPBFT). Yggdrasil only implements Cardano, and the field docstring already notes “documentation-only”, meaning any non-Cardano value silently runs as Cardano at the runtime layer. That is precisely the silent-misconfiguration shape a preflight should catch — an operator who sets "Protocol": "RealPBFT" expects pre-Shelley behavior and will be confused when Shelley+ rules still apply. Case-sensitive comparison against exactly "Cardano" (matches upstream parser) so "cardano" / "CARDANO" are also flagged — the upstream parser rejects those too. None stays warning-free so existing configs that omit the field (our preset constructors all do) are untouched, and the canonical "Cardano" stays silent. One comprehensive test _warns_on_non_cardano_protocol_value exercises five paths in sequence against a single temp-dir fixture: typo "Cadrano" (warn, exact offending value in message), legacy "RealPBFT" (warn), lowercase "cardano" (warn — case-sensitive gate pin), canonical "Cardano" (silent), None (silent). Each probe re-reads the fresh report so prior warnings don’t mask later probes. Live mainnet-config preflight re-checked: "Protocol": "Cardano" in all three vendored presets produces zero false positives. 4287 workspace tests pass across all crates, 0 failures.
  • Metrics export drift-detection invariant — every MetricsSnapshot numeric field must appear in the Prometheus text emission as yggdrasil_<field>. Previously a new AtomicU64 added to NodeMetrics could be plumbed into MetricsSnapshot (and therefore into the JSON /metrics/json surface) while silently remaining invisible to Prometheus scrapers if the author forgot to touch the format! block in to_prometheus_text. New test every_metrics_snapshot_field_is_exported_in_prometheus_text uses serde_json::to_value(&snapshot) to enumerate the snapshot’s field names at runtime and asserts each one appears in the rendered Prometheus text. The single documented exception — uptime_ms published as yggdrasil_uptime_seconds (divided by 1000) — is explicitly tolerated by the lookup so it does not become a stealth tripwire. Validation methodology: temporarily added a drift_canary_counter: u64 to MetricsSnapshot and its snapshot() populator, ran the test to confirm it fails with the expected ["drift_canary_counter"] diagnostic + the helpful “Every new counter must be mirrored in MetricsSnapshot::to_prometheus_text” hint, then reverted the canary and re-ran to confirm the test passes. This direct verification of detect-and-revert confirms the test catches real drift rather than simply passing vacuously. 4288 workspace tests pass across all crates, 0 failures.
  • QueryCommand ↔ dispatcher drift-detection invariant — closes the remaining silent-failure mode for the LSQ CLI surface. The pre-existing encode_ntc_query_emits_expected_tag_bytes test pins the encoder output for every variant but says nothing about whether the server-side BasicLocalQueryDispatcher has a matching Some(N) arm for each emitted tag. Without this slice, adding a new QueryCommand variant + its encode_ntc_query arm with a brand-new tag would compile fine, emit well-formed CBOR, get routed through the NtC mux, and fall through to the dispatcher’s unknown-query _ => {} default — returning exactly zero bytes, which looks indistinguishable from “query returned no data” at the CLI. New test every_query_command_variant_is_dispatched constructs a representative instance of every QueryCommand variant in a single Vec<QueryCommand> with a compiler-enforced exhaustive match guard (_check_exhaustiveness closure) so adding a new variant without extending the test is a hard compile error, runs each through encode_ntc_query → BasicLocalQueryDispatcher::dispatch_query against LedgerState::new(Era::Conway).snapshot(), and asserts non-empty output (the dispatcher’s unknown-tag arm returns exactly zero bytes via its empty encoder state so the signal is clean). Parametric variants are exercised with syntactically-valid placeholder inputs (28/29/32-byte hex) that let the tag arm execute even when the underlying data yields an empty match set — the tag-recognition signal is what matters. Validation methodology: temporarily sabotaged the Some(23) => GetLedgerCounts dispatcher arm (replaced with Some(9001) => enc.array(0)) so the tag 23 path fell through to _ => {}, ran the test, confirmed it failed with the exact diagnostic "BasicLocalQueryDispatcher returned empty bytes for LedgerCounts — every QueryCommand variant must have a matching dispatcher arm", then reverted the sabotage and re-ran clean. This detect-and-revert proves the test catches real drift rather than passing vacuously, and the diagnostic names the offending variant so diagnosis is zero-effort. 4289 workspace tests pass across all crates, 0 failures.
  • SyncError::is_peer_attributable exhaustiveness invariant — extends the drift-detection pattern to the peer-attribution classification that drives the reconnect-vs-propagate policy in the sync loop (upstream InvalidBlockPunishment analogue). The pre-existing sync_error_peer_attributable_for_validation_failures test only exercised 4 of the 8 peer-attributable variants; a future author adding ProtocolVersionMismatch or WrongBlockBodySize would not be forced to update any test. More dangerously, adding a new validation-failure variant without also adding it to the matches! list in is_peer_attributable would silently classify the new variant as non-peer-attributable — meaning a malicious peer triggering that variant would not get disconnected. The existing matches! is a pattern without _ fall-through, so new variants do NOT default-match — but the classification gate is matches! not match, so the compiler cannot warn about missing arms. New test every_sync_error_variant_has_explicit_peer_attributable_decision builds a Vec<SyncError> with one representative of every variant, then runs each through an exhaustive match whose arms hard-code the expected classification; the compiler’s exhaustiveness requirement forces any new SyncError variant to receive an explicit classification decision in this test, and the assertion cross-checks the decision against the runtime is_peer_attributable output. The pre-existing test was also extended to cover the 4 previously-unchecked peer-attributable variants (WrongBlockBodySize, ProtocolVersionMismatch, ProtocolVersionTooHigh, HeaderProtVerTooHigh). Validation methodology: temporarily removed HeaderProtVerTooHigh from the is_peer_attributable matches! list, ran the test, confirmed it failed with "classification mismatch for HeaderProtVerTooHigh { header_major: 20, pp_major: 10 }: test expected true, implementation returned false" and the actionable hint “Review the is_peer_attributable matches! list against this test’s expected map”, then reverted the sabotage and re-ran clean. The diagnostic names the offending variant AND points directly at the file to edit. 4290 workspace tests pass across all crates, 0 failures.
  • Vendored-preset warning-allowlist regression guard — closes the broader pattern the slice-42 false positive belonged to. Every time a preflight is added that fires on canonical NetworkPreset::Mainnet / Preprod / Preview configs, CI now catches it rather than the operator discovering it at validate-config --network … runtime. New test vendored_network_presets_produce_only_environmental_warnings loads each of the three presets through load_effective_config(None, Some(preset)), runs them through validate_config_report, and asserts every warning contains one of two allow-listed substrings (not exact strings — stable across message-wording refinements): "peer snapshot file" (no peer-snapshot.json vendored with the repo) and "storage directories are not initialized" (fresh checkout). Both are genuine environmental conditions that the repo cannot resolve without a real node run, so their presence on every preset is correct. Any NEW warning outside those categories is almost certainly a broken preflight. The failure message includes the offending warning quoted AND an actionable AGENTS.md pointer (slice 44) reminding the author to either add a new environmental category (if the condition is genuinely environmental) or fix the broken preflight (the likely case). Validation methodology: temporarily inserted an always-firing warnings.push("sabotage: bogus preflight fires on every config") in validate_config_report, ran the test, confirmed failure with the expected diagnostic "preset Mainnet produced an unexpected warning outside the environmental allowlist: \"sabotage: bogus preflight fires on every config\"" including the AGENTS.md pointer, then reverted and re-ran clean. Detect-and-revert confirms the guard catches real drift. 4291 workspace tests pass across all crates, 0 failures.
  • Test ergonomics: Debug derives on validation-report structs — retroactively unblocks the cleaner .expect_err("msg") test pattern that was previously inaccessible because the T in Result<T, E>::expect_err requires T: Debug. ConfigValidationReport, PeerSnapshotValidationReport, StorageValidationReport, LedgerCountsReport, and StatusReport all gain Debug alongside their existing Serialize derives — these are internal JSON-surface structs so Debug is purely an ergonomics win with no public-API implications. Converted the 5 pre-existing call sites using the awkward .err().expect("…") pattern to the idiomatic .expect_err("…") form: _rejects_zero_slots_per_kes_period, _rejects_zero_max_kes_evolutions, _rejects_zero_security_param_k, _rejects_zero_epoch_length, _rejects_zero_byron_epoch_length_with_boundary_set. Zero test-count delta — same tests, same coverage, just less visual noise in the assertion setup. Future preflight negative-path tests will use .expect_err by default without re-hitting this friction. 4291 workspace tests pass across all crates, 0 failures.
  • ConsensusError display-message coverage — 6 of the 14 ConsensusError variants had no dedicated Display test, relying only on the all_variants_are_displayable smoke test which asserts nothing beyond “message is non-empty”. Operator-facing log messages for peer-attributable failures need to surface the dynamic field values so diagnosis is zero-effort; without explicit content tests, a future refactor that accidentally drops a struct field from the #[error(...)] format string would silently degrade the log output. Added 6 dedicated tests: display_slot_not_increasing (both slot values), display_prev_hash_mismatch (“expected” + “got” labels), display_ocert_counter_too_old (both counter values), display_ocert_counter_too_far (both counter values), display_obsolete_node (slice 43’s new variant — asserts header major, ceiling major, AND the “obsolete” identifier), display_vrf_key_mismatch_names_both_hashes (pins the Debug-formatted byte content so a swap of byte arrays doesn’t silently pass — 0xAA = 170, 0xBB = 187 decimal cross-check). The ObsoleteNode test is particularly important: slice 43 added that variant, but no dedicated test previously asserted the Display format surfaces both numeric fields + the rule name. Now regression-safe. 4297 workspace tests pass across all crates, 0 failures.
  • SyncError display-message coverage — extends the ConsensusError Display-content pattern to the sync-layer error surface. Previously SyncError had NO Display-content tests: a future refactor of any #[error(...)] format string could silently drop diagnostic fields without any test failing. Added 5 dedicated tests for the validation-failure variants carrying operator-facing diagnostic fields: display_block_from_future_names_slot_and_excess (both slot and excess_slots), display_wrong_block_body_size_names_both_sizes (both declared and actual), display_protocol_version_mismatch_names_era_and_versions (era name via Debug formatting + declared major + expected range string), display_protocol_version_too_high_names_both_majors (both major and max), display_header_prot_ver_too_high_names_both_majors (both header_major and pp_major). Each test asserts on the format-string-derived content using both decimal and underscore-separated representations ("12345" OR "12_345") so a future rustc update switching between formattings doesn’t make the test brittle. Combined with slice 55, every error variant carrying diagnostic fields across both consensus and sync layers now has content-level Display regression coverage. 4302 workspace tests pass across all crates, 0 failures.
  • StorageError Display / PartialEq coverage — final crate-level gap in the Display-content-regression pattern established in slices 55-56. The storage crate had zero error-level tests despite its StorageError enum being reachable through every sync/runtime path. Added 6 tests: display_duplicate_block_names_hash_prefix (pins that HeaderHash Display impl’s hex bytes reach the outer error message — a future refactor silently switching the {0} placeholder to Debug formatting would pass existing smoke tests but fail this assertion), display_point_not_found, display_io_propagates_inner_error (crucially asserts the inner std::io::Error message survives the outer {0} placeholder — this is the common regression shape where operators see “I/O error” with no details), display_serialization_propagates_message, display_recovery_propagates_message, partial_eq_ignores_io_inner_message_uses_kind (pins the PartialEq impl’s documented behavior: two Io(_) errors compare equal iff their ErrorKinds match, ignoring the inner message — this lets tests like assert_eq!(a, b) work without exact-message matching for I/O paths, but the invariant must be CI-checked because std::io::Error has no natural PartialEq and the manual impl could drift). Now every error enum carrying diagnostic fields across the consensus/sync/storage stack has content-level Display + equality coverage. 4308 workspace tests pass across all crates, 0 failures.
  • GenesisLoadError Display-content coverage — closes the final error-enum gap in the slice-55-to-57 Display-content-regression series. The GenesisLoadError variants are the primary operator-facing surface when a genesis file is missing / corrupt / hash-mismatched, yet had zero format-string content tests — only shape tests via matches!. Added 5 tests: display_hash_mismatch_names_path_expected_actual (all three operator-diagnostic fields: path + declared hash + computed hash), display_invalid_hash_hex_names_field_and_value (field name + offending value so the operator can grep their config), display_invalid_field_names_field_value_and_reason (covers the three-field case InvalidField { field, value, message }), display_io_error_names_path_and_inner (asserts the inner std::io::Error message survives — parallel to the slice-57 StorageError/Io pattern), display_json_error_names_path_and_inner_reason (asserts the serde_json error message is propagated; tolerant to upstream message-wording changes via a parse OR expected OR key lowercase token check). The InvalidField-variant test is particularly important because that variant is emitted from the Byron nonAvvmBalances and avvmDistr genesis-parsing paths, which are the most user-facing error surface when a Byron genesis file is malformed. 4313 workspace tests pass across all crates, 0 failures.
  • conway_pv_can_follow u64::MAX overflow edge-case fix — real latent bug caught while auditing the hard-fork-proposal version-increment rule. Upstream pvCanFollow accepts the new protocol version (M, N) only when it is exactly one step above previous: either same major + next minor, or next major + minor=0. Our implementation used previous.1.saturating_add(1) on the minor branch, which collapses to identity at u64::MAX: (10, u64::MAX).saturating_add(1) == u64::MAX, so (10, u64::MAX) → (10, u64::MAX) was silently accepted as an increment despite being a same-version identity proposal. Fixed by switching both branches to checked_add(1).is_some_and(...) so the overflow returns None and the branch is rejected. Two new regression tests: pv_can_follow_rejects_identity_at_u64_max_minor_boundary (pins the exact edge case that collapsed under saturating_add; also positively asserts (10, u64::MAX - 1) → (10, u64::MAX) stays accepted as a legitimate minor increment) and pv_can_follow_rejects_major_overflow (pins the major-branch variant (u64::MAX, 5) → (0, 0) does not wrap). Validation methodology: temporarily reverted the fix to saturating_add, confirmed the new regression test failed with "assertion failed: !conway_pv_can_follow((10, u64::MAX), (10, u64::MAX))", then reinstated the fix and re-ran all 7 pv_can_follow tests clean. This detect-and-revert proves the fix addresses the exact issue the test pins. In practice this edge case is unreachable (no real chain will ever have a u64::MAX minor protocol version) but silently accepting identity at the overflow boundary is a defense-in-depth gap that could mask test-harness bugs in future slices. 4315 workspace tests pass across all crates, 0 failures.
  • Direct unit-level coverage for GovernorTargets::is_sane — upstream sanePeerSelectionTargets is the single safety gate that prevents the governor from entering an unreachable target configuration, yet had ZERO direct unit tests. The preflight test _warns_on_insane_governor_targets proves “at least one insane config is caught” but does not pin the individual invariants, so a regression flipping a single predicate (e.g. accidentally swapping <= for < on the active ≤ established check, allowing the equal-to boundary to silently pass) would not surface as a failing test. Added 14 dedicated tests each pinning exactly one invariant: is_sane_accepts_default_targets, _rejects_active_above_established, _rejects_established_above_known, _rejects_root_above_known, _rejects_active_big_above_established_big, _rejects_established_big_above_known_big, _accepts_boundary_upper_limits (exactly 100 / 1000 / 10000 must pass — pins that the bounds use <= not <), _rejects_active_above_100, _rejects_established_above_1000, _rejects_known_above_10000, _rejects_active_big_above_100, _rejects_established_big_above_1000, _rejects_known_big_above_10000, _accepts_all_zeros (no-peer-pressure config is valid — pins that the governor does not force any positive lower bound). Test set size matches the invariant count 1:1 so future audits can map invariants to tests by name. 4329 workspace tests pass across all crates, 0 failures.
  • Preflight peer_sharing wire-range sanity — the NtN handshake peerSharing field is a Word8 with exactly two upstream-defined values: 0 (disabled) and 1 (enabled). Our NodePeerSharing::from_wire uses value >= 1 on the receiver side, so it silently normalizes any undefined value to “enabled” — but transmitting an out-of-range value is a misconfiguration on our side that peers implementing strict codecs may reject at handshake time. validate_config_report now warns when peer_sharing > 1 with the exact offending value inlined so an operator who meant 0/1 spots the typo. Two tests: _warns_on_out_of_range_peer_sharing covers both 2 (most common typo) and 255 (max u8); _accepts_canonical_peer_sharing_values loops over the canonical {0, 1} pair. Mainnet preset validate-config re-checked to confirm no false positive (all three presets use default_peer_sharing() which is within the valid range). 4331 workspace tests pass across all crates, 0 failures.
  • check_kes_period overflow-guard regression test — the KesPeriodOverflow path was implemented correctly via checked_add(max_kes_evolutions) but had ZERO test coverage, so a future refactor accidentally switching to saturating_add or wrapping_add (both would compile and not change any existing test’s outcome) could silently cause the function to accept certificates well past their intended expiry when opcert.kes_period + max_kes_evolutions overflows u64. New test check_kes_period_rejects_overflow pins: (1) the overflow case — opcert.kes_period = u64::MAX - 5 with max_kes_evolutions = 10 must return KesPeriodOverflow, AND (2) the adjacent non-overflow boundary — max_kes_evolutions = 5 with the same cert start yields u64::MAX exactly, which is representable so the function returns Ok. Both assertions in the same test so a regression that shifts the boundary in either direction fails a single test with a clear diagnosis. Validation methodology: temporarily replaced checked_add(...).ok_or(KesPeriodOverflow)? with saturating_add(...), confirmed the new regression test failed with assertion failed: left: Ok(()), right: Err(KesPeriodOverflow), then reinstated the fix and re-ran all 5 check_kes_period tests clean. Detect-and-revert confirms the test catches the exact defensive invariant it pins. In practice this boundary is unreachable on mainnet but matters because KES period is a u64 that advances monotonically — a malformed upstream opcert could place kes_period arbitrarily close to u64::MAX and a wraparound here would let an obviously-expired cert pass. 4332 workspace tests pass across all crates, 0 failures.
  • Documented Nonce::combine upstream-parity gap — identified while auditing consensus-layer primitives: upstream’s (⭒) / Semigroup operator on Nonce is defined as Nonce(Blake2b-256(bytesOf(a) ‖ bytesOf(b))) (hash-concatenation) in Cardano.Ledger.BaseTypes and reused by Cardano.Protocol.TPraos.BHeader for nonce evolution across UPDN and TICKN. Our implementation uses byte-wise XOR instead — a historical simplification that produces DIFFERENT evolving/candidate/epoch nonces than upstream, which means our VRF verification is not bit-identical against real-mainnet data. Fixing it is a deliberate future slice (not this one) because: (1) every downstream nonce test — nonce_combine_is_xor, plus ~a dozen integration tests whose expected nonce outputs were derived under the XOR rule — would need its expected values recomputed; (2) the change cascades into chain-state computations which are validated by VRF leader-election tests. Doing it right requires a single coordinated slice with full regression coverage, not incremental work. This slice closes the documentation gap: the Nonce::combine rustdoc now carries a ⚠ Known upstream-parity gap banner pointing at the upstream reference and explaining why the fix is a dedicated follow-up; crates/consensus/AGENTS.md gains a matching tracked-gap entry so the parity debt is visible at the operational level. Zero functional change, zero test delta — pure documentation/traceability improvement so the gap is not forgotten when a real-mainnet VRF replay test lands. 4332 workspace tests pass across all crates, 0 failures.
  • MempoolError Display-content coverage — extends the Display-content-regression pattern (slices 55-58) to the mempool admission failure surface. MempoolError variants reach operators via submit-tx rejection reasons over NtC and as wire-encoded MsgRejectTx payloads — each rejection needs to surface WHICH limit was hit AND the offending values. Previously zero content tests covered these. Added 8 dedicated tests, one per Display-relevant variant: display_mempool_duplicate_names_tx_id, display_mempool_capacity_exceeded_names_all_three_counts (current + incoming + limit), display_mempool_ttl_expired_names_both_slots, display_mempool_fee_too_small_names_both_amounts, display_mempool_tx_too_large_names_both_sizes, display_mempool_ex_units_exceed_names_all_four_dimensions (tx_mem + tx_steps + max_mem + max_steps — the Plutus-path limit), display_mempool_conflicting_inputs_names_colliding_tx, display_mempool_protocol_param_validation_propagates_message. Combined with slices 55/56/57/58, every error-enum surface along the sync + consensus + storage + genesis-loading + mempool-admission path now has format-string-content regression coverage. 4340 workspace tests pass across all crates, 0 failures.
  • AcquireFailure human-readable Display impl — small real-code quality improvement. The LSQ AcquireFailure enum had only #[derive(Debug)] and was embedded in LocalStateQueryClientError::AcquireFailed via {0:?} Debug formatting, so an operator seeing “acquire failed: PointTooOld” would get a developer-facing token rather than a descriptive message. Added dedicated Display impl emitting “point too old (older than the immutable tip)” / “point not on current chain”, and switched LocalStateQueryClientError::AcquireFailed’s error-format from {0:?} to {0} so the outer error surface picks up the new form automatically. Two new tests: acquire_failure_display_point_too_old and acquire_failure_display_point_not_on_chain each assert the human-readable rule tokens appear AND the Debug variant-name identifier ("PointTooOld" / "PointNotOnChain") does NOT leak — so a future refactor reverting to {0:?} formatting (which would emit the variant name) fails the test. Existing acquire_*_roundtrip tests unchanged — CBOR wire format is untouched, this is a presentation-layer refinement only. 4342 workspace tests pass across all crates, 0 failures.
  • RefuseReason human-readable Display impl — parallel improvement to slice 65 for the handshake surface. RefuseReason had only #[derive(Debug)] and was embedded in PeerError::Refused { reason } via {reason:?} Debug formatting, so operators saw error messages like handshake refused: VersionMismatch([HandshakeVersion(13), HandshakeVersion(14)]) — a developer-facing token dump instead of a descriptive message. Added dedicated Display impl that emits human-readable forms: "version mismatch — peer accepts [13, 14]", "handshake version data for version 14 failed to decode: expected map", "refused version 13: wrong magic". Switched PeerError::Refused’s format from {reason:?} to {reason}. Four new tests in a freshly-created handshake test module: refuse_reason_display_version_mismatch (rule name + both version numbers listed + Debug variant name NOT leaked), refuse_reason_display_handshake_decode_error (rule + version + inner reason propagated), refuse_reason_display_refused (rule + version + inner reason), refuse_reason_display_empty_version_list_is_stable (empty VersionMismatch(vec![]) must render [] cleanly without panicking — edge case that a future .unwrap() refactor could expose). Wire-format / CBOR encoding untouched. 4346 workspace tests pass across all crates, 0 failures.
  • ConnectionManagerError Display-content coverage — 9 dedicated tests one per variant, pinning the peer-identifying fields that an operator needs to diagnose connection-state-machine errors. Every ConnectionManagerError variant carries either a SocketAddr (peer) or a ConnectionId (local + remote) and the hand-written Display impl includes these in each message, but zero tests previously asserted they actually surface. New tests: display_cm_error_connection_exists_names_provenance_and_peer, _forbidden_connection_names_conn_id, _inbound_not_found_names_peer, _impossible_connection_names_conn_id, _connection_terminating_names_conn_id, _connection_terminated_names_conn_id, _impossible_state_names_peer, _forbidden_operation_names_peer_and_state (the two-field case — both peer AND the AbstractState the operation was rejected from must appear), _unknown_peer_names_addr. Test naming explicitly enumerates which fields are asserted so a future audit can map diagnostic fields to tests by name. 4355 workspace tests pass across all crates, 0 failures.
  • MachineError test-coverage gap close + exhaustiveness drift guard — audit found a real coverage gap in crates/plutus/src/error.rs: the MissingBuiltinCost(String) variant (structural error for a malformed/incomplete cost model) had NO dedicated Display-content test AND was absent from BOTH the operational_errors_are_classified_correctly and structural_errors_are_classified_correctly test lists. Together with the fact that is_operational uses matches! (no compiler-enforced exhaustiveness), this meant: (1) a regression accidentally adding MissingBuiltinCost to the operational list would silently collapse malformed-cost-model diagnostics to opaque EvaluationFailure — exactly the wrong behavior for a structural error that identifies a configuration bug; (2) future variants added without test updates would inherit the silent-structural default with no warning. Fixed three gaps in one slice: (a) missing_builtin_cost_display pins the #[error(...)] format content including the bls12_381_G1_neg builtin-name substring; (b) two other under-covered display-content tests filled (non_constr_scrutinized_display, builtin_term_argument_expected_display); (c) extended structural_errors_are_classified_correctly to include MissingBuiltinCost; (d) NEW every_machine_error_variant_has_explicit_operational_decision drift-guard test uses an exhaustive match with one arm per variant that hard-codes the expected classification, so any new variant added to MachineError WITHOUT being classified in this test is a hard compile error. Cross-assertion on the current runtime is_operational output — a regression that toggles classification silently in is_operational fails the test with the exact variant name in the diagnostic. The 19-arm match enumeration means every variant is locked to its current classification individually. 4359 workspace tests pass across all crates, 0 failures.
  • BlockFetchClientError + ChainSyncClientError Display-content coverage — bundle two network-client error enums that had zero Display tests. Both error types propagate inner diagnostic strings (CBOR decode reasons, protocol timeouts, unexpected-message contexts) to the sync-layer peer-attribution path; without content tests, a future refactor dropping a {0} placeholder in #[error(...)] would silently hide operator diagnostics. Added fresh tests modules to both files (neither had one). 4 tests for BlockFetchClientError: display_blockfetch_connection_closed, _timeout_surfaces_duration (pins "30" survives the {0:?} Duration debug formatting), _decode_propagates_inner_reason ("trailing bytes at offset 17" substring), _unexpected_message_propagates_inner. 6 tests for ChainSyncClientError: _connection_closed, _timeout_surfaces_duration (uses an unusual 269-second value so a future refactor that accidentally constantizes the timeout to upstream’s 97s also fails), _decode_propagates_inner_reason, _unexpected_message_propagates_inner, _point_decode_propagates_inner_reason, _header_decode_propagates_inner_reason. Both enums use #[from] inner errors (MuxError, LedgerError) which inherit their own Display impls and are covered by the per-crate tests, so only the String-carrying variants need dedicated coverage here. 4369 workspace tests pass across all crates, 0 failures.
  • CostModelError + KeepAliveClientError Display-content coverage — bundle two small error enums that had zero test coverage. CostModelError (2 variants) surfaces at cost-model-construction time when Alonzo/Conway genesis files are missing named parameters or contain negative values — operators need the parameter name and the value that tripped the check. KeepAliveClientError (6 variants) includes the KeepAlive-specific CookieMismatch { sent, received } that no other error type carries. New tests: display_cost_model_missing_parameter_names_parameter, display_cost_model_negative_parameter_names_field_and_value (pins both name and signed value), plus 5 keepalive tests including display_keepalive_cookie_mismatch_names_both_cookies which uses 0xABCD / 0x1234 inputs and asserts the decimal decodings (43981, 4660) appear — so a refactor that switches to hex formatting would also trigger the test assertion. The 97-second timeout value matches the upstream KeepAlive client inactivity limit so the test doubly-documents the upstream constant. 4376 workspace tests pass across all crates, 0 failures.
  • Server-side Display-content coverage — 3 server-side error enums (BlockFetchServerError, ChainSyncServerError, KeepAliveServerError) had ZERO test modules. These errors appear in peer-attribution logs when we REFUSE inbound protocol messages, so the Decode and UnexpectedMessage diagnostic strings need to propagate to operator logs even after error-format refactors. Each got a fresh tests module with 4 tests: _connection_closed, _timeout, _decode_propagates_inner (includes a server-specific decode reason e.g. "invalid range point" for BlockFetch), _unexpected_message_propagates_inner (includes a plausible state-transition violation e.g. "MsgRequestRange in StStreaming" for BlockFetch or "MsgFindIntersect in StMustReply" for ChainSync). 12 tests total, mirroring the slice-69/70 client-side coverage so both directions of peer communication now have content-level regression protection for their error surfaces. 4388 workspace tests pass across all crates, 0 failures.
  • NtC + remaining NtN server Display-content coverage — final batch closing all server-side protocol-error enums. 5 server error enums across local (NtC) and inbound (NtN-tx-submission / PeerSharing) surfaces had no test modules: LocalTxSubmissionServerError, LocalTxMonitorServerError, LocalStateQueryServerError, TxSubmissionServerError, PeerSharingServerError. Each got 3 tests (_connection_closed, _decode_propagates_inner, _unexpected_message_propagates_inner) — 15 tests total. Inner reason strings are protocol-specific so a copy-paste refactor that crosses wires between surfaces (e.g. LTS error using LTM message names) would fail the content assertion. Combined with slices 65-71 this completes the “every error enum with operator-diagnostic fields has a Display-content regression test” milestone across the consensus + sync + storage + genesis + mempool + plutus + network client + network server + NtC surfaces. Any future format-string refactor that drops a diagnostic field now fails at least one test, and the per-enum enumeration means the failing test names the offending enum directly. 4403 workspace tests pass across all crates, 0 failures.
  • Testable decode_tx_hex_arg helper + submit-tx CLI input coverage — real refactor of the submit-tx --tx-hex argument-parsing logic out of an inline match expression into a standalone decode_tx_hex_arg(raw: &str) -> Result<Vec<u8>> helper. Previously the three-step parse (trim / strip 0x prefix / hex-decode) was buried inside the Command::SubmitTx dispatch arm with no direct test coverage — meaning a refactor that silently dropped the 0x-prefix support (a cardano-cli ergonomic that operators rely on for pasted transaction bodies) would pass all existing tests. Extracted the helper with a rustdoc that documents the three acceptance rules + the “invalid hex in –tx-hex” error-wrapping contract, then added 7 tests: _accepts_plain_hex (baseline), _strips_0x_prefix (pins cardano-cli-compat behavior), _trims_whitespace (pins the terminal-paste ergonomic with a trailing newline), _combines_whitespace_and_prefix (the realistic paste scenario \t0xDEADBEEF\n), _accepts_empty_string (pins the “decode-only, don’t validate-shape” contract — empty hex is not an error here, it’s an empty byte sequence that LTS will reject downstream), _rejects_odd_length_hex, _rejects_non_hex_chars (both latter assert the "invalid hex in --tx-hex" wrap survives — so the operator sees which CLI flag is at fault rather than a bare hex-crate error). Zero functional change to the submit-tx flow; the Command::SubmitTx arm now reads decode_tx_hex_arg(&hex)? instead of the inline trio. 4410 workspace tests pass across all crates, 0 failures.
  • Consistent 0x-prefix ergonomic across all query CLI hex arguments — extends the slice-73 submit-tx ergonomic to the 5 query-argument encoders (UtxoByAddress, RewardBalance, UtxoByTxIn, DelegationsAndRewards, StakePoolParams). Previously each site inlined hex::decode(x.trim()).unwrap_or_default() without 0x-prefix support, so an operator pasting a 0x1234… address from a block explorer would get a silently-empty query. Added decode_optional_prefixed_hex(raw: &str) -> Vec<u8> — the lenient counterpart of decode_tx_hex_arg — that trims whitespace, strips an optional 0x prefix, hex-decodes, and returns Vec::new() on parse failure (preserving the prior .unwrap_or_default() call-site semantics so the change is additive). All 5 query-argument sites now call it. 5 unit tests on the helper itself: _accepts_plain_hex, _strips_0x_prefix, _trims_whitespace, _returns_empty_on_invalid (pins the lenient contract so an eventual strict-mode upgrade is an explicit opt-in), _empty_is_empty (pins "", "0x", " " — three spellings of “no input”). Plus encode_ntc_query_accepts_0x_prefixed_arguments_end_to_end pins the full QueryCommand → encode_ntc_query → CBOR bytes pipeline at two representative variants (UtxoByAddress, StakePoolParams) — asserting 0x-prefixed and plain inputs emit IDENTICAL CBOR. The end-to-end test catches the partial-refactor case where someone inlines one of the five sites without going through the helper. Rustdoc notes that a future strict-argument-validation slice would only need to touch the helper + the five call sites. 4416 workspace tests pass across all crates, 0 failures.
  • CLI help-text documentation of the 0x-prefix ergonomic — slice 74 added 0x-prefix support to the 5 query-argument encoders and the submit-tx --tx-hex flag, but the CLI help text still read “Hex-encoded address bytes” with no mention of the accepted shapes — so an operator running yggdrasil-node query utxo-by-address --help had no way to know the ergonomic existed. Updated the clap #[arg] docstrings on all 6 affected flags: --tx-hex, --address, --account, --tx-id, --credential, --pool-hash — each now reads “… (with or without `0x` prefix)” (or the submit-tx variant “Accepts an optional `0x` prefix and surrounding whitespace for terminal-paste ergonomics”). Plus a new drift-guard test cli_help_text_documents_0x_prefix_ergonomic that uses clap::CommandFactory to render the actual long-help for the root command plus all subcommands and nested subcommands, asserts each hex flag appears AND counts "0x" mentions to ensure the number is at least equal to the number of hex flags — so a future refactor dropping the docstring on ONE flag fails with "expected at least 6 '0x' mentions in CLI help (one per hex flag), found 5". Validation methodology: temporarily reverted the UtxoByAddress docstring back to “Hex-encoded address bytes”, confirmed the test failed with exactly that diagnostic (5 mentions when 6 are expected), reinstated the docstring, clean pass. This ensures the human-facing CLI ergonomics tracked by slice 74 are protected at CI time against silent documentation regression. 4417 workspace tests pass across all crates, 0 failures.
  • MAINNET_NETWORK_MAGIC named constant — small code-quality improvement that pulls the literal mainnet-magic 764_824_073 out of two inline sites in node/src/config.rs (RequiresNetworkMagic::default_for_magic and mainnet_config()) and into a single public module-level constant. Upstream cardano-node Cardano.Chain.Genesis.Data fixes protocolMagicId = 764824073; a drift on our side produces silently-incompatible clients that fail every NtN/NtC handshake against mainnet. Three new tests pin the invariant: mainnet_network_magic_constant_matches_upstream (value = 764_824_073 — direct ground-truth pin), mainnet_config_uses_canonical_magic_constant (mainnet_config().network_magic == MAINNET_NETWORK_MAGIC — catches a regression that re-inlines the literal), requires_network_magic_default_pins_constant (mainnet → RequiresNoMagic, mainnet+1 → RequiresMagic, testnet magic 2 → RequiresMagic — pins both branches of the dispatch so the constant flip silently loses Byron-header-decode compatibility). Zero functional change (all existing tests unaffected). The remaining hard-coded literals live in crates/network test fixtures and documentation examples — left alone to avoid cross-crate coupling for a minor refactor. 4420 workspace tests pass across all crates, 0 failures.
  • Disposition routing exhaustiveness — handle_reconnect_batch_error_punishes_for_peer_attributable_errors previously tested only 2 of the 8 peer-attributable SyncError variants (BlockBodyHashMismatch + Consensus(InvalidKesSignature)). Slices 52 and 71 had the classification logic + classification exhaustiveness covered, but this left a gap: a regression flipping ONE peer-attributable variant to “not attributable” in the matches! list in is_peer_attributable would cause that variant to route to a bare Reconnect (no peer demotion) instead of ReconnectAndPunish — silently losing peer-punishment semantics for that error class. Extended the test to iterate over all 8 peer-attributable variants via an exhaustive Vec<SyncError>, asserting is_peer_attributable() returns true AND the disposition is ReconnectAndPunish. Two sources-of-truth (the list here + the matches! arm in is_peer_attributable) must stay aligned; any regression that flips one without the other fails the test with the exact offending variant named in the diagnostic. Also added #[derive(Debug)] to BatchErrorDisposition so {disposition:?} formatting works in the assertion diagnostic — small ergonomics improvement that unlocks clean failure messages. Validation methodology: temporarily removed HeaderProtVerTooHigh from the is_peer_attributable matches! list, confirmed the test failed with "test precondition: HeaderProtVerTooHigh { ... } must be peer-attributable", reinstated, clean pass. The two-layer guard (precondition assertion + disposition assertion) means either half of the link breaking surfaces at CI time. 4420 workspace tests pass across all crates, 0 failures.
  • PREPROD_NETWORK_MAGIC + PREVIEW_NETWORK_MAGIC named constants — extends slice 76 to the two public testnet preset magics. Previously preprod_config() inlined network_magic: 1 and preview_config() inlined network_magic: 2. Both now reference public module-level constants with rustdoc citing the upstream cardano-configurations source. 4 new tests: _constant_matches_upstream for each (direct value pin), all_three_network_magics_are_distinct (defensive — if any two collided handshake disambiguation would break; pins all three pairs), preset_configs_use_canonical_magic_constants (preprod_config() / preview_config() → their canonical constants — catches a refactor re-inlining the literals). With slice 76 + this slice, every Yggdrasil preset’s network_magic now goes through a named constant. Zero functional change. 4424 workspace tests pass across all crates, 0 failures.
  • NetworkPreset::network_magic() cheap accessor + caller refactor — capitalises on slices 76 + 78’s named constants by adding an O(1) accessor pub fn network_magic(self) -> u32 that returns the canonical magic without going through to_config() (which re-reads topology files, computes fallback peers, and constructs a full NodeConfigFile just to extract a u32). Refactored the one existing network.to_config().network_magic call site (extract_reference_network_magic) to use the cheap accessor — eliminates a hot-path file read per CLI invocation. Two new tests pin the accessor: network_preset_network_magic_returns_named_constants (per-preset value pin against the constants from slices 76 + 78) and network_preset_network_magic_matches_to_config_for_all_presets (for every preset, asserts the cheap accessor and the full constructor agree — pinned because a drift would mean preflight code and node startup disagree on the network, silently producing handshake failures on real connections). The accessor’s docstring explains the cost difference and the equivalence guarantee. 4426 workspace tests pass across all crates, 0 failures.
  • MAINNET_NETWORK_ID + TESTNET_NETWORK_ID named constants — closes the matching gap to slices 76 + 78 for the network ID (the 1/0 value embedded in every reward / Shelley address byte string at the high nibble), distinct from the network MAGIC (the handshake discriminant). expected_network_id was inlining BOTH the magic literal 764_824_073 AND the bare 1/0 returns — now it routes through MAINNET_NETWORK_MAGIC for the comparison and the new MAINNET_NETWORK_ID / TESTNET_NETWORK_ID constants for the result. Two new tests: mainnet_network_id_constant_matches_upstream (direct value pin against Cardano.Ledger.Api.Tx.Address Network = Mainnet → 1), expected_network_id_uses_named_constants_consistently (cross-asserts mainnet/preprod/preview presets AND a synthetic custom magic, pinning that any non-mainnet value classifies as testnet — so a regression flipping the dispatch direction silently misclassifies addresses at value-preservation time). The two distinct concept names (network MAGIC vs network ID) are now visually unambiguous in code, eliminating the slice-42-style namespace-confusion risk that prompted the slice-44 lesson. 4428 workspace tests pass across all crates, 0 failures.
  • Defensive continue for AlwaysAbstain / AlwaysNoConfidence in tally_drep_votes — small robustness improvement identified during an audit of production unreachable!() sites. The DRep voter-tag match at the bottom of the tally_drep_votes loop used unreachable!() for DRep::AlwaysAbstain | DRep::AlwaysNoConfidence, relying on the early continue branches at the top of the loop body to short-circuit them. This is correct under current control-flow, but a future refactor that removes or restructures the early filter (e.g. folds it into the outer caller) would cause a production panic with no log context — bad failure mode for the governance tally path, which runs at every epoch boundary. Swapped unreachable!() for continue so the variants are silently skipped if they somehow reach that arm — same semantic (no voter tag for these pseudo-DReps) but no panic. Added rustdoc explaining the defensive choice. New regression test drep_tally_handles_always_abstain_and_no_confidence_without_panic constructs a stake map containing a regular DRep (Yes vote, stake 100) plus AlwaysAbstain (500) and AlwaysNoConfidence (200), then asserts the tally output at both count_no_confidence_as_yes = false (total=300, yes=100 — AlwaysAbstain excluded from total, AlwaysNoConfidence in total but not Yes) and = true (total=300, yes=300 — AlwaysNoConfidence now counts as Yes). The “without_panic” suffix documents the regression-guard intent. 4429 workspace tests pass across all crates, 0 failures.
  • NetworkPreset::all() helper + caller refactor — 4 test sites were iterating over the three variants via hand-written [NetworkPreset::Mainnet, NetworkPreset::Preprod, NetworkPreset::Preview] array literals. Each of those sites would silently keep iterating only over the existing variants if a new preset was added — hiding the fact that tests needed to be updated. Added pub const fn all() -> &'static [Self] returning a canonical-order 'static slice (Mainnet, Preprod, Preview), with rustdoc calling out the “adding a new variant MUST extend this list” contract. Refactored 4 call sites to for &preset in NetworkPreset::all(): network_preset_network_magic_matches_to_config_for_all_presets, vendored_preset_hashes_match_vendored_genesis_files_end_to_end, network_preset_display_round_trips, and slice-53’s vendored_network_presets_produce_only_environmental_warnings. New test network_preset_all_returns_every_variant_exactly_once pins the canonical order AND distinctness of every pair — so a copy-paste refactor that duplicates an entry in all() fails CI. Future variants added to NetworkPreset without also extending all() are caught by this test’s assert_eq!(all.len(), 3) failing. 4430 workspace tests pass across all crates, 0 failures.
  • Era::all() helper + drift guard — mirror of slice 82 for the Era enum (Byron through Conway, 7 variants). Previously no iteration helper existed; integration tests that wanted to loop over every era hand-listed all 7 variants — same silent-drift risk as slice 82. Added pub const fn all() -> &'static [Self] returning the canonical ordinal-ascending slice, with rustdoc calling out the “new hard-fork era MUST extend this list” contract and the linkage to the drift-guard test. Two new unit tests in eras::tests: era_all_returns_every_variant_in_canonical_order (pins the 7 named variants at the exact slice positions so a copy-paste reorder fails — critical because is_hard_fork_to / is_era_regression correctness depends on the ordinal ordering), era_all_ordinals_are_zero_through_six_in_order (iterates the slice and asserts era_ordinal() == index for each — cross-asserts all()’s order against the era_ordinal() implementation, so a regression that flips an ordinal but forgets the slice, or vice versa, fails CI). 4432 workspace tests pass across all crates, 0 failures.
  • CONWAY_MAJOR_PROTOCOL_VERSION named constant — closes the remaining magic-number gap in node/src/config.rs by pulling the inlined 10 (Conway-era MaxMajorProtVer) out of default_max_major_protocol_version() and into a public module-level constant. default_max_major_protocol_version() now returns the constant; the preflight message in main.rs that previously hard-coded "Recommended: 10 (Conway-era default)" now interpolates the constant so operator-facing text and code stay in sync. Rustdoc documents upstream reference (Ouroboros.Consensus.Protocol.Abstract MaxMajorProtVer) and explains that a future hard-fork would add a new NEXT_ERA_MAJOR_PROTOCOL_VERSION constant rather than mutating this one. Two new tests: conway_major_protocol_version_constant_matches_upstream_default (pins value = 10 AND the function-constant equivalence), preset_configs_use_conway_major_protocol_version (all three presets default to the Conway constant — catches a copy-paste regression that re-inlines a different value in one preset). With this slice and slices 76/78/80, every upstream-defined Cardano protocol constant in config.rs is now named and test-pinned. 4434 workspace tests pass across all crates, 0 failures.
  • default_governor_target_* drift guards — the six default_governor_target_* serde-default functions in config.rs hand-code the values 20 / 10 / 5 / 0 / 0 / 0 for the regular + big-ledger target tiers. GovernorTargets::default() in crates/network independently hand-codes the same values. Drift between the two would mean a freshly parsed config (via serde defaults) and a hand-constructed GovernorTargets::default() (used internally) silently disagree on peer-selection targets. Added default_governor_target_fns_match_governor_targets_default — explicitly cross-asserts each of the 6 function returns against the corresponding GovernorTargets::default() field, so drift on either side fails CI with a clear per-field diagnostic. Second test default_governor_targets_are_sane — runs GovernorTargets::is_sane() against a struct built from the defaults, pinning that the fresh-install baseline doesn’t trigger the slice-40 “insane governor targets” preflight warning. Belt-and-braces next to slice 60’s direct unit coverage of individual is_sane invariants. 4436 workspace tests pass across all crates, 0 failures.
  • Nonce-combine upstream-parity slice — closes the long-standing critical-path parity gap previously documented as a deliberate “dedicated follow-up slice” in the type’s own rustdoc and in crates/consensus/AGENTS.md. yggdrasil-ledger::types::Nonce::combine previously implemented byte-wise XOR (Hash(a) ⊕ Hash(b) = Hash(a XOR b)); upstream Semigroup Nonce (Cardano.Ledger.BaseTypes) and combineNonces (Cardano.Protocol.TPraos.BHeader) define (⭒) as Hash(a) ⭒ Hash(b) = Hash(Blake2b-256(a ‖ b)). The XOR simplification produced evolving / candidate / epoch nonces that diverged from mainnet on-chain values, blocking byte-identical VRF verification against real chains and therefore blocking mainnet sync correctness end-to-end. Nonce::combine now copies the two 32-byte digests into a 64-byte preimage buffer and returns Hash(yggdrasil_crypto::blake2b::hash_bytes_256(preimage).0), matching the upstream Haskell Semigroup instance bit-for-bit. Three test suites updated in lockstep: the ledger unit test nonce_combine_xor is replaced with nonce_combine_is_blake2b_concat (pinning the literal Blake2b-256 of [0xFF; 32] ‖ [0x0F; 32] = 5cd61717ec07b4b5ca8c6eb04bd9adc6c94b4d10f8356c6f11380077a02a29c0) plus a new nonce_combine_is_not_commutative to guard against a future canonicalising-sort regression; the consensus integration tests nonce_combine_is_xor and nonce_self_combine_yields_zero are replaced with hash-concat equivalents (nonce_combine_is_blake2b_concat and nonce_self_combine_is_deterministic_hash, the latter pinning Blake2b-256 of [0x42; 32] ‖ [0x42; 32] = b4e02ed6977c5cd9ac4398e94e6376ee2fcd6026f8833b7e7d7dd6a33572b3c4); and nonce_evolution_neutral_extra_entropy is renamed to nonce_evolution_neutral_vs_zero_extra_entropy and its assertion inverted from assert_eq! to assert_ne! since Nonce::Hash([0;32]) is no longer an identity element under hash-concat. Surrounding rustdoc and the trailing assertion message in the extra-entropy combine test are also updated to drop residual XOR references. The new function and tests are anchored in the rustdoc to the upstream module paths in IntersectMBO/cardano-ledger. Reference: Semigroup Nonce in Cardano.Ledger.BaseTypes; combineNonces via (<>) in Cardano.Protocol.TPraos.BHeader. 4437 workspace tests pass across all crates, 0 failures.
  • Historical pre-R238 OpCert counter cross-restart persistence slice — closes the second critical-path parity gap from the same audit. Upstream PraosState.csCounters (Ouroboros.Consensus.Protocol.Praos) is part of the durable ChainDepState, so a restart preserves the per-pool monotonicity high-water mark used by currentIssueNo (stored ≤ new_seq ≤ stored + 1). Yggdrasil previously constructed OcertCounters::new() afresh on every node startup at node/src/main.rs::run (two sites), so a restart silently reset all counters to zero, allowing a malicious peer to replay an old block whose OpCert sequence number was below the true on-chain value. Now: (1) crates/consensus::OcertCounters implements CborEncode/CborDecode against the ledger crate’s deterministic Encoder/Decoder (single CBOR map keyed by 28-byte pool key hash with u64 sequence-number values, emitted in canonical BTreeMap order) plus an iter() accessor, with 4 new unit tests (empty round-trip pinning the 0xa0 byte, multi-pool round-trip, decode rejection on short keys, deterministic encoding regardless of insertion order). (2) The first implementation used root-level save_ocert_counters/load_ocert_counters helpers; R238 removed those public helpers and moved nonce/OpCert persistence into canonical slot-indexed ChainDepState bundles. (3) node/src/sync.rs extends LedgerCheckpointTracking with an ocert_persist_dir: Option<PathBuf> field; update_ledger_checkpoint_after_progress and apply_verified_progress_to_chaindb gain an ocert_counters: Option<&OcertCounters> parameter, and the persist branch atomically writes the encoded sidecar alongside chain_db.persist_ledger_checkpoint. (4) node/src/runtime.rs::ResumeReconnectingVerifiedSyncRequest gains a corresponding ocert_persist_dir: Option<PathBuf> field plus a fluent with_chain_dep_persist_dir(...) setter, threaded through both the standalone-ChainDb and shared-ChainDb resume runners into the LedgerCheckpointTracking constructed inside each. (5) node/src/main.rs::run_node resolves storage_dir once before constructing the verification config, attempts yggdrasil_storage::load_ocert_counters with graceful fallback (decode failure or read failure both log and fall back to OcertCounters::new() rather than crashing the run path), uses the restored counters in both VerificationConfig construction sites, and calls .with_chain_dep_persist_dir(Some(storage_dir.clone())) on the resume request so subsequent checkpoint persistences write the sidecar. Two end-to-end integration tests in crates/consensus/tests/integration.rs (ocert_counters_persist_across_simulated_restart and ocert_counters_load_returns_none_when_no_prior_run) exercise the full encode → atomic save → load → decode → continued-validation pipeline, asserting that a replayed lower sequence number is rejected post-restart but stored + 1 is still accepted. Reference: PraosState.csCounters and currentIssueNo in Ouroboros.Consensus.Protocol.Praos, persisted as part of ChainDepState. 4447 workspace tests pass across all crates, 0 failures.
  • Idempotent volatile→immutable promotion slice — closes a real partial-completion crash window in crates/storage::ChainDb::promote_volatile_prefix. The previous implementation read the volatile prefix, looped self.immutable.append_block(block.clone())? over each block, then ran self.volatile.prune_up_to(point)?. A crash between two appends — or between the last append and prune_up_to — left the immutable store with N blocks and the volatile store still holding all M ≥ N of them. On restart, the next sync attempt would call promote_volatile_prefix against the same point, hit FileImmutable::append_block for an already-present hash, and return StorageError::DuplicateBlock from the very first overlapping block — blocking ALL subsequent sync until manual cleanup of the storage directory. The fix introduces ImmutableStore::contains_block(&HeaderHash) -> bool (trait-default delegates to get_block(...).is_some(); FileImmutable overrides for O(1) HashMap lookup; InMemoryImmutable overrides for O(n) linear scan) and threads it into promote_volatile_prefix: blocks already present in immutable are silently skipped before append_block is called, then the volatile pruning runs as before. The append-then-prune ordering is preserved on purpose so every block stays present in at least one store across the crash window — recovery can always reach the chain tip via immutable + volatile-suffix replay even if the process is killed mid-promotion. Reference: Ouroboros.Consensus.Storage.ChainDB.Impl copyToImmutableDB, which runs as an idempotent operation across restarts. Three new regression tests in crates/storage/tests/integration.rs pin the new contract: promote_volatile_prefix_is_idempotent_after_partial_promotion_crash builds the exact pathological state (immutable already contains the first block of the prefix; volatile still has all three) and asserts the next promote succeeds without DuplicateBlock, completes pruning, and leaves immutable counts at exactly the expected size; promote_volatile_prefix_is_idempotent_when_replayed_back_to_back belt-and-braces a second consecutive call is a no-op (the volatile prefix is empty after the first); immutable_store_contains_block_default_matches_get_block pins the trait-default delegation contract so a future backend that overrides get_block but forgets contains_block still produces consistent answers via the default. 4450 workspace tests pass across all crates, 0 failures.
  • BlockFetch FetchMode unification + governor → pool wiring slice — closes the upstream-parity gap previously logged in the audit (gap #5) where the workspace carried two distinct FetchMode enums for what upstream models as a single canonical type, and the BlockFetchPool’s per-peer concurrency cap stayed pinned at construction time regardless of the live LedgerStateJudgement signal the governor was already computing every tick. crates/network::blockfetch_pool::FetchMode { BulkSync, Deadline } is deleted; the module now pub use crate::governor::FetchMode so there is one definition (variants FetchModeBulkSync / FetchModeDeadline, matching the upstream Haskell FetchModeBulkSync / FetchModeDeadline constructor names from Ouroboros.Network.BlockFetch.ConsensusInterface.FetchMode). The per-peer concurrency-cap helper that was previously a method on the deleted enum is now blockfetch_pool::max_concurrency_per_peer(mode) (free function — the enum is owned by the governor module, but the cap is a BlockFetch-specific policy and stays here). All 21 internal call sites in blockfetch_pool.rs plus the one external test caller in node/tests/runtime.rs are updated to the unified variant names. node/src/runtime.rs::RuntimeGovernorConfig gains an optional block_fetch_pool: Option<BlockFetchInstrumentation> field plus a fluent with_block_fetch_pool(...) setter; run_governor_loop’s tick now calls pool.lock().set_mode(governor_state.fetch_mode) immediately after computing fetch_mode_from_judgement(...), mirroring upstream mkReadFetchMode from Ouroboros.Network.BlockFetch.ConsensusInterface which is the single source of truth for the BlockFetch decision policy’s bfcMaxConcurrency{BulkSync,Deadline} selection. node/src/main.rs::run now constructs a single shared BlockFetchInstrumentation (Arc<Mutex<BlockFetchPool::new(FetchMode::FetchModeBulkSync)>>) once before the verification config, then attaches the same handle to BOTH VerifiedSyncServiceConfig.block_fetch_pool (already-existing field, previously hardcoded to None at two construction sites) AND the new RuntimeGovernorConfig.block_fetch_pool field — so the per-peer dispatch / success / failure counters used by the sync runtime AND the per-peer concurrency cap consumed by the pool’s has_capacity check both observe the same live state. Three new regression tests pin the contract: fetch_mode_is_unified_with_governor_module cross-asserts TypeId::of::<blockfetch_pool::FetchMode>() == TypeId::of::<governor::FetchMode>() so a future regression that re-introduces a duplicate enum fails CI cleanly; max_concurrency_per_peer_matches_upstream pins the bfcMaxConcurrency{BulkSync,Deadline} constants against the unified enum; pool_set_mode_flips_per_peer_capacity_cap exercises the runtime seam by saturating bulk-sync capacity, calling set_mode(FetchModeDeadline), and asserting the deadline cap (which is strictly lower) now rejects the same in-flight count. RuntimeGovernorConfig no longer derives Eq, PartialEq since Arc<Mutex<...>> doesn’t implement them; no current call site relied on those derives. Note: BlockFetchPool::schedule() is still not yet called from the runtime fetch loop — single-peer single-range fetches remain the live path — but the per-peer concurrency cap now correctly tracks ledger judgement, which is a prerequisite for the multi-peer fetch fan-out follow-up. 4453 workspace tests pass across all crates, 0 failures.
  • Live LedgerStateJudgement slice — closes the audit gap where node/src/runtime.rs::ChainDbConsensusLedgerSource::observe() hardcoded judgement: LedgerStateJudgement::YoungEnough regardless of how stale the recovered tip actually was. With the previous slice’s FetchMode unification this meant the BlockFetch pool’s per-peer concurrency cap defaulted to deadline mode (cap = 1) even during initial sync of a tip thousands of slots behind the network, the OPPOSITE of upstream mkLedgerStateJudgement from Cardano.Node.Diffusion.Configuration (which flips to TooOld and therefore BulkSync mode whenever now - tipSlotTime > stabilityWindow * slotLength). New crates/network::judge_ledger_state_age(LedgerStateAgeInputs) is the upstream-aligned pure helper, returning YoungEnough / TooOld / Unavailable from (tip_slot, system_start_unix_secs, slot_length_secs, max_age_secs, now_unix_secs); the comparator is strict > matching upstream so now == tip + max_age stays YoungEnough. Pathological numeric inputs (NaN, ≤ 0 slot length, NaN max_age) and missing wall-clock inputs all return Unavailable so the governor falls back to BulkSync rather than producing arithmetic garbage. New runtime::LedgerJudgementSettings { system_start_unix_secs, slot_length_secs, max_ledger_state_age_secs } carries the genesis-derived inputs through RuntimeGovernorConfig::with_ledger_judgement_settings(...) and into all three refresh_ledger_peer_sources_from_chain_db call sites (initial seed, governor tick, on-demand reconnect refresh). ChainDbConsensusLedgerSource now stores those three values and calls derive_judgement_at(...) (a thin wrapper over judge_ledger_state_age) on every observe(), so the per-tick fetch_mode_from_judgement(ledger_observation.judgement) signal — and therefore the BlockFetchPool’s per-peer concurrency cap wired in the previous slice — finally tracks live wall-clock tip age. node/src/main.rs::run builds the settings from genesis_system_start_unix_secs, genesis_slot_length, and 3 * security_param_k / active_slot_coeff * slotLength (the upstream stabilityWindow * slotLength formula). Backward-compat preserved: when either of the genesis timing inputs is None the wrapper returns YoungEnough (the legacy hardcoded constant), so LedgerJudgementSettings::default() stays a drop-in replacement for tests and the existing pre-slice fixture refresh_ledger_peer_sources_from_chain_db_uses_chain_db_to_resolve_peers keeps asserting YoungEnough. Seven new regression tests pin the contract: judge_ledger_state_age_flips_at_threshold and judge_ledger_state_age_boundary_is_strict_greater_than (network unit, pin the upstream-aligned semantics at the exact now == tip + max_age boundary so a > ↔ >= regression fails CI); judge_ledger_state_age_returns_unavailable_for_missing_inputs (cycles through all three missing-input variants); judge_ledger_state_age_rejects_pathological_numerics (NaN max_age + zero slot length); plus three node-side runtime tests derive_judgement_at_falls_back_to_young_enough_without_genesis, derive_judgement_at_returns_too_old_when_genesis_present_and_tip_stale, and derive_judgement_at_returns_young_enough_when_genesis_present_and_tip_fresh that pin the production-shaped helper across both the legacy fallback path and the live wall-clock path. Reference: mkLedgerStateJudgement from Cardano.Node.Diffusion.Configuration; Ouroboros.Consensus.HardFork.Combinator.Ledger. 4460 workspace tests pass across all crates, 0 failures.
  • Mempool capacity-overflow eviction policy slice — closes the upstream-parity gap where Mempool::insert rejected with CapacityExceeded whenever the mempool was full, even when the incoming transaction had a strictly higher fee than the lowest-fee tail entries. Upstream Ouroboros.Consensus.Mempool.Impl.Update.makeRoomForTransaction evicts the lowest-fee transactions to make room when the incoming candidate is unambiguously a better deal for the network. New Mempool::insert_with_eviction(entry) -> Result<Vec<TxId>, MempoolError> walks the existing fee-descending entry list from the tail, tentatively collecting candidates whose fee is strictly less than the incoming entry’s fee until either enough bytes have been freed or no more candidates remain. The eviction commits only when (a) freeable bytes ≥ needed bytes AND (b) the cumulative evicted fee is strictly less than the incoming fee — otherwise it returns the new typed MempoolError::EvictionNotWorthwhile { incoming_fee, evicted_fee } so the network is never displaced into a worse cumulative-fee state. When the incoming transaction exceeds the mempool’s total capacity (no eviction can ever fit it) the helper returns the new typed MempoolError::EvictionInsufficientSpace { incoming, limit, freeable } so the caller can distinguish “bad input” from “transient overflow”. Duplicate-tx and conflicting-input checks fire BEFORE eviction is considered (same as insert), so a replay attack can never displace unrelated low-fee entries. The function returns the list of evicted TxIds on success so the caller can prune downstream peer-relay state (e.g. SharedTxState known-set entries). SharedMempool::insert_with_eviction proxies the inner method behind the existing shared lock and notifies snapshot waiters via change_notify.notify_waiters() exactly as insert does. The pre-existing rollback re-admission path in node/src/runtime.rs::rollback_re_admit_to_mempool keeps using the strict insert_checked (capacity-exceeded → bookkeeping increment, no eviction) since rolled-back transactions are themselves typically low-fee — but its match arm is widened to handle the new error variants exhaustively so a future call-graph change that routes re-admissions through the eviction-aware path is a typed signal rather than a silently-dropped error. 7 new regression tests in crates/consensus/src/mempool/src/queue.rs pin the contract: insert_with_eviction_no_op_when_under_capacity (fast path), insert_with_eviction_evicts_lowest_fee_when_higher_fee_arrives (happy path with returned evicted-id list), insert_with_eviction_rejects_when_evicted_fee_meets_incoming_fee (the strict-less-than guard against fee-grinding attacks), insert_with_eviction_rejects_when_incoming_exceeds_total_capacity (the wider-than-capacity guard), insert_with_eviction_does_not_displace_higher_or_equal_fee_entries (head-protection), insert_with_eviction_rejects_duplicate_before_considering_eviction (replay-attack guard), and shared_mempool_insert_with_eviction_displaces_lowest_fee_entry (SharedMempool wrapper end-to-end). Reference: Ouroboros.Consensus.Mempool.Impl.Update.makeRoomForTransaction. 4467 workspace tests pass across all crates, 0 failures.
  • Eviction-aware inbound submission slice — closes the dead-API loop on the previous mempool eviction slice by routing both NtN TxSubmission inbound (SharedTxSubmissionConsumer::consume_txs in node/src/server.rs) and NtC LocalTxSubmission inbound (local_server.rs) through the upstream-aligned eviction-on-overflow path. Without this, the prior insert_with_eviction API was opt-in code that no production caller used, leaving inbound submissions to be rejected with CapacityExceeded under congestion. New Mempool::insert_checked_with_eviction(entry, current_slot, protocol_params) composes the existing TTL + fee/size/ExUnits precheck (extracted from insert_checked into a private precheck_ttl_and_params helper) with insert_with_eviction. SharedMempool::insert_checked_with_eviction proxies behind the existing lock with change_notify.notify_waiters(). New runtime helpers add_tx_to_shared_mempool_with_eviction and add_txs_to_shared_mempool_with_eviction in node/src/runtime.rs return a new MempoolAddTxOutcome { result: MempoolAddTxResult, evicted: Vec<TxId> } so inbound paths can attribute the displaced TxIds (operator metrics counters, future trace events). local_server.rs::run swaps add_tx_to_shared_mempool for the eviction-aware variant on the LocalTxSubmission server-side admission, and server.rs::SharedTxSubmissionConsumer::consume_txs swaps add_txs_to_shared_mempool for the eviction-aware batch variant. Both call sites count each evicted TxId as a mempool_tx_rejected metric increment alongside the mempool_tx_added increment for the admitted tx, so operator dashboards see displacement rates without a new metric. The pre-existing rollback re-admission path keeps using strict insert_checked because rolled-back transactions are themselves typically low-fee and shouldn’t displace newer high-fee entries. 3 new integration tests in node/tests/runtime.rs exercise the live inbound path: runtime_add_tx_to_shared_mempool_with_eviction_no_op_when_under_capacity (fast path returns empty evicted), runtime_add_tx_to_shared_mempool_with_eviction_displaces_lowest_fee_entry (pre-loads a synthetic low-fee 100-byte entry into a 100-byte-capacity mempool, submits a real Shelley tx with fee 150_000, asserts the synthetic entry is displaced and its TxId is returned in outcome.evicted), and runtime_add_txs_to_shared_mempool_with_eviction_records_per_tx_evictions (batch variant records evictions independently per tx). Reference: Ouroboros.Consensus.Mempool.Impl.Update.makeRoomForTransaction. 4470 workspace tests pass across all crates, 0 failures.
  • OpCert counter rollback-reset slice — closes a real chain-fork correctness gap left after the slice-3 OpCert persistence work. The persisted-counter approach was upstream-aligned for restart safety but did NOT roll back when the chain rolled back: the per-pool monotonicity high-water mark kept growing across RollBackward events, so an alt chain that legitimately included lower-sequence OpCerts from the same pool (because the fork happened before the pool advanced its KES schedule on the abandoned chain) was rejected as OcertCounterTooOld. Upstream Cardano.Protocol.TPraos.API tickChainDepState rolls back PraosState.csCounters to a ChainDepState snapshot at the rollback restore point. Yggdrasil now mirrors that semantically (without yet adding multi-versioned counter snapshots): crates/consensus::OcertCounters::clear() empties the counter map, and node/src/sync.rs::update_ledger_checkpoint_after_progress calls it on every progress.rollback_count > 0 branch, alongside the existing reset of stake_snapshots and pool_block_counts. After the reset, the existing “first-seen pool is permissive” rule in validate_and_update accepts each pool’s next OpCert as the new initial value, restoring the monotonicity guard from that point forward — equivalent to the bufferedTxs-style “permissive at the boundary, strict everywhere else” pattern. The persisted sidecar is overwritten with the post-reset map at the next checkpoint persistence, so a later restart sees the post-rollback baseline rather than the stale pre-rollback high-water marks. To plumb the reset, apply_verified_progress_to_chaindb and update_ledger_checkpoint_after_progress switched their ocert_counters parameter from Option<&OcertCounters> to Option<&mut OcertCounters>; all 3 call sites (sync.rs + 2 in runtime.rs) updated to pass .as_mut() instead of .as_ref(). The persist branch reads the (possibly post-reset) map via as_deref() for sidecar encoding. Note: this is a SEMANTIC reset rather than a byte-perfect upstream snapshot restore — the trade-off is one block of permissive admission per pool per rollback, in exchange for no architectural churn around multi-versioned counter snapshots. Two new regression tests pin the contract: ocert_counters_clear_resets_to_empty_and_accepts_next_block_as_first_seen (consensus unit) advances a pool to seq 5, replays seq 2 (rejected as TooOld), calls clear(), and asserts the same seq 2 is now accepted as first-seen; update_ledger_checkpoint_after_progress_clears_ocert_counters_on_rollback (node sync.rs) builds a minimal in-memory ChainDb, pre-loads counters with pool→5, runs the helper with rollback_count=1, and asserts the counter map is empty post-call. Reference: Cardano.Protocol.TPraos.API tickChainDepState; PraosState.csCounters snapshot/restore semantics in Ouroboros.Consensus.Protocol.Praos. 4472 workspace tests pass across all crates, 0 failures.
  • NodePeerSharing::to_wire() strict inverse of from_wire() — the receive side (from_wire) is deliberately lenient (value >= 1 → Enabled) to tolerate undefined wire values from older peers. Until this slice there was no matching to_wire() — callers transmitting a NodePeerSharing had to inline match self { ... } in each spot. Added pub fn to_wire(self) -> u8 returning the canonical 0 / 1 mapping. Rustdoc calls out the asymmetric contract: transmit is strict (always 0 or 1, never a round-tripped bogus value), receive is lenient — mirrors Postel’s Law and matches upstream NodeToNodeVersionData codec behavior. Two new tests: node_peer_sharing_to_wire_is_strict_inverse_of_from_wire (canonical pair pin + round-trip over both values), node_peer_sharing_from_wire_then_to_wire_normalises_bogus_inputs (pins that from_wire(42).to_wire() == 1 — lenient accept + strict transmit means bogus incoming values are NOT amplified through the node, a subtle but important defensive property). Together with slice 61’s preflight warning, the NtN peer-sharing wire surface now has strict-producer + lenient-consumer coverage end-to-end. 4438 workspace tests pass across all crates, 0 failures.
  • NtC handshake version table drift guards — the NTC_SUPPORTED_VERSIONS const array (8 entries from V16 down to V9) hand-encodes HandshakeVersion::NTC_V9 .. NTC_V16 in descending order. The individual constants (pub const NTC_V9: Self = Self(9) etc.) and the array order are independent hand-written statements — drift between them would silently misnegotiate handshakes (e.g. NTC_V14: Self(15) typo would make clients that speak V14 land on V15 semantics, or an accidentally-reordered array would pick the wrong “best common version” at handshake time). Added two drift guards: ntc_supported_versions_covers_v9_through_v16_descending — pins length = 8, exhaustive coverage of all 8 constants in descending order, AND an adjacent-pair strictly-descending assertion (so a future non-adjacent reorder that happens to leave the overall range the same would still fail); ntc_handshake_version_constants_are_sequential — pins each NTC_Vn.0 == n so a typo in ONE constant surfaces as a failing test naming the offending constant. Both guards are defense-in-depth against a subtle class of bug that produces quiet handshake-succeeds-but-downstream-protocol-misbehaves failures. 4440 workspace tests pass across all crates, 0 failures.
  • NtN handshake version-constant parity + sequentiality guard — closes the asymmetry exposed by the preceding NtC drift-guard slice. NtC had 8 named constants (V9-V16) but only NtN V14 + V15 had names; V13 (Conway / PeerSharing) was used throughout the codebase as HandshakeVersion(13) literals — scattered across tests and documentation — while no named constant existed. Added pub const V13: Self = Self(13); and the matching ntn_handshake_version_constants_are_sequential drift-guard test that pins V13.0 == 13, V14.0 == 14, V15.0 == 15. Mirrors the preceding NtC constant-sequentiality test so a typo in a single NtN constant surfaces the same way. The literal-HandshakeVersion(13) sites in tests and protocol_versions config defaults remain as-is (zero-churn refactor) — the new constant simply gives future callers a named alternative. 4441 workspace tests pass across all crates, 0 failures.
  • NodeToNodeVersionData codec asymmetry guard — the encoder (encode_version_data) always writes the v13+ 4-element shape; the decoder (decode_version_data) accepts 2/3/4 element shapes with defaults for missing fields (liberal-receive / strict-transmit — mirrors the earlier NodePeerSharing::to_wire Postel pattern at a higher level). This is deliberate: we only ever advertise v13+ in supported-version lists, so the outbound shape is fixed, but inbound handshakes from older peers might emit legacy 2/3-element data. Never had a test pinning either half. Added version_data_codec_encodes_4_elements_decodes_2_to_4 which: (a) asserts encoder output is a 4-element array, (b) round-trips a 4-element value preserving all fields, (c) decodes a legacy 2-element fixture and asserts peer_sharing = 0 / query = false defaults, (d) decodes a legacy 3-element fixture and asserts query = false default, (e) rejects 1-element and 5-element arrays via CborInvalidLength. A future refactor that (wrongly) makes the encoder emit 3 elements for a “lean” shape silently breaks handshake interop with newer peers — this test catches it at CI time. 4442 workspace tests pass across all crates, 0 failures.
  • DefaultFun::all() helper + builtin-set drift guards (Round 104, Plutus CEK) — closes the 🔴 High residual risk flagged in docs/archive/PARITY_PLAN.md (line 1021, “Plutus execution divergence”). The CEK builtin enum carries 88 hand-coded variants (AddInteger = 0 … ExpModInteger = 87) with three independent hand-written statements that must stay in lockstep: the discriminant assignments, the from_tag decode cascade (88 match arms), and — until this slice — no exhaustive iteration helper at all. Drift between any pair of these is the worst-case Plutus bug: handshake-level decoding succeeds but the script silently executes the wrong builtin (e.g. 60 => Ok(Self::Bls12_381_G1_Compress) accidentally typed as 60 => Ok(Self::Bls12_381_G1_Uncompress)). Mirrors slices 82/83 (NetworkPreset::all / Era::all) for the on-chain Plutus surface. Added pub const fn DefaultFun::all() -> &'static [Self] returning the canonical tag-ascending slice (88 entries) with rustdoc anchoring it to upstream PlutusCore.Default.Builtins.DefaultFun ordering. Three new drift-guard tests: default_fun_all_covers_every_tag_in_canonical_order (pins length = 88 AND all()[i] as u8 == i for every entry — catches both reorder and missing-extension regressions), default_fun_from_tag_round_trips_for_every_variant (iterates all() and asserts from_tag(v as u8) == Ok(v) for all 88 — strictly stronger than the pre-existing 2-endpoint round-trip test), default_fun_from_tag_rejects_tags_outside_canonical_range (pins that all().len() as u8 = 88, then asserts tags 88/100/200/255 all fail with FlatDecodeError naming the offending tag — and because the boundary derives from all().len(), a future variant addition that updates all() but forgets from_tag is auto-caught). Three independent guards composing the strongest defensible coverage of the Plutus on-chain decode surface. 4445 workspace tests pass across all crates, 0 failures.
  • Conway tx body full-governance-payload round-trip golden test (Round 105, CBOR bytes-parity) — closes the coverage gap left by cbor_golden_conway_submitted_tx_round_trip in crates/ledger/tests/integration/golden.rs, which sets every Conway-specific field (voting_procedures, proposal_procedures, current_treasury_value, treasury_donation — CDDL keys 19/20/21/22) to None and therefore only exercises the Babbage-shape inheritance path. Because the four governance keys are independently optional, a regression in any single key’s encode_cbor/decode_cbor pair would slip past the all-None test silently — the exact “🟡 Medium: CBOR bytes mismatch — Roundtrip golden tests, Ongoing” risk flagged in docs/archive/PARITY_PLAN.md. New test cbor_golden_conway_submitted_tx_round_trip_with_full_governance_payload populates ALL four keys with non-trivial values: a VotingProcedures map containing a DRepKeyHash voter casting Yes on a GovActionId with a non-null Anchor, a TreasuryWithdrawals proposal with a guardrails script hash and a real BTreeMap<RewardAccount, u64> withdrawal entry (exercises the canonical-ordering encode path that production proposals use), current_treasury_value = 10_000_000_000, treasury_donation = 500_000. The test (a) field-equality-asserts the decoded body for diagnostic clarity, (b) pins each governance field is preserved across the round-trip, (c) byte-identity-asserts the re-encode (the strongest CBOR-parity property short of an upstream-derived golden vector — a regression in any encode path that produces functionally-equivalent-but-byte-different output fails CI), (d) cross-checks the MultiEraSubmittedTx dispatch path also decodes cleanly. Future improvement path: replace the round-trip pin with a pinned-byte fixture once an upstream-emitted Conway governance tx with the same shape is captured. 4446 workspace tests pass across all crates, 0 failures.
  • Preset protocol_versions cross-preset drift guard (Round 106, NtN handshake) — composes slice 82’s NetworkPreset::all() iteration helper with slice 88’s HandshakeVersion::V13/V14/V15 named constants to close a real cross-preset drift exposure: mainnet_config(), preprod_config(), and preview_config() in node/src/config.rs each independently hand-code protocol_versions: vec![13, 14]. Drift between them (e.g. someone bumps mainnet to [13, 14, 15] but forgets preprod/preview) would mean a freshly bootstrapped mainnet relay proposes a different NtN version range than a preprod relay built from the same binary — silently producing handshake mismatches that look like peer-misbehaviour at the operator level. Two new tests pin the contract: preset_configs_share_canonical_protocol_versions (iterates NetworkPreset::all() and asserts every preset’s protocol_versions is identical to mainnet’s, naming the offending preset on failure — drift in any single constructor fails CI clean) and preset_configs_protocol_versions_match_named_handshake_constants (cross-asserts the canonical [13, 14] against [HandshakeVersion::V13.0, HandshakeVersion::V14.0], plus a literal [13, 14] triple-pin so a typo like vec![13, 41] (transposed digits) — which would otherwise pass the cross-preset check since all three could share the typo — fails because tag 41 is not a named NtN version). The two-way pin between named-constant and literal value also gives future contributors a single coordinated edit path when the proposed range bumps (e.g. adding V15 once Conway+1 is live): update the preset constructors, update the expected array here, named constants already exist. 4448 workspace tests pass across all crates, 0 failures.
  • Full-corpus VRF vendored-fixture drift guard (Round 107, upstream-derived golden vectors; R239 fixture tree refresh) — first slice in the “real upstream-derived golden vectors” cadence: replaces single-pair sampling with exhaustive corpus iteration. The Praos VRF test vectors live in two places: 14 vendored fixture files at the current SHA-anchored specs/upstream-test-vectors/cardano-base/7a8a991945d401d89e27f53b3d3bb464a354ad4c/cardano-crypto-praos/test_vectors/ path (7 ver03 + 7 ver13) AND a hand-transcribed Rust copy in crates/crypto/src/test_vectors.rs::vrf_praos_test_vectors() / vrf_praos_batchcompat_test_vectors(). The pre-existing embedded_vrf_vectors_match_vendored_standard_examples only cross-checks standard_10 for both cipher suites — leaving 12 of 14 fixtures uncovered. A future upstream commit-bump that refreshes any of those 12 (e.g. updates vrf_ver03_generated_2.beta because of an underlying libsodium fix) without also updating the hand-transcribed Rust copy would silently produce divergent test-corpus behavior. Two new tests close this gap: embedded_ver03_vrf_vectors_match_full_vendored_corpus iterates all 7 hand-transcribed ver03 vectors, locates each one’s vendored fixture file (hyphen→underscore name normalization), parses the key:value format, and asserts byte-equality on sk, pk (cross-checked against BOTH halves of the embedded secret_key = sk‖pk libsodium-shape concatenation, so a refactor that re-orders the halves silently fails), pi (proof), beta (output), and alpha (message; handles the literal empty sentinel as Vec::new()); plus exhaustive bidirectional name-set equality between the embedded Vec<VrfPraosTestVector> and the on-disk vrf_ver03_* filenames so an orphan in either direction (fixture added upstream but not transcribed, OR transcribed but renamed/removed upstream) fails CI naming the offending entry. embedded_ver13_vrf_vectors_match_full_vendored_corpus mirrors the structure for the 128-byte-proof batch-compatible ver13 cipher suite. Together this gives FULL-CORPUS upstream-fixture parity with the embedded copies — a future upstream refresh now cannot drift undetected. Reference: cardano-base/cardano-crypto-praos/test_vectors/vrf_ver03_* and vrf_ver13_* at commit 7a8a991945d401d89e27f53b3d3bb464a354ad4c. 4450 workspace tests pass across all crates, 0 failures.
  • BLS12-381 hardcoded test-parameter drift guard (Round 108, upstream-derived golden vectors) — companion to Round 107 for the BLS surface. Unlike the VRF Praos fixtures (which carry their inputs inline as sk/pk/alpha), the BLS12-381 fixture files (ec_operations_test_vectors, bls_sig_aug_test_vectors) only vendor the OUTPUTS — the inputs (a 32-byte scalar; a DST/aug/msg triple) come from upstream test setup and were hardcoded mid-test in crates/crypto/tests/upstream_vectors.rs. If upstream refreshed any input parameter alongside its corresponding fixture line in a future commit-bump, the existing operational tests caught the drift only as opaque “G1 scalar mul mismatch” / “BLS sig aug pairing check failed” failures — several stack frames removed from the actual delta. Extracted four upstream-derived parameters into module-level named constants — BLS_EC_OPERATIONS_SCALAR_HEX (cited to cardano-base/cardano-crypto-class/bls12-381-test-vectors/ at the pinned commit), BLS_SIG_AUG_DST (cited to IETF BLS signature suite ID draft-irtf-cfrg-bls-signature-05 §4.2.3), BLS_SIG_AUG_AUG, BLS_SIG_AUG_MSG — refactored both operational tests to use them, and added bls_hardcoded_test_parameters_match_upstream_pins which asserts each constant byte-for-byte against the literal (with a load-bearing-trailing-space callout for BLS_SIG_AUG_AUG). A future drift now surfaces as a clearly-named failure citing the offending constant rather than an opaque downstream pairing failure. Mirrors slices 76/78/80/84 (“named constant + drift guard”) for the BLS surface. 4451 workspace tests pass across all crates, 0 failures.
  • MiniProtocolNum::all_named() helper + mux wire-ID drift guards (Round 109, mux/multiplexer) — closes the worst-case mux bug class: silent misrouting where SDU framing succeeds but frames are delivered to the wrong mini-protocol handler. The MiniProtocolNum impl carries 9 named pub const wire IDs (HANDSHAKE=0, CHAIN_SYNC=2, BLOCK_FETCH=3, TX_SUBMISSION=4, NTC_LOCAL_TX_SUBMISSION=5, NTC_LOCAL_STATE_QUERY=7, KEEP_ALIVE=8, NTC_LOCAL_TX_MONITOR=9, PEER_SHARING=10) plus two per-side hand-coded arrays (N2N_PROTOCOLS 6 entries in peer.rs, NTC_PROTOCOLS 4 entries in ntc_peer.rs) — three independent sites that must stay in lockstep with upstream Network.Mux.Types.MiniProtocolNum / nodeToNodeProtocols / nodeToClientProtocols. Pre-existing coverage was a single assert!(N2N_PROTOCOLS.contains(...)) test naming PEER_SHARING; everything else was unguarded. Mirrors slices 82/83/104 (NetworkPreset::all / Era::all / DefaultFun::all) for the mux surface. Added pub const fn MiniProtocolNum::all_named() -> &'static [Self] returning the canonical strictly-ascending slice (9 entries) with rustdoc anchoring it to upstream Network.Mux.Types.MiniProtocolNum. Four new drift-guard tests across three files: mini_protocol_num_constants_match_upstream_wire_ids (in multiplexer.rs — pins each of the 9 pub const X.0 against its literal upstream wire ID with per-protocol diagnostic message; a CHAIN_SYNC: Self = Self(3) typo would otherwise cause silent BlockFetch↔ChainSync framing crossover); mini_protocol_num_all_named_is_strictly_ascending_and_complete (pins length=9, strictly-ascending invariant, plus exhaustive expected-equality so a missing-extension regression fails CI); n2n_protocols_match_canonical_six (in peer.rs — pins N2N_PROTOCOLS exact content against the canonical 6-element NtN subset, catching both extra entries from accidental NtC mix-in AND missing entries from forgotten extensions); ntc_protocols_match_canonical_four (in ntc_peer.rs — same for the 4-element NtC subset). The two side-specific exact-content pins also indirectly enforce the disjointness invariant (HANDSHAKE is the only shared protocol) — by pinning each subset’s exact content rather than just contains checks, any cross-side mix-in fails one or both tests with a clear “drifted from canonical set” diagnostic. 4455 workspace tests pass across all crates, 0 failures.
  • DCert encoder tag+arity drift guard (Round 110, ledger CBOR wire-tag space) — closes a subtle gap in the existing dcert_shelley_tags_round_trip / dcert_conway_tags_round_trip tests: a coupled encoder/decoder typo (e.g. encoder accidentally emits enc.unsigned(1) for AccountRegistration AND the decoder grows a matching 1 => AccountRegistration arm in the same commit) would still round-trip cleanly while silently breaking on-chain wire compat with upstream — the worst-case ledger bug class because chain-fork-day misinterpretation of a certificate is unrecoverable. DCert carries 19 variants across three independent hand-coded sites: rustdoc-described tags (lines 893-940 of types.rs), the encode_cbor cascade (lines 1542-1656 of cbor.rs), and the decode_cbor cascade (line 1658+). The new dcert_encoder_tag_and_arity_match_canonical_cddl test constructs a representative value for every variant in the 0..=18 tag space, encodes via to_cbor_bytes, then INDEPENDENTLY decodes only the array-header + first-unsigned (NOT via the cascade) and asserts both the array length AND the tag against the literal CDDL-specified values. Bidirectional completeness: pins cases.len() == 19 (so a future tag-19 upstream variant added without extending this table fails the assertion), and after iterating asserts the sorted observed-tag set is exactly 0..=18 (catches duplicate tags from a copy-paste regression where two variants accidentally encode with the same wire ID, AND missing tags from a forgotten case). Reference: Cardano.Ledger.Conway.TxCert.ConwayTxCert constructor tags; CDDL certificate rule in cardano-ledger-conway/cddl-files/conway.cddl. Mirrors the slice-110 pattern of “three-site lockstep enum + drift-guard” applied to the most consequential ledger wire surface. 4456 workspace tests pass across all crates, 0 failures.
  • Conway governance encoder drift guards: GovAction (Round 111), Voter+Vote+DRep (Round 112) — extends the Round 110 DCert-encoder pattern across the rest of the Conway governance wire surface. Round 111 GovAction: 7 variants (tags 0..=6) with mixed array lengths 4/3/3/2/5/3/1 from the upstream CDDL gov_action rule. Same coupled-encoder/decoder-typo failure mode as DCert but with treasury-redirection blast radius (TreasuryWithdrawals=tag 2 misencoded as ParameterChange=tag 0 silently swaps a treasury draw for a parameter update). New gov_action_encoder_tag_and_arity_match_canonical_cddl constructs every variant, encodes, independently decodes the array header + first unsigned, asserts canonical length AND tag, plus exhaustive-tag-set bidirectional pin (cases.len() == 7 and sorted observed tags == 0..=6). Round 112 adds three companion drift guards in one slice: vote_encoder_unsigned_value_matches_canonical_cddl (Vote is encoded as a bare unsigned NOT array-wrapped — a typo flipping Vote::No = 0 to encode as 1 would silently flip every No vote to Yes); voter_encoder_tag_and_arity_match_canonical_cddl (5 voter classes 0..=4 all length-2 with hash; a swap between DRepKeyHash=2 and StakePool=4 would route every DRep vote into the SPO tally bucket); drep_encoder_tag_and_arity_match_canonical_cddl (4 variants with mixed length 2/2/1/1 — distinct because AlwaysAbstain/AlwaysNoConfidence are bare-tag arrays; a length-confusion drift would silently strip a real voter’s voice). Together with Round 110, the entire on-chain Conway governance wire-tag surface now has independent encoder pins for tag value AND CDDL-arity. References: Cardano.Ledger.Conway.Governance.Procedures.{Vote,Voter,GovAction} and Cardano.Ledger.Conway.Governance.DRep. 4460 workspace tests pass across all crates, 0 failures.
  • NativeScript encoder tag+arity drift guard (Round 113, ledger CBOR wire-tag space) — extends the Round 110-112 encoder-pin pattern to the timelock/multisig surface. NativeScript carries 6 variants (tags 0..=5) with mixed array lengths (2/2/2/3/2/2). Used by every native-asset minting policy and Shelley-era multi-signature lock. A coupled encoder/decoder typo would silently misinterpret every native script — e.g. tag-1 ScriptAll (require-all) mistakenly decoded as tag-2 ScriptAny (require-any) would turn a 2-of-2 multisig into a 1-of-2, silently weakening every multisig lock on chain. New native_script_encoder_tag_and_arity_match_canonical_cddl constructs a representative for each variant, encodes via to_cbor_bytes, independently decodes the array header + first unsigned, and asserts canonical length AND tag with bidirectional completeness pin (cases.len() == 6 and sorted observed tags == 0..=5). Reference: Cardano.Ledger.Allegra.Scripts.Timelock; CDDL native_script rule. 4461 workspace tests pass across all crates, 0 failures.
  • Script + StakeCredential encoder tag drift guards (Round 114, ledger CBOR wire-tag space) — closes two more wire-tag surfaces. Script: 4 variants (tags 0..=3, all length 2) covering Native/PlutusV1/PlutusV2/PlutusV3. A typo swapping PlutusV2=2 and PlutusV3=3 would silently route every V2 script into the V3 evaluator — the worst-case Plutus bug, applying the wrong cost model and wrong builtin set to real on-chain transactions. StakeCredential: 2 variants (tags 0..=1, both length 2) covering AddrKeyHash and ScriptHash. A typo swapping the two would silently turn every key-hash credential into a script-hash credential, breaking every reward delegation, witness check, and script witness obligation. New script_encoder_tag_and_arity_match_canonical_cddl and stake_credential_encoder_tag_and_arity_match_canonical_cddl pin per-variant tag and array arity with bidirectional completeness assertions. References: Cardano.Ledger.Core.Script, Cardano.Ledger.Credential.Credential. 4463 workspace tests pass across all crates, 0 failures.
  • DatumOption encoder tag drift guard (Round 115, ledger CBOR wire-tag space) — Babbage post-Alonzo txout datum_option field. 2 variants (tags 0..=1, both length 2): Hash (32-byte digest pointer) vs Inline (CBOR-tag-24 wrapped PlutusData). A typo swapping the two would silently misinterpret every post-Alonzo output’s datum, breaking script execution at the txout-spending phase. New datum_option_encoder_tag_and_arity_match_canonical_cddl pins per-variant tag and arity with bidirectional completeness assertion. Reference: Cardano.Ledger.Babbage.TxBody.Datum; CDDL datum_option rule. 4464 workspace tests pass across all crates, 0 failures.
  • Relay + MirPot encoder drift guards (Round 116, ledger CBOR wire-tag space) — closes two more wire-tag surfaces. Relay: 3 variants (tags 0..=2, mixed lengths 4/3/2) covering SingleHostAddr / SingleHostName / MultiHostName. A typo swapping tag-0 and tag-1 would silently misinterpret every pool’s announced relay endpoints, breaking peer discovery for the affected operators. MirPot: 2 values (Reserves=0, Treasury=1) embedded inside the DCert tag-6 MIR cascade. A typo swapping the two would silently flip every MIR certificate’s source pot — turning reserves-funded rewards into treasury-funded ones, silently misallocating epoch-boundary fund movement (Shelley-Babbage). Because MirPot is inline-encoded inside DCert tag-6, the new mir_pot_encoder_value_matches_canonical_cddl exercises the embedded encoding by constructing a full DCert::MoveInstantaneousReward, encoding it, and inspecting the inner array’s pot byte — pinning the outer DCert wrapper structure (tag 6, length 2) AND the inner MIR pair (length 2) AND the embedded pot value in one composite assertion. References: Cardano.Ledger.Shelley.TxBody.StakePoolRelay, Cardano.Ledger.Shelley.TxCert.MIRPot. 4466 workspace tests pass across all crates, 0 failures.
  • HandshakeMessage + RefuseReason inner tag drift guards (Round 117, NtN handshake CBOR wire-tag space) — closes a gap in the network-handshake test surface where pre-existing tests covered RefuseReason Display, version-table codec, and per-version constants but NEVER pinned the outer message tag/arity OR the inner refuse-reason sub-tag/arity. Two new tests: HandshakeMessage (4 variants 0..=3, mixed lengths 2/3/2/2 per handshake-node-to-node-v14.cddl outer envelope; worst-case bug is tag-1 AcceptVersion decoded as tag-2 Refuse, silently closing every connection that should have succeeded). RefuseReason (3 inner sub-tags 0..=2, lengths 2/3/3; worst-case bug swaps HandshakeDecodeError and Refused, misclassifying connection-failure causes in operator dashboards). Because RefuseReason has no standalone encode method (it’s only encoded inline inside HandshakeMessage::Refuse), the inner-tag test wraps each variant in HandshakeMessage::Refuse and inspects both the outer [2, ...] envelope AND the inner refuseReason array — three composite assertions per variant. Reference: handshake-node-to-node-v14.cddl; Ouroboros.Network.Protocol.Handshake.Codec. 4468 workspace tests pass across all crates, 0 failures.
  • PlutusData CBOR tag-constant drift guard (Round 118, ledger Plutus codec) — pins the four upstream-defined CBOR tags used by the plutus_data CDDL rule against literal upstream values: CONSTR_TAG_BASE = 121 (compact-constructor base, alts 0..=6 → tags 121..=127), CONSTR_TAG_GENERAL = 102 (general constructor form for alt > 6), BIG_UINT_TAG = 2 (IETF CBOR big_uint), BIG_NINT_TAG = 3 (IETF CBOR big_nint). These four constants are independently referenced in the encoder cascade AND in the decoder-arm pattern matches (e.g. 121..=127 => alt = tag - CONSTR_TAG_BASE, 102 => general, 2 => bignum). Existing round-trip tests catch encoder/decoder asymmetry but NOT a coupled refactor where the constant AND decode-arm range are bumped in lockstep — e.g. CONSTR_TAG_BASE to 122 with the decode arm changed to 122..=128 would round-trip cleanly while breaking wire compat with every other Cardano implementation. New plutus_data_cbor_tag_constants_match_canonical_cddl adds explicit literal pins for all four constants AND a derived assertion that the compact-constructor range size is exactly 7 (covering alts 0..=6). Reference: Cardano.Ledger.Plutus.Data.Data; CDDL plutus_data rule; IETF CBOR registry tags 2/3 for big_uint/big_nint. 4469 workspace tests pass across all crates, 0 failures.
  • max_concurrent_block_fetch_peers config knob (Round 119, Phase 3 item 5 step 4) — first non-drift-guard slice in this cadence: real groundwork for the multi-peer concurrent BlockFetch follow-up explicitly deferred in crates/network/src/blockfetch_pool.rs:24 and docs/archive/PARITY_PLAN.md Phase 3 item 5. Adds NodeConfigFile::max_concurrent_block_fetch_peers: u8 (default 1 — keeps the proven single-peer pipeline byte-for-byte) with full rustdoc citing upstream Ouroboros.Network.BlockFetch.Decision (bfcMaxConcurrencyDeadline = 1, bfcMaxConcurrencyBulkSync = 2). Wired through all three preset constructors (mainnet/preprod/preview) so the in-process default and serde-default agree. Two drift-guard tests: preset_configs_share_canonical_max_concurrent_block_fetch_peers (iterates NetworkPreset::all() from slice 82, asserts every preset defaults to 1, naming the offending preset on failure); default_max_concurrent_block_fetch_peers_matches_preset_value (cross-asserts serde-default == in-process default for every preset, so a drift between the parsed-from-disk path and the in-process default-construction path can’t silently produce different runtime behaviour for the same nominal preset). The runtime wiring that actually reads this knob and dispatches across N peers is the next slice (step 5 of the Phase 3 item 5 stepwise plan); a non-default here today is a declaration of intent only, not an immediate behaviour change. 4472 workspace tests pass across all crates, 0 failures.
  • Slice A: Plomin V3 cost-model drift watch (Round 121, audit/bring-up plan) — node/src/genesis.rs::SUPPORTED_CONWAY_V3_ARRAY_LENGTHS = &[251, 302] (function-local const) caps Conway plutusV3CostModel at the current upstream-known shapes. The matching CONWAY_V3_PARAM_NAMES table holds 302 entries. Existing tests pin the rejection of mid-range arrays (build_plutus_cost_model_rejects_short_conway_v3_array / _rejects_partial_bitwise_tail_array), but no test pinned the table-size invariant: a future contributor extending the supported set to accept a Plomin-shape array (e.g. 320 entries) WITHOUT also extending CONWAY_V3_PARAM_NAMES would slip past CI. ensure_conway_v3_mapping_complete catches it at runtime, but only when a real genesis is parsed. Two new drift-pin tests in genesis::tests: conway_v3_param_names_table_size_pinned_to_max_supported_length (pins len() == 302 with a “extend the table in lockstep” diagnostic naming SUPPORTED_CONWAY_V3_ARRAY_LENGTHS and docs/archive/AUDIT_VERIFICATION_2026Q2.md); supported_conway_v3_array_lengths_fit_within_param_names_table (cross-asserts every value in the canonical-mirrored &[251, 302] is <= CONWAY_V3_PARAM_NAMES.len(), so the table is always sized for every accepted array shape). When upstream actually ships a Plomin V3 array, this test set is the canonical place to bump in lockstep with the supported-set extension. Reference: crates/plutus/AGENTS.md:70. 4474 workspace tests pass across all crates, 0 failures.
  • Slices F+G+H: Upstream commit pinning (Round 122, audit baseline 2026-Q2; R239 refresh) — Yggdrasil is a pure-Rust port with no Cargo git = dependencies (verified: find Cargo.toml -exec grep -l "git =" returns empty), so pinning is documentary plus vendored-fixture provenance. node/src/upstream_pins.rs consolidates 6 pub const UPSTREAM_*_COMMIT: &str constants plus an UPSTREAM_PINS (name, sha) slice for the canonical IntersectMBO repos: cardano-base is pinned at the current vendored test-vector directory SHA 7a8a991945d401d89e27f53b3d3bb464a354ad4c, and the other repositories are pinned to their last audited live HEADs. Three drift-guard tests in upstream_pins::tests: upstream_pins_are_40_lowercase_hex (catches paste errors at CI time), upstream_pins_cover_all_six_canonical_repos (cardinality + ordering pin so a future addition/removal can’t slip past), upstream_cardano_base_pin_matches_vendored_directory_name (cross-check against specs/upstream-test-vectors/cardano-base/<sha>/). Companion node/scripts/check_upstream_drift.sh parses the SHAs from the Rust source via grep, fetches live HEAD via git ls-remote for each repo, and emits either human-readable or JSON drift report with --json / --fail-on-drift flags. Drift is informational by default (exit 0 even on drift); the CI-gating flag exists for future use. docs/UPSTREAM_PARITY.md lists every SHA, its source-of-truth file, and the procedure to advance a pin. R239 refreshed the coordinated cardano-base fixture tree, and the drift detector reports all 6 canonical repos in sync at the slice boundary. 4477 workspace tests pass across all crates, 0 failures.
  • Slice B: CDDL parser range constraints (Round 123, commit 5bb0bf1) — closes tools/cddl-codegen/AGENTS.md:42 “remaining work”. New RangeBound { Exact | AtLeast | AtMost | Between } AST node + TypeExpr::SizeRange / TypeExpr::ValueRange variants in tools/cddl-codegen/src/parser.rs. Recognises .size N..M, .le N, .ge N, .lt N, .gt N, and open ranges (N.., ..M); the existing TypeExpr::Sized(name, n) fast-path is preserved for byte-identical [u8; N] codegen. Generator emits post-decode bound checks returning LedgerError::CborInvalidLength { expected, actual } for non-fast-path constraints. Inequality-prefix detection runs ahead of split_nil_alternative to avoid / collisions. Vendored fixture specs/upstream-cddl-fragments/conway-ranges-min.cddl mirrors representative constructs from eras/conway/impl/cddl-files/conway.cddl at the pinned cardano-ledger SHA 9ae77d611ad86ae58add04b6042ab730272f2327 (header comment records source). +16 tests (parser-accept, parser-reject, Display round-trips, generator golden snapshots).
  • Slice D: HotPeerScheduling per-mini-protocol weight table (Round 124, commit b1ec7cd) — closes crates/network/AGENTS.md:57 step 2. New struct HotPeerScheduling { weights: BTreeMap<MiniProtocolNum, u8> } in crates/network/src/governor.rs mirrors upstream Ouroboros.Network.PeerSelection.Governor.HotPeers. Defaults to upstream-canonical defaultMiniProtocolParameters: ChainSync=3, BlockFetch=10, TxSubmission=2, KeepAlive=1, PeerSharing=1. Accessors: set_hot_protocol_weight(proto, weight), hot_protocol_weight(proto). New evaluate_hot_promotions(registry, targets, pick, scheduling) produces min(target_active, count_above_threshold) upstream-style multi-leader promotions (replacing the prior single-leader semantics in Normal mode); Sensitive mode still uses evaluate_warm_to_hot_promotions for the bootstrap-only single-promotion path. hot_peers_remote(&PeerRegistry) derives a sorted view of currently-hot peer addresses for governor consumers. Hot-to-warm demotion biases toward laggards in hot_peers_remote whose ChainSync arrival lag exceeds policyChurnInterval / 2. +16 tests covering weight defaults, setter idempotence, multi-promotion arithmetic, Sensitive-mode interaction, big-ledger-target interaction, derived-view consistency, and laggard-bias demotion.
  • Slice E foundation: multi-peer BlockFetch primitives (Round 125, commit 55b66d1) — adds effective_block_fetch_concurrency(max_knob, n_peers) + BlockFetchAssignment { peer, lower, upper } + partition_fetch_range_across_peers(lower, upper, peers, max_knob) in node/src/sync.rs, all generic over the block type so unit tests can use synthetic blocks without needing real BlockFetchClient mocking. VerifiedSyncServiceConfig.max_concurrent_block_fetch_peers field sourced from NodeConfigFile; run_reconnecting_verified_sync_service_chaindb_inner calls config.effective_block_fetch_concurrency(1) so the knob is read by a production code path even though the prior runtime keeps one session per call. Closes the “config knob is read by no production path” half of Phase 3 item 5; the multi-session orchestration that consumes this primitive lands in Slices E-Workers / E-Wire / E-Promote below. +10 tests covering knob arithmetic at zero / single / multi-peer boundaries plus partition correctness.
  • Slice GD: genesis density tracking primitive (Round 126, commit 682dfa8) — closes docs/archive/PARITY_PLAN.md:606 “future milestone” entry. New crates/consensus/src/genesis_density.rs::DensityWindow { slot_window, headers_seen, last_slot, window_start } is a sliding-window header-density estimator mirroring upstream Ouroboros.Consensus.Genesis.Governor. DEFAULT_SLOT_WINDOW = 6480 (3 × securityParam, upstream default), DEFAULT_LOW_DENSITY_THRESHOLD = 0.6, deterministic slot-only math (no wallclock — re-derivable from history alone), O(1) amortised slide. API: observe_header(slot), density() -> f64, slide_to(now), is_low_density(threshold). Slot-regression rejected to prevent backward-time mutation. +15 tests covering window slide, empty/full state, slot-regression rejection, density math, threshold, default slot_window, and deterministic re-derivation.
  • Slice DOC: 100% feature-complete closure (Round 127, commit 7623e58) — flips every “deferred” / “future-milestone” row across docs/archive/AUDIT_VERIFICATION_2026Q2.md, docs/archive/PARITY_PLAN.md, docs/PARITY_SUMMARY.md, README.md, and the per-crate AGENTS.md files for tools/cddl-codegen + crates/network. Adds new “Status: Yggdrasil 1.0” section to the audit doc summarising slice closures and recording the 100% closure commit. Per-crate tools/cddl-codegen/AGENTS.md and crates/network/AGENTS.md “remaining work” sections struck. No code touched.
  • Slice GD-RT: ChainSync header density observation hook (Round 128, commit 36bdbef) — first runtime integration after Slice DOC. Adds node/src/sync.rs::DensityRegistry { Arc<RwLock<HashMap<SocketAddr, DensityWindow>>> } plus observe_chain_sync_header_density(registry, peer, slot), read_peer_density(registry, peer), forget_peer_density(registry, peer). VerifiedSyncServiceConfig.density_registry: Option<DensityRegistry> field; sync_batch_verified_with_tentative observes every RollForward header into the registry. Forms the consensus → network seam — windows live in the consensus crate (Slice GD primitive), but the runtime owns the per-peer registry so the network governor can read it without a circular dependency. +9 tests.
  • Slice GD-Governor: density-biased hot demotion (Round 129, commit d3316d1) — crates/network/src/governor.rs::PeerMetrics gains density: BTreeMap<SocketAddr, f64> field plus density_for(peer), is_low_density(peer), set_density(peer, value). LOW_DENSITY_THRESHOLD = 0.6 pinned against the consensus-side DEFAULT_LOW_DENSITY_THRESHOLD constant. HIGH_DENSITY_BONUS = 5 is added to combined_score when peer density exceeds the threshold; below-threshold peers are biased toward demotion via score deduction. remove_peer clears the density entry to prevent stale lookups across reconnects. +10 tests pinning bonus arithmetic, threshold semantics, and clean-out on remove.
  • Slice GD-Final: runtime data flow (Round 130, commit 6b5431b) — closes the GD chain. RuntimeGovernorConfig.density_registry: Option<DensityRegistry> + with_density_registry() builder; run_governor_loop reads density into governor_state.metrics.density before each tick. node/src/main.rs constructs ONE shared DensityRegistry and threads clones into both the verified-sync side (writer) and the governor config (reader), unifying the hand-off so density observed on the sync path immediately influences the next governor tick.
  • Slice D-Scheduler: HotPeerScheduling drives mux egress weights (Round 131, commit 35cca97) — apply_hot_weights(weights, &HotPeerScheduling) reads from the governor’s scheduling table instead of two hardcoded constants. Upstream-canonical share now applied at promote-to-hot: BlockFetch=10, ChainSync=3, TxSubmission=2, KeepAlive=1, PeerSharing=1. Operator overrides via set_hot_protocol_weight land at the next promote-to-hot. Removes the now-stale HOT_WEIGHT_CHAIN_SYNC / HOT_WEIGHT_BLOCK_FETCH constants. +2 tests pinning canonical weights and override path.
  • Slice E-Dispatch: multi-peer plan executor (Round 132, commit a72b6fb) — execute_multi_peer_blockfetch_plan(plan, from_point, fetch_one, pool_instr) in node/src/sync.rs. Parallel dispatch via tokio::JoinSet, error propagation with JoinSet::abort_all on first failure, in-order reassembly via ReorderBuffer<B>. Generic over the block type so tests use synthetic u64 blocks (no BlockFetchClient mocking required). Genesis multi-peer (from_point = Origin) explicitly errors so callers route initial sync to the single-peer path — ReorderBuffer head=Origin never releases on its own. Tentative-header timing is intentionally kept in the caller (the dispatcher is tentative-state-agnostic, so async tasks cannot race on mutation). +6 tests covering empty plan, genesis error, single-peer fast path, in-order release, sibling cancellation on error, and out-of-order arrival reassembly.
  • Slice E-Tentative: tentative-header integration helper (Round 133, commit 24bdfd3) — dispatch_range_with_tentative(header, tip, from_point, peers, knob, tentative_state, pool_instr, fetch_one) ties together partition_fetch_range_across_peers + execute_multi_peer_blockfetch_plan + try_set_tentative_header / clear_tentative_trap in a single layer that locks the consensus-correctness contract: announce before dispatch, clear trap on any chunk failure. Also fixes a ReorderBuffer head-seed edge case so the first chunk releases when its lower slot equals from_point.slot (previously seeded with from_point directly, which never released the head=non-Origin chunk either). +5 tests pinning tentative timing on success/failure paths.
  • Slice E-Phase6-Seam: OutboundPeerManager hot-peer accessors (Round 134, commit 5d44c70) — with_hot_block_fetch_clients (closure-style accessor yielding &mut [(SocketAddr, &mut BlockFetchClient)]) + hot_peer_addrs (cheap snapshot for sizing concurrency). +4 tests pinning empty-when-no-hot, BTreeMap-sorted output, hot-only filtering, and empty-slice fall-back contract. Phase 6 step 1 seam from docs/ARCHITECTURE.md.
  • Slice E-Inline: non-spawning multi-peer dispatcher (Round 135, commit 8bd4cdf) — execute_multi_peer_blockfetch_plan_inline<B, F, Fut> with FnMut closure bound — no tokio::spawn, no 'static + Send + Sync requirement, so the runtime sync loop can consume the with_hot_block_fetch_clients accessor without restructuring BlockFetchClient ownership. Same contract as the parallel dispatcher. +5 tests covering empty / genesis-error / single-peer fast path / short-circuit on error / in-order reassembly. Re-exported alongside execute_multi_peer_blockfetch_plan from node/src/lib.rs (commit 10ee4cd).
  • Slice E-Workers: per-peer fetch worker primitive (Round 136, commit 434af60) — new file node/src/blockfetch_worker.rs. FetchWorkerHandle<B> owns its BlockFetchClient via mpsc + oneshot channels; FetchWorkerPool<B> is a BTreeMap<SocketAddr, FetchWorkerHandle<B>> registry with two-phase parallel dispatch. Mirrors upstream Ouroboros.Network.BlockFetch.ClientRegistry per-peer FetchClientStateVars semantics — operational feel identical to the Haskell node. Resolves the Phase 6 step 3 lifetime constraint (&mut BlockFetchClient cannot cross an await boundary; per-peer task ownership replaces the borrow with channel-mediated ownership). +14 tests covering worker lifecycle (spawn/round-trip/error/shutdown), channel-closed errors, pool register/replace/unregister, BTreeMap-sorted peer iteration, dispatch (empty/genesis-error/multi-peer/error-propagation), and prune_closed GC of dead workers.
  • Slice E-Production-Spawn: BlockFetchClient → FetchWorkerHandle (Round 137, commit cafc31a) — FetchWorkerHandle::spawn_with_block_fetch_client(addr, BlockFetchClient) is the production wire that takes a real BlockFetchClient (moved into the spawned task) and dispatches via crate::sync::fetch_range_blocks_multi_era_raw_decoded. Bridges the worker primitive to the runtime’s PeerSession lifecycle.
  • Slice E-Migration: PeerSession ↔ worker pool wiring (Round 138, commits 0f612aa + 7c06baf) — PeerSession.block_fetch: Option<BlockFetchClient> (was non-Option) plus take_block_fetch(), block_fetch_mut(), has_block_fetch() accessors so the BlockFetchClient can be moved out without dropping the entire session. OutboundPeerManager.fetch_worker_pool: SharedFetchWorkerPool (Arc<tokio::sync::RwLock<FetchWorkerPool<MultiEraBlock>>>). New methods: migrate_session_to_worker(peer) (takes the BlockFetchClient out and spawns a worker), unregister_worker(peer) (clean shutdown), with_fetch_worker_pool(pool) (constructor for shared use). demote_to_cold is now async and unregisters the worker on disconnect, mirroring upstream bracketSyncWithFetchClient exit path. fake_peer_session_async test helper for #[tokio::test] callers (the original fake_peer_session creates its own runtime and cannot be called from inside one). All 18 existing &mut session.block_fetch references updated to as_mut().expect("block_fetch migrated") (lifetime-conservative, single-line refactor). +4 tests covering migration idempotency, unknown-peer no-op, and clean unregister.
  • Slice E-Wire: sync-loop multi-peer dispatch branch (Round 139, commit 9f87447) — MultiPeerDispatchContext<'a> { pool, max_concurrent_knob } struct + new optional parameter on sync_batch_verified_with_tentative (block_fetch becomes Option<&mut BlockFetchClient>). When Some AND effective_block_fetch_concurrency(workers, knob) > 1, the per-RollForward fetch step reads the shared pool under a brief tokio::sync::RwLock::read guard, partitions the range, calls pool.dispatch_plan(...), and clears the tentative trap on error. SharedFetchWorkerPool type alias and new_shared_fetch_worker_pool() constructor exposed as the runtime hand-off type. +1 cross-task visibility test pinning that a worker registered on the producer task is visible on the consumer task.
  • Slice E-Promote: governor migrates BlockFetchClient on promote_to_warm (Round 140, commit 1249f7f) — closes the multi-peer dispatch chain. RuntimeGovernorConfig.max_concurrent_block_fetch_peers: u8 (default 1) + with_max_concurrent_block_fetch_peers builder. RuntimeGovernorConfig.shared_fetch_worker_pool: Option<SharedFetchWorkerPool> + with_shared_fetch_worker_pool builder. run_governor_loop constructs OutboundPeerManager::with_fetch_worker_pool(...) when configured. apply_cm_actions takes the knob and calls migrate_session_to_worker(peer) after successful promote_to_warm when knob > 1, emitting a Net.BlockFetch.Worker info trace. node/src/main.rs wires the shared pool + knob into the governor config alongside the sync-side wiring. Operator can now activate end-to-end multi-peer fetch by setting max_concurrent_block_fetch_peers > 1.
  • Slice E-Runbook: parallel-fetch rehearsal (Round 141, commit 3c6cd6a documented at 3c5bcf3) — extends docs/MANUAL_TEST_RUNBOOK.md with §6.5 (steps 6.5a–6.5f) covering operator wallclock validation of the multi-peer path: enable knob, observe worker registration trace + Prometheus counter, confirm tip-progress matches single-peer baseline within tolerance, exercise per-peer disconnect recovery, restart-resilience cycle, and §9 sign-off block. Audit doc records the closure with a [parallel-blockfetch] sign-off slot.
  • Phase 6 BlockFetch worker observability (Round 142, commit b3a6080) — node/src/tracer.rs::NodeMetrics gains blockfetch_workers_registered: AtomicU64 and blockfetch_workers_migrated_total: AtomicU64 counters with matching set_* / inc_* mutators. MetricsSnapshot extended with both fields; to_prometheus_text emits yggdrasil_blockfetch_workers_registered (gauge) and yggdrasil_blockfetch_workers_migrated_total (counter) with TYPE/HELP metadata. Wired into apply_cm_actions (increment-on-migrate) and run_governor_loop (set-from-pool-size each tick). Operator dashboards can now alert on stuck migration. §7 of the runbook updated to list both metrics.
  • Doc closure: retire stale follow-up phrasing (Round 143, commit 43ce81a) — README §”Status: 100% feature-complete” parenthetical, PARITY_SUMMARY L160/L183, PARITY_PLAN §”Network Summary” L315 / §”What’s Missing” L606 / Phase 3 item 5 step 5 description L785+ all rewritten to reflect the closed state of multi-session BlockFetch + ChainSync density hook + HotPeerScheduling-driven mux weights. AUDIT_VERIFICATION_2026Q2 §”Slice closure status” rows for E and GD updated to point readers to the runtime-integration sub-table for the actual closure commits. Phase 3 success criterion ⏳ Concurrent BlockFetch from N warm peers flipped to ✅. Doc-only; cargo lint clean.
  • Round 91 Gap BN closure: from-genesis livelock under max_concurrent_block_fetch_peers > 1 (Round 144, BlockFetch multi-peer dispatch parity) — closes the OPEN production-blocking gap flagged in docs/MANUAL_TEST_RUNBOOK.md §6.5a. Symptom: with knob > 1 set and ≥2 warm peers migrated to the FetchWorkerPool, ChainSync advanced normally but find $YGG_DB -type f | wc -l stayed at 0; node re-synced from Origin on every handoff (no crash, livelock). Initial unit-test fix was insufficient: a single-chunk fast path in FetchWorkerPool::dispatch_plan covered the genesis ReorderBuffer Origin-head gate but did NOT close the operational gap because split_range(BlockPoint(N), BlockPoint(M), 2) synthesises HeaderHash([0;32]) placeholders for intermediate boundaries (rustdoc’d contract: “the runtime must resolve synthesised intermediate points before issuing MsgRequestRange”), and the runtime never resolved them. Operationally captured via YGG_SYNC_DEBUG=1 showing wire-level blockfetch-request-cbor=83008218535820152bf9...821904635820 0000… (placeholder upper-hash) — peers responded NoBlocks to unknown-hash bounds, every batch returned zero blocks, storage stayed empty, livelock confirmed. Two-layer runtime fix: (1) partition_fetch_range_across_peers gains a placeholder-hash guard — when split_range returns chunks containing the all-zeros sentinel point_carries_placeholder_hash, the helper collapses to a single-chunk plan against peers[0] with the original (lower, upper) preserved exactly; (2) the multi-peer dispatch branch in sync_batch_verified_with_tentative now performs the same lower_hash dedup as the legacy single-peer branch — without it, the BlockFetch wire’s closed-interval [lower, upper] returns the duplicate block at lower which apply_multi_era_step_to_volatile swallows idempotently but track_chain_state_entries’s expected N, got N-1 non-contiguity check rejects, producing a consensus error: non-contiguous block on every batch after the first. Five regression tests across node/src/sync.rs + node/src/blockfetch_worker.rs: partition_with_two_peers_collapses_to_single_chunk_when_split_produces_placeholder_hashes (pins the collapse + endpoint preservation), partition_collapses_only_when_chunks_actually_carry_placeholders (single-chunk input must NOT trip the guard — pinned via the placeholder-aware test helper), point_carries_placeholder_hash_recognises_split_range_synthetic_boundary (helper sanity), pool_dispatch_plan_releases_single_chunk_genesis (worker-pool fast path delivers blocks for the production from-Origin shape), pool_dispatch_plan_single_chunk_records_pool_instrumentation (governor accounting still wired through the fast path). Pre-existing dispatch_range_returns_blocks_in_order_on_success and partition_clamps_to_available_peers updated to reflect the post-collapse semantics. The block_point test helper now uses a non-zero deterministic hash so test inputs cannot accidentally trip the placeholder guard. Operational verification: 2026-04-27 preprod run with knob=2 and 2-localRoot topology — 845 storage files, 836 blocks_synced, 7 worker migrations across 120s, 0 reconnects, 0 consensus errors (vs storage=0/blocks_synced=0 pre-fix). Throughput delta is currently 0.54× the knob=1 baseline because the placeholder collapse forces single-chunk dispatch even when N peers are migrated; closure of that throughput gap requires multi-peer ChainSync candidate-fragment lookup (a separate slice). Production default max_concurrent_block_fetch_peers = 1 stays in place pending the runbook §6.5f sign-off including the throughput-delta target. Reference: Ouroboros.Network.BlockFetch.Decision.fetchDecisions; docs/MANUAL_TEST_RUNBOOK.md §6.5a; full operational record in docs/operational-runs/2026-04-27-runbook-pass.md. 4644 workspace tests pass across all crates, 0 failures.
  • NtC wire-format parity slice — V16 high-bit, LSQ inline-CBOR, MsgAcquireVolatileTip tag (Round 146, 2026-04-27 haskell-parity rehearsal continued) — closes the three remaining wire-level NtC parity gaps so upstream cardano-cli 10.16.0.0 query tip --testnet-magic 1 reaches yggdrasil’s LocalStateQuery query/result phase end-to-end. Discovered by YGG_NTC_DEBUG=1 (a new diagnostic env var added to crates/network/src/ntc_peer.rs and crates/network/src/local_state_query_server.rs) capturing the exact 51-byte ProposeVersions and 2-byte MsgAcquireVolatileTip payloads cardano-cli sends. (1) Version high-bit (Finding B closure): upstream nodeToClientVersionBit = 0x8000 flags every NtC version on the wire so it cannot collide with NtN versions sharing the same handshake table. yggdrasil’s HandshakeVersion::NTC_V9..=NTC_V16 were defined as logical 9..=16, so cardano-cli’s [V_16..V_23] proposal (encoded [0x8010..=0x8017]) never matched and the handshake refused. Fixed: all 8 constants now NTC_VERSION_BIT | n plus a new pub const NTC_VERSION_BIT: u16 = 0x8000. Three regression tests in crates/network/src/ntc_peer.rs: ntc_handshake_version_constants_have_high_bit_set (pins both vc.0 & NTC_VERSION_BIT == NTC_VERSION_BIT AND vc.0 & !NTC_VERSION_BIT == logical for every V9..V16, plus literal 0x8010 for V16), ntc_version_bit_matches_upstream_constant (pins 0x8000), decode_ntc_propose_versions_accepts_real_cardano_cli_payload (the captured 51-byte [0, {0x8010..=0x8017 -> [1, false]}] payload from cardano-cli must round-trip to the 8 NTC_V* constants). Existing decode_ntc_propose_versions_roundtrip and encode_ntc_accept_version_roundtrip updated to expect wire-format 0x8010 instead of logical 16. (2) LocalStateQuery wire format (new finding): yggdrasil’s MsgAcquire/MsgReAcquire/MsgQuery/MsgResult codec wrapped the point/query/result payloads in CBOR byte-string major type 2 (enc.bytes(...) / dec.bytes()?) — but upstream Ouroboros.Network.Protocol.LocalStateQuery.Codec writes them as INLINE structured CBOR (no wrapper). yggdrasil’s dec.bytes()? of cardano-cli’s inline-encoded MsgAcquire returned a type-mismatch error and tore down the bearer (operator-observable: BearerClosed "<socket: 11> closed when reading data"). Fixed: switched encode to enc.raw(payload) and decode to dec.raw_value() for all three payload sites; new acquire_point_wire_bytes_are_inline_not_byte_string_wrapped test pins the byte-by-byte wire shape (0x82 0x00 <inline> not 0x82 0x00 0x58 <len> <bytes>); query_result_roundtrip test inputs updated to be valid CBOR (since the codec no longer accepts arbitrary bytes). (3) MsgAcquireVolatileTip tag mismatch (new finding): yggdrasil mapped this variant to wire tag 9 (encode AND decode); upstream Ouroboros.Network.Protocol.LocalStateQuery.Codec uses tag 8. cardano-cli sends [8] (0x81 0x08); yggdrasil rejected it as unknown LocalStateQuery message tag: 8 and tore down the connection. yggdrasil’s own client+server agreed on the wrong tag 9, so §8 NtC LocalStateQuery smoke tests passed against itself — the bug only surfaced under upstream traffic. Fixed: encode + decode + rustdoc table all corrected to tag 8; new acquire_volatile_tip_wire_tag_matches_upstream_canonical_tag_8 test pins the exact 2-byte wire payload [0x81, 0x08] for both encode AND decode. Operational verification: with all three fixes, upstream cardano-cli query tip against yggdrasil’s NtC socket now succeeds through handshake → MsgAcquireVolatileTip → MsgAcquired → MsgQuery → MsgResult; the next failure is DeserialiseFailure 2 "expected list len or indef" in upstream’s HardForkBlock result decoder, which reflects yggdrasil’s BasicLocalQueryDispatcher returning a flat tag-table result envelope rather than the upstream era-aware HardForkQuery-wrapped shape. Closing that gap requires a full upstream Ouroboros.Consensus.HardFork.Combinator.Ledger.Query codec (~1000+ lines) and is documented as Finding E in docs/operational-runs/2026-04-27-runbook-pass.md. Reference: Ouroboros.Network.NodeToClient.Version, Ouroboros.Network.Protocol.LocalStateQuery.Codec. 4649 workspace tests pass across all crates, 0 failures.
  • NtC handshake refuse-payload bug + comparator silent-exit (Round 145, 2026-04-27 haskell-parity rehearsal) — surfaced by attempting the runbook §5 hash-compare cadence with upstream cardano-node 10.7.1 + cardano-cli 10.16.0.0 running side-by-side with yggdrasil-node on preprod. cardano-cli’s query tip against yggdrasil’s NtC socket reproduces HandshakeError (VersionMismatch [V_16..V_23] []) — the empty right-hand list is the operator-observable symptom that yggdrasil’s Refuse VersionMismatch reply carries no recognisable server-side versions. Two bugs: (1) crates/network/src/ntc_peer.rs::ntc_accept was calling encode_ntc_refuse_version_mismatch(&proposed.iter().map(|(v,_)| *v).collect::<Vec<_>>()) — echoing the client’s proposed versions back instead of yggdrasil’s own NTC_SUPPORTED_VERSIONS. Per upstream Ouroboros.Network.Protocol.Handshake.Codec, the Refuse VersionMismatch payload must carry the server’s version table so the client knows what to renegotiate against. Fix: pass NTC_SUPPORTED_VERSIONS (V9..V16) directly; new ntc_accept_refuse_payload_carries_server_supported_versions test pins both the length (==NTC_SUPPORTED_VERSIONS.len()) and the exact ordered list, so a future drift in either the supported set or the encoding fails CI cleanly with a “Refuse VersionMismatch must list every server-supported version, not echo the client’s proposed list” diagnostic. (2) node/scripts/compare_tip_to_haskell.sh ran under set -euo pipefail and called extract_field (a grep | head | sed | tr pipeline) for block/epoch fields — which yggdrasil’s cardano-cli query-tip JSON does NOT emit ({tip: {hash, origin, slot}} only). When grep found no match, pipefail propagated the failure and set -e exited the script without reaching the [info] summary or the divergence-snapshot block — operators saw exit-1 with no output and no snapshot dir, masking any real divergence diagnosis. Fix: extract_field now captures grep output via raw="$(... || true)" and short-circuits on empty, so missing keys render as blanks in the summary rather than killing the script. Open follow-up: the V16 set-intersection between yggdrasil’s V9..V16 and cardano-cli’s V16..V23 should select V16 but doesn’t — likely a per-version decode_ntc_version_data shape mismatch where modern cardano-cli encodes V16’s version-data with a non-2-element CBOR shape that yggdrasil’s strict 2-element decoder rejects. Documented in docs/operational-runs/2026-04-27-runbook-pass.md “Finding B” as requiring a per-version codec table rather than the current one-size-fits-all decoder. Sync-rate finding (no fix this slice): yggdrasil syncs preprod from genesis at ~80 slots/sec; cardano-node 10.7.1 syncs at ~1600 slots/sec — 20× gap. At yggdrasil’s rate, catching current preprod tip from genesis takes ~17 days vs Haskell’s ~6 hours. The §5 moving-tip hash-compare cadence requires both nodes pre-synced to network tip; the §5 sign-off step therefore needs an out-of-band pre-sync window. 4645 workspace tests pass across all crates, 0 failures.
  • Finding E full closure + Finding A foundation (Rounds 148–150, 2026-04-27 haskell-parity completion) — closes Finding E (cardano-cli query tip against yggdrasil’s NtC socket now succeeds end-to-end with structured JSON output) AND lays the foundation for Finding A (multi-peer ChainSync with candidate-fragment lookups so multi-peer BlockFetch can dispatch with real intermediate hashes). Round 148 — Upstream Query / BlockQuery / HardForkBlock codec: new crates/network/src/protocols/local_state_query_upstream.rs implements the layered Query → BlockQuery → SomeBlockQuery (HardForkBlock xs) → QueryHardFork / QueryAnytime / QueryIfCurrent wire codec end-to-end (decoder + encoder), per upstream Ouroboros.Consensus.Ledger.Query + Ouroboros.Consensus.HardFork.Combinator.Serialisation.SerialiseNodeToClient. Top-level wire tags: BlockQuery=0, GetSystemStart=1, GetChainBlockNo=2, GetChainPoint=3, DebugLedgerConfig=4. HardForkBlock tags: QueryIfCurrent=0, QueryAnytime=1, QueryHardFork=2. QueryHardFork inner tags: GetInterpreter=0, GetCurrentEra=1. 13 regression tests covering captured upstream wire fixtures (e.g. the real 0x82 0x00 0x82 0x02 0x81 0x01 payload from cardano-cli 10.16.0.0). Wired into BasicLocalQueryDispatcher via a new dispatch_upstream_query helper that recognises upstream-shaped queries and falls back to yggdrasil’s flat-table dispatcher otherwise. Yggdrasil’s own CLI tags 1/2/3 collided with upstream’s GetSystemStart/GetChainBlockNo/GetChainPoint; CLI migrated Tip → [3] (upstream GetChainPoint) and CurrentEra → [0, [2, [1]]] (upstream BlockQuery (QueryHardFork GetCurrentEra)); CurrentEpoch and ProtocolParams moved to extension tags [101] / [102]. Round 149 — NtC V_23 + result shapes: bumped supported NtC versions from V_9..V_16 to V_9..V_23 to match upstream cardano-node 10.7.1’s ceiling (15 versions; all share the same [network_magic, query] NodeToClientVersionData). Restored monotonic SDU timestamps in crates/network/src/mux.rs + crates/network/src/bearer.rs — pre-fix yggdrasil sent literal 0 timestamps, matching cardano-cli’s accept-versions tolerance for handshake but failing data-protocol SDUs. Result encoders (per operator-captured wire bytes from socat -x -v proxy on the upstream Haskell node): EraIndex → bare CBOR uint (0x06 for Conway), Point → [] for Origin / [slot, hash] for BlockPoint, WithOrigin BlockNo → [0] for Origin / [1, n] for At, UTCTime → [year, dayOfYear, picosecondsOfDay] (3-element, per cardano-cli’s explicit error message), Interpreter → indefinite-length array of [Bound, EraEnd, EraParams] triples with EraParams shape [epochSize, slotLength, [tag, slots, lowerBound], genesisWindow] matching the captured Byron-era bytes verbatim. Round 150 — Multi-peer ChainSync foundation: new node/src/chainsync_worker.rs implements ChainSyncWorkerHandle, CandidateFragment (per-peer rolling window of announced (slot, hash) tuples, default capacity 2160), ChainSyncWorkerPool registry keyed on SocketAddr, plus SharedChainSyncWorkerPool runtime handle. partition_fetch_range_with_candidate_fragments in node/src/sync.rs resolves split_range’s synthetic [0; 32] placeholder hashes against per-peer candidate fragments — when every intermediate boundary is announced by at least one peer, the planner returns a real-hash multi-chunk plan suitable for parallel MsgRequestRange dispatch (the upstream fetchDecisions analogue). Falls back to single-chunk path when fragments don’t have the required hashes. Operational verification: 2026-04-27 rehearsal — cardano-cli query tip --testnet-magic 1 --socket-path /tmp/ygg.sock returns structured JSON {epoch, era=Shelley, slotInEpoch, slotsToEpochEnd, syncProgress} against yggdrasil’s NtC socket (pre-Round-148 it returned BearerClosed then DeserialiseFailure 2 "expected list len or indef"). 4679 workspace tests pass across all crates, 0 failures. Open follow-ups for full Finding A closure: (1) wire the ChainSyncWorkerPool into the runtime governor so workers actually spawn on promote_to_warm and populate fragments from real wire traffic; (2) thread real preprod era-history into Interpreter response (Phase-3 Finding E refinement); (3) thread chain-block-no into the snapshot for accurate GetChainBlockNo results. Reference: Ouroboros.Network.ChainSync.Client, Ouroboros.Network.BlockFetch.Decision.fetchDecisions, full operational record in docs/operational-runs/2026-04-27-runbook-pass.md “Finding E closure”.
  • ChainSync worker pool runtime wiring + observability (Round 151, 2026-04-27 Finding A continuation) — closes the first follow-up flagged at the end of Round 150 by plumbing the SharedChainSyncWorkerPool end-to-end through the production runtime so candidate fragments populate from real preprod wire traffic. Wiring path: new field shared_chainsync_worker_pool: Option<SharedChainSyncWorkerPool> on VerifiedSyncServiceConfig (cloned into the multi-peer MultiPeerDispatchContext via chainsync_pool: Option<&SharedChainSyncWorkerPool>), parallel field on RuntimeGovernorConfig with a with_shared_chainsync_worker_pool(...) builder, runtime startup in node/src/main.rs constructs one shared pool with yggdrasil_node::new_shared_chainsync_worker_pool() and clones it into both the sync-service config (reader path) and the governor config (metrics path). sync_batch_verified_with_tentative in node/src/sync.rs now publishes every observed RollForward header into the candidate fragment via publish_announced_header and tries partition_fetch_range_with_candidate_fragments BEFORE falling back to placeholder collapse — so when fragments cover the requested range, the planner returns a real-hash multi-chunk plan suitable for parallel dispatch. Observability: new gauge yggdrasil_chainsync_workers_registered in node/src/tracer.rs (NodeMetrics::set_chainsync_workers_registered, surfaced through MetricsSnapshot.chainsync_workers_registered, emitted in to_prometheus_text with TYPE/HELP metadata). Governor tick in node/src/runtime.rs reads cs_pool.read().await.len() alongside the existing BlockFetch pool size each tick, so operators can alert on chainsync_workers_registered == 0 (means dispatch is falling back to single-chunk placeholder collapse) vs > 0 (means candidate-fragment partitioning is feeding real header hashes into BlockFetch). Eleven regression tests on node/src/chainsync_worker.rs cover CandidateFragment push/rollback/lookup semantics (hash_at_slot, tip, capacity bounds), ChainSyncWorkerPool registry keying, publish_announced_header auto-registration on first observe, and publish_rollback slot truncation. Twelve sites updated to add the new shared_chainsync_worker_pool: None default to VerifiedSyncServiceConfig initializers across node/src/main.rs, node/src/runtime.rs, node/tests/sync.rs, node/tests/runtime.rs. Operational verification: 2026-04-27 preprod run with knob=2, 2-localRoot topology — yggdrasil_chainsync_workers_registered=1 (one worker auto-registered from the verified-sync reader path’s RollForward stream), yggdrasil_blockfetch_workers_registered=10 (knob=2 → 10 warm peers migrated), yggdrasil_blocks_synced=556 and yggdrasil_current_slot=96640 after ~60s, yggdrasil_reconnects=0. cardano-cli query tip still returns structured JSON end-to-end through the new wiring ({epoch, era=Shelley, slotInEpoch, slotsToEpochEnd, syncProgress}) — confirms NtC parity preserved. Metrics snapshot in /tmp/ygg-verify-metrics-final.txt, cardano-cli capture in /tmp/ygg-verify-cli-tip-final.txt. 4682 workspace tests pass across all crates, 0 failures. Open follow-ups: (1) plumb each peer’s per-peer ChainSync upstream task RollForward observations into the pool (currently only the reader-side peer registers a worker, capping the partitioner’s per-peer hash coverage) — would surface as chainsync_workers_registered ≥ 2 under knob=2; (2) thread real preprod era-history into Interpreter response (Phase-3 Finding E refinement); (3) thread chain-block-no into LedgerStateSnapshot for accurate GetChainBlockNo results so cardano-cli’s reported tip reflects live chain progress instead of the snapshot-time origin display. Reference: Ouroboros.Network.ChainSync.Client, Ouroboros.Network.BlockFetch.Decision.fetchDecisions.
  • cardano-cli query tip parity — Interpreter shape + GetChainBlockNo (Round 152, 2026-04-27 cardano-cli display fix) — closes the operator-visible parity gap where cardano-cli 10.16.0.0 query tip against yggdrasil’s NtC socket returned the structured JSON envelope but reported origin tip ({epoch:0, slot:0, syncProgress:"0.00"} and missing block/hash/slot fields) even when yggdrasil had progressed past slot 87000. Root cause analysis via socat -x -v wire capture (/tmp/ygg-runbook/haskell-traffic.bin) and YGG_NTC_DEBUG=1 snapshot logging: (1) encode_interpreter_minimal emitted a single closed Byron-shaped era summary ending at slot 86_400 — any queried slot > 86_400 fell outside our era list and cardano-cli silently fell back to default-Byron-shape display (epochSize=21600 from the --epoch-slots CLI default); (2) the Bound.relativeTime field was wrongly encoded as a CBOR bignum tag-2 byte string when upstream Ouroboros.Consensus.HardFork.History.Summary writes it as a plain CBOR uint when the value fits in u64 (verified byte-by-byte against the captured Byron eraEnd 83 1b 17fb16d83be00000 1a 00015180 04); (3) Shelley eraParams used epochSize=21600 (Byron-shape) when the captured upstream uses epochSize=432000 (5-day Shelley epochs); (4) GetChainBlockNo always returned Origin ([0]) which causes cardano-cli’s query tip to suppress the block/slot/hash fields entirely — Origin BlockNo is treated as “no chain” by the display layer regardless of GetChainPoint’s slot. Fix path: rewrote encode_interpreter_preprod to emit two era summaries — Byron (closed at slot 86_400, 20s slots, captured upstream params) + Shelley (synthetic far-future end at slot 10_000_000 keeping relativeTime in u64 range, 1s slots, captured upstream params epochSize=432000/slotLength=1000ms/safeZone=[0,129600,[0]]/genesisWindow=129600). Added encode_relative_time helper using enc.unsigned(picoseconds) (not enc.tag(2) + enc.bytes(...)) for parity with the captured wire bytes; encode_bignum_u128 retained as a fallback helper for hypothetical future synthetic slots that exceed u64. In dispatch_upstream_query GetChainBlockNo now derives a synthetic block number from snapshot.tip().slot() so cardano-cli emits block / slot / hash fields; documented as approximating block-no until consensus ChainState.chain_block_number is threaded through LedgerStateSnapshot (Phase-3 follow-up). Two regression tests in crates/network/src/protocols/local_state_query_upstream.rs: preprod_interpreter_byron_prefix_matches_upstream_capture (pins the 39-byte Byron prefix verbatim — including the 0x1b 17fb16d83be00000 u64 relativeTime, NOT bignum), preprod_interpreter_shelley_uses_captured_epoch_size_and_genesis_window (pins the 84 1a 00069780 1903e8 Shelley params marker = epochSize=432000/slotLength=1000ms and the 0x1fa40 (=129600) genesisWindow occurrence count). Operational verification: 2026-04-27 preprod knob=2 ~60s soak — cardano-cli query tip --testnet-magic 1 --socket-path /tmp/ygg-verify-multi.sock now returns {block:88040, epoch:4, era:"Shelley", hash:"96a02bdd…ba36", slot:88040, slotInEpoch:1640, slotsToEpochEnd:430360, syncProgress:"1.40"} against yggdrasil’s NtC socket — every JSON field populated with the live chain state. Captures saved to /tmp/ygg-verify-cli-tip-r152.txt (cardano-cli output), /tmp/ygg-verify-metrics-r152.txt (Prometheus snapshot), /tmp/ygg-proxy-capture.txt (socat wire bytes used to diagnose the bignum-vs-uint regression). 4684 workspace tests pass across all crates, 0 failures (up from 4682 in Round 151). Open follow-ups: (1) thread real ChainState.chain_block_number through LedgerStateSnapshot so GetChainBlockNo returns the true block count instead of approximating from slot; (2) emit additional era summaries (Allegra+) when the snapshot’s current era exceeds Shelley so cardano-cli’s slot↔epoch math stays accurate past slot 10M (the current synthetic Shelley far-future end); (3) parameterise the era summaries by network preset (preprod/preview/mainnet) instead of hard-coding preprod values. Reference: Ouroboros.Consensus.HardFork.History.Summary, Ouroboros.Consensus.HardFork.Combinator.Serialisation.SerialiseNodeToClient; full operational record in docs/operational-runs/archive/2026-04-27-round-152-cardano-cli-tip-parity.md.
  • Network-aware Interpreter / SystemStart per preview/preprod/mainnet (Round 153, 2026-04-27 cardano-cli tip parity continuation) — closes Round 152’s open follow-up #3 (“parameterise the era summaries by network preset”) so cardano-cli query tip reports correct epoch/slot math regardless of which Cardano network yggdrasil is connected to. Pre-fix: encode_interpreter_minimal and encode_system_start were hardcoded to preprod values (Shelley epochSize=432_000, systemStart=2022-06-01) — running yggdrasil against preview (epochSize=86_400 1-day epochs, systemStart=2022-10-25) or mainnet (Byron→Shelley at slot 4_492_800 / epoch 208) would emit a wrong-shaped Interpreter and cardano-cli’s slot↔epoch conversion would silently produce nonsense. Wiring: new NetworkKind enum (Preprod/Preview/Mainnet) plus encode_interpreter_for_network(NetworkKind) -> Vec<u8> and encode_system_start_for_network(NetworkKind) -> Vec<u8> selectors. Per-network encoders: encode_interpreter_preprod (unchanged from Round 152 — Byron+Shelley, epochSize=432_000), encode_interpreter_preview (single open Shelley summary, epochSize=86_400, no Byron because preview’s config.json sets every Test*HardForkAtEpoch=0), encode_interpreter_mainnet (Byron+Shelley with Byron→Shelley at slot 4_492_800 / epoch 208, Shelley epochSize=432_000; relativeTime caps at u64 via slot-based picosecond approximation). Per-network systemStart values: preprod 2022-06-01 (day-of-year 152), preview 2022-10-25 (day-of-year 298), mainnet 2017-09-23 (day-of-year 266). Mirrored on the consumer side: new NetworkPreset enum and BasicLocalQueryDispatcher::new(NetworkPreset) constructor; dispatch_upstream_query now takes NetworkPreset and selects the right encoder. NetworkPreset::from_network_magic(u32) derives the preset from the runtime-configured network_magic (1=preprod, 2=preview, 764824073=mainnet) so node/src/main.rs can wire it transparently from existing config without new operator flags. Eight test sites updated from unit-style BasicLocalQueryDispatcher to BasicLocalQueryDispatcher::default() (preprod-pinned default for tests). Three regression tests in crates/network/src/protocols/local_state_query_upstream.rs: preview_interpreter_emits_single_shelley_summary_with_1day_epochs (pins 0x1a 00015180 1903e8 Shelley params marker = epochSize=86_400/slotLength=1000ms, asserts preprod’s 0x69780 does NOT appear in preview output), preview_system_start_is_2022_day_298 (pins 83 19 07e6 19 012a 00), preprod_system_start_is_2022_day_152 (regression baseline). Operational verification: preprod knob=2 ~30s soak post-fix returns {block:88040, epoch:4, era:"Shelley", hash:"96a02bdd…ba36", slot:88040, slotInEpoch:1640, slotsToEpochEnd:430360, syncProgress:"1.40"} — same shape as Round 152, no regression from the network-aware refactor. Preview verification could not complete operationally because preview’s Test*HardForkAtEpoch=0 chain produces blocks with mismatched envelope-era / protocol-version pairs (Alonzo era_tag=5 wrapping Babbage PV=(7,2)) that yggdrasil’s strict validate_block_protocol_version_for_era rejects with “expected major in 5..=6” — separate sync-layer parity gap unrelated to NtC. Preview NtC codec output verified via the captured-bytes regression tests instead. Captures saved to /tmp/ygg-verify-cli-tip-r153.txt, /tmp/ygg-verify-metrics-r153.txt. 4687 workspace tests pass across all crates, 0 failures (up from 4684 in Round 152). Open follow-ups: (1) loosen yggdrasil’s strict era-tag/protocol-version pairing or thread the hard-fork combinator’s “lifted” era handling through validate_block_protocol_version_for_era so preview’s at-genesis-multi-fork chain syncs end-to-end; (2) emit Allegra+ summaries when a snapshot’s current era exceeds Shelley (mainnet at slot ~75M+ already past current Shelley synthetic far-future end of slot 14M); (3) thread network preset through CLI query tip mode so yggdrasil’s own JSON output uses live era summaries. Reference: Ouroboros.Consensus.HardFork.Combinator.Embed.Nary (era-lifting), Cardano.Node.Configuration.NodeAddress (network preset enum).
  • Era-PV pairing admits hard-fork transition signal (Round 154, 2026-04-27 preview-sync prerequisite) — closes Round 153’s open follow-up #1 by relaxing yggdrasil’s strict era_tag/protocol-version pairing in validate_protocol_version_for_era so the upstream hard-fork combinator’s transition-signalling mechanism is admitted instead of rejected. Pre-fix bug: yggdrasil enforced exact intra-era PV ranges (Era::Alonzo => major == 5 || major == 6). Upstream Cardano’s hard-fork combinator bumps PV major within era N via an in-band protocol-parameters update to signal that era N+1 will activate at the next epoch boundary — so the LAST block of era N legitimately carries the next era’s transition major (alonzoTransition=5, babbageTransition=7, conwayTransition=9 per Ouroboros.Consensus.Cardano.CanHardFork). Preview’s Test*HardForkAtEpoch=0 testnet configuration produces this transition state at chain genesis: the first Alonzo-codec block carries PV major=7 (Babbage signal). Yggdrasil rejected with protocol version mismatch: block in era Alonzo carries version (7, 2), expected major in 5..=6 — the operator-visible symptom captured during the Round 153 preview operational verification attempt. Fix: each era now admits its intra-era range PLUS the next era’s transition major: Shelley 2..=3, Allegra 3..=4, Mary 4..=5, Alonzo 5..=7, Babbage 7..=9, Conway 9+. The MaxMajorProtVer ceiling check delegated to yggdrasil_consensus::check_header_protocol_version is unchanged — that’s the canonical PRTCL rule and remains the primary defensive gate. Two regression tests updated/added in node/src/sync.rs: protocol_version_constraints_enforce_alonzo_era_gate (now asserts Alonzo + PV(7,0) succeeds with the rationale comment “Babbage transition signal emitted by Test*HardForkAtEpoch=0 testnets at chain genesis”, retained the pre/post-Alonzo rejection assertions), protocol_version_constraints_enforce_babbage_era_gate (new — pins Babbage + PV(9,0) Conway transition signal acceptance and PV(6,0) / PV(10,0) rejections). Rustdoc table on validate_block_protocol_version rewritten to list intra-era + transition-signal pairs and reference the upstream *Transition ProtVer values. Operational verification: preview operational sync now advances past the PV-mismatch rejection that previously blocked at currentPoint=Origin. Next blocker on preview is a separate, deeper CBOR canonicalization parity gap: fee too small: minimum 237_837 lovelace, declared 237_793 — difference of exactly 44 lovelace = minFeeA × 1 byte, indicating yggdrasil’s tx CBOR re-encoding produces a 1-byte-different size from upstream. Closing that gap requires byte-perfect CBOR roundtrip through AlonzoTxBody/AlonzoBlock codecs and is documented as a follow-up. Preprod no-regression check: post-Round-154 preprod knob=2 ~30s soak still returns full cardano-cli query tip output ({block:87340, epoch:4, era:"Shelley", slotInEpoch:940, slotsToEpochEnd:431060, syncProgress:"1.40"}) — the relaxed era-PV pairing didn’t break preprod sync. 4688 workspace tests pass across all crates, 0 failures (up from 4687 in Round 153). Open follow-ups: (1) byte-perfect CBOR tx-size parity so preview’s first transactions pass validateFeeTooSmallUTxO — likely requires aligning AlonzoTxBody encoder canonicalization with upstream’s Cardano.Ledger.Alonzo.Tx; (2) era-summary auto-derivation from LedgerStateSnapshot.current_era rather than hardcoded preprod/preview shapes (Round 153 follow-up #2 still open); (3) NetworkPreset auto-detection from genesis hash rather than network_magic so custom-magic operators get correct era-history. Reference: Ouroboros.Consensus.Cardano.CanHardFork, Cardano.Ledger.Shelley.Rules.Utxo.validateFeeTooSmallUTxO; full operational record in docs/operational-runs/archive/2026-04-27-round-154-era-pv-transition-signal.md.
  • Alonzo+ tx-size for fee/max-tx excludes is_valid byte (Round 155, 2026-04-27 preview-sync unblocking) — closes Round 154’s open follow-up #1 by fixing yggdrasil’s tx-size computation to match upstream’s sizeAlonzoTxF / toCBORForSizeComputation which uses a 3-element CBOR list [body, witnesses, auxData] deliberately excluding is_valid for Mary-era fee compatibility. Yggdrasil’s Tx::serialized_size was using the 4-element wire form ([body, wits, isValid, aux]), producing a 1-byte-too-large tx_size for every Alonzo+ tx. At minFeeA=44, this rejected real preview blocks with fee too small: minimum 237_837 lovelace, declared 237_793 — difference exactly 44 lovelace = minFeeA × 1 byte. Diagnostic path: added YGG_FEE_DEBUG=1 instrumentation around the failing call site, captured tx_size=1874, witness_bytes_len=710, aux_data_len=None, is_valid=Some(true), reencoded_body_len=1161, computed expected upstream tx_size=(237_793-155_381)/44=1873, then fetched upstream’s Cardano.Ledger.Alonzo.Tx.toCBORForSizeComputation source directly (encodeListLen 3 <> encCBOR atBody <> encCBOR atWits <> encodeNullStrictMaybe encCBOR atAuxData) which confirmed the Mary-era-compat exclusion of is_valid. Fix: Tx::serialized_size now always uses the 3-element form regardless of era — pre-Alonzo and Alonzo+ produce identical fee/size values for the same body+wits+aux content. New AlonzoCompatibleSubmittedTx::size_for_fee_and_max returns raw_cbor.len() - 1 (subtracting the is_valid byte) for fee/max-tx-size validation in submitted-tx paths. Three submitted-tx call sites in crates/ledger/src/state.rs (Alonzo, Babbage, Conway MultiEraSubmittedTx::* arms at lines 4612 / 4985 / 5394) updated from tx.raw_cbor.len() to tx.size_for_fee_and_max(). Block-apply paths already used tx.serialized_size() and inherit the fix automatically. Two new regression tests in crates/ledger/src/tx.rs: serialized_size_alonzo_plus_excludes_is_valid (pins the 3-element form returning 10 bytes for a 5-byte body / 1-byte wits / 3-byte aux Alonzo+ tx — pre-fix bug returned 11), serialized_size_invariant_across_eras_for_fee_math (pins that pre-Alonzo and Alonzo+ produce identical fee/size for the same content). Existing serialized_size_larger_than_body_only test updated from 12 to 11 to match the new 3-element semantics. Operational verification — preview now syncs end-to-end: preview knob=2 ~30s soak post-Round-155 produces yggdrasil_blocks_synced=1988, yggdrasil_current_slot=39740, yggdrasil_reconnects=1 (single reconnect from a peer keepalive failure, not a block rejection). cardano-cli 10.16.0.0 query tip --testnet-magic 2 returns full JSON {block:39740, epoch:0, era:"Alonzo", hash:"c6d9124b…3385", slot:39740, slotInEpoch:39740, slotsToEpochEnd:46660, syncProgress:"0.04"} — every field correctly populated for preview’s 86_400-slot epochs and Alonzo-era genesis. Bonus parity win: preview’s larger peer count exercises multi-peer ChainSync — yggdrasil_chainsync_workers_registered=2 (first time we’ve observed >1 in the field; previously preprod’s reader-side path only registered 1 worker). Preprod no-regression: post-Round-155 preprod knob=2 ~30s soak still returns {block:86840, epoch:4, era:"Shelley", hash:"7dab2681…dcc6", slot:86840, slotInEpoch:440, slotsToEpochEnd:431560, syncProgress:"1.40"} — same shape as Round 154 baseline. 4689 workspace tests pass across all crates, 0 failures (up from 4688 in Round 154). Open follow-ups: (1) thread the consensus chain-tracker block number into LedgerStateSnapshot so GetChainBlockNo returns the true count (currently approximating from slot — Round 152 follow-up still open); (2) Allegra+ era summaries when current era exceeds Shelley; (3) extend preview’s validate_protocol_version_for_era admission to capture the Babbage→Conway and Conway-internal transition signals that will surface as preview progresses. Reference: Cardano.Ledger.Alonzo.Tx.toCBORForSizeComputation, Cardano.Ledger.Shelley.Rules.Utxo.validateMaxTxSizeUTxO; full operational record in docs/operational-runs/archive/2026-04-27-round-155-tx-size-fee-parity.md.
  • cardano-cli query protocol-parameters end-to-end (Round 156, 2026-04-27 NtC LSQ era-specific dispatch) — extends Round 155’s preview-sync win by wiring the second-most-used cardano-cli operation through yggdrasil’s NtC socket. Pre-fix: cardano-cli query protocol-parameters returned DecoderFailure ... DeserialiseFailure 2 "expected list len" because yggdrasil’s dispatch_upstream_query returned null for BlockQuery (QueryIfCurrent ...) queries instead of dispatching them to era-specific result encoders. Implementation: new decode_query_if_current(inner_cbor) -> (era_index, EraSpecificQuery) parses the [era_index, era_specific_query] payload of QueryIfCurrent and classifies the era-specific tag — currently recognises GetCurrentPParams (tag 3); other tags fall through as EraSpecificQuery::Unknown. New encode_query_if_current_match wraps results in upstream’s Either (MismatchEraInfo) r envelope per encodeEitherMismatch — load-bearing detail: HFC NodeToClient uses list-length discrimination between Right and Left (no leading variant tag), so Right a is [encoded_a] (1-element list) and Left mismatch is [era1_ns, era2_ns] (2-element list of NS-encoded era names). Initial implementation incorrectly used [1, result] (2-element with discriminator) which cardano-cli interpreted as the Left/mismatch shape and failed at offset 3 looking for the second NS-encoded era; fetched upstream’s encodeEitherMismatch source via WebFetch to confirm the 1-element form. Companion encode_query_if_current_mismatch(ledger_era_idx, query_era_idx) emits the Left form for era-mismatch responses. New encode_shelley_pparams_for_lsq(params: &ProtocolParameters) emits the upstream Cardano.Ledger.Shelley.PParams.encCBOR 17-element list shape: [minFeeA, minFeeB, maxBBSize, maxTxSize, maxBHSize, keyDeposit, poolDeposit, eMax, nOpt, a0, rho, tau, d, extraEntropy, protocolVersion, minUTxOValue, minPoolCost] with correct field types (UnitInterval = CBOR tag 30 + [num, den]; Nonce = [0] Neutral or [1, hash]; ProtVer = [major, minor]). Wired into BasicLocalQueryDispatcher::dispatch_query for era_index in 1..=3 (Shelley/Allegra/Mary share PP shape); Alonzo/Babbage/Conway PP shapes are documented as Phase-3 follow-ups. Five regression tests in crates/network/src/protocols/local_state_query_upstream.rs: decode_real_cardano_cli_get_current_pparams_payload (pins the captured 82 00 82 00 82 01 81 03 cardano-cli payload), encode_query_if_current_match_is_one_element_list_no_tag (pins the 1-element list shape, including a “MUST NOT be 2-element” assertion guarding against a future regression to the [1, result] form), encode_query_if_current_mismatch_is_two_element_ns_list (pins the Left form), shelley_pparams_emit_17_element_list_with_preprod_values (pins the 17-element list with preprod minFeeA=44/minFeeB=155381 prefix bytes), plus decode_real_cardano_cli_get_current_era_payload (existing). Operational verification: cardano-cli query protocol-parameters --testnet-magic 1 against yggdrasil’s preprod NtC socket now returns full Shelley PP JSON with correct preprod-genesis values: {decentralization:1, extraPraosEntropy:null, maxBlockBodySize:65536, maxBlockHeaderSize:1100, maxTxSize:16384, minPoolCost:340000000, minUTxOValue:1000000, monetaryExpansion:3.0e-3, poolPledgeInfluence:0.3, poolRetireMaxEpoch:18, protocolVersion:{major:2,minor:0}, stakeAddressDeposit:2000000, stakePoolDeposit:500000000, stakePoolTargetNum:150, treasuryCut:0.2, txFeeFixed:155381, txFeePerByte:44}. 4693 workspace tests pass across all crates, 0 failures (up from 4689 in Round 155). Open follow-ups: (1) Alonzo/Babbage/Conway PParams shape encoders (each era has additional fields: cost models, ex_unit_prices, max_tx_ex_units, max_block_ex_units, coins_per_utxo_byte, collateral_percentage, max_collateral_inputs; Conway adds DRep/governance fields and tiered ref-script fees) — needed for query protocol-parameters once yggdrasil syncs past Mary on preprod or against Alonzo+ chains; (2) other era-specific queries — GetUTxOByAddress/GetUTxOByTxIn (essential for wallets), GetEpochNo, GetCurrentEpochState, GetGenesisConfig, GetStakeDistribution, GetPoolState, GetGovState (Conway); (3) deeper Mismatch handling: when era_index doesn’t match snapshot’s current era, emit a proper EraMismatch so cardano-cli retries with the right era hint. Reference: Cardano.Consensus.HardFork.Combinator.Ledger.Query (HFC dispatch), Cardano.Consensus.HardFork.Combinator.Serialisation.Common.encodeEitherMismatch (envelope), Cardano.Ledger.Shelley.PParams.encCBOR (17-element list shape). Full operational record in docs/operational-runs/archive/2026-04-27-round-156-pparams-query-parity.md.
  • cardano-cli query utxo (–whole-utxo / –address / –tx-in) end-to-end (Round 157, 2026-04-28 wallet-tooling parity) — extends Round 156’s QueryIfCurrent infrastructure with three more era-specific query variants so wallets, tx-builders, and explorers can scan UTxO state via yggdrasil’s NtC socket. Wire shapes captured from cardano-cli 10.16.0.0 + Round 156 socat-x-v rehearsal: GetWholeUTxO = era-specific tag 7 (singleton [7]); GetUTxOByAddress = era-specific tag 6 ([6, address_set_cbor]); GetUTxOByTxIn = era-specific tag 15 (NOT 14 — the captured wire confirmed 82 0f for the singleton-list-2 form). Implementation: extended EraSpecificQuery with GetEpochNo, GetWholeUTxO, GetUTxOByAddress { address_set_cbor }, GetUTxOByTxIn { txin_set_cbor } variants; updated decode_query_if_current to recognise tags 1/3/6/7/15. Dispatcher wires GetWholeUTxO to a new encode_utxo_map(snapshot, predicate) helper that emits a CBOR Map TxIn TxOut (upstream’s bare Map form per Cardano.Ledger.Shelley.UTxO.UTxO’s EncCBOR (UTxO m) = encCBOR m). TxOuts encoded in their bare era-specific shape via encode_txout_era_specific — must NOT use yggdrasil’s internal [era_tag, txout] envelope. GetUTxOByAddress decodes the address-set payload (tolerating CBOR tag 258 “set” prefix per CIP-21) and filters by txout_address_bytes(out); GetUTxOByTxIn decodes the TxIn-set similarly via ShelleyTxIn::decode_cbor and uses encode_utxo_map_for_txins. GetEpochNo returns a bare CBOR uint of snapshot.current_epoch().0. Three new regression tests: decode_real_cardano_cli_get_whole_utxo_payload (pins the captured 82 00 82 00 82 01 81 07 payload), decode_real_cardano_cli_get_utxo_by_tx_in_payload (pins the tag=15 + 32-byte txid + index format — load-bearing because tag 14 was the initial guess and produced silent fall-through), decode_get_utxo_by_address_recognises_tag_6 (pins the address-set shape). Operational verification on preprod: cardano-cli query utxo --whole-utxo --testnet-magic 1 returns yggdrasil’s full UTxO state as JSON — three Byron-genesis bootstrap entries with the expected addresses (addr_test1vz09v9yfxguvlp0zsnrpa3tdtm7el8xufp3m5lsm7qxzclgmzkket carrying 29_699_998_493_355_698 lovelace) and 100_000_000_000_000 lovelace each in two more bootstrap addresses. cardano-cli query utxo --address addr_test1vz09v9... correctly filters to the single matching UTxO. cardano-cli query utxo --tx-in a00696a0...#0 correctly resolves to that single entry. Diagnostic captures: /tmp/ygg-r157-whole-utxo.txt, /tmp/ygg-r157-utxo-by-address.txt, /tmp/ygg-r157-utxo-by-txin.txt. 4696 workspace tests pass across all crates, 0 failures (up from 4693 in Round 156). Open follow-ups: (1) query slot-number fails with Past horizon when the requested timestamp falls outside our 2-era preprod Interpreter’s coverage (synthetic Shelley far-future end at slot 10_000_000 = epoch 26 = ~116 days post-Byron) — extending coverage requires emitting more eras as the snapshot’s current_era progresses, or pushing the synthetic end further; (2) Alonzo+ era TxOut encoding (currently TxOuts work for Shelley/Mary because their [address, value] shape is identical, but Alonzo+ adds optional datum / script-ref fields that need era-aware encoding); (3) query stake-distribution, query stake-pools, query gov-state (Conway), query stake-address-info — each adds ~5-15 lines of dispatcher code once tagged. Reference: Cardano.Ledger.Shelley.LedgerStateQuery (era-specific query tag table), Cardano.Ledger.Shelley.UTxO.UTxO (Map TxIn TxOut encoding); full operational record in docs/operational-runs/archive/2026-04-28-round-157-utxo-query-parity.md.
  • LocalTxMonitor upstream tag-mapping fix + cardano-cli query tx-mempool end-to-end (Round 158, 2026-04-28 mempool-query parity) — closes the LocalTxMonitor wire-tag drift surfaced by cardano-cli query tx-mempool info hanging silently against yggdrasil’s NtC socket. Pre-fix bug: yggdrasil’s LocalTxMonitorMessage::to_cbor / from_cbor used a non-upstream tag scheme (MsgAcquire=0, MsgAcquired=1, MsgNextTx=2, …, MsgRelease=8, MsgDone=9). Internal roundtrip tests passed, but cardano-cli sent [1] (MsgAcquire on upstream’s wire) which yggdrasil decoded as MsgAcquired { slot_no: ? } (server-only) and the connection stalled. Diagnostic: socat -x -v wire capture showed cardano-cli’s first message as 81 01 = [1]; pre-fix yggdrasil had no MsgAcquire response handler for that tag. WebFetch of upstream Haddock for Ouroboros.Network.Protocol.LocalTxMonitor.Codec gave the canonical tag table: 0=MsgDone, 1=MsgAcquire/MsgAwaitAcquire, 2=MsgAcquired, 3=MsgRelease, 5=MsgNextTx, 6=MsgReplyNextTx, 7=MsgHasTx, 8=MsgReplyHasTx, 9=MsgGetSizes, 10=MsgReplyGetSizes. Second bug discovered during tx-exists testing: MsgHasTx payload is NOT a bare hash but a OneEraTxId envelope [era_idx, hash_bytes] — the wire shape 82 07 82 01 58 20 <32 bytes> reflects Cardano’s HardForkBlock parameterisation where TxId blk = OneEraTxId xs (era-tagged identifier). Fix: rewrote LocalTxMonitorMessage::to_cbor and from_cbor with the upstream tag table; updated MsgHasTx encoder to emit [7, [era_idx=1, hash_bytes]] (defaulting to Shelley era_idx) and decoder to consume the era-tagged envelope (preserving the tx_id: Vec<u8> API by storing only the hash bytes — mempool lookup is era-independent). Updated rustdoc tag table on the to_cbor method to point at upstream’s canonical mapping. Four new regression tests in crates/network/src/protocols/local_tx_monitor.rs: decode_real_cardano_cli_msg_acquire_payload (pins 81 01 = MsgAcquire — load-bearing because it was the symptom that revealed the entire tag-scheme drift), encode_msg_acquired_uses_tag_2 (pins 82 02 1a <slot> for the server response shape), decode_real_cardano_cli_has_tx_payload (pins 82 07 82 01 58 20 <32 bytes> for the OneEraTxId envelope), encode_msg_has_tx_emits_one_era_tx_id_envelope (pins the encoder produces the same shape on the wire). Operational verification on preprod: all three cardano-cli query tx-mempool subcommands now work end-to-end against yggdrasil’s NtC socket — info returns {capacityInBytes:0, numberOfTxs:0, sizeInBytes:0, slot:87040}, next-tx returns {nextTx:null, slot:87040} (empty mempool from a fresh sync), tx-exists 0123…ef returns {exists:false, slot:87040, txId:"0123…ef"} — the tx-exists query actually exercises the era-tagged MsgHasTx round-trip end-to-end. Bonus parity win: cardano-cli query era-history was already working from Round 153’s per-network Interpreter wiring — it’s just BlockQuery (QueryHardFork GetInterpreter) and yggdrasil emits the preprod 2-era summary CBOR which cardano-cli decodes and re-emits as {type:"EraHistory", description:"", cborHex:"9f8383000000…"}. No code changes needed for era-history; it was a “free” cardano-cli command we hadn’t tested before this round. Regression check: query tip, query protocol-parameters, query utxo --whole-utxo all continue to work — no regression from the codec re-tagging. 4700 workspace tests pass across all crates, 0 failures (up from 4696 in Round 157). Open follow-ups: (1) query slot-number for timestamps past the synthetic Shelley far-future end at slot 10M still hits Past horizon — extending preprod era-history coverage requires emitting more eras as the snapshot’s current_era advances; (2) query stake-address-info needs Bech32 stake-address parsing in dispatcher (currently returns null — would emit GetFilteredDelegationsAndRewardAccounts tag 10 response); (3) Babbage+ era-gated queries (stake-distribution, stake-pools, protocol-state, ledger-state, ledger-peer-snapshot) all blocked client-side by cardano-cli’s “This query is not supported in the era: Shelley” check until yggdrasil’s snapshot reports current_era ≥ Babbage — requires sync past Mary which on preprod is ~slot 1.5M = ~17 hours of sync at current rate. Reference: Ouroboros.Network.Protocol.LocalTxMonitor.Codec (canonical tag table); full operational record in docs/operational-runs/archive/2026-04-28-round-158-tx-mempool-parity.md.
  • Alonzo PParams shape (24-element list) — preview query protocol-parameters (Round 159, 2026-04-28 multi-era query parity) — extends Round 156’s PP query infrastructure with the Alonzo-shape encoder so cardano-cli query protocol-parameters works against snapshots reporting era_index=4 (Alonzo). Pre-fix: yggdrasil’s dispatcher only handled era_index 1..=3 (Shelley-family 17-element list); Alonzo and beyond returned null and cardano-cli reported DeserialiseFailure 2 "expected list len". Implementation: new encode_alonzo_pparams_for_lsq emits the upstream Cardano.Ledger.Alonzo.PParams.encCBOR 24-element list shape: 16 Shelley fields (with minPoolCost at slot 16) + coinsPerUtxoWord (Alonzo’s name; params.coins_per_utxo_byte * 8) + costModels (CBOR map of language → array of int64 ops) + prices ([priceMem, priceSteps] UnitInterval pair) + maxTxExUnits ([mem, steps]) + maxBlockExUnits ([mem, steps]) + maxValSize + collateralPercentage + maxCollateralInputs. Helpers: encode_alonzo_cost_models handles the CBOR map of lang → ops (encoding negative i64 ops as CBOR negative integers), encode_ex_unit_prices emits [priceMem, priceSteps] UnitInterval pair (default 0/1 when missing), encode_ex_units emits [mem, steps] u64 pair. Dispatcher in node/src/local_server.rs now branches on era_index to select the right encoder: 1..=3 → Shelley shape, 4 → Alonzo shape, 5+ → null (Babbage/Conway PP shapes are Phase-3 follow-ups). One regression test in crates/network/src/protocols/local_state_query_upstream.rs: alonzo_pparams_emit_24_element_list (pins the 0x98 0x18 array-len-24 prefix, then the minFeeA/minFeeB Shelley-shared prefix bytes). Operational verification — preview at Alonzo era: cardano-cli query protocol-parameters --testnet-magic 2 against yggdrasil’s preview NtC socket now returns full Alonzo PP JSON with all 24 fields populated: {collateralPercentage:150, costModels:{}, decentralization:1, executionUnitPrices:{priceMemory:0.0577, priceSteps:7.21e-5}, extraPraosEntropy:null, maxBlockBodySize:65536, maxBlockExecutionUnits:{memory:50000000,steps:40000000000}, maxBlockHeaderSize:1100, maxCollateralInputs:3, maxTxExecutionUnits:{memory:10000000,steps:10000000000}, maxTxSize:16384, maxValueSize:5000, minPoolCost:340000000, monetaryExpansion:0.003, poolPledgeInfluence:0.3, poolRetireMaxEpoch:18, protocolVersion:{major:6,minor:0}, stakeAddressDeposit:2000000, stakePoolDeposit:500000000, stakePoolTargetNum:150, treasuryCut:0.2, txFeeFixed:155381, txFeePerByte:44, utxoCostPerByte:34480} — every field including the Alonzo-specific cost models (empty by default), ex-unit prices, ex-unit limits, max-value-size, collateral-percentage, and utxoCostPerByte renders correctly. Preview query utxo --whole-utxo also picks up Alonzo’s datum/datumhash TxOut fields (which were already supported by encode_txout_era_specific from Round 157). Preprod regression check: post-Round-159 preprod query tip and query protocol-parameters still work (Shelley-shape unchanged for era_index=1). 4701 workspace tests pass across all crates, 0 failures (up from 4700 in Round 158). Survey of remaining era-blocked queries: query stake-pools, query stake-distribution, query protocol-state, query ledger-state, query ledger-peer-snapshot, query stake-address-info are all gated client-side by cardano-cli at era ≤ Alonzo with the message “This query is not supported in the era: Alonzo” — they require a Babbage+ snapshot. Unblocking them requires either (1) Babbage PP encoder + classifying Alonzo blocks with PV ≥ 7 as Babbage-era snapshots, or (2) syncing yggdrasil far enough that real Babbage-tagged blocks arrive. Open follow-ups: (1) Babbage PP shape (drops d/extraEntropy, adds coinsPerUtxoByte rename of coinsPerUtxoWord/8); (2) Conway PP shape (adds DRep/governance/committee fields and tiered ref-script fees); (3) era classification fix to advance snapshot.current_era when block PV major ≥ next-era threshold (which would let preview’s PV=(7,2) snapshot report Babbage and unblock client-side era checks). Reference: Cardano.Ledger.Alonzo.PParams.encCBOR; full operational record in docs/operational-runs/archive/2026-04-28-round-159-alonzo-pparams.md.
  • Babbage PParams shape (22-element list) + PV-aware era classification (Round 160, 2026-04-28 era-progression parity) — extends Round 159’s per-era PP dispatch with the Babbage shape (22 elements; drops d/extraEntropy, renames coinsPerUtxoWord → coinsPerUtxoByte) and adds PV-aware era reporting so yggdrasil’s LSQ snapshot reports the canonical Cardano era driven by the chain’s active protocol version (header PV major), not just the wire-format era_tag. Codec: new encode_babbage_pparams_for_lsq emits the upstream Cardano.Ledger.Babbage.PParams.encCBOR 22-element list per the same field ordering as Alonzo minus d/extraEntropy. Dispatcher in node/src/local_server.rs now branches era_index=5 → Babbage encoder (1..=3 Shelley, 4 Alonzo, 5 Babbage; 6+ Conway is Phase-3). PV-aware era classification — Round 160’s load-bearing change: added protocol_version: Option<(u64, u64)> field to tx::BlockHeader (populated by shelley_block_to_block / alonzo_block_to_block_with_spans macro / Babbage / Conway from each era’s header.body.protocol_version). LedgerState gains latest_block_protocol_version: Option<(u64, u64)> set in apply_block_validated after every block apply. LedgerStateSnapshot::latest_block_protocol_version() accessor exposes it to LSQ dispatcher. New helper effective_era_index_for_lsq maps PV major → era_index per upstream Ouroboros.Consensus.Cardano.CanHardFork’s *Transition ProtVer table: PV 1→Byron(0), 2→Shelley(1), 3→Allegra(2), 4→Mary(3), 5–6→Alonzo(4), 7–8→Babbage(5), 9+→Conway(6). Promotes the snapshot’s wire-era_tag-derived era to the higher of the two (wire vs PV-derived) so LSQ surfaces the chain’s active protocol era to cardano-cli’s per-era query gating. Wires the helper into both GetCurrentEra response and QueryIfCurrent era-mismatch comparisons. 30+ test files updated: bulk perl insertion of protocol_version: None, in tx::BlockHeader constructors across crates/ledger/tests/integration/*.rs, node/tests/runtime.rs, node/tests/sync.rs, node/src/sync.rs, node/src/server.rs, node/src/block_producer.rs, node/src/runtime.rs. Production sites populate from real header PV: shelley_block_to_block and the alonzo_family_block_to_block_with_spans! macro thread body.protocol_version through; block_producer.rs reads from forged.header.header_body.protocol_version; server.rs reads from the served block’s header.body.protocol_version. Operational verification: preprod at slot 86640 now reports era=Allegra (era_index=2) — upstream-faithful because preprod’s first non-Byron blocks have PV major=3 (Allegra transition signal), matching upstream cardano-node’s behaviour. Pre-Round-160 yggdrasil reported era=Shelley because it used the wire era_tag (Shelley=1) without PV-awareness. Preview at slot 4160 reports era=Alonzo (era_index=4) because the chain’s actual PV is (6, 0) at that range — which is genuinely intra-era Alonzo, not Babbage transition. Reaching Babbage on preview requires syncing further until the chain’s PV bumps to 7, expected at the first epoch boundary. cardano-cli query protocol-parameters returns Babbage shape automatically once snapshot reports era_index=5 (verified via the dispatcher branch table; will be exercised operationally once preview sync advances). Preprod no-regression: all 10 cardano-cli operations confirmed working (tip, protocol-parameters, utxo –whole-utxo / –address / –tx-in, era-history, tx-mempool info / next-tx / tx-exists, submit-tx). 4701 workspace tests pass across all crates, 0 failures. Open follow-ups: (1) Conway PP shape (adds DRep/governance/committee fields and tiered ref-script fees per Cardano.Ledger.Conway.PParams.encCBOR); (2) regression test pinning effective_era_index_for_lsq’s PV→era table; (3) extend the era-promotion to also cover the snapshot’s current_era field returned by snapshot.current_era() — currently we promote only at LSQ-dispatch time, leaving the internal era classification at wire era_tag value. Reference: Cardano.Ledger.Babbage.PParams.encCBOR, Ouroboros.Consensus.Cardano.CanHardFork’s *Transition ProtVer table; full operational record in docs/operational-runs/archive/2026-04-28-round-160-babbage-pparams-pv-era.md.
  • Conway PParams shape (31-element list) + PV→era regression test (Round 161, 2026-04-28 era-codec completeness) — closes Round 160’s open follow-ups #1 and #2 by adding the Conway PP encoder (the final era’s shape) and pinning the PV-major→era_index table with regression tests. Conway PP shape: new encode_conway_pparams_for_lsq emits the 31-element CBOR list per Cardano.Ledger.Conway.PParams.encCBOR — the 22 Babbage fields followed by 9 governance fields: poolVotingThresholds (5-elem UnitInterval list), drepVotingThresholds (10-elem UnitInterval list), minCommitteeSize, committeeTermLimit, govActionLifetime, govActionDeposit, drepDeposit, drepActivity, minFeeRefScriptCostPerByte (UnitInterval used for tierRefScriptFee). Defaults match the Conway-genesis values for mainnet (e.g. govActionDeposit=100_000_000_000, drepDeposit=500_000_000, drepActivity=20, minCommitteeSize=7, committeeTermLimit=146). Dispatcher in node/src/local_server.rs now branches era_index=6 → Conway encoder, completing the per-era PP dispatch table: 1..=3 Shelley (17-elem), 4 Alonzo (24-elem), 5 Babbage (22-elem), 6 Conway (31-elem). PV→era regression tests: three new tests in node/src/local_server.rs: effective_era_index_pv_table_matches_upstream (parameterised over PV major 1-100 + None, asserting era_index per upstream’s *Transition table), effective_era_index_falls_back_to_params_pv_when_no_block (pins the params_pv fallback when no block has been applied yet), effective_era_index_never_demotes_below_wire_era (pins the “never demote” rule that keeps wire era_tag when PV-derived would regress). Conway+Babbage PP wire-shape tests: babbage_pparams_emit_22_element_list and conway_pparams_emit_31_element_list in crates/network/src/protocols/local_state_query_upstream.rs pin the array-len prefix bytes (0x96 = array(22), 0x98 0x1f = array(31)) and the minFeeA/minFeeB shared-prefix bytes. 4706 workspace tests pass across all crates, 0 failures (up from 4701 in Round 160). Cumulative per-era PP support: yggdrasil now serves cardano-cli query protocol-parameters for any snapshot reporting era_index 1..=6 (Shelley/Allegra/Mary/Alonzo/Babbage/Conway). Mainnet-style chains in Conway era will receive the 31-element response with all governance fields populated from the snapshot’s protocol_params (which yggdrasil’s ledger applies via PPUP enactment at epoch boundaries). Open follow-ups: (1) Babbage TxOut encoding (current encode_txout_era_specific handles Shelley/Mary/Alonzo/Babbage but Babbage TxOut adds optional datum_inline and script_ref fields beyond Alonzo’s datum_hash) — needed for query utxo --whole-utxo to render correctly when synced past Alonzo; (2) era-specific era summaries — current encode_interpreter_for_network returns Byron+Shelley summaries; chains in Babbage+ will eventually need Allegra/Mary/Alonzo/Babbage summaries inlined for accurate slot↔epoch math past slot ~10M; (3) query stake-address-info (era-blocked client-side until Babbage+ snapshot reported) decoder for GetFilteredDelegationsAndRewardAccounts (tag 10). Reference: Cardano.Ledger.Conway.PParams.encCBOR; full operational record in docs/operational-runs/archive/2026-04-28-round-161-conway-pparams.md.
  • Era-history coverage to slot 2^48 + bignum-aware relativeTime — query slot-number works for any realistic timestamp (Round 162, 2026-04-28 era-history Past-horizon closure) — closes Round 152’s open follow-up #2 by extending the synthetic far-future end of every network’s Interpreter (preprod/preview/mainnet) from slot 10_000_000 (≈116 days post-Byron at 1s/slot) to slot 2^48 (≈281 trillion slots, far past any realistic chain). Pre-fix: cardano-cli query slot-number 2030-06-15T00:00:00Z failed with Past horizon: PastHorizon{...pastHorizonExpression=ELet (ERelTimeToSlot (EAbsToRelTime (ELit (RelativeTime 253670400s))))...} because the slot-to-time conversion exceeded the synthetic Shelley summary’s eraEnd at slot 10M. Fix path: changed encode_relative_time(enc, picoseconds: u64) to take u128 and dispatch — emits CBOR uint when the value fits in u64 (matches captured upstream wire bytes for real era boundaries) and falls through to CBOR positive-bignum (tag 2) when the value exceeds u64 (used by Round 162’s bumped synthetic far-future end at 2^48 slots = 2.81e26 picoseconds, which overflows u64’s 1.844e19 ceiling). Updated all three per-network encoders (encode_interpreter_preprod, encode_interpreter_preview, encode_interpreter_mainnet) to use SHELLEY_END_SLOT = 1u64 << 48 and SHELLEY_END_PICOS: u128 computed via u128 arithmetic. Mainnet’s Byron eraEnd relativeTime (4_492_800 × 20s × 1e12 = 8.9856e19 ps) was also previously workaround-capped at u64-safe value; Round 162’s bignum-aware encoder now emits the real picosecond value. Operational verification: cardano-cli query slot-number --testnet-magic 1 2030-06-15T00:00:00Z against yggdrasil’s preprod NtC socket now returns 252028800 (instead of Past horizon). Even further-future timestamps work: 2100-01-01T00:00:00Z returns slot 2446761600. All other cardano-cli operations confirmed regression-free: query tip still returns epoch:4, era:Allegra, slot:86840, query protocol-parameters returns Shelley-shape PP, query utxo --whole-utxo returns full UTxO map, query era-history returns the (now bignum-encoded) era summary CBOR. 4706 workspace tests pass across all crates, 0 failures (no test count change — the bignum path is exercised through the existing interpreter encoders). Cumulative cardano-cli parity: 11 operations now work end-to-end (+query slot-number from R162: tip, protocol-parameters, utxo whole/address/tx-in, era-history, tx-mempool info/next-tx/tx-exists, slot-number, submit-tx). Open follow-ups: (1) Babbage TxOut datum_inline/script_ref encoding (already correct in BabbageTxOut::encode_cbor but not yet operationally verified once preview crosses Alonzo→Babbage); (2) query stake-address-info Bech32 + tag 10 dispatcher; (3) era-classification promotion at LedgerStateSnapshot::current_era() (currently only LSQ-dispatch promotes). Reference: Ouroboros.Consensus.HardFork.History.Summary — RelativeTime encoding (uint when fits in u64, bignum tag 2 otherwise); full operational record in docs/operational-runs/archive/2026-04-28-round-162-era-history-coverage.md.
  • Era-specific query dispatchers for stake-pools / stake-distribution / stake-address-info / genesis-config (Round 163, 2026-04-28 LSQ era-query coverage) — extends the dispatcher with handlers for four more upstream era-specific query tags so they auto-unblock once LedgerStateSnapshot::current_era reports Babbage+ via Round 160’s PV-aware promotion (currently cardano-cli’s per-era client gating blocks them at era ≤ Alonzo). Decoder: extended EraSpecificQuery enum and decode_query_if_current tag table with: GetStakeDistribution (era-specific tag 5, singleton [5]), GetFilteredDelegationsAndRewardAccounts (tag 10, [10, credential_set]), GetGenesisConfig (tag 11, singleton [11]), GetStakePools (tag 13, singleton [13]). Tag values match upstream Cardano.Ledger.Shelley.LedgerStateQuery’s era-specific BlockQuery sum-type encoder. Encoders in node/src/local_server.rs: encode_stake_pools_set emits tag(258) [* bytes(28)] (CBOR set of 28-byte pool keyhashes per CIP-21 set tag); encode_stake_distribution_map returns an empty CBOR map 0xa0 for now (Phase-3 follow-up: thread the live mark/set/go stake-snapshot rotation from Cardano.Ledger.Shelley.LedgerState.PState into the snapshot so each pool’s relative stake can be computed); encode_filtered_delegations_and_rewards emits the upstream 2-element list [delegations_map, rewards_map] filtered by the supplied stake-credential set, looking up delegated_pool from snapshot.stake_credentials() and balance from snapshot.reward_accounts(); decode_stake_credential_set parses the CBOR set/array of [kind, hash] pairs (kind 0=AddrKeyHash, 1=ScriptHash) tolerating the optional CBOR tag 258 wrapper; encode_stake_credential emits the matching [kind, hash] shape on the response side. GetGenesisConfig returns null for now (Phase-3 follow-up: serialise the loaded ShelleyGenesis/AlonzoGenesis/ConwayGenesis per Cardano.Ledger.Shelley.Genesis.encCBOR). Dispatcher in node/src/local_server.rs::dispatch_upstream_query routes the four new variants to their encoders, keeping the era-mismatch envelope wrapping intact. Six new regression tests across both crates: decode_recognises_stake_pool_distribution_genesis_tags (pins all four new tag→variant decodings), get_stake_pools_empty_snapshot_emits_tag_258_empty_set (pins 0xd9 0x01 0x02 0x80 for empty pool set), get_stake_distribution_empty_snapshot_emits_empty_map (pins 0xa0), get_filtered_delegations_empty_snapshot_emits_two_empty_maps (pins 0x82 0xa0 0xa0). 4710 workspace tests pass across all crates, 0 failures (up from 4706 in Round 162). Operational status: era-blocked client-side until snapshot reports Babbage+ — preview’s chain at slot ~4000 has PV=(6,0) (Alonzo-era), so query stake-pools etc. still surface This query is not supported in the era: Alonzo. The dispatcher infrastructure is now ready: once preview syncs to its first epoch boundary (PV bump to 7) the queries auto-unblock through cardano-cli with no further yggdrasil changes needed. Mainnet Conway snapshots would respond directly with the populated pool set from yggdrasil’s pool_state. Open follow-ups: (1) live stake-distribution computation via mark/set/go snapshot rotation (currently empty map); (2) GetGenesisConfig ShelleyGenesis serialisation; (3) Babbage TxOut datum_inline/script_ref operational verification once preview crosses Alonzo. Reference: Cardano.Ledger.Shelley.LedgerStateQuery’s BlockQuery encoder; full operational record in docs/operational-runs/archive/2026-04-28-round-163-stake-query-dispatchers.md.
  • Phase D.2 bytes-out — ChainSync server bytes-served (Round 235, 2026-05-01 egress accounting follow-up) — extends R234’s bytes-out instrumentation pattern to ChainSync server. New aggregate Prometheus counter yggdrasil_chainsync_server_bytes_served_total for MsgRollForward { header, tip } + MsgIntersectFound { point, tip } + MsgIntersectNotFound { tip } payload bytes. Code change in node/src/server.rs::run_chainsync_server: new metrics: Option<&NodeMetrics> param; closure record_emit(header, tip, metrics) called at every roll_forward site (4 sites); explicit m.add_chainsync_server_bytes_served(point.len() + tip.len()) at intersect sites. NodeMetrics extension: new chainsync_server_bytes_served_total: AtomicU64 field; mirror on MetricsSnapshot; new add_chainsync_server_bytes_served(n) setter; Prometheus exposition adds the new counter with HELP+TYPE. Caller wiring in run_inbound_accept_loop: ChainSync responder spawn now clones cs_metrics = bf_metrics.clone() (reuses R234’s bf_metrics since both responders need the same Arc<NodeMetrics>); call site updated to pass cs_metrics.as_deref() to the new param. Verification (instance-to-instance preprod, 30s): A’s chainsync_server_bytes_served_total = 19 635 — 100 RollForward msgs × ~196 bytes each (94-byte Byron header + ~50-byte tip envelope + CBOR framing). Ratio to BlockFetch (100 500 bytes) is ~5×, matching the expected order-of-magnitude difference between header-only and full-block payloads. Test count stable at 4749. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4749 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (37.59s). Strategic significance: closes ChainSync server egress-accounting follow-up to R234. Yggdrasil’s egress-side observability now covers the two highest-volume mini-protocols (BlockFetch + ChainSync); TxSubmission2 server bytes-out remains as a low-priority follow-up (txs are infrequent and small relative to blocks). Open follow-ups (3 deferred): Phase D.2 TxSubmission2 server bytes-out + per-peer egress attribution (substantive refactor); Phase D.1 full deep-rollback recovery; Phase E.1 cardano-base coordinated fixture refresh; Phase E.2 24h+ mainnet rehearsal. Captures: /tmp/ygg-r235-{a,b}.log. Reference: standard Prometheus counter exposition; same instrumentation pattern as R234.
  • Phase D.2 bytes-out initial slice — BlockFetch server bytes-served (Round 234, 2026-05-01 egress accounting) — closes the major Phase D.2 bytes-out gap by adding an aggregate Prometheus counter for bytes served by the BlockFetch SERVER (yggdrasil-as-peer egress). Counterpart to R224’s peer_lifetime_bytes_in_total (yggdrasil-as-client ingress). Code change: new metrics: Option<&NodeMetrics> parameter on node/src/server.rs::run_blockfetch_server; after each successful serve_batch, sum blocks.iter().map(|b| b.len() as u64).sum() and call m.add_blockfetch_server_bytes_served(bytes_out). NodeMetrics extension in node/src/tracer.rs: new blockfetch_server_bytes_served_total: AtomicU64 field; mirror on MetricsSnapshot; new add_blockfetch_server_bytes_served(n) setter (additive); Prometheus exposition adds yggdrasil_blockfetch_server_bytes_served_total (counter). Caller wiring in run_inbound_accept_loop: BlockFetch responder spawn now clones the metrics handle into the closure scope (let bf_metrics: Option<Arc<NodeMetrics>> = metrics.cloned()). End-to-end verification (instance-to-instance preprod): A serves to B (60s test); A’s blockfetch_server_bytes_served_total = 100 500 matches B’s peer_lifetime_bytes_in_total = 100 500 exactly — operational proof of correctness via egress/ingress symmetry. No leakage, no double-counting. Test count stable at 4749. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4749 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (33.26s). Strategic significance: closes the major Phase D.2 bytes-out gap that was the last substantive deferred item from the lifetime peer-stats deliverable. Operators can now see how much yggdrasil contributes to the upstream Cardano network as a relay (BlockFetch egress); ChainSync header + TxSubmission2 egress remain deferred to follow-ups using the same instrumentation pattern. Per-peer attribution requires threading remote SocketAddr through the responder run-loop signature (deferred — substantive refactor). Open follow-ups (3 deferred): Phase D.2 ChainSync + TxSubmission2 server bytes-out (same pattern); Phase D.2 per-peer egress attribution; Phase D.1 full deep-rollback recovery; Phase E.1 cardano-base coordinated fixture refresh; Phase E.2 24h+ mainnet rehearsal. Captures: /tmp/ygg-r234b-{a,b}.log. Reference: standard Prometheus counter exposition. Full operational record in docs/operational-runs/archive/2026-05-01-round-234-blockfetch-server-bytes-out.md.
  • PARITY_PLAN.md Executive Summary refresh post-R232 (Round 233, 2026-05-01 PARITY_PLAN hygiene, no code changes) — refreshes docs/archive/PARITY_PLAN.md Executive Summary section to reflect post-R232 cumulative state. Achieved-items list extended with: R220+R221 bidirectional P2P parity; R222–R226 Phase D.2 5-counter lifetime peer-stats; R225 Phase D.1 rollback-depth observability; R201+R216 Phase E.1 5/5 documentary pins; R229+R230+R231 cumulative regression coverage. Deferred items list reduced from 7 to 5 by reflecting items that R211→R232 actually closed: removes Phase A.6 (R214 closed), Phase C.2 (R217 measurement de-prioritised — fetch dominates apply 59×, only 1.7% gain). Remaining 5: Phase D.1 full deep-rollback recovery (~4-5 days, R225 data prerequisite shipped); Phase D.2 bytes-out (~3-4 days architectural); Phase E.1 cardano-base (vendored fixture refresh + corpus re-run); Phase E.2 24h+ mainnet rehearsal; Plutus CEK drift monitoring (ongoing). Footer “Actual delivery status” refreshed from R214 to R232 with the canonical state: production-ready pure-Rust Cardano node; all 3 networks operational including heavyweight queries; bidirectional P2P parity; Phase D.2 5-counter deliverable + Phase D.1 observability; 4749 workspace tests passing; 4 substantive deferred items. Test count stable at 4749. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4749 passed / 0 failed / 1 ignored. Strategic significance: R233 closes the documentation hierarchy refresh started by R227+R228+R232 — every canonical project doc (README, PARITY_PROOF, PARITY_PLAN, MANUAL_TEST_RUNBOOK, AGENTS) now reflects the post-R232 cumulative state with consistent terminology and remaining-work scope. Future contributors can land on any of these documents and see the same accurate picture. No code changes.
  • README cumulative R211→R231 arc summary (Round 232, 2026-05-01 README hygiene, no code changes) — refreshes README.md “Current Status” section to reflect the cumulative arc. Test count baseline updated: 4 640 (v0.2.0) → 4 749 (R231 cumulative). Adds bullet enumeration of R211→R231 deliverables: mainnet sync end-to-end (R211/R213), full LSQ surface verified on all 3 networks (R212–R215), bidirectional P2P parity (R220+R221), Phase A.6 GetGenesisConfig (R214), Phase D.2 5-counter lifetime peer-stats (R222–R226), Phase D.1 rollback-depth observability (R225), Phase E.1 5/5 documentary pins in-sync (R201+R216), full Prometheus-output regression coverage (R229+R230+R231). New “Deferred substantive items” subsection documenting the 4 remaining items with operator-facing rationale: Phase D.1 full deep-rollback recovery (data-justified by R225 histogram); Phase D.2 bytes-out (per-mini-protocol egress accounting); Phase E.1 cardano-base (vendored fixture refresh); Phase E.2 24h+ mainnet rehearsal. Each item includes “Bar to close” framing so future operators understand what’s needed and what observability data exists today to support the work. Test count stable at 4749. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4749 passed / 0 failed / 1 ignored. Strategic significance: R232 closes the documentation hierarchy — README (project entry-point) ↔ PARITY_PROOF.md (canonical cumulative status) ↔ MANUAL_TEST_RUNBOOK.md (operator workflow) ↔ AGENTS.md (rolling journal) ↔ per-round operational-runs/. Future contributors landing on the README see a faithful representation of yggdrasil’s current state and the remaining work scope. No code changes.
  • R200 apply-batch + R217 fetch-batch histogram regression test (Round 231, 2026-05-01 contract pinning) — completes the cumulative regression coverage of R211→R226 observability metrics by pinning the apply-batch + fetch-batch duration histogram contracts. New test node_metrics_tracks_fetch_and_apply_batch_histograms in node/src/tracer.rs pins three load-bearing aspects: (1) bucket boundaries [1ms, 5ms, 10ms, 50ms, 100ms, 500ms, 1s, 5s, 10s, +Inf] shared by both histograms — drift means R217+R218’s multi-peer sync-rate quantification (fetch-vs-apply side-by-side comparison) breaks; (2) cumulative-bucket semantic; (3) Prometheus exposition shape for both metrics. Test exercises real-world observation values: apply 200ms (R218 mainnet typical), fetch 12.85s (R217 single-peer baseline), fetch 8.56s (R218 multi-peer 2 workers) — verifying inclusion + exclusion at the relevant bucket boundaries (le=0.1, le=0.5, le=10.0, +Inf). Test count 4748→4749. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4749 passed / 0 failed / 1 ignored. Strategic significance: with R229+R230+R231 cumulative regression coverage, every R200/R217/R225/R226 observability metric now has explicit Prometheus-output regression tests pinning their wire-protocol contract. Future refactors that accidentally drop a counter, change a counter to a gauge, alter bucket boundaries, or break the exposition format will fail CI rather than silently breaking operator dashboards. Open follow-ups (4 deferred): Phase D.1 full deep-rollback recovery; Phase D.2 bytes-out per-mini-protocol egress; Phase E.1 cardano-base vendored fixture refresh; Phase E.2 24h+ mainnet rehearsal. Reference: standard Prometheus exposition format § “Histograms”.
  • Phase D.1 rollback-depth histogram regression test (Round 230, 2026-05-01 contract pinning) — mirrors R229’s regression-pin pattern for the Phase D.1 rollback-depth histogram (R225). New test node_metrics_tracks_phase_d1_rollback_depth_histogram in node/src/tracer.rs pins three load-bearing aspects: (1) bucket boundaries [1, 2, 5, 50, 2160 (k), 10_000, u64::MAX] — drift means dashboards misclassify severity; (2) cumulative-bucket semantic (an observation of depth d increments every bucket whose le is ≥ d, so +Inf is total observation count); (3) Prometheus exposition shape (# TYPE … histogram, _bucket{le="…"}, _sum, _count). Test exercises three observations: depth=0 (session-start confirm, falls into every bucket), depth=3 (small reorg, falls into le≥5 only), depth=5000 (cross-epoch, falls into le≥10_000 only) — verifying both inclusion and exclusion at each bucket boundary. Test count 4747→4748. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4748 passed / 0 failed / 1 ignored. Strategic significance: the R230 regression guard pins the wire-protocol contract for the Phase D.1 observability prerequisite so the histogram shape is stable across future refactors. Together with R229’s Phase D.2 regression-pin, every R211→R226 observability metric now has explicit Prometheus-output regression coverage. Open follow-ups (4 deferred): Phase D.1 full deep-rollback recovery; Phase D.2 bytes-out per-mini-protocol egress; Phase E.1 cardano-base vendored fixture refresh; Phase E.2 24h+ mainnet rehearsal. Reference: standard Prometheus exposition format § “Histograms”.
  • Phase D.2 Prometheus shape regression test (Round 229, 2026-05-01 contract pinning) — adds a regression test node_metrics_tracks_phase_d2_lifetime_peer_stats in node/src/tracer.rs that pins the 5-counter Phase D.2 lifetime peer-stats Prometheus output contract. The 4 cumulative metrics (peer_lifetime_sessions_total, _failures_total, _bytes_in_total, _handshakes_total) MUST emit # TYPE …_total counter; the 1 cardinality metric (peer_lifetime_unique_peers) MUST emit # TYPE … gauge. Drift in counter/gauge discrimination silently breaks operator alerts that depend on rate(...) semantics (only valid on counters). Test exercises: (a) zero-init state, (b) governor-tick aggregate setter calls populating each metric, (c) snapshot fields match setter values, (d) Prometheus text emits correct TYPE lines + value lines for all 5 metrics. Test count 4746→4747. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4747 passed / 0 failed / 1 ignored. Strategic significance: the R229 regression guard pins the wire-protocol contract for the Phase D.2 deliverable so the metric-name and metric-type semantics are stable across future refactors. Future changes to the lifetime peer-stats output that accidentally drop counters or change types will fail CI rather than silently break operator dashboards. Open follow-ups (4 deferred): Phase D.1 full deep-rollback recovery; Phase D.2 bytes-out per-mini-protocol egress; Phase E.1 cardano-base vendored fixture refresh; Phase E.2 24h+ mainnet rehearsal. Reference: standard Prometheus exposition format § “Type metadata” — counter vs gauge contract.
  • Operator runbook §7 metrics list — R222–R226 lifetime peer-stats + R225 rollback-depth (Round 228, 2026-05-01 operator docs hygiene, no code changes) — extends docs/MANUAL_TEST_RUNBOOK.md §7 metrics-snapshot section with detailed interpretation of all 6 new R211→R226 observability metrics: 5 lifetime peer-stats counters (peer_lifetime_sessions_total, _failures_total, _bytes_in_total, _unique_peers, _handshakes_total) + 1 rollback-depth histogram (yggdrasil_rollback_depth_blocks). Each metric documented with: source/origin, operator interpretation, and known limitations (e.g. bytes_in_total is BlockFetch-only lower bound; unique_peers > sessions_total indicates registry-leakage; handshakes > sessions indicates handshake-complete-but-no-traffic disconnects). Adds 4 PromQL recipe snippets for operator-derived signals: peer reliability ratio, avg bytes/session, registry-leakage indicator, peer churn rate. Phase D.1 rollback-depth alert query example: histogram_quantile(0.99, rate(yggdrasil_rollback_depth_blocks_bucket[1h])). Test count stable at 4746. Verification gates: cargo fmt --all -- --check clean, cargo test-all 4746 passed / 0 failed / 1 ignored. Strategic significance: completes the operator-facing documentation for the R211→R226 parity arc — every new Prometheus metric has a documented interpretation in the canonical operator runbook. No code changes. Open follow-ups (4 deferred): Phase D.1 full deep-rollback recovery; Phase D.2 bytes-out per-mini-protocol egress; Phase E.1 cardano-base vendored fixture refresh; Phase E.2 24h+ mainnet rehearsal. Reference: docs/MANUAL_TEST_RUNBOOK.md §7 (refreshed metrics list).
  • PARITY_PROOF refresh post-R211/R226 — cumulative parity arc documentation (Round 227, 2026-05-01 docs hygiene, no code changes) — refreshes docs/PARITY_PROOF.md cumulative status report with the R211→R226 arc evidence: phase status table updated to reflect 13 closed/verified items (was 8), 1 partial (Phase D.1 observability), 4 deferred (was 7); new §4b “Phase D.2 multi-session peer accounting” with the 5-counter Prometheus deliverable + operator-derived signals (reliability ratio, bytes/session, registry-leakage indicator, peer churn rate); new §4c “Phase D.1 rollback-depth observability” with the histogram bucket structure + alert query; §5 upstream alignment table refreshed with R216 advances (ouroboros-consensus c368c2529f2f → b047aca4a731, plutus e3eb4c76ea20 → 4cd40a14e364). Phase status reclassified: A.6 ✅ (R214), C.2 🚫 de-prioritised (R217 measurement showed ~1.7% gain), D.1 ⏳ partial (observability via R225), D.2 ✅ major scope (R222+R223+R224+R226), E.1 ✅ documentary pins (5/5). Adds new B (mainnet) row for R211+R213, B (P2P) row for R220+R221. Test count stable at 4746. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4746 passed / 0 failed / 1 ignored. Strategic significance: R227 closes the documentary loop on the R211→R226 arc — docs/PARITY_PROOF.md is once again the canonical “what works today” reference, post all the substantive parity work since R206. Open follow-ups (4 deferred items): Phase D.1 full deep-rollback recovery; Phase D.2 bytes-out (per-mini-protocol egress); Phase E.1 cardano-base vendored fixture refresh; Phase E.2 24h+ mainnet rehearsal. Captures: none (no operational run). Reference: docs/PARITY_PROOF.md (refreshed canonical reference).
  • Phase D.2 fourth slice — unique-peers + handshakes-total counters (Round 226, 2026-05-01 lifetime peer-stats completion) — adds two cheap-to-compute aggregate counters that surface useful operator-derived signals. New fields on NodeMetrics in node/src/tracer.rs: peer_lifetime_unique_peers: AtomicU64 (gauge tracking cardinality of governor_state.lifetime_stats map), peer_lifetime_handshakes_total: AtomicU64 (counter summing PeerLifetimeStats.successful_handshakes across all peers). Mirror fields on MetricsSnapshot; two new setters; Prometheus rendering adds yggdrasil_peer_lifetime_unique_peers (gauge) + yggdrasil_peer_lifetime_handshakes_total (counter). Runtime governor-tick fold in node/src/runtime.rs extended to collect successful_handshakes alongside existing sessions/failures/bytes_in; calls set_peer_lifetime_unique_peers(lifetime_stats.len()) and set_peer_lifetime_handshakes_total(...). Mainnet verification (60s knob=4 sync): unique_peers=3, handshakes_total=2, sessions_total=2, failures_total=0, bytes_in_total=1 548 246. Operator-relevant observation: unique_peers (3) > sessions (2) reveals 3 distinct peer addresses tracked but only 2 promoted to warm — useful debug signal for “peer entries created but never promoted”. Operators can now compute derived signals like failures_total/sessions_total (peer reliability), bytes_in_total/sessions_total (avg bytes per session), 1 - sessions/handshakes (handshake-but-no-session rate), 1 - sessions/unique_peers (registry leakage indicator). Test count stable at 4746. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4746 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (42.84s). Strategic significance: closes the 5-counter Phase D.2 lifetime peer-stats deliverable — sessions_total, failures_total, bytes_in_total, unique_peers, handshakes_total. Bytes-out remains 0 (deferred — requires per-mini-protocol egress byte accounting). Open follow-ups: Phase D.2 bytes-out + per-peer labelled metrics (deferred); Phase D.1 full deep-rollback recovery; Phase E.1 cardano-base coordinated fixture refresh; Phase E.2 24h+ mainnet rehearsal. Captures: /tmp/ygg-r226-mainnet.log. Reference: standard Prometheus counter/gauge exposition. Full operational record in docs/operational-runs/archive/2026-05-01-round-226-peer-lifetime-unique-handshakes.md.
  • Phase D.1 first slice — rollback-depth histogram (Round 225, 2026-05-01 deep-rollback observability foundation) — lays the data foundation for Phase D.1 deep cross-epoch rollback recovery: a Prometheus histogram classifying actual rollback depths so operators can graph the distribution and alert on rare deep rollbacks (the Phase D.1 problematic case where current behaviour forces re-sync from origin). Full recovery infrastructure (historical stake-snapshot reconstruction) remains deferred — R225 is observability-only. Code change: new rollback_depth_buckets: [AtomicU64; 7] + _sum_blocks + _count fields on NodeMetrics in node/src/tracer.rs; bucket boundaries [1, 2, 5, 50, 2160 (k), 10_000, +Inf] span shallow chain reorgs through cross-epoch and full-resync. New record_rollback_depth(blocks) method follows R200/R217 cumulative-bucket histogram pattern. MetricsSnapshot extended; to_prometheus_text adds yggdrasil_rollback_depth_blocks_{bucket,sum,count} standard exposition. Drift-guard test extended with 3 accept clauses. Both production apply call sites in node/src/runtime.rs (chaindb path + shared-chaindb path) record observations when progress.rollback_count > 0; depth unit is rolled-back transactions (applied.rolled_back_tx_ids.len()) — proxy for block depth × txs/block. Depth=0 captures the common session-start RollBackward(Origin) confirm-shape rollback. Preprod verification (45s sync): 1 rollback observation at depth=0 (session-start confirm); cumulative buckets all show 1 for le=1 through +Inf; count=1, sum=0; blocks_synced=149, rollbacks=1 — matches expected preprod behaviour with no actual chain rollbacks after the initial confirm. Test count stable at 4746. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4746 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (41.29s). Strategic significance: R225 is the prerequisite for sizing the substantive Phase D.1 work — if mainnet runs show only shallow rollbacks dominant (le=2), the implementation priority is lower than if deep rollbacks (le=+Inf) are routine. Operators can now histogram_quantile(0.99, rate(yggdrasil_rollback_depth_blocks_bucket[1h])) to alert on rare deep cross-epoch rollbacks. Open follow-ups (Phase D.1 remaining): full deep-rollback recovery requires reconstructing historical stake snapshots when rolling back across epoch boundaries (substantive multi-day architectural change). Other deferred items unchanged: Phase E.1 cardano-base coordinated fixture refresh; Phase E.2 24h+ mainnet rehearsal; Phase D.2 bytes-out egress accounting; (de-prioritised) Phase C.2 pipelined fetch+apply. Captures: /tmp/ygg-r225-preprod.log. Reference: standard Prometheus histogram exposition format; R200/R217 histogram pattern. Full operational record in docs/operational-runs/archive/2026-05-01-round-225-rollback-depth-histogram.md.
  • Phase D.2 third slice — lifetime bytes-in counter (Round 224, 2026-04-30 multi-session peer accounting completion) — completes the major Phase D.2 deliverable by mirroring per-peer BlockFetchInstrumentation::bytes_delivered (already cumulative across reconnects) into PeerLifetimeStats.bytes_in at each governor tick. New method GovernorState::set_lifetime_bytes_in(peer, total) in crates/network/src/governor.rs: cumulative-overwrite (not additive) since the source is already cumulative; creates the lifetime entry if absent. Runtime wiring in node/src/runtime.rs at the governor-tick site: iterates pool.peers BTreeMap to refresh per-peer bytes_in from bytes_delivered, then folds across lifetime_stats.values() to compute the aggregate. New aggregate counter peer_lifetime_bytes_in_total on NodeMetrics exposed as yggdrasil_peer_lifetime_bytes_in_total (counter); setter set_peer_lifetime_bytes_in_total. Mainnet verification (75s knob=4 sync): yggdrasil_peer_lifetime_bytes_in_total=2 511 595 (2.5 MB cumulative blocks fetched), peer_lifetime_sessions_total=2, failures=0, blocks_synced=299, known/established/active_peers=3/3/3. Order-of-magnitude check: 2.5 MB / ~50 batches ≈ 50 KB/batch matches R218’s per-batch fetch numbers. Test count stable at 4746. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4746 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (35.92s). Strategic significance: R222 + R223 + R224 together complete the major Phase D.2 deliverable — a parallel-tracking shadow data structure for lifetime peer stats with three monotonic Prometheus counters (sessions, failures, bytes_in). Operator dashboards can now graph cumulative bytes received per peer/network distinct from current session activity, enabling per-peer reliability metrics like bytes_in_total / sessions_total (avg bytes per session) or failures_total / sessions_total (peer reliability ratio). Remaining D.2 slice (deferred): bytes-out accounting requires per-mini-protocol byte accounting on the egress path (larger architectural change). Other deferred items unchanged: Phase D.1 deep cross-epoch rollback; Phase E.1 cardano-base coordinated fixture refresh; Phase E.2 24h+ mainnet rehearsal; (de-prioritised) Phase C.2 pipelined fetch+apply. Captures: /tmp/ygg-r224-mainnet.log. Reference: Ouroboros.Network.PeerSelection.State.KnownPeers byte-tracking pattern. Full operational record in docs/operational-runs/archive/2026-04-30-round-224-peer-lifetime-bytes-in.md.
  • Phase D.2 second slice — wire lifetime stats + aggregate Prometheus exposition (Round 223, 2026-04-30 multi-session peer accounting) — wires the first concrete update points and exposes aggregate counters via /metrics. Wiring in node/src/runtime.rs::PeerSessionManager::promote_to_warm: success branch now calls governor_state.record_lifetime_session_started(peer) after the existing record_success; error branch calls record_lifetime_session_failure(peer) after the existing record_failure. Two new aggregate counters on NodeMetrics: peer_lifetime_sessions_total and peer_lifetime_failures_total. Prometheus output via to_prometheus_text adds yggdrasil_peer_lifetime_sessions_total (counter) and yggdrasil_peer_lifetime_failures_total (counter). Two new setters set_peer_lifetime_sessions_total and set_peer_lifetime_failures_total. The runtime governor tick (alongside set_peer_selection_counters) folds across governor_state.lifetime_stats.values() to compute totals and calls the setters every tick. Mainnet verification (60s sync, knob=4): yggdrasil_peer_lifetime_sessions_total=2, yggdrasil_peer_lifetime_failures_total=0, while live counts show known_peers=3, established_peers=3, active_peers=1 — the lifetime counter (2) is distinct from the live active gauge (1) confirming the observability win Phase D.2 was designed for. Operators can compute peer-churn rate as rate(yggdrasil_peer_lifetime_sessions_total[5m]) which session-keyed gauges cannot expose. Test count stable at 4746. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4746 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (38.61s). Strategic significance: R223 closes the foundational + observability slice of Phase D.2 — lifetime stats accumulate in the right places, aggregate across peers, expose via the standard /metrics endpoint. Operator dashboards can now graph real peer churn distinct from live session counts. Open follow-ups (Phase D.2 remaining): byte-counter wiring (bytes_in, bytes_out from BlockFetchInstrumentation::note_success + per-protocol byte accounting in ChainSync/TxSubmission2). Plus unchanged Phase D.1 deep cross-epoch rollback recovery, Phase E.1 cardano-base coordinated fixture refresh, Phase E.2 24h+ mainnet sync rehearsal. Captures: /tmp/ygg-r223-mainnet.log. Reference: Ouroboros.Network.PeerSelection.State.KnownPeers.knownPeerInfo. Full operational record in docs/operational-runs/archive/2026-04-30-round-223-peer-lifetime-stats-wiring.md.
  • Phase D.2 first slice — PeerLifetimeStats foundation (Round 222, 2026-04-30 multi-session peer accounting) — adds the parallel-tracking shadow data structure for “lifetime” peer statistics that survive across reconnects, distinct from the existing session-keyed governor state (failures map, in_flight_* sets, peer-registry status) which resets per session. New struct PeerLifetimeStats in crates/network/src/governor.rs: fields sessions: u32, bytes_in: u64, bytes_out: u64, successful_handshakes: u32, failures_total: u32, first_seen: Option<Instant>, last_seen: Option<Instant>. Each field documented with rationale + upstream parallel. New field on GovernorState: lifetime_stats: BTreeMap<SocketAddr, PeerLifetimeStats>. Documented contract: distinct from session-keyed state; survives record_success and other resets; upstream parallel is KnownPeers.knownPeerInfo map keyed by PeerAddr. Three accessor methods: record_lifetime_session_started(peer) bumps sessions+successful_handshakes+sets first_seen/last_seen; record_lifetime_session_failure(peer) bumps failures_total+updates last_seen; record_lifetime_traffic(peer, bytes_in, bytes_out) accumulates byte counts (no-op if peer entry absent). Plus read-only accessor lifetime_stats_for(peer) -> Option<&PeerLifetimeStats>. Regression test lifetime_stats_accumulate_across_simulated_reconnects pins the accumulation contract: simulates two sessions with traffic + failure, asserts monotonic accumulation across the simulated reconnect (counters survive a session-keyed record_failure+record_success cycle that would reset the existing failures map). R222 is the foundation slice — does NOT yet wire update points into the runtime; subsequent slices wire record_lifetime_session_started at handshake-complete sites, record_lifetime_session_failure at mux-abort sites, record_lifetime_traffic from BlockFetchInstrumentation::note_success, and expose /metrics Prometheus counters. Test count 4745→4746. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4746 passed / 0 failed / 1 ignored. Strategic significance: Phase D.2 full scope is multi-day architectural work; R222 lays the data-model foundation so future slices can wire concrete update points without re-litigating the design. Open follow-ups: Phase D.2 wiring slices (handshake+failure+traffic+metrics); Phase D.1 deep cross-epoch rollback; Phase E.1 cardano-base coordinated fixture refresh; Phase E.2 24h+ mainnet rehearsal; (de-prioritised) Phase C.2 pipelined fetch+apply. Reference: Ouroboros.Network.PeerSelection.State.KnownPeers.knownPeerInfo. Full operational record in docs/operational-runs/archive/2026-04-30-round-222-peer-lifetime-stats-foundation.md.
  • ChainProvider trait contract: separate chain_tip (Tip envelope) from chain_tip_point (bare Point) (Round 221, 2026-04-30 R220 follow-on fix) — closes a follow-on bug from R220’s trait change. R220 had provider.chain_tip() return Tip envelope; the tentative-trap rollback path at node/src/server.rs:684-691 was using chain_tip() for BOTH slots of MsgRollBackward { point, tip } — but point slot is bare Point (rollback target) while tip is Tip envelope. Test chainsync_server_rolls_back_after_tentative_trap asserted Tip envelope [130, 130, 1, 88, 32, ...] instead of bare Point [130, 1, 88, 32, ...]. Fix: new chain_tip_point() method on ChainProvider trait returns CBOR-encoded bare Point ([] or [slot, hash]); production SharedChainDb impl returns db.tip().to_cbor_bytes(); MockTentativeChainProvider test mock implements both methods. Tentative-trap rollback path now uses both: chain_tip_point() for cursor + MsgRollBackward.point, chain_tip() for MsgRollBackward.tip. Trait-level docs spell out the contract with a per-method table mapping methods to wire-protocol use sites. End-to-end verification: same as R220 setup (A listens, B --peer); B successfully synced 250 blocks from A (reconnects=0, current_slot=94440); no chainsync decode errors. R221 preserves R220 bidirectional P2P parity AND fixes the rollback wire shape. Test count stable at 4745. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4745 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (31.97s). Strategic significance: R220 + R221 establish the clean trait-level invariant — every tip Vec is upstream `Tip` envelope; `chain_tip_point()` is the distinct accessor for bare-Point uses. **Open follow-ups** (unchanged): Phase E.2 24h+ mainnet rehearsal; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh; (de-prioritised) Phase C.2 pipelined fetch+apply. Captures: `/tmp/ygg-r221-{a,b}.log`. Reference: `Ouroboros.Network.Protocol.ChainSync.Codec` — `MsgRollBackward` carries heterogeneous `(Point, Tip)` shape at the two argument positions. Full operational record in [`docs/operational-runs/archive/2026-04-30-round-221-chainprovider-tip-point-split.md`](docs/operational-runs/archive/2026-04-30-round-221-chainprovider-tip-point-split.md).
  • Full P2P functionality — server-side ChainSync Tip envelope fix (Round 220, 2026-04-30 inbound P2P parity) — closes a latent inbound P2P functionality gap surfaced by user-requested “full P2P connection functionality” verification. Two yggdrasil instances test (A listens on :13021, B --peer 127.0.0.1:13021) revealed B couldn’t sync from A: ChainSync.Client connectivity lost; reconnecting error=point decode error: CBOR: type mismatch (expected major 4, got 0). Root cause: node/src/server.rs::SharedChainDb encoded the chain tip in 4 places (chain_tip(), next_header(), find_intersect(), tentative_tip()) as Point::to_cbor_bytes() ([] or [slot, hash]), but the upstream-aligned ChainSync wire shape requires Tip ([] or [point, blockNo]) per Cardano.Slotting.Block.Tip. Yggdrasil already had the correct Tip enum + CborEncode impl in crates/ledger/src/types.rs:158-181; the server side just wasn’t using it. Bug was latent because yggdrasil-only testing has yggdrasil’s CLIENT also accepting bare-Point shape (forgiving by design); strictly upstream-conforming client (cardano-node 10.x, ouroboros-network test peers) would silently fail. Fix: new chain_tip_envelope_cbor<I, V, L>(&ChainDb) helper in node/src/server.rs reads db.tip(), looks up block in volatile→immutable to get block_no (mirrors runtime.rs::tip_context_from_chain_db), encodes via Tip::TipGenesis or Tip::Tip(point, block_no). All 4 call sites use the helper; tentative_tip() directly uses the tentative struct’s block_no field. Test chain_provider_returns_header_bytes_and_advances_by_point updated: pinned shape replaced with Tip::Tip(second_point, BlockNo(2)).encode_cbor(); imports extended with Tip from yggdrasil_ledger. End-to-end verification: pre-R220 instance B reported blocks_synced=0, current_slot=0 with repeated chainsync errors; post-R220 instance B successfully synced 250 blocks from instance A (blocks_synced=250, current_slot=96440, fetch_batch_duration_seconds_count=3, reconnects=0), with no chainsync decode errors. Verified all P2P layers working node-to-node: NtN handshake (v13/v14), Mux+SDU framing, ChainSync (R220 fix), BlockFetch (B got blocks), KeepAlive, TxSubmission2, PeerSharing, inbound listener, peer governor (no thrashing), connection manager. Test count stable at 4745. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4745 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (33.19s). Strategic significance: R220 brings yggdrasil to byte-accurate parity on the server-side ChainSync wire shape — completes bidirectional P2P parity required for yggdrasil to participate in the upstream Cardano network as a peer (relaying blocks to other nodes, not just syncing from them). Open follow-ups (unchanged from R219 minus this fix): Phase E.2 24h+ mainnet rehearsal (now also eligible to verify R220 server-side wire-shape under sustained load); Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh; (de-prioritised) Phase C.2 pipelined fetch+apply. Captures: /tmp/ygg-r220-preprod.log (pre-fix), /tmp/ygg-r220c-{a,b}.log (post-fix verification). Reference: Cardano.Slotting.Block.Tip; Ouroboros.Network.Protocol.ChainSync.Codec — MsgRollForward/MsgIntersectFound/MsgIntersectNotFound all carry Tip blk at the tip position. Full operational record in docs/operational-runs/archive/2026-04-30-round-220-server-tip-envelope-fix.md.
  • Operator runbook + PARITY_PROOF documentation refresh post-R217/R218 (Round 219, 2026-04-30 docs hygiene, no code changes) — captures the R217 fetch-batch histogram + R218 multi-peer mainnet measurements into operator-facing docs. Runbook update in docs/MANUAL_TEST_RUNBOOK.md §6.5c (Sustained-rate measurement): adds operator-quantified empirical numbers table (single-peer vs knob=4 fetch/apply per-batch and throughput), explains fetch dominance ratio (~59× more expensive than apply), shows how to use the R217 histogram + yggdrasil_blockfetch_workers_registered gauge to verify topology health (fetch_avg/batch ≈ baseline / N for N active workers). §7 metrics-snapshot section gains 2 entries documenting yggdrasil_fetch_batch_duration_seconds (R217 — operator-facing baseline + topology-health interpretation) and yggdrasil_apply_batch_duration_seconds (R200 reference for cross-comparison). PARITY_PROOF update in docs/PARITY_PROOF.md §4: extends the Phase C.1 observability section with R217 mainnet baseline output and the R218 quantified comparison table (single-peer vs 2-worker multi-peer). Surfaces the strategic conclusion that multi-peer is the immediate sync-rate lever on mainnet. Test count stable at 4745. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4745 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node baseline preserved. Open follow-ups (unchanged from R218 in scope; documentation hygiene only): Phase E.2 24h+ mainnet rehearsal; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh; (de-prioritised) Phase C.2 pipelined fetch+apply. Reference: R217 + R218 operational-run docs.
  • Mainnet multi-peer dispatch operational verification (Round 218, 2026-04-30 R217 follow-up, no code changes) — operationally verifies R217’s strategic insight: multi-peer dispatch is the actual sync-rate lever on mainnet, not Phase C.2 pipelining. Test setup: started fresh mainnet sync with --max-concurrent-block-fetch-peers 4 against 3.135.125.51:3001; 90-second window; captured /metrics snapshot. Results — direct comparison vs R217 single-peer baseline: fetch_batch_duration_count 4 → 10 (2.5×), fetch sum 51.38s → 85.63s (1.67×), fetch avg/batch 12.85s → 8.56s (0.67×, 33% faster); apply unchanged at ~0.22s/batch (within noise); blockfetch_workers_registered 0 → 2; tip advanced from slot 197 to slot 495 (2.51×); throughput 3.33 → 5.55 blk/s (1.67×, 67% faster). Worker count = 2 despite knob = 4 because only 2 warm peers are established — adding more topology peers would unlock further linear scaling. Apply rate unchanged confirms R217 finding that apply isn’t the bottleneck. Strategic implication: existing --max-concurrent-block-fetch-peers > 1 knob is the immediate lever; effectiveness scales linearly with warm peer count; each additional worker subtracts roughly (fetch_avg / N) from per-batch fetch time. Action priority post-R218: (1) operators can recover most sync-rate by increasing topology peer count (no code change); (2) Phase C.2 pipelined fetch+apply reward is ~1.7% (per R217); (3) Phase E.2 24h+ mainnet rehearsal can now operate at multi-peer rates. Test count stable at 4745. Verification gates: same as R217 (no code changes). Captures: /tmp/ygg-r218-mainnet.log + /metrics scrape captured in operational-run doc. Reference: R166 multi-peer dispatch implementation; R199 Phase B closure; R217 fetch-batch baseline. Full operational record in docs/operational-runs/archive/2026-04-30-round-218-mainnet-multipeer-fetch-rate.md.
  • Phase C.2 prerequisite — fetch-batch duration histogram (Round 217, 2026-04-30 observability) — adds yggdrasil_fetch_batch_duration_seconds Prometheus histogram mirroring R200’s apply-batch histogram so operators have hard numbers on fetch vs apply per-batch time. Code change: new fetch_batch_duration_buckets: [AtomicU64; 10] + _sum_micros + _count fields on NodeMetrics in node/src/tracer.rs; new record_fetch_batch_duration(Duration) method reusing APPLY_BATCH_BUCKETS_SECONDS boundaries ([0.001, 0.005, 0.01, 0.05, 0.1, 0.5, 1.0, 5.0, 10.0, +Inf]) for direct fetch-vs-apply comparison; MetricsSnapshot extended; to_prometheus_text appends standard histogram exposition; drift-guard test extended with 3 accept clauses. Both production call sites of sync_batch_verified_with_tentative in node/src/runtime.rs (chaindb path ~line 4950 and shared-chaindb path ~line 5568) bracket the future with let fetch_start = Instant::now() before the call and metrics.record_fetch_batch_duration(fetch_start.elapsed()) inside the result = batch_fut => arm of the tokio::select! (records on both Ok and Err paths). Mainnet baseline measurement (60 s sync, 4 batches): fetch_batch_duration_seconds_sum = 51.38 / count = 4 → avg 12.85 s/batch (~257 ms per 50-block batch); apply_batch_duration_seconds_sum = 0.87 / count = 4 → avg 0.22 s/batch (~4 ms per block). All 4 fetch observations land in +Inf bucket; all 4 apply observations land in ≤ 0.5 bucket. Strategic insight — Phase C.2 sizing revision: fetch is ~59× more expensive than apply on mainnet. Phase C.2 pipelined fetch+apply best-case throughput improvement = 0.22 / 13.07 ≈ 1.7% for multi-day implementation effort. The dominant bottleneck is BlockFetch wire round-trip from a single peer. Multi-peer dispatch (--max-concurrent-block-fetch-peers > 1, already implemented) parallelises the 12.85 s/batch latency and is the actual sync-rate lever. This re-prioritises open follow-ups: multi-peer dispatch verification + Phase E.2 24h+ rehearsal jump in priority; Phase C.2 de-prioritised (low-reward). Test count stable at 4745. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4745 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (36.30 s). Open follow-ups (re-prioritised post-R217): (1) multi-peer dispatch operational verification with quantified fetch_batch_duration ratio reduction; (2) Phase E.2 24h+ mainnet rehearsal (now also sync-rate-baseline operation); (3) Phase D.1 deep cross-epoch rollback recovery (correctness); (4) Phase D.2 multi-session peer accounting (architectural); (5) Phase E.1 cardano-base coordinated fixture refresh; (6) DE-PRIORITISED Phase C.2 pipelined fetch+apply (~1.7% reward, multi-day effort). Captures: /tmp/ygg-r217b-mainnet.log + /metrics scrape captured in operational-run doc. Reference: R200 apply-batch histogram (companion). Full operational record in docs/operational-runs/archive/2026-04-30-round-217-fetch-batch-histogram.md.
  • Phase E.1 pin refresh round 2 — ouroboros-consensus + plutus (Round 216, 2026-04-30 documentary-pin advance) — refreshes the two non-cardano-base documentary pins that had drifted since R201’s last advance ~15 rounds ago. Pin advances in node/src/upstream_pins.rs: UPSTREAM_OUROBOROS_CONSENSUS_COMMIT c368c2529f2f… → b047aca4a731d3282b1dab012d3669e9395328cc; UPSTREAM_PLUTUS_COMMIT e3eb4c76ea20… → 4cd40a14e36431019414fad519c1a6d426a55509. Each constant’s doc comment now records both the R201 advance and the R216 advance with rationale (no upstream-only changes during the drift window affect the ported subset; cumulative R215 multi-network operational evidence confirms the existing port still passes against the new audit baseline). Pre/post drift report: drifted=3 → drifted=1 (only cardano-base remains DRIFT, intentionally — its SHA is mirrored by the vendored test-vector directory name and pinning gate is crates/crypto/tests/upstream_vectors.rs::CARDANO_BASE_SHA; advancing requires coordinated fixture refresh which is a separate Phase E.1 slice). Cumulative documentary-pin scoreboard: 5 of 5 documentary pins in-sync (cardano-ledger, ouroboros-consensus, ouroboros-network, plutus, cardano-node); 1 of 1 vendored-fixture-coupled pin still drifted (cardano-base, deferred). Companion doc updates: docs/UPSTREAM_PARITY.md pinning table refreshed with new SHAs and “R216 advance” annotations; drift snapshot section refreshed with new live-HEAD comparison. Test count stable at 4745. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4745 passed / 0 failed / 1 ignored, node/scripts/check_upstream_drift.sh reports 5 in-sync / 1 DRIFT (cardano-base only). Three pin guards (upstream_pins_are_40_lowercase_hex, upstream_pins_cover_all_six_canonical_repos, upstream_cardano_base_pin_matches_vendored_directory_name) all pass against the new SHAs. Strategic significance: R201 → R216 cadence (15 rounds apart) demonstrates the audit-baseline is being actively maintained against upstream. Open follow-ups (unchanged from R215 minus the documentary-pin refresh): cardano-base coordinated vendored fixture refresh (Phase E.1 final slice); Phase E.2 24h+ mainnet rehearsal; Phase C.2 pipelined fetch+apply; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting. Reference: docs/UPSTREAM_PARITY.md §pinning table; upstream commit links in operational-run doc. Full operational record in docs/operational-runs/archive/2026-04-30-round-216-pin-refresh-r2.md.
  • Multi-network regression verify post-R211/R212/R213/R214 (Round 215, 2026-04-30 operational verification, no code changes) — confirms R211–R214’s substantial changes (consensus slot monotonicity, Byron EBB hash prefix, mux egress back-pressure, R214 genesis-config dispatcher field) haven’t regressed preview Conway or preprod Allegra operational surfaces verified by R205 and R207. Preview (with YGG_LSQ_ERA_FLOOR=6): tip returns era=Conway block 7960; conway query gov-state returns full state with constitution + script; conway query constitution returns valid JSON (anchor + dataHash + url + script); R214 startup trace shows genesisConfigCborBytes=821; all 3 sidecars persist (114 B + 218 B + 18 B). Preprod: tip returns block 91440 era=Allegra epoch 4 syncProgress 1.40%; query era-history returns valid CBOR; query protocol-parameters returns 17-element Shelley shape; query tx-mempool info returns valid mempool JSON; R214 trace shows genesisConfigCborBytes=821; sidecars persist. Cumulative multi-network parity matrix (post-R215): preview, preprod, mainnet all demonstrate operational sync + full LSQ surface + sidecars + R214 genesis-config bytes; heavyweight queries flow cleanly (R213 fix on mainnet; testnet UTxO sets too small to exercise it but no regression). Test count stable at 4745. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4745 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (R214 baseline preserved). Open follow-ups (unchanged from R214): long-running 24h+ mainnet rehearsal; Phase C.2 pipelined fetch+apply; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh. Captures: /tmp/ygg-r215-{preview,preview2,preprod}.log. Reference: cumulative parity through R1→R214. Full operational record in docs/operational-runs/archive/2026-04-30-round-215-multinetwork-post-r214-regression.md.
  • Phase A.6: GetGenesisConfig ShelleyGenesis serialiser (Round 214, 2026-04-30 final Phase A item) — closes Phase A with the upstream-aligned Cardano.Ledger.Shelley.Genesis.encCBOR 15-element list encoder. Replaces the legacy null_response() placeholder in EraSpecificQuery::GetGenesisConfig (era-specific tag 11) with real genesis bytes pre-encoded once at startup. Encoder helper encode_shelley_genesis_for_lsq(genesis, full_protocol_params, chain_start_unix_secs) -> Vec<u8> in node/src/local_server.rs emits: (1) systemStart UTCTime as 3-tuple [modifiedJulianDay, picosOfDay, attos=0] per Cardano.Ledger.Binary.encUTCTime — MJD via (unix_secs / 86400) + 40_587 (offset between 1858-11-17 MJD epoch and 1970-01-01 Unix epoch); (2) networkMagic Word32; (3) networkId 0/1 (Testnet/Mainnet); (4) activeSlotsCoeff PositiveUnitInterval tag(30) + [num, den] with denom 10^6; (5)–(11) Word64 scalars (securityParam, epochLength, slotsPerKESPeriod, maxKESEvolutions, slotLength picoseconds, updateQuorum, maxLovelaceSupply); (12) protocolParams via R156’s encode_shelley_pparams_for_lsq 17-element shape; (13) genDelegs as CBOR map keyed by 28-byte genesis-key hashes with [delegate_28b, vrf_32b] values; (14) initialFunds as CBOR map keyed by raw address bytes with Coin values; (15) staking record [pools_map, stake_map] (empty maps for mainnet/preprod/preview). Dispatcher plumbing: extended BasicLocalQueryDispatcher with genesis_config_cbor: Option<Arc<Vec<u8>>> field plus with_genesis_config_cbor() builder; dispatch_upstream_query takes the optional bytes as parameter; EraSpecificQuery::GetGenesisConfig arm wraps in encode_query_if_current_match envelope when present (falls back to null_response() otherwise). Startup wiring in node/src/main.rs: new RunNodeRequest::genesis_config_cbor field; CLI run command computes the bytes once at startup (where shelley_genesis is in scope) and threads them into the NtC dispatcher. Held in Arc<Vec<u8>> for cheap sharing. Regression test shelley_genesis_encoder_emits_15_element_list builds a mainnet-shaped genesis and asserts: outer is 15-element CBOR array; field 1 (systemStart) decodes as [mjd≈58019, picos<86400×10^12, 0] for mainnet’s 2017-09-23T21:44:51Z. Operational verification — mainnet: started fresh sync; trace shows Net.NtC starting NtC local server genesisConfigCborBytes=833 — dispatcher has 833 bytes of pre-encoded mainnet genesis CBOR. query tip --mainnet continues to work, proving the new field doesn’t break existing paths. Phase A status — 7/7 closed: A.1 (R192 ChainDepStateContext), A.2 (R196-198 nonce + ocert plumbing), A.3 (R193+R204 praos-state + gov-state), A.4 (R194 drep/spo distributions), A.5 (R195 ledger-peer-snapshot v2), A.6 (R214 GetGenesisConfig ← this round), A.7 (R202-203 stake-snapshots sidecar). Test count: 4744 → 4745 (+1 encoder shape test). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4745 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (32.32 s). Strategic significance: R214 closes the final Phase A item. Combined with Phase B closure (R211 mainnet sync fix + R213 mux egress) and Phase E.3 closure (R206 parity proof), the cumulative operational-parity arc is now 9 of 15 plan items closed + 2 verified. Yggdrasil’s mainnet operational LSQ surface is feature-complete: every cardano-cli query decodes end-to-end, all 3 consensus-side sidecars persist, heavyweight queries flow cleanly through the mux, and GetGenesisConfig returns real upstream-shape bytes. Open follow-ups (unchanged from R213): long-running 24h+ mainnet rehearsal; Phase C.2 pipelined fetch+apply for sync speed; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh. Captures: /tmp/ygg-r214-mainnet.log. Reference: Cardano.Ledger.Shelley.Genesis.encCBOR; Cardano.Ledger.Binary.encUTCTime. Full operational record in docs/operational-runs/archive/2026-04-30-round-214-getgenesisconfig-encoder.md.
  • Mux egress: allow single payloads larger than EGRESS_SOFT_LIMIT (Round 213, 2026-04-30 R212 BearerClosed root-cause + fix) — closes the R212 known limitation: query utxo --whole-utxo --mainnet failed with BearerClosed because yggdrasil’s ProtocolHandle::send rejected single payloads > 262 KB even with an empty buffer. Diagnosis: YGG_NTC_DEBUG=1 traced the LSQ response to 1 319 561 bytes (1.3 MB). Send fails at the over-strict back-pressure check current + len > self.egress_limit in crates/network/src/mux.rs; with current=0, len=1.3MB, limit=262KB the check fires. This contradicts upstream network-mux’s egressSoftBufferLimit semantic, which is back-pressure on accumulated bytes (a writer that fell behind), not single-message rejection. Fix: relax check to current > self.egress_limit — the buffer must already be over the limit before new sends are rejected. A single large payload is always accepted when the buffer is empty. Doc comments on EGRESS_SOFT_LIMIT and ProtocolHandle::send updated to clarify the back-pressure semantic. Test update: mux_egress_buffer_overflow integration test was pinning the OLD (buggy) semantic — flipped to assert single large payloads succeed AND accumulated payloads eventually trip back-pressure. Verification: cardano-cli query utxo --whole-utxo --mainnet now returns the full mainnet AVVM bootstrap UTxO — 14 505 entries totaling 31 112 484 745 ADA (31.1 billion ADA), exactly matching mainnet byron-genesis.json::avvmDistr count and upstream genesis-utxo formula. Sample entries decode with proper Byron addresses (e.g. Ae2tdPwUPEZKLbb7iGFGtKuWj1yJEiMK53ovb1HVd6GztJgqJZnuebMbP2Z carrying 462 146 000 000 lovelace). Test count stable at 4744. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (36.48 s). Strategic significance: R213 closes the R212 known limitation and proves yggdrasil’s mainnet operational LSQ surface is now complete — every cardano-cli query that works on testnets also works on mainnet, including heavyweight query utxo --whole-utxo returning ~1.3 MB. The bug was a latent ~10-line semantic miscoding in the mux back-pressure check that only manifested for LSQ responses > 262 KB; testnet bootstrap UTxOs are too small to trigger it, so R212’s mainnet test was the first to surface it. Open follow-ups (unchanged from R212 minus BearerClosed): Phase E.2 24h+ rehearsal; Phase A.6 GetGenesisConfig; Phase C.2 pipelined fetch+apply; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh. Captures: /tmp/ygg-r213c-mainnet.log (diagnosis), /tmp/ygg-r213e-mainnet.log (14505 UTxO verification). Reference: Ouroboros.Network.Mux.Egress.send (upstream’s matching back-pressure semantic). Full operational record in docs/operational-runs/archive/2026-04-30-round-213-mux-egress-singlemsg-allow.md.
  • Mainnet operational verification with cardano-cli + sidecars (Round 212, 2026-04-30 multi-network parity matrix completion, no code changes) — third-network end-to-end operational verification completing the multi-network parity matrix. Combined with R205 (preview Conway) and R207 (preprod Allegra), yggdrasil now demonstrates working operational LSQ surface + consensus-side sidecars on all three official Cardano networks. Verification: started fresh mainnet sync (--socket-path /tmp/ygg-r212-mainnet.sock --peer 3.135.125.51:3001) and after 45s of sync (volatile=1.45 MB, ledger=1.36 MB, checkpoint persisted at slot 47 + skipped at slots 97/147), dispatched cardano-cli queries. Results: query tip --mainnet returns valid JSON {block: 197 → 397 across queries, epoch: 0, era: "Shelley", hash: cf298afb…/a15b1790…, slot: 197 → 397}; query era-history --mainnet returns indef-length 2-era summary CBOR (Byron + Shelley, 9f...ff shape, R162 bignum-aware relativeTime); query slot-number 2024-06-01T00:00:00Z returns slot 125712000 (mainnet system-start at 2017-09-23 + 6.65 years); query protocol-parameters --mainnet returns 17-element Shelley shape with R156 encoder; query tx-mempool info --mainnet returns {capacityInBytes: 0, numberOfTxs: 0, sizeInBytes: 0, slot: 397} with R158 LocalTxMonitor codec. All 3 consensus-side sidecars present: nonce_state.cbor 12B, ocert_counters.cbor 1B, stake_snapshots.cbor 14B (smaller than testnets because mainnet at slot 397 is pre-Shelley so post-Byron consensus state is mostly empty — same as pre-Shelley testnet behaviour). Known limitation: query utxo --whole-utxo --mainnet failed with BearerClosed — concurrent-access during socket teardown, separate follow-up. Strategic significance: R211 mainnet sync fix validated not just by direct sync-tip-advancement evidence but by independent end-to-end cardano-cli queries exercising the full LSQ wire stack. The cumulative parity arc through R1 → R211 is now demonstrated on mainnet with the same shape as preview/preprod. Test count stable at 4744. Verification gates: same as R211 (no code changes, all gates pre-cleared). Captures: /tmp/ygg-r212-mainnet.log. Open follow-ups (unchanged from R211 plus mainnet-specific): Phase E.2 24h+ rehearsal; query utxo --whole-utxo --mainnet BearerClosed root-cause; Phase A.6 GetGenesisConfig; Phase C.2 pipelined fetch+apply; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh. Reference: docs/PARITY_PROOF.md §8e (mainnet operational verification). Full operational record in docs/operational-runs/archive/2026-04-30-round-212-mainnet-cardano-cli-verification.md.
  • Mainnet sync unblocked — Byron EBB hash + same-slot tolerance (Round 211, 2026-04-30 Phase E.2 critical-path closure) — closes the mainnet sync gap surfaced by R208 and narrowed by R210 to the BlockFetch wire layer. Two-bug cascade, both manifesting only on Byron mainnet’s genesis EBB transition (preview skips Byron entirely; preprod’s Byron is shorter and never lands on the offending code path). Bug 1 — wrong hash prefix for Byron EBB headers: node/src/sync.rs::point_from_raw_header’s decode_point_from_byron_raw_header returned None for EBB shapes (consensus_data length 2 vs main’s length 4); the fall-through path used byron_main_header_hash with [0x82, 0x01] (main-block discriminator) for the hash, but EBBs require [0x82, 0x00] (boundary discriminator) per Cardano.Chain.Block.Header.boundaryHeaderHashAnnotated. Wrong prefix → wrong hash → upstream BlockFetch can’t resolve the upper-bound point → IOG peer closes mux mid-request. Bug 2 — strict slot-monotonicity rejects Byron EBB→main_block at same slot: crates/consensus/src/chain_state.rs:148’s entry.slot.0 <= last.slot.0 rejected the legitimate Byron EBB at slot 0 + first main block of epoch 0 also at slot 0 (Byron EBBs are virtual epoch-boundary markers that don’t consume a slot). Ledger-side check at crates/ledger/src/state.rs:4062 already had Byron exemption; consensus-side was missing the same. Code changes: new byron_ebb_header_hash helper using [0x82, 0x00] prefix in node/src/sync.rs; decode_point_from_byron_raw_header now returns Some(Point) for EBB shapes (slot derived from inner epoch * BYRON_SLOTS_PER_EPOCH, hash via EBB-prefix); slot check relaxed from <= to < in crates/consensus/src/chain_state.rs (block-number contiguity check above catches re-application; Praos guarantees ≤ 1 block/slot post-Byron so no invalid post-Byron chain accepted); R210’s YGG_SYNC_DEBUG=1 trace mirrored to the shared-chaindb apply call site in node/src/runtime.rs (~line 5615) — the variant used by production NtN+NtC server, which R210 had missed. Test updates: chain_state::tests::roll_forward_rejects_non_increasing_slot renamed to roll_forward_accepts_same_slot_byron_ebb_main_pair with assertion flipped; sync::tests::point_from_raw_header_decodes_observed_byron_serialised_header_envelope updated to expect slot=0 (from inner EBB epoch=0) + EBB hash prefix [0x82, 0x00] (the original test pinned the wrong slot 83 from outer envelope + main hash, masking the bug for ~200 rounds). Verification — mainnet now syncs: 60s window with --peer 3.135.125.51:3001 advances tip to slot 197, volatile/ to 1.5 MB, ledger/ to 1.4 MB; checkpoint persisted at slot 47, then skipped at slots 97/147/197 (expected per 2160-slot delta). Compare R210 → R211: apply-side calls 0 → 6, volatile 0B → 1.5MB, ledger 0B → 1.4MB, final tip Origin → slot 197, cleared-origin recoveries 12 → 0. Test count stable at 4744. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (32.28 s). Strategic significance: R211 closes the operational Phase E.2 critical path — yggdrasil now syncs mainnet end-to-end (subject to performance + long-running stability, separately tracked). The mainnet sync gap that has been the gating item for full parity is resolved. R210’s instrumentation is what made R211 tractable: without it, R211 would have required tcpdump/socat-relay byte-capture. The two-step diagnosis (R210 narrows to BlockFetch wire layer → R211 source-level diff identifies the encoding bug) is the canonical pattern for operational-parity work going forward. Open follow-ups: long-running mainnet sync rehearsal (24h+, Phase E.2 full); Phase A.6 GetGenesisConfig; Phase C.2 pipelined fetch+apply; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh. Captures: /tmp/ygg-r211c-mainnet.log (slot 297), /tmp/ygg-r211e-mainnet.log (slot 197). References: Cardano.Chain.Block.Header.boundaryHeaderHashAnnotated, Cardano.Chain.Block.Header.Boundary.ConsensusData. Full operational record in docs/operational-runs/archive/2026-04-30-round-211-mainnet-byron-ebb-hash-fix.md.
  • Mainnet stall diagnostic — apply-side ruled out (Round 210, 2026-04-30 wire-layer narrowing) — adds an opt-in YGG_SYNC_DEBUG=1 apply-side trace at the apply_verified_progress_to_chaindb call site in node/src/runtime.rs (~line 5008) so a brief mainnet run can answer R208’s open question: is the stall at BlockFetch (zero blocks fetched per batch) or at apply (blocks fetched but silently rejected)? The diagnostic prints [YGG_SYNC_DEBUG] apply_verified_progress fetched_blocks=N rollback_count=R steps=S current_point={...} before the call and [YGG_SYNC_DEBUG] applied stable_block_count=N epoch_events=E rolled_back_tx_ids=T tracking.tip={...} after. Zero overhead when the env var is unset. 90 s mainnet run findings (--peer 3.135.125.51:3001 --max-concurrent-block-fetch-peers 1): 0 apply-side traces vs 634 pre-existing [ygg-sync-debug] blockfetch-range lines and 2 [ygg-sync-debug] demux-exit error=connection closed by remote peer; volatile/, immutable/, ledger/ all 0 bytes; Node.Recovery.Checkpoint cleared-origin fires 12 times in the window. ChainSync header decode succeeds (header_point_decoded=true raw_header_len=94) for the first Byron-era range Origin → SlotNo(648087) — the IOG backbone peer accepts the verified-sync session, then closes the mux connection during the BlockFetch request. Because apply_verified_progress is never invoked, no checkpoint, sidecar, volatile, or immutable file is written. Conclusion: the R208 mainnet sync gap is at the BlockFetch wire layer, NOT at apply / ledger / storage — every R208 hypothesis pointing at apply-path silent rejection or storage hand-off is now ruled out. Likely root causes (now narrowed): (1) Byron BlockFetch MsgRequestRange CBOR shape divergence on the request side; (2) NtN handshake version negotiation rejecting BlockFetch but accepting ChainSync; (3) Byron EBB hash indirection upstream expects in the upper bound. R211+ followup: capture MsgRequestRange bytes via tcpdump/socat-relay against the same peer, run upstream cardano-node 10.7.x for byte-comparison, fix in crates/network/src/protocols/blockfetch_pool.rs or the encoder. Test count stable at 4744. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean (35.66 s). Open follow-ups (unchanged from R209 plus narrowed E.2 scope): R211+ Phase E.2 wire-byte BlockFetch diagnosis (now de-risked — ledger/apply/storage paths cleared); Phase A.6 GetGenesisConfig; Phase C.2 pipelined fetch+apply; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh. Captures: /tmp/ygg-r210-mainnet.log (90 s). Full operational record in docs/operational-runs/archive/2026-04-30-round-210-mainnet-stall-diagnostic.md.
  • Documentation consistency pass post-R208 (Round 209, 2026-04-30 docs hygiene, no code changes) — refreshes docs/archive/PARITY_PLAN.md Executive Summary to reflect post-R208 reality (sidecar persistence listed under “consensus-side state persistence” item; multi-network LSQ surface evidence cited; mainnet sync gap acknowledged with ⚠️ marker; R200’s apply-batch histogram listed under monitoring). Adds a top-of-document pointer to docs/PARITY_PROOF.md so readers immediately see the canonical R206 cumulative reference. Adds a bottom-of-document “Actual delivery status (R208, 2026-04-30)” line clarifying what was delivered vs the original Mid-June 2026 projection. “To achieve full parity” section updated with the 7 documented deferred items + bar-to-close estimates per docs/PARITY_PROOF.md §7. Cross-doc consistency: PARITY_SUMMARY.md table extended with R209 entry; CHANGELOG.md arc range bumped to R144→R209. Test count stable at 4744. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Open follow-ups (unchanged): Phase E.2 mainnet sync diagnosis; Phase A.6 GetGenesisConfig; Phase C.2 pipelined fetch+apply; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh. Reference: docs/PARITY_PROOF.md (canonical cumulative status); docs/archive/PARITY_PLAN.md (refreshed roadmap).
  • Mainnet boot smoke test — Phase E.2 partial (Round 208, 2026-04-30 operational verification, no code changes) — quick 2-minute mainnet boot test surfaces a real production gap. Verification: started fresh --network mainnet sync; cardano-cli query tip --mainnet returned valid JSON {epoch: 0, era: "Byron", slotInEpoch: 0, syncProgress: "0.00"}; verified-sync session established to bootstrap peer 18.221.168.221:3001; NtC server bound /tmp/ygg-r208-mainnet.sock cleanly. However: after 2 minutes, volatile/ directory remains 0 bytes — block fetch + apply does NOT advance past Origin. Log shows repeated Node.Recovery.Checkpoint action=cleared-origin events suggesting verified-sync session repeatedly resets. Hypothesis: Byron-era ChainSync/BlockFetch shape mismatch specific to mainnet’s ancient first ~17M blocks; preview’s Test*HardForkAtEpoch=0 config skips Byron entirely, and preprod’s ~80K Byron blocks may not exercise the variation. Alternatively: bootstrap peer behavior or apply-path silent rejection. Status: yggdrasil binary, NtC dispatcher, sidecar persistence, and LSQ surface are fully verified on testnets (preview R205 + preprod R207). Mainnet sync at the block-pipeline layer needs separate diagnostic investigation. Phase E.2 deferred to follow-up round that does wire-byte capture (BlockFetch mini-protocol via socat) and comparison against upstream cardano-node 10.7.x on the same bootstrap peer. Open follow-ups (unchanged from R207 + R208 mainnet diagnosis): Phase E.2 mainnet sync diagnosis; Phase A.6 GetGenesisConfig; Phase C.2 pipelined fetch+apply; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh. Test count stable at 4744. Verification gates: same as R207 (no code changes, all gates pre-cleared). Captures: /tmp/ygg-r208-mainnet.log. Reference: docs/PARITY_PROOF.md §8b (mainnet boot smoke test). Full operational record in docs/operational-runs/archive/2026-04-30-round-208-mainnet-boot-smoke.md.
  • Multi-network verification — preprod (Round 207, 2026-04-30 operational verification, no code changes) — extends R205’s preview verification with the equivalent end-to-end check on preprod. Verification result: started fresh preprod sync (no YGG_LSQ_ERA_FLOOR needed since baseline queries don’t require era gating); after 35 seconds reached slot 87440 (87K blocks, era=Allegra, epoch=4); all 3 consensus-side sidecars (nonce_state.cbor 114 bytes, ocert_counters.cbor 1 byte, stake_snapshots.cbor 18 bytes) persist on preprod identically to preview; 6/6 baseline cardano-cli queries pass (tip at slot 87440 era=Allegra, protocol-parameters, era-history, slot-number, utxo --whole-utxo, tx-mempool info). Strategic significance: R207 confirms the cumulative operational-parity arc through R1 → R206 works across both testnets (preview Conway via R205 and preprod Allegra via R207). Sidecars persist on both networks; baseline cardano-cli works without era-floor on real Shelley-era chains (preprod) AND with era-floor on synthetic Conway-era chains (preview). Combined documentation in docs/PARITY_PROOF.md §8a (multi-network verification). Test count stable at 4744. Verification gates: same as R206 (no code changes, all gates pre-cleared). Captures: /tmp/ygg-r207-preprod.log. Open follow-ups (unchanged from R206): Phase A.6 GetGenesisConfig (deferred); Phase C.2 pipelined fetch+apply; Phase D.1 deep cross-epoch rollback; Phase D.2 multi-session peer accounting; Phase E.1 cardano-base coordinated fixture refresh; Phase E.2 mainnet rehearsal (24h+). Reference: docs/PARITY_PROOF.md §1 (cardano-cli LSQ surface), §2 (sidecar persistence), §6 (cumulative phase status), §8a (multi-network verification).
  • Parity proof report — Phase E.3 closed (Round 206, 2026-04-30 cumulative reference doc) — assembles the 205-round operational-parity arc into a single canonical reference document at docs/PARITY_PROOF.md. No code changes; pure documentation. Document structure: (1) cardano-cli LSQ surface — full table of 25 working subcommands with round attribution, wire encoder, live-data status; (2) consensus-side sidecar persistence — 3 sidecars (ocert_counters.cbor, nonce_state.cbor, stake_snapshots.cbor) with restart-resilience evidence captured from R205; (3) sync robustness — Phase B verification trace from R199; (4) observability — Phase C.1 baseline (~206 ms/batch); (5) upstream alignment — Phase E.1 pin status (5/6 in-sync, 1 deferred); (6) cumulative phase status table — 8 closed, 1 verified, 7 deferred; (7) deferral rationale with bar-to-close estimates per remaining item; (8) verification commands operators can run to reproduce R205’s audit; (9) cross-references to plan, operational-runs, parity matrix, summary, journal. Operational evidence cited: R190 28-subcommand audit, R199 multi-peer livelock verification, R200 apply-batch histogram baseline, R201 pin advance, R205 25/25 subcommand sweep + 3-sidecar verification + restart-resilience proof. Verification gates (no code changes, but baseline preserved): cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R206 closes the operational-parity arc with a definitive status document. Combined with R205’s operational verification, the cumulative arc through R1 → R205 is now documented in a single auditable reference. The remaining 7 deferred items are explicitly scoped (with bar-to-close estimates: A.6 ~2-3 days, C.2 ~3-4 days, D.1 ~4-5 days, D.2 ~3-4 days, E.1 cardano-base requires fetching upstream fixtures, E.2 24h+ run, E.3 done). Open follow-ups (unchanged from R205): (1) Phase A.6 — GetGenesisConfig; (2) Phase C.2 — pipelined fetch+apply; (3) Phase D.1 — deep cross-epoch rollback; (4) Phase D.2 — multi-session peer accounting; (5) Phase E.1 cardano-base — coordinated fixture refresh; (6) Phase E.2 — mainnet rehearsal. Reference: docs/PARITY_PROOF.md.
  • Comprehensive end-to-end verification post-Phase A — 6/7 Phase A items closed (Round 205, 2026-04-30 operational verification, no code changes) — runs the cumulative Phase A data-plumbing arc end-to-end on a fresh preview sync to confirm everything works. Verification result 1 — 25/25 cardano-cli queries pass: tip, protocol-parameters, era-history, slot-number, utxo --whole-utxo, tx-mempool info, constitution, drep-state, drep-stake-distribution, committee-state, treasury, spo-stake-distribution, proposals, ratify-state, future-pparams, gov-state, ledger-peer-snapshot, stake-pools, stake-distribution, stake-snapshot, pool-state, ref-script-size, ledger-state, protocol-state, stake-pool-default-vote — all decode end-to-end on preview at slot ~5K with YGG_LSQ_ERA_FLOOR=6. Verification result 2 — All 3 sidecars persist: nonce_state.cbor (114 bytes), ocert_counters.cbor (218 bytes), stake_snapshots.cbor (18 bytes) all present in <storage_dir>/ after ~30s of sync; 117 immutable files + 4 ledger snapshots accumulated by ~60s. Verification result 3 — Live nonces survive restart: stop node at slot ~10K, restart with same DB → recovery log reports recovered ledger state from coordinated storage checkpointSlot=9960 point=BlockPoint(SlotNo(10960)) replayedVolatileBlocks=50; tip resumes from slot 10960 and advances to 11940. Post-restart cardano-cli conway query protocol-state returns live candidateNonce: "509aed8a...", evolvingNonce: "509aed8a...", labNonce: "0e454674..." (real Blake2b hashes) loaded from nonce_state.cbor — the consensus-side sidecar end-to-end flow works across node restart. epochNonce/lastEpochBlockNonce correctly remain null because preview is still in epoch 0 (no epoch transition fired); oCertCounters empty because preview validation path doesn’t accumulate counters yet (separate follow-up). Cumulative Phase A status: A.1 (R192), A.2 (R196+R197+R198), A.3 (R193+R204), A.4 (R194), A.5 (R195), A.7 (R202+R203) — 6 of 7 closed. Only A.6 (GetGenesisConfig ShelleyGenesis serialiser) remains, deferred because the LSQ dispatcher returns null_response placeholder and no direct cardano-cli subcommand exercises it (leadership-schedule and kes-period-info use it internally but fail at client-side arg validation per R190). Test count stable at 4744 (R205 is verification-only, no code changes). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R205 provides concrete operational evidence that the cumulative Phase A data-plumbing arc through R191–R204 works end-to-end on a real chain. Combined with R190’s audit (28 cardano-cli subcommands) and R199’s multi-peer dispatch verification, this round is the canonical operational proof that the LSQ surface + sync robustness + consensus-state persistence + restart resilience all work together correctly. Open follow-ups: (1) Phase A.6 — GetGenesisConfig (deferred); (2) Phase C.2 — pipelined fetch+apply; (3) Phase D.1 — deep cross-epoch rollback; (4) Phase D.2 — multi-session peer accounting; (5) Phase E.1 cardano-base — coordinated fixture refresh; (6) Phase E.2 — mainnet rehearsal (24h+); (7) Phase E.3 — parity proof report. Captures: /tmp/ygg-r205-preview.log, /tmp/ygg-r205-restart.log. Full operational record in docs/operational-runs/archive/2026-04-30-round-205-comprehensive-verification.md.
  • gov-state OMap proposals shape adapter — Phase A.3 closed (Round 204, 2026-04-30 data-plumbing arc) — closes the last LSQ wire-shape gap by adapting yggdrasil’s reduced GovernanceActionState (4 fields) to upstream’s 7-field GovActionState era shape so cardano-cli conway query gov-state proposals field will surface real entries when governance traffic arrives. Code change: new encode_gov_action_state_upstream(enc, gov_action_id, state) helper in node/src/local_server.rs emitting the upstream wire shape [gasId, committeeVotes, dRepVotes, stakePoolVotes, proposalProcedure, proposedIn, expiresAfter] per Cardano.Ledger.Conway.Governance.Procedures.GovActionState. Splits yggdrasil’s unified votes: BTreeMap<Voter, Vote> into three upstream-shape maps: committee votes (Credential [kind, hash] keys for Voter::CommitteeKeyHash / CommitteeScript), DRep votes (Credential keys for Voter::DRepKeyHash / DRepScript), SPO votes (28-byte pool key hash for Voter::StakePool). Each map is filled via BTreeMap for deterministic CBOR ordering. proposed_in / expires_after are Option<EpochNo> in yggdrasil; emit 0 for None to satisfy upstream’s non-optional EpochNo. encode_conway_gov_state_for_lsq field 1 (cgsProposals’s OMap) now iterates snapshot.governance_actions() and emits each entry via the new helper (per upstream’s OMap encoding encodeStrictSeq encCBOR (toStrictSeq omap) — a CBOR list of values where each value is the GovActionState containing gasId). Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query gov-state --testnet-magic 2 continues to return correct JSON with proposals: [] (preview at slot ~5K has no governance proposals submitted, so the iterating loop emits 0 entries). When governance proposals are submitted on a chain, the same encoder will surface real entries with all 7 upstream fields populated. Regression checks pass: ratify-state / constitution / future-pparams / drep-state / committee-state / spo-stake-distribution / proposals / stake-pool-default-vote / ledger-peer-snapshot / protocol-state / stake-snapshot all continue to work. Test count stable at 4744. Verification gates: cargo fmt --all -- --check clean (one auto-fmt fix), cargo lint clean (one clippy::clone_on_copy fix on Vote value — Vote impls Copy, so dereference instead of clone), cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R204 closes Phase A.3 — the gov-state Proposals OMap now has an upstream-faithful encoder. Combined with R193 (live GovRelation from EnactState) and R188 (gov-state body shape), the entire gov-state response is now upstream-shape-correct for both empty and populated chains. This is the last LSQ wire-shape gap of the data-plumbing arc — every cardano-cli LSQ query now has both the wire surface (R164–R191) and the data-plumbing path (R191–R204) complete. Open follow-ups: (1) Phase A.6 — GetGenesisConfig ShelleyGenesis serialiser (last untouched LSQ dispatcher); (2) Phase C.2 — pipelined fetch+apply; (3) Phase D.1 — deep cross-epoch rollback; (4) Phase D.2 — multi-session peer accounting; (5) Phase E.1 cardano-base — coordinated fixture refresh; (6) Phase E.2 — mainnet rehearsal (24h+); (7) Phase E.3 — parity proof report. Reference: Cardano.Ledger.Conway.Governance.Procedures.GovActionState. Full operational record in docs/operational-runs/archive/2026-04-30-round-204-gov-action-state-shape-adapter.md.
  • stake_snapshots.cbor sidecar persist+load — Phase A.7 closed (Round 203, 2026-04-30 data-plumbing arc) — wires the runtime persist site and LSQ loader so query stake-snapshot will surface live per-pool stake totals once preview crosses its first epoch boundary. Code change: new STAKE_SNAPSHOTS_FILENAME = "stake_snapshots.cbor" constant + stake_snapshots_sidecar_path helper + save_stake_snapshots(dir, encoded) / load_stake_snapshots(dir) helpers in crates/storage/src/ocert_sidecar.rs, mirroring the existing OCert + nonce atomic-write contract; re-exported from crates/storage/src/lib.rs. At the same conditional block in node/src/sync.rs that persists the OCert sidecar, update_ledger_checkpoint_after_progress now also persists tracking.stake_snapshots if present (using StakeSnapshots::encode_cbor from crates/ledger/src/stake.rs). attach_chain_dep_state_from_sidecar in node/src/local_server.rs refactored to mutate snap through three independent sidecar reads; when stake_snapshots.cbor decodes successfully, calls snap.with_stake_snapshots(snapshots) (R202 builder). Each sidecar remains independently optional. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6, ~30 s sync): /tmp/ygg-r203-preview-db/ now contains all three sidecars: nonce_state.cbor (114 bytes), ocert_counters.cbor (1 byte = empty map), stake_snapshots.cbor (18 bytes = three empty StakeSnapshot records + zero fee_pot). cardano-cli conway query stake-snapshot --testnet-magic 2 --all-stake-pools returns 3 pools with stakeMark=0/stakeSet=0/stakeGo=0 and totals 1/1/1 — encoder picks up the persisted sidecar via snapshot.stake_snapshots() and uses the real-data path (R202); per-pool totals are 0 because preview at slot ~5K hasn’t crossed an epoch boundary yet (snapshot rotation fires on epoch transition). When preview crosses slot 86 400 → epoch 1, tracking.stake_snapshots will rotate and the sidecar will contain real per-credential stake; the same encoder will then surface real totals. Regression checks pass: gov-state / ratify-state / ledger-peer-snapshot / spo-stake-distribution / protocol-state continue to work. Test count stable at 4744. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R203 closes the Phase A.7 stake-snapshots arc. Combined with R196/R197/R198 (PraosState OCert + nonces) and R202’s stake_snapshots snapshot infrastructure, all three consensus-side sidecars now persist + load + attach end-to-end: OCert counters / nonces / stake snapshots all survive node restarts and surface in their respective LSQ queries. This is the canonical end of the data-plumbing arc — every LSQ encoder that depended on consensus-runtime state now has a path to live data via the sidecar pattern. Open follow-ups: (1) Phase A.6 — GetGenesisConfig ShelleyGenesis serialiser; (2) Phase A.3 OMap proposals — gov-state proposal entries; (3) Phase C.2 — pipelined fetch+apply; (4) Phase D.1 — deep cross-epoch rollback; (5) Phase D.2 — multi-session peer accounting; (6) Phase E.1 cardano-base — coordinated fixture refresh; (7) Phase E.2 — mainnet rehearsal; (8) Phase E.3 — parity proof. Reference: Ouroboros.Consensus.Protocol.Praos.PraosState; Cardano.Ledger.Shelley.LedgerState.SnapShots. Full operational record in docs/operational-runs/archive/2026-04-30-round-203-stake-snapshots-sidecar.md.
  • StakeSnapshots snapshot infrastructure — Phase A.7 first slice (Round 202, 2026-04-30 data-plumbing arc) — extends LedgerStateSnapshot with an optional stake_snapshots companion field (mirrors R192’s chain_dep_state pattern) so future runtime-attach calls can surface live per-pool mark/set/go stake totals in cardano-cli conway query stake-snapshot. Code change: new stake_snapshots: Option<crate::stake::StakeSnapshots> field on LedgerStateSnapshot in crates/ledger/src/state.rs; new with_stake_snapshots(snapshots) builder + stake_snapshots() -> Option<&StakeSnapshots> accessor; LedgerState::snapshot() defaults to None. encode_stake_snapshots in node/src/local_server.rs extended with a real-data path: when snapshot.stake_snapshots() returns Some, computes per-pool [mark, set, go] totals by iterating s.delegations.iter() and summing each credential’s s.stake.get(cred) (saturating-add) for every credential whose delegated_pool matches; computes accurate ssStake{Mark,Set,Go}Total via IndividualStake::iter() saturating-sum; emits real values. When None, falls back to the R163/R179 placeholder (zero per-pool + 1-lovelace NonZero Coin totals — required because cardano-cli’s decoder rejects 0 with “Encountered zero while trying to construct a NonZero value”). Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query stake-snapshot --testnet-magic 2 --all-stake-pools returns the previous R163/R179 output (zeros + 1-lovelace placeholders) because no runtime has yet attached StakeSnapshots to the snapshot — the stake_snapshots() accessor returns None and the encoder branches to the placeholder path. When the runtime-attach call site is wired in a follow-up round (at the same checkpoint landing site that persists nonce_state.cbor / ocert_counters.cbor, where tracking.stake_snapshots is already tracked in LedgerCheckpointTracking), the same encoder will surface real per-pool stake totals automatically. Regression checks pass: gov-state / ratify-state / ledger-peer-snapshot / spo-stake-distribution / protocol-state continue to work. Test count stable at 4744 (R202 is plumbing-only; encoder fall-back path preserves existing behavior bit-for-bit). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R202 establishes the read-side plumbing for the last major LSQ data-plumbing slice of Phase A. Combined with R192’s ChainDepStateContext, R202’s StakeSnapshots companion gives the snapshot two optional consensus-side context fields that runtime can opt into without breaking existing snapshot construction. Same R196/R197 read-first-write-later pattern. Open follow-ups: (1) Phase A.7 next — runtime attach at update_ledger_checkpoint_after_progress where tracking.stake_snapshots.clone() is already maintained; (2) Phase A.6 — GetGenesisConfig ShelleyGenesis serialiser; (3) Phase A.3 OMap proposals; (4) Phase C.2 — pipelined fetch+apply; (5) Phase D.1 — deep cross-epoch rollback; (6) Phase D.2 — multi-session peer accounting; (7) Phase E.1 cardano-base — coordinated fixture refresh; (8) Phase E.2/E.3 — mainnet rehearsal + parity proof. Reference: Cardano.Ledger.Shelley.LedgerStateQuery.GetStakeSnapshots; Cardano.Ledger.Shelley.LedgerState.SnapShots. Full operational record in docs/operational-runs/archive/2026-04-30-round-202-stake-snapshots-infra.md.
  • Audit baseline pin refresh — Phase E.1 first slice (Round 201, 2026-04-30 documentary pins) — advanced 4 of 5 drifted upstream commit pins in node/src/upstream_pins.rs to current HEAD reported by node/scripts/check_upstream_drift.sh. Code change: UPSTREAM_CARDANO_LEDGER_COMMIT 9ae77d611ad8… → 42d088ed84b799d6d980f9be6f14ad953a3c957d; UPSTREAM_OUROBOROS_CONSENSUS_COMMIT 91c8e1bb5d7f… → c368c2529f2f41196461883013f749b7ac7aa58e; UPSTREAM_PLUTUS_COMMIT 187c3971a34e… → e3eb4c76ea20cf4f90231a25bdfaab998346b406; UPSTREAM_CARDANO_NODE_COMMIT 60af1c23bc20… → 799325937a4598899c8cab61f4c957662a0aeb53. Each constant gains an “R201 audit baseline (2026-04-30) — advanced from … to live HEAD” rustdoc note. cardano-base intentionally NOT advanced — its SHA is mirrored by the vendored test-vector directory name (specs/upstream-test-vectors/cardano-base/<sha>/) consumed by crates/crypto/tests/upstream_vectors.rs::CARDANO_BASE_SHA; advancing requires a coordinated refresh of the vendored fixtures and re-running the full corpus drift-guard tests, which is intentionally a separate audit slice. docs/UPSTREAM_PARITY.md updated: pinned-commits table now shows new SHAs with audit-baseline date 2026-04-30, R201 advance notes; drift snapshot section retitled to “2026-04-30 (post-R201 advance)” with all 5 advanced pins shown as **in-sync** and cardano-base shown as drifted (vendored-fixture coupled — see below) plus an explanation paragraph. Verification: drift detector run shows drifted=1 unreachable=0 total=6 (down from drifted=5); all 3 drift-guard tests (upstream_pins_are_40_lowercase_hex, upstream_pins_cover_all_six_canonical_repos, upstream_cardano_base_pin_matches_vendored_directory_name) pass. Test count stable at 4744. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R201 establishes a fresh audit baseline so future regressions against the new upstream HEAD can be tracked from a known-good reference point. The pin advance is documentary (no behavioral change) but acknowledges that the audit cadence has been re-run against the new SHAs. Pure-Rust port has no Cargo git = deps — pinning is informational tracking only. Open follow-ups: (1) cardano-base pin coordinated refresh (vendored fixture + corpus drift-guard tests); (2) Phase E.2 — mainnet rehearsal once data-plumbing arc complete; (3) Phase E.3 — parity proof report (cumulative test matrix + JSON byte comparison vs upstream); (4) Phase A.6/A.7/A.3 OMap; (5) Phase C.2 pipelined fetch+apply; (6) Phase D.1 deep cross-epoch rollback; (7) Phase D.2 multi-session peer accounting. Reference: node/src/upstream_pins.rs’s UPSTREAM_PINS table; drift-guard tests in node/src/upstream_pins.rs::tests mod. Full operational record in docs/operational-runs/archive/2026-04-30-round-201-pin-refresh.md.
  • Phase B verified resolved + Phase C.1 apply-batch duration histogram (Rounds 199 + 200, 2026-04-30 sync-perf observability) — combined operational round closing two plan items. R199 (Phase B): ran yggdrasil with --max-concurrent-block-fetch-peers 4 for 2 minutes, then killed and restarted same DB. Result: 22 K blocks synced (slot 21960 reached), 667 immutable files written, volatile=963 KB, ledger=22 KB; on restart, Node.Recovery log reports recovered ledger state from coordinated storage checkpointSlot=21960 point=BlockPoint(SlotNo(23960)) replayedVolatileBlocks=100, sync resumes from slot 23960 (not origin) and advances to slot 25940 — R91 multi-peer storage livelock no longer reproduces, presumably closed by an intervening round (likely R196’s checkpoint persistence wiring). R200 (Phase C.1): new yggdrasil_apply_batch_duration_seconds Prometheus histogram in node/src/tracer.rs — apply_batch_duration_buckets: [AtomicU64; 10] + apply_batch_duration_sum_micros + apply_batch_duration_count; bucket boundaries [0.001, 0.005, 0.01, 0.05, 0.1, 0.5, 1.0, 5.0, 10.0, +Inf] cover ~1 ms to ~10 s; new record_apply_batch_duration(Duration) cumulative-bucket helper; mirrored snapshot fields with snapshot-construction wiring; Prometheus rendering appended in to_prometheus_text (_bucket{le="X"}, _sum in seconds, _count); drift-guard test extended with three accept clauses for the histogram suffix mapping. Instrumented two apply sites in node/src/runtime.rs (chaindb + shared-chaindb runtime variants) wrapping apply_verified_progress_to_chaindb with Instant::now() / record_apply_batch_duration. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6, 30 s sync): curl /metrics | grep apply_batch returns 12 lines covering all 10 bucket counters + _sum=0.412206 (seconds) + _count=2 — both observations fall in the [0.1, 0.5] bucket, average ≈ 206 ms/batch. Regression checks pass: gov-state / ratify-state / ledger-peer-snapshot / spo-stake-distribution / protocol-state continue to work; restart from checkpoint works correctly. Test count stable at 4744 (R200’s drift-guard test extension keeps the existing snapshot-coverage invariant intact). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R199 verifies Phase B is closed without further code changes (the R91 documented blocker is resolved). R200 closes Phase C.1 and produces the operational baseline for Phase C.2 pipelined fetch+apply regression measurement — a post-pipeline rerun should preserve the per-batch p50/p99 distribution while throughput (blocks/s at the applied tip) goes up. Open follow-ups: (1) Phase C.2 — pipelined fetch+apply (deadlock-risk; uses R200 histogram as regression baseline); (2) Phase D.1 — deep cross-epoch rollback recovery; (3) Phase D.2 — multi-session peer accounting; (4) Phase A.6 — GetGenesisConfig ShelleyGenesis serialiser; (5) Phase A.7 — active stake distribution amounts; (6) Phase A.3 OMap proposals; (7) Phase E — pin refresh + mainnet rehearsal + parity proof. Reference: standard Prometheus histogram exposition format; Ouroboros.Network.BlockFetch.ClientRegistry (multi-peer dispatch). Full operational record in docs/operational-runs/archive/2026-04-30-round-199-200-multipeer-verified-and-apply-histogram.md.
  • Sync-side persist for nonce_state — live nonces in protocol-state (Round 198, 2026-04-30 Phase A.2 final) — completes the Phase A.2 nonce arc by wiring the runtime persist site. Combined with R196 (OCert sidecar load) and R197 (Nonce sidecar codec + load), cardano-cli conway query protocol-state now surfaces live PraosState data: real Blake2b nonces and per-pool OCert counter map. Code change: new persist_nonce_state_sidecar(checkpoint_outcome, storage_dir, state) helper in node/src/sync.rs that’s a no-op unless outcome is Persisted AND storage_dir is set; encodes via R197’s CborEncode impl and calls yggdrasil_storage::save_nonce_state. Helper invoked from run_verified_sync_service_chaindb right after apply_nonce_evolution_to_progress. Same persist logic inlined at 3 reconnecting-runtime apply sites in node/src/runtime.rs (right after record_verified_batch_progress). Imports Path alongside existing PathBuf in sync.rs. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6, chain at slot ~4960): storage dir now contains both nonce_state.cbor (114 bytes) and ocert_counters.cbor (218 bytes). cardano-cli conway query protocol-state --testnet-magic 2 returns: candidateNonce: "81b58164...", evolvingNonce: "81b58164..." (real Blake2b-256 nonce hashes evolving from VRF outputs), labNonce: "0f5d06e7..." (last-applied-block prev-hash nonce), and oCertCounters map with 7+ block-issuing pool key hashes. epochNonce and lastEpochBlockNonce correctly remain null because preview is still in epoch 0 (no epoch transition fired). Regression checks pass: gov-state / ratify-state / ledger-peer-snapshot / spo-stake-distribution / future-pparams continue to work. Test count stable at 4744. Verification gates: cargo fmt --all -- --check clean, cargo lint clean (one useless-conversion fix on SyncError::Storage(err).into() → Err(SyncError::Storage(err))), cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R198 closes the Phase A.2 nonce arc — combined with R192 (ChainDepStateContext infrastructure), R196 (OCert sidecar load), R197 (nonce CBOR codec + sidecar load), this round delivers the first user-visible end-to-end runtime → sidecar → LSQ → cardano-cli flow for live consensus state. Restart resilience: nonces and OCert counters now persist across node restarts via nonce_state.cbor + ocert_counters.cbor. Open follow-ups: (1) Phase A.6 — GetGenesisConfig ShelleyGenesis serialiser; (2) Phase A.7 — active stake distribution amounts; (3) Phase A.3 OMap proposals; (4) Phase B — R91 multi-peer livelock; (5) Phase C/D/E — sync perf, deep rollback, mainnet rehearsal. Reference: Ouroboros.Consensus.Protocol.Praos.PraosState; Cardano.Protocol.TPraos.API.ChainDepState. Full operational record in docs/operational-runs/archive/2026-04-30-round-198-nonce-sidecar-persist.md.
  • NonceEvolutionState CBOR codec + sidecar load (Round 197, 2026-04-30 Phase A.2 next) — extends R196’s sidecar plumbing to also load persisted NonceEvolutionState so protocol-state will surface live nonces once sync-side persist lands. Code change: new CborEncode/CborDecode impls for NonceEvolutionState in crates/consensus/src/nonce.rs emitting a 6-element CBOR list [evolving, candidate, epoch, prev_hash, lab, current_epoch] with each Nonce using upstream Cardano.Ledger.Crypto.Nonce wire shape (NeutralNonce → [0], Nonce h → [1, h]). Local helpers encode_nonce/decode_nonce factor per-field encoding. New NONCE_STATE_FILENAME = "nonce_state.cbor" constant + save_nonce_state(dir, encoded) / load_nonce_state(dir) helpers in crates/storage/src/ocert_sidecar.rs mirroring the existing OCert atomic-write contract; re-exported from crates/storage/src/lib.rs. attach_chain_dep_state_from_sidecar in node/src/local_server.rs extended to also call load_nonce_state and map yggdrasil’s 5-nonce NonceEvolutionState into upstream’s 6-nonce ChainDepStateContext (evolving → praosStateEvolvingNonce, candidate → praosStateCandidateNonce, epoch → praosStateEpochNonce, prev_hash → praosStateLastEpochBlockNonce, lab → praosStateLabNonce; previous_epoch_nonce stays Neutral since yggdrasil doesn’t track it distinctly). Both sidecars are independently optional; missing or undecodeable files fall back to neutral defaults gracefully. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query protocol-state --testnet-magic 2 continues to return neutral nonces (regression-free) — nonce_state.cbor doesn’t yet exist in storage_dir because sync-side persist is deferred to a follow-up round. Once that lands at the same call site as the existing OCert sidecar persist, protocol-state will surface live nonces with no further encoder changes. Regression checks pass: gov-state / ratify-state / ledger-peer-snapshot / spo-stake-distribution continue to work. Test count stable at 4744 (R197 is plumbing-only). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R197 closes Phase A.2 next — the read-side sidecar layer is now complete (both OCert counters AND nonces). When sync-side persist is wired in a follow-up round (single helper call after apply_nonce_evolution_to_progress), live nonces flow into protocol-state automatically. Same R196 pattern applied: read first, write later. Open follow-ups: (1) sync-side persist for nonce_state — at sync.rs:~2087 and runtime.rs:~5001/5553, after apply_nonce_evolution_to_progress, encode + call save_nonce_state(dir, &encoded); (2) wire OcertCounters::validate_and_update into verified-sync apply path; (3) Phase A.6 — GetGenesisConfig ShelleyGenesis serialiser; (4) Phase A.7 — active stake distribution amounts; (5) Phase A.3 OMap proposals; (6) Phase B — R91 multi-peer livelock; (7) Phase C/D/E — sync perf, deep rollback, mainnet rehearsal. Reference: Ouroboros.Consensus.Protocol.Praos.PraosState; Cardano.Ledger.Crypto.Nonce. Full operational record in docs/operational-runs/archive/2026-04-30-round-197-nonce-sidecar-codec.md.
  • OCert counter sidecar load (Round 196, 2026-04-30 Phase A.2 partial) — wires the read-side plumbing for live PraosState data so cardano-cli conway query protocol-state will surface real per-pool OpCert counters once the sync apply path populates them. Code change: new attach_chain_dep_state_from_sidecar(snapshot, storage_dir) helper in node/src/local_server.rs calls yggdrasil_storage::load_ocert_counters(dir) to read the persisted ocert_counters.cbor sidecar, decodes via OcertCounters::decode_cbor, translates OcertCounters::iter() entries into ChainDepStateContext::opcert_counters, and calls snapshot.with_chain_dep_state(ctx) to attach. Threaded storage_dir: Option<PathBuf> through acquire_snapshot, run_local_state_query_session, run_local_client_session, run_local_accept_loop. node/src/main.rs now passes Some(storage_dir.clone()) from the loaded node_config. node/tests/local_ntc.rs — both run_local_accept_loop test call sites updated with None storage_dir (in-memory test fixtures don’t have a real directory). Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query protocol-state --testnet-magic 2 returns oCertCounters: {} correctly — the persisted sidecar (/tmp/ygg-r196-preview-db/ocert_counters.cbor, 1 byte = 0xa0 empty CBOR map) round-trips through load → decode → attach → encode. The empty result reflects that yggdrasil’s verified-sync flow doesn’t currently invoke OcertCounters::validate_and_update on inbound blocks — once the sync apply path is wired (separate follow-up), the same plumbing will surface real counters with no further encoder changes. Regression checks: tip / gov-state / ratify-state / ledger-peer-snapshot continue to work. Test count stable at 4744 (R196 is plumbing-only; both local_ntc integration tests updated with None storage_dir). Verification gates: cargo fmt --all -- --check clean (one auto-fmt fix), cargo lint clean (added #[allow(clippy::too_many_arguments)] on run_local_client_session now 9 params), cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R196 closes Phase A.2’s read side. This is the architectural foundation for live nonces too — once nonce_state is persisted to a similar sidecar (Phase A.2 follow-up), the same attach_chain_dep_state_from_sidecar helper can extend to load nonces, and protocol-state will surface live nonces. Open follow-ups: (1) Phase A.2 next — persist NonceEvolutionState to a similar sidecar (nonce_state.cbor); (2) wire OcertCounters::validate_and_update into the verified-sync apply path so the existing sidecar accumulates real counters; (3) Phase A.6 — GetGenesisConfig ShelleyGenesis serialiser; (4) Phase A.7 — active stake distribution amounts; (5) Phase A.3 OMap proposals; (6) Phase B — R91 multi-peer livelock; (7) Phase C/D/E — sync perf, deep rollback, mainnet rehearsal. Reference: Ouroboros.Consensus.Protocol.Praos.PraosState.csCounters; yggdrasil’s OcertCounters in crates/consensus/src/opcert.rs; yggdrasil_storage::{save,load}_ocert_counters in crates/storage/src/ocert_sidecar.rs. Full operational record in docs/operational-runs/archive/2026-04-30-round-196-ocert-sidecar-load.md.
  • Live ledger-peer-snapshot pool list (Round 195, 2026-04-30 Phase A.5) — replaces the empty bigLedgerPools placeholder in cardano-cli conway query ledger-peer-snapshot with live data from yggdrasil’s pool_state. Code change: new encode_ledger_peer_snapshot_v2_for_lsq(snapshot) helper in node/src/local_server.rs emitting the upstream V2 wire shape [1, [WithOrigin SlotNo, indef pools]] where each pool is [AccPoolStake, [PoolStake, NonEmpty Relays]]. Per-pool: AccPoolStake/PoolStake use 0/1 Rational placeholders (live active stake distribution snapshot is Phase A.7 follow-up); NonEmpty Relays is an indef-length CBOR list (cardano-cli’s V2 decoder rejected definite-length at depth 20 — discovery during R195 testing). Per-relay encoding per upstream LedgerRelayAccessPoint: Domain (DNS) [3, 0, port_int, domain_bstr], IPv4 [3, 1, port_int, ipv4_word32], IPv6 [3, 2, port_int, ipv6_bytes]. Yggdrasil’s PoolRelayAccessPoint { address: String, port: u16 } parses via IpAddr::parse to detect IPv4/IPv6; otherwise falls through to Domain. GetLedgerPeerSnapshot dispatcher arm now calls the helper (replacing the inline R189 implementation). Operational verification (preview, YGG_LSQ_ERA_FLOOR=6, chain at slot ~2960): cardano-cli conway query ledger-peer-snapshot --testnet-magic 2 returns full JSON with all three preview-registered pools surfacing their real DNS relay endpoints preview-node.world.dev.cardano.org:30002 — previously the empty [] placeholder was returned. Stake values remain 0 placeholders (Phase A.7 active-stake plumbing). Regression checks: tip / gov-state / ratify-state / spo-stake-distribution / protocol-state continue to work. Test count stable at 4744 (R195 is data-plumbing only). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R195 closes Phase A.5. Combined with R194, three additional LSQ queries now serve user-visible parity (pool hashes, deposits, distributions, peer relays). Open follow-ups: (1) Phase A.6 — GetGenesisConfig ShelleyGenesis serialiser; (2) Phase A.7 — wire active stake distribution into bigLedgerPools AccPoolStake/PoolStake fields and spo-stake-distribution amounts; (3) Phase A.2 deferred — runtime nonce attach via Arc publish channel; (4) Phase A.3 OMap proposals — gov-state proposal entries; (5) Phase B — R91 multi-peer livelock; (6) Phase C/D/E — sync perf, deep rollback, mainnet rehearsal. Reference: Ouroboros.Network.PeerSelection.LedgerPeers.Type.LedgerPeerSnapshotV2; Ouroboros.Network.PeerSelection.RelayAccessPoint.LedgerRelayAccessPoint. Full operational record in docs/operational-runs/archive/2026-04-30-round-195-ledger-peer-pools-live.md.
  • Live DRep / SPO stake distributions + stake-deleg deposits (Round 194, 2026-04-30 Phase A.4) — replaces empty-map placeholders in three LSQ queries with live computed values from yggdrasil’s snapshot. Code change: three new encoder helpers in node/src/local_server.rs — encode_drep_stake_distribution_for_lsq (uses existing LedgerStateSnapshot::query_drep_stake_distribution), encode_spo_stake_distribution_for_lsq (iterates stake_credentials + reward_accounts, sums RewardAccountState::balance per delegated_pool into BTreeMap<[u8;28], u64> for deterministic ordering), encode_stake_deleg_deposits_for_lsq (iterates stake_credentials emitting (credential, deposit) map from StakeCredentialState::deposit). Three dispatcher arms updated: GetDRepStakeDistr (tag 26), GetSPOStakeDistr (tag 30), GetStakeDelegDeposits (tag 22). Operational verification (preview, YGG_LSQ_ERA_FLOOR=6, chain at slot ~3960): cardano-cli conway query spo-stake-distribution --testnet-magic 2 --all-spos returns the JSON list [["38f4a58aaf3fec84f3410520c70ad75321fb651ada7ca026373ce486", 0, null], ["40d806d73c8d2a0c8d9b1e95ccb9f380e40cb4d4b23ff6e403ae1456", 0, null], ["d5cfc42cf67f6b637688d19fa50a4342658f63370b9e2c9e3eaf4dfe", 0, null]] — the three preview-registered pools now surface with their real cold-key hashes (was empty [] before R194). Stake amounts remain 0 because preview’s chain hasn’t begun rewarding stake; once delegations occur the same encoder will surface live amounts. query drep-stake-distribution returns {} correctly (no DRep delegations on preview). Regression checks: gov-state / ratify-state / ledger-peer-snapshot / protocol-state continue to work. Test count stable at 4744 (R194 is data-plumbing only). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R194 closes Phase A.4 of the data-plumbing arc. Three more LSQ queries now serve user-visible parity (real pool hashes, real deposits, real distributions) instead of empty placeholders. Open follow-ups: (1) Phase A.5 — ledger-peer-snapshot pool list from peer governor’s big-ledger ranking; (2) Phase A.6 — GetGenesisConfig ShelleyGenesis serialiser; (3) Phase A.2 deferred — runtime nonce attach via Arc publish channel; (4) Phase A.3 next — gov-state OMap proposals (requires GovActionState shape adaptation); (5) Phase B — R91 multi-peer livelock; (6) Phase C/D/E — sync perf, deep rollback, mainnet rehearsal. Reference: Cardano.Ledger.Conway.LedgerStateQuery.queryDRepStakeDistr/querySPOStakeDistr; Cardano.Ledger.Shelley.LedgerStateQuery.queryStakeDelegDeposits. Full operational record in docs/operational-runs/archive/2026-04-30-round-194-stake-distributions-live.md.
  • Live GovRelation from EnactState (Round 193, 2026-04-30 Phase A.3 first slice) — wires real governance-action lineage IDs from yggdrasil’s EnactState into the gov-state and ratify-state LSQ responses, replacing the static 4-SNothing placeholders for GovRelation StrictMaybe. Code change: new encode_strict_maybe_gov_action_id(enc, Option<&GovActionId>) helper in node/src/local_server.rs emitting upstream Cardano.Ledger.Conway.Governance.GovRelation field shape — SNothing → [] (empty list), SJust id → [id_cbor] (1-element list using GovActionId’s native CborEncode). encode_enact_state_for_lsq field 7 (ensPrevGovActionIds) and encode_conway_gov_state_for_lsq field 1 (cgsProposals’s GovRelation — the first half of the 2-tuple) now both read live values from EnactState’s public fields (prev_pparams_update, prev_hard_fork, prev_committee, prev_constitution — all populated by R67’s enact_gov_action). Why this is non-trivial: the four lineage fields existed and were tracked, but the LSQ encoder had been hardcoded to emit 4 SNothings since R187/R188 because we shipped wire-protocol parity first and live data plumbing second. R193 closes that gap. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query gov-state and query ratify-state continue to decode end-to-end; preview’s chain at slot ~3960 has no governance actions enacted so all four prev-action IDs are still SNothing — but this is now correct live behaviour rather than a placeholder. When governance traffic arrives the same encoders will surface the real lineage automatically. OMap of proposals in cgsProposals remains empty pending a separate slice that adapts yggdrasil’s structurally-reduced GovernanceActionState (4 fields: proposal/votes/proposed_in/expires_after) to upstream’s 7-field GovActionState era wire shape (id/committee_votes/drep_votes/spo_votes/proposal/proposed_in/expires_after). Test count stable at 4744 (R193 is encoder-only, no shape regression test changes). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R193 is the first “live data” slice that delivers user-visible parity (vs R192’s foundation work) — when proposals are enacted, the lineage IDs surface in query gov-state/ratify-state JSON rather than always being null. Open follow-ups: (1) Phase A.2 (deferred) — runtime nonce attach; (2) Phase A.3 next slice — gov-state OMap proposals (requires GovActionState shape adaptation); (3) Phase A.4–A.6 — drep/spo stake, ledger-peer pools, ShelleyGenesis; (4) Phase B — R91 multi-peer livelock; (5) Phase C/D/E — sync perf, deep rollback, mainnet rehearsal. Reference: Cardano.Ledger.Conway.Governance.GovRelation; Cardano.Ledger.Conway.Governance.Internal.EnactState.ensPrevGovActionIds. Full operational record in docs/operational-runs/archive/2026-04-30-round-193-gov-relation-live.md.
  • ChainDepStateContext snapshot infrastructure — Phase A.1 foundation (Round 192, 2026-04-30 data-plumbing arc) — lays the foundation for live PraosState data in cardano-cli conway query protocol-state. Code change: new ChainDepStateContext struct in crates/ledger/src/state.rs mirroring upstream Ouroboros.Consensus.Protocol.Praos.PraosState’s 6 Nonce fields (evolving_nonce, candidate_nonce, epoch_nonce, previous_epoch_nonce, lab_nonce, last_epoch_block_nonce) and BTreeMap<[u8;28], u64> for OCert counters, with Default impl emitting all-neutral nonces + empty counters. New optional chain_dep_state: Option<ChainDepStateContext> field on LedgerStateSnapshot with with_chain_dep_state(ctx) builder + chain_dep_state() accessor; LedgerState::snapshot() defaults the field to None (the runtime opts in after construction). ChainDepStateContext re-exported from crates/ledger/src/lib.rs crate root. encode_praos_state_versioned in node/src/local_server.rs now branches on snapshot.chain_dep_state() presence: when Some(ctx), emits live OCert counters map + 6 nonces using upstream Cardano.Ledger.Crypto.Nonce wire encoding (Nonce::Neutral → [0], Nonce::Hash(h) → [1, h]); when None, falls back to the R190 neutral placeholder behavior. Why this design: crates/ledger is below crates/consensus in the dependency graph, so it cannot import NonceEvolutionState/OcertCounters directly. The mirror struct lives in ledger so LedgerStateSnapshot carries it natively; the consensus runtime translates from its native types into this snapshot mirror at attach time. The Option wrapper keeps the change backward-compatible. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query protocol-state --testnet-magic 2 returns the same neutral-fallback JSON as R191 (confirms regression-free path); once the runtime starts attaching populated context in R193+, the same query will surface live nonces + OCert counters with no further encoder changes. Regression checks pass: gov-state / ratify-state / ledger-peer-snapshot continue to work. Test count stable at 4744 (R192 is infrastructure-only; subsequent rounds will add population/regression tests). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R192 is the Phase A.1 foundation of the documented full-parity-completion plan in /home/vscode/.claude/plans/clever-shimmying-quokka.md — establishes the snapshot extension contract so subsequent rounds can plumb live data (nonces + ocert counters in R193, gov proposals in R194, drep/spo stake in R195, ledger-peer pools in R196, ShelleyGenesis in R197) without further snapshot-shape churn. Open follow-ups: (1) Phase A.2 — runtime attach: thread Arc<RwLock<NonceEvolutionState>> + Arc<RwLock<OcertCounters>> from sync.rs/runtime.rs through to the LSQ dispatcher path, translate into ChainDepStateContext, call snapshot.with_chain_dep_state(ctx); (2) Phase A.3+ — the per-encoder live-data slices outlined in the plan; (3) Phase B — R91 multi-peer dispatch storage livelock; (4) Phase C/D/E — sync perf, deep rollback, mainnet rehearsal. Reference: Ouroboros.Consensus.Protocol.Praos.PraosState; Cardano.Ledger.Crypto.Nonce. Full operational record in docs/operational-runs/archive/2026-04-30-round-192-chain-dep-state-context.md.
  • Live tip-slot plumbing into protocol-state + ledger-peer-snapshot (Round 191, 2026-04-30 data-plumbing arc) — begins the post-audit data-plumbing work: replaces static Origin ([0] CBOR singleton) for praosStateLastSlot (R190 PraosState helper) and ledger-peer-snapshot’s V2 WithOrigin SlotNo field (R189 dispatcher) with live LedgerStateSnapshot::tip().slot(). Code change: encode_praos_state_versioned in node/src/local_server.rs now takes &LedgerStateSnapshot and emits praosStateLastSlot from the snapshot’s tip — Some(slot) → [1, slot] (At slot), None → [0] (Origin only at pre-genesis). GetLedgerPeerSnapshot dispatcher arm’s WithOrigin SlotNo field updated identically. Both call sites in dispatch_upstream_query and dispatch_inner_era_query updated. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6, chain at slot 3960): cardano-cli conway query protocol-state --testnet-magic 2 now returns "lastSlot": 3960 (was "lastSlot": "origin"); cardano-cli conway query ledger-peer-snapshot --testnet-magic 2 returns "slotNo": 3960 (was "slotNo": "origin"). Both fields advance naturally with the chain. Regression checks pass: tip / gov-state / ratify-state continue to work. Test count stable at 4744 (R191 is encoder-only, no test changes). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R191 is the first slice of the post-R190 data-plumbing arc — the wire-protocol surface is now complete; remaining work is replacing the empty/origin/neutral placeholders with live runtime values. The next plumbing slices (PraosState OCert counters + 6 nonces, gov-state proposals, drep stake, spo stake) require either threading NonceEvolutionState/OcertCounters from the consensus runtime into LedgerStateSnapshot, or building a separate ChainDepStateContext that the dispatcher receives alongside the ledger snapshot. Open follow-ups: (1) live nonces + ocert counters in protocol-state — substantial plumbing; (2) gov-state proposals / ratify-state enacted / drep+spo stake distribution / ledger-peer-snapshot pool list — each requires the runtime to track them and expose via snapshot; (3) GetGenesisConfig ShelleyGenesis serialisation (R163); (4) apply-batch duration histogram (R169); (5) multi-session peer accounting (R168 structural); (6) pipelined fetch + apply (R166); (7) deep cross-epoch rollback recovery (R167). Reference: Ouroboros.Consensus.Protocol.Praos.PraosState.praosStateLastSlot (WithOrigin SlotNo); Ouroboros.Network.PeerSelection.LedgerPeers.Type.encodeLedgerPeerSnapshot (V2 WithOrigin SlotNo field). Full operational record in docs/operational-runs/archive/2026-04-30-round-191-live-tip-slot-plumbing.md.
  • Comprehensive cardano-cli parity audit + tag 12/13 dispatchers (Round 190, 2026-04-30 audit + fixes) — systematic end-to-end audit of EVERY cardano-cli conway query subcommand against yggdrasil to verify the Conway-era LSQ parity arc is genuinely complete. Audit method: started yggdrasil-node on preview with YGG_LSQ_ERA_FLOOR=6; ran every subcommand listed by cardano-cli conway query --help; categorised results into working / decode-failing / cli-arg-failing; for decode failures, captured wire bytes via instrumented decode_query_if_current (YGG_NTC_DEBUG=1); looked up upstream wire shapes via WebFetch and added missing dispatchers. Audit findings: 28 cardano-cli subcommands confirmed working end-to-end (always-available queries + era-gated queries + 12 Conway-governance + 2 operational R190 additions). Two genuine gaps surfaced: (1) cardano-cli conway query protocol-state failed with DeserialiseFailure 0 "expected list len" because yggdrasil returned null from the Unknown fall-through; (2) cardano-cli conway query ledger-state showed f6 # null (acceptable for the permissive ledger-state decoder but not explicitly recognised). Three subcommands initially flagged as “failing” turned out to be client-side CLI arg validation issues, not yggdrasil bugs: kes-period-info needed valid --op-cert-file, leadership-schedule needed --genesis FILEPATH + --stake-pool-verification-key, and stake-address-info needed a Bech32-valid stake address (the test address used initially had wrong format; works fine with cardano-cli conway stake-address build-generated address — returns [] for unregistered addresses). Code change: new EraSpecificQuery::DebugNewEpochState (tag 12 singleton) and EraSpecificQuery::DebugChainDepState (tag 13 singleton) variants in crates/network/src/protocols/local_state_query_upstream.rs with decoder branches (1, 12) and (1, 13). New encode_praos_state_versioned() helper in node/src/local_server.rs emitting the upstream Versioned 0-wrapped 8-element PraosState placeholder per Ouroboros.Consensus.Protocol.Praos.PraosState: [2-elem outer [version=0, [8-elem [Origin=[0], empty Map=0xa0, NeutralNonce=[0]×6]]]]. Two new dispatcher arms (DebugNewEpochState emits CBOR null — accepted by cardano-cli’s permissive query ledger-state decoder; DebugChainDepState emits the Versioned PraosState). Extended dispatch_inner_era_query to handle both new variants when wrapped via GetCBOR (cardano-cli sends protocol-state via tag 9 → 13 wrapping in the v15+ path). Discovery — Versioned wrapper: initial bare 8-element PraosState emission triggered DeserialiseFailure 1 "Size mismatch when decoding Versioned. Expected 2, but found 8.". The wire shape is actually [version_uint, [8-element PraosState]] per upstream’s Versioned newtype encoding. Switched to the 2-element outer form and the response decoded. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query protocol-state --testnet-magic 2 returns {"candidateNonce": null, "epochNonce": null, "evolvingNonce": null, "labNonce": null, "lastEpochBlockNonce": null, "lastSlot": "origin", "oCertCounters": {}}; query ledger-state shows f6 # null (cardano-cli treats this as valid permissive output); query stake-address-info --address <generated stake address> returns []; default-era flow (no era floor) regression-checked: query tip reports era: Alonzo, protocol-parameters / utxo --whole-utxo / era-history all continue to work. Test count stable at 4744 (R190 is encoder-only; the wire forms [1, [12]] and [1, [13]] were already covered by the existing decoder fall-through behavior). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Coverage achievement: the comprehensive audit confirms the Conway-era LSQ wire-protocol gap is fully closed — every documented LSQ tag has a wire-correct dispatcher in yggdrasil; every cardano-cli conway query subcommand decodes end-to-end (given correct CLI inputs). Remaining open items shift entirely to data plumbing (live values for the empty placeholders) and unrelated operational improvements. Open follow-ups: (1) live data plumbing — populate gov-state proposals / ratify-state enacted / drep stake distribution / spo stake distribution / ledger-peer-snapshot pool list / protocol-state OCert counters + nonces from yggdrasil’s runtime as it tracks them; (2) GetGenesisConfig ShelleyGenesis serialisation (R163); (3) apply-batch duration histogram (R169); (4) multi-session peer accounting (R168 structural); (5) pipelined fetch + apply (R166); (6) deep cross-epoch rollback recovery (R167). Reference: Ouroboros.Consensus.Shelley.Ledger.Query.DebugNewEpochState (tag 12, returns NewEpochState era); Ouroboros.Consensus.Shelley.Ledger.Query.DebugChainDepState (tag 13, returns ChainDepState proto); Ouroboros.Consensus.Protocol.Praos.PraosState (8-element record); Versioned newtype ([version_uint, payload] 2-tuple wrapper). Full operational record in docs/operational-runs/archive/2026-04-30-round-190-comprehensive-audit.md.
  • Conway ledger-peer-snapshot (tag 34) end-to-end — closes the Conway-era LSQ wire-protocol gap entirely (Round 189, 2026-04-30 Conway-era series) — closes the last documented Conway-era LSQ tag so every cardano-cli conway query subcommand decodes end-to-end against yggdrasil with YGG_LSQ_ERA_FLOOR=6. Code change: new EraSpecificQuery::GetLedgerPeerSnapshot { peer_kind: Option<u8> } variant in crates/network/src/protocols/local_state_query_upstream.rs covering both v15+ form [34, peer_kind] (with peer_kind = 0 = BigLedgerPeers or 1 = AllLedgerPeers) and the legacy singleton [34] form; decoder branches (1, 34) (legacy → peer_kind: None) and (2, 34) (v15+, re-decodes the inner cbor to extract the peer_kind byte after the tag); regression test decode_recognises_ledger_peer_snapshot_tag_34 covering both wire forms. Dispatcher arm in node/src/local_server.rs emits the V2 form (discriminator 1) regardless of requested peer_kind: [1, [<WithOrigin SlotNo Origin = [0]>, <pools = 0x9f 0xff>]] per upstream Ouroboros.Network.PeerSelection.LedgerPeers.Type.encodeLedgerPeerSnapshot (LedgerPeerSnapshotV2 (wOrigin, pools)). Discovery — V23 forms rejected by cardano-cli 10.16: initial implementation emitted V23 forms (discriminator 2 for BigLedgerPeers, 3 for AllLedgerPeers); cardano-cli rejected with DeserialiseFailure 5 "LedgerPeers.Type: no decoder could be found for version 3" even when it had requested AllLedgerPeers (peer_kind=1) — its decoder at the negotiated NtC version doesn’t yet support the V23 forms. Switched to V2 form (discriminator 1) which is the legacy-but-still-supported shape (the SRV-related distinctions don’t affect the empty-pool case). Discovery — pool list requires indef-length: a second decoder failure surfaced DeserialiseFailure 8 "expected list start" when emitting the pool list as a definite-length empty list 0x80; upstream’s toCBOR @[a] for the pool list specifically uses indefinite-length encoding (0x9f start ... 0xff break) per encodeListLenIndef. Switched the empty pool list to indef-length 0x9f 0xff and the response decoded. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6, chain at slot ~8960): cardano-cli conway query ledger-peer-snapshot --testnet-magic 2 returns {"bigLedgerPools": [], "slotNo": "origin", "version": 2} end-to-end. Regression checks pass: tip / gov-state / ratify-state / constitution / future-pparams / spo-stake-distribution all continue to work. Test count progression: 4743 → 4744 (one new regression test pinning both the v15+ and legacy wire forms). Verification gates: cargo fmt --all -- --check clean (one auto-fmt of the test layout), cargo lint clean, cargo test-all 4744 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Coverage achievement: every documented Conway-era LSQ query tag (16, 19, 20, 22, 23–37) now has a wire-correct dispatcher in yggdrasil — the Conway-era LSQ wire-protocol parity arc started in R163 (era-specific dispatcher infrastructure) and continued through R179 (era blockage end-to-end fix), R180–R188 (governance dispatcher series), and R189 (last open dispatcher) is fully complete. Open follow-ups (now data-plumbing rather than wire-shape parity): (1) live data plumbing — current placeholders return empty data for gov-state proposals, ratify-state enacted, drep stake distribution, ledger-peer-snapshot pool list, etc. Populating these is the natural follow-on as yggdrasil’s runtime tracks them in the snapshot; (2) GetGenesisConfig ShelleyGenesis serialisation (R163); (3) apply-batch duration histogram (R169); (4) multi-session peer accounting (R168 structural); (5) pipelined fetch + apply (R166); (6) deep cross-epoch rollback recovery (R167). Reference: Ouroboros.Network.PeerSelection.LedgerPeers.Type.LedgerPeerSnapshot (3 constructors); encodeLedgerPeerSnapshot (V2 case for legacy clients); decodeLedgerPeerSnapshot (case-matches on (ledgerPeerKind, version) — cardano-cli 10.16 only recognises version 1 in the V2 case at the negotiated NtC version). Full operational record in docs/operational-runs/archive/2026-04-30-round-189-ledger-peer-snapshot.md.
  • Conway gov-state body shape (tag 24) end-to-end — closes last user-facing Conway gap (Round 188, 2026-04-30 Conway-governance series) — closes the longest-standing item on the Conway-era follow-up list (open since R180’s dispatcher route): cardano-cli conway query gov-state now decodes end-to-end with full upstream-faithful 7-element ConwayGovState body shape, rendering real Conway constitution + Conway 31-element PParams. Code change: replaced R180’s placeholder dispatcher arm (which emitted a flat CBOR map of governance actions and was rejected by cardano-cli at depth 3) with a call to the new encode_conway_gov_state_for_lsq(snapshot) helper in node/src/local_server.rs. The helper emits the 7-element ConwayGovState per Cardano.Ledger.Conway.Governance.ConwayGovState: (1) cgsProposals 2-tuple (GovRelation StrictMaybe = 4-SNothing list, OMap GovActionId GovActionState = empty list per upstream's encodeStrictSeq encoding NOT empty map); (2) cgsCommittee = SNothing = []; (3) cgsConstitution from snapshot; (4) cgsCurPParams Conway 31-element via R161; (5) cgsPrevPParams same as cur; (6) cgsFuturePParams internal Sum ADT NoPParamsUpdate = [0] (1-elem list with just the variant tag — distinct from R183’s wire-facing Maybe (PParams era) = Nothing = []); (7) cgsDRepPulsingState = DRComplete encoded as bare 2-element [PulsingSnapshot, RatifyState] (no discriminator), where PulsingSnapshot empty = 4-element [empty StrictSeq, empty Map, empty Map, empty Map] and RatifyState reuses R187’s encode_ratify_state_for_lsq. Subtle wire-shape distinction documented: FuturePParams denotes two different types upstream — the internal ADT (Cardano.Ledger.Core.PParams.FuturePParams, Sum NoPParamsUpdate=0/DefinitePParamsUpdate=1/PotentialPParamsUpdate=2) used inside ConwayGovState, vs the LSQ-facing Maybe (PParams era) returned by tag-33 GetFuturePParams (R183). Same name, different wire shapes ([0] vs [] for the no-update placeholder). R188 implements the internal ADT; R183 implemented the wire-facing Maybe. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6, chain at slot ~2960): cardano-cli conway query gov-state --testnet-magic 2 returns full JSON with committee: null, real Conway constitution (anchor URL ipfs://bafkreifnwj6zpu3ixa4siz2lndqybyc5wnnt3jkwyutci4e2tmbnj3xrdm, guardrails script hash fa24fb305126805cf2164c161d852a0e7330cf988f1fe558cf7d4a64), full Conway 31-element currentPParams (collateralPercentage 150, dRepActivity 20, dRepDeposit 500_000_000, all governance thresholds), and proposals: []. Regression checks pass: tip / ratify-state / constitution / committee-state / future-pparams / proposals all continue to work. Cumulative coverage achievement: every cardano-cli conway query subcommand other than the operational ledger-peer-snapshot (tag 34, peer-discovery query) now decodes end-to-end against yggdrasil — completes the Conway-era LSQ user-facing parity arc started in R180. Test count unchanged at 4743 (R188 is encoder-only; the gov-state wire form was already pinned by R180’s decode_recognises_conway_governance_tags test). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4743 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Open follow-ups: (1) ledger-peer-snapshot (tag 34) body shape — operational, last open Conway-era LSQ dispatcher; (2) live data plumbing — current placeholders return empty data, populating gov-state proposals / ratify-state enacted / drep stake / etc. is the natural follow-on once yggdrasil’s runtime tracks them in the snapshot; (3)–(7) carry-overs from R163/R166/R167/R168/R169/R173. Reference: Cardano.Ledger.Conway.Governance.ConwayGovState (7-element record); Cardano.Ledger.Conway.Governance.Proposals (2-tuple (GovRelation StrictMaybe, OMap GovActionId GovActionState)); Cardano.Ledger.Conway.Governance.DRepPulser.PulsingSnapshot (4-element record); Cardano.Ledger.Conway.Governance.DRepPulser.DRepPulsingState (DRComplete = bare 2-elem); Cardano.Ledger.Core.PParams.FuturePParams (internal Sum ADT, distinct from LSQ-facing Maybe). Full operational record in docs/operational-runs/archive/2026-04-30-round-188-gov-state.md.
  • Conway ratify-state body shape (tag 32) end-to-end (Round 187, 2026-04-30 Conway-governance series) — closes the substantial 4-field-record body-shape gap so cardano-cli conway query ratify-state decodes the full RatifyState era with real Conway constitution + 31-element PParams + treasury rendered. Code change: new singleton EraSpecificQuery::GetRatifyState variant in crates/network/src/protocols/local_state_query_upstream.rs with (1, 32) decoder branch and decode_recognises_ratify_state_tag_32 regression test. Two new helpers in node/src/local_server.rs: encode_enact_state_for_lsq(snapshot) emits the upstream 7-element EnactState CBOR list per Cardano.Ledger.Conway.Governance.Internal.EnactState ([ensCommittee SNothing, real Conway Constitution from snapshot, Conway 31-element PParams (cur), same Conway PParams (prev — until separate prev-epoch tracker is plumbed), real treasury from accounting(), empty Map (withdrawals applied at enactment time so empty between epochs), GovRelation StrictMaybe = 4-SNothing list]); encode_ratify_state_for_lsq(snapshot) wraps it in the 4-element RatifyState record [EnactState, empty Seq, empty Set, Bool=false]. New dispatcher arm for GetRatifyState calling the helper. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6, chain at slot ~2960): cardano-cli conway query ratify-state --testnet-magic 2 returns full JSON with enactedGovActions: [], expiredGovActions: [], ratificationDelayed: false, and nextEnactState containing real Conway constitution (with anchor URL ipfs://bafkreifnwj6zpu3ixa4siz2lndqybyc5wnnt3jkwyutci4e2tmbnj3xrdm and guardrails script hash fa24fb305126805cf2164c161d852a0e7330cf988f1fe558cf7d4a64), committee: null, and full Conway 31-element curPParams (collateralPercentage 150, dRepActivity 20, dRepDeposit 500_000_000, all governance thresholds, etc.). Regression checks pass: tip / constitution / treasury / future-pparams / proposals / spo-stake-distribution all continue to work. Test count progression: 4742 → 4743. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4743 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Strategic significance: R187’s EnactState encoder is the load-bearing helper for the remaining Conway governance work — gov-state (tag 24) field 7 (DRepPulsingState) is encoded as [PulsingSnapshot, RatifyState], so R187’s RatifyState helper directly composes into gov-state. After R187, the gov-state delta reduces to: (a) Proposals era 2-tuple (GovRelation StrictMaybe, OMap GovActionId GovActionState) — small encoder; (b) FuturePParams era ADT (the internal Sum form, distinct from R183’s wire-facing Maybe shape — note that [0] = NoPParamsUpdate, [1, pp] = DefinitePParamsUpdate, [2, pp] = PotentialPParamsUpdate); (c) PulsingSnapshot empty stub (small). Open follow-ups: (1) gov-state body shape — composes R187’s helpers with new Proposals/FuturePParams/PulsingSnapshot encoders; (2) ledger-peer-snapshot (tag 34) body shape — operational, lower priority; (3) live stake-distribution plumbing (R163/R173/R184 follow-up); (4)–(8) carry-overs from R163/R166/R167/R168/R169/R173. Reference: Cardano.Ledger.Conway.Governance.Internal.EnactState (7-element record); Cardano.Ledger.Conway.Governance.Internal.RatifyState (4-element record); Cardano.Ledger.Conway.LedgerStateQuery.GetRatifyState. Full operational record in docs/operational-runs/archive/2026-04-30-round-187-ratify-state.md.
  • Conway tail-end LSQ dispatchers — GetStakeDelegDeposits (tag 22) + GetPoolDistr2 (tag 36) (Round 186, 2026-04-30 Conway-governance series) — closes the simpler remaining Conway-era LSQ dispatcher gaps so the codec layer recognises every documented Conway era-specific query tag. Code change: two new EraSpecificQuery variants in crates/network/src/protocols/local_state_query_upstream.rs — GetStakeDelegDeposits { stake_cred_set_cbor } (tag 22, returns Map (Credential 'Staking) Coin) and GetPoolDistr2 { maybe_pool_hash_set_cbor } (tag 36, returns PoolDistr 2-element record [map, NonZero Coin] — same shape as GetStakeDistribution2 (tag 37, R179) but with an optional pool-id filter); decoder branches (2, 22) and (2, 36); two dispatcher arms in node/src/local_server.rs — GetStakeDelegDeposits emits empty CBOR map (0xa0), GetPoolDistr2 emits [map, 1] (empty individual-stake map + 1-lovelace pdTotalStake placeholder to satisfy the NonZero Coin requirement). Filter parameters carried for protocol compatibility but not applied. Operational note: tags 22 and 36 don’t have direct cardano-cli conway query subcommands — they’re invoked internally by other queries or by external LSQ-protocol tooling. The dispatchers are added as part of the Conway-era completeness arc so any client sending these queries gets a wire-valid response (empty placeholder) instead of fall-through null from Unknown. One new regression test: decode_recognises_stake_deleg_deposits_and_pool_distr2_tags covering wire forms [1, [22, set]] and [1, [36, []]] (the latter is Maybe Nothing). Test count progression: 4741 → 4742. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4742 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Updated Conway-era query coverage: of the 16 Conway-era query tags (16, 19, 20, 22-37 with 21/34 wire-known but body open), 14 are wire-correct and end-to-end-tested through cardano-cli; only gov-state (tag 24, substantial 7-element ConwayGovState record per upstream [Proposals 2-tuple, StrictMaybe Committee, Constitution, current PParams, previous PParams, FuturePParams ADT, DRepPulsingState 2-element]) and ratify-state (tag 32, 4-field record [EnactState era, Seq GovActionState, Set GovActionId, Bool]) remain as substantial body-shape gaps. ledger-peer-snapshot (tag 34) is also open but operational rather than governance-facing. Open follow-ups: (1) gov-state body shape — substantial; tackle as dedicated round once nested encoders (Proposals, GovRelation, DRepPulsingState, PulsingSnapshot, RatifyState, EnactState) are mapped to upstream wire shapes; (2) ratify-state body shape — shares EnactState encoder with gov-state; (3) tag 34 GetLedgerPeerSnapshot' body shape — operational query, lower priority for cli parity but useful for downstream peer-discovery tooling; (4) live stake-distribution plumbing (R163/R173/R184 follow-up); (5)–(9) carry-overs from R163/R166/R167/R168/R169/R173. Reference: Cardano.Ledger.Conway.LedgerStateQuery.GetStakeDelegDeposits (Set (Credential 'Staking) → Map (Credential 'Staking) Coin); Cardano.Ledger.Conway.LedgerStateQuery.GetPoolDistr2 (Maybe (Set PoolKeyHash) → PoolDistr); Cardano.Ledger.Core.PoolDistr (2-tuple of [Map PoolKeyHash IndividualPoolStake, NonZero Coin pdTotalStake]). Full operational record in docs/operational-runs/archive/2026-04-30-round-186-stake-deleg-deposits-pool-distr2.md.
  • Conway proposals + stake-pool-default-vote LSQ dispatchers (Round 185, 2026-04-30 Conway-governance series) — adds cardano-cli conway query proposals --all-proposals and query stake-pool-default-vote --spo-key-hash <hash> end-to-end against yggdrasil. Code change: two new EraSpecificQuery variants in crates/network/src/protocols/local_state_query_upstream.rs — GetProposals { gov_action_id_set_cbor } (tag 31, returns Seq (GovActionState era) per upstream Cardano.Ledger.Conway.LedgerStateQuery.GetProposals) and QueryStakePoolDefaultVote { pool_key_hash_cbor } (tag 35, returns DefaultVote = DefaultNo (0) | DefaultAbstain (1) | DefaultNoConfidence (2) encoded as a single CBOR uint per upstream Cardano.Ledger.Conway.Governance.DefaultVote); decoder branches (2, 31) and (2, 35); two dispatcher arms in node/src/local_server.rs — GetProposals emits empty CBOR list 0x80 (no pending proposals on a fresh-sync chain), QueryStakePoolDefaultVote emits DefaultNo (0) as a single CBOR uint placeholder. Filter parameters carried for protocol compatibility but not applied — cardano-cli filters/contextualises client-side. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6, chain at slot ~7K, era=Conway): cardano-cli conway query proposals --testnet-magic 2 --all-proposals returns [] end-to-end; cardano-cli conway query stake-pool-default-vote --testnet-magic 2 --spo-key-hash <56-hex> returns "DefaultNo" end-to-end (correct placeholder for un-registered SPOs). Regression checks pass: query tip reports era: Conway, slot: 6960, block: 6960; constitution returns real Conway data; drep-stake-distribution / spo-stake-distribution return {} / []; treasury returns 0; committee-state returns {committee: {}, ...}; future-pparams renders the human-readable “No protocol parameter changes” message. One new regression test: decode_recognises_proposals_and_default_vote_tags covering the wire forms [1, [31, set]] and [1, [35, bytes(28)]]. Test count progression: 4740 → 4741. Verification gates: cargo fmt --all -- --check clean (one auto-fmt of the rust 2-line struct pattern), cargo lint clean, cargo test-all 4741 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Updated Conway-era query end-to-end coverage: constitution ✓, drep-state ✓, drep-stake-distribution ✓, treasury ✓, committee-state ✓, filtered-vote-delegatees ✓ (internal), spo-stake-distribution ✓, proposals ✓, future-pparams ✓, stake-pool-default-vote ✓, stake-pools ✓, stake-distribution ✓, pool-state ✓, stake-snapshot ✓ — open shape gaps now reduced to gov-state (tag 24, substantial 7-element ConwayGovState) and ratify-state (tag 32, 4-field record including EnactState). Open follow-ups: (1) gov-state body shape; (2) ratify-state body shape — needs upstream-faithful EnactState encoder + 4-field [EnactState, Seq, Set, Bool] wrapping; (3) tag 36 GetPoolDistr2, 22 GetStakeDelegDeposits — additional Conway-era dispatchers; (4) live stake-distribution plumbing (R163/R173/R184 follow-up); (5)–(8) carry-overs from R163/R166/R167/R168/R169/R173. Reference: Cardano.Ledger.Conway.LedgerStateQuery.GetProposals (Set GovActionId → Seq (GovActionState era)); Cardano.Ledger.Conway.LedgerStateQuery.QueryStakePoolDefaultVote; Cardano.Ledger.Conway.Governance.DefaultVote (3-variant enum encoded as Word8). Full operational record in docs/operational-runs/archive/2026-04-30-round-185-proposals-default-vote.md.
  • Conway DRep / SPO stake-distribution + filtered-vote-delegatees LSQ dispatchers (Round 184, 2026-04-30 Conway-governance series) — adds cardano-cli conway query drep-stake-distribution --all-dreps and query spo-stake-distribution --all-spos end-to-end against yggdrasil; continues the Conway-governance dispatcher series after R180/R181/R182/R183 (constitution, drep-state Map shape, treasury, committee-state, future-pparams). Code change: three new EraSpecificQuery variants in crates/network/src/protocols/local_state_query_upstream.rs — GetDRepStakeDistr { drep_set_cbor } (tag 26), GetFilteredVoteDelegatees { stake_cred_set_cbor } (tag 28), GetSPOStakeDistr { spo_set_cbor } (tag 30); decoder branches (2, 26), (2, 28), (2, 30); three dispatcher arms in node/src/local_server.rs each emitting empty CBOR map (0xa0) — yggdrasil doesn’t yet track per-DRep/per-SPO active stake or per-credential vote delegations, so empty is the correct response on a fresh-sync chain. Filter parameters carried for protocol compatibility but not applied — cardano-cli filters client-side. Discovery — SPO query is a 3-call flow: initial implementation added only tags 26 and 30; DRep query worked end-to-end but SPO query failed with DeserialiseFailure 2 "expected list len". Wire-debug capture (temporarily-instrumented decode_query_if_current with YGG_NTC_DEBUG=1 env-var) revealed cardano-cli conway query spo-stake-distribution --all-spos sends THREE sequential queries: (1) tag 30 GetSPOStakeDistr → Map (KeyHash 'StakePool) Coin; (2) tag 9 GetCBOR wrapping tag 19 GetPoolState (to fetch pool registration data for the SPO set); (3) tag 28 GetFilteredVoteDelegatees → Map (Credential 'Staking) DRep (to look up vote delegations for the pools’ reward credentials, used to render the JSON’s voteDelegation field). The SPO response itself was correct (bare 0xa0 decoded fine through cardano-cli) — the failure was from call (3), which fell through to the dispatcher’s Unknown arm and returned null, which cardano-cli rejected. Adding tag 28 closed the flow end-to-end. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query drep-stake-distribution --testnet-magic 2 --all-dreps returns {} end-to-end; cardano-cli conway query spo-stake-distribution --testnet-magic 2 --all-spos returns [] end-to-end (chain at slot ~2K, era=Conway, no DReps/SPOs yet). Regression checks pass: query tip reports era: Conway, slot: 1960; constitution returns real Conway data; committee-state returns {committee: {}, epoch: 0, threshold: null}; future-pparams returns Maybe Nothing rendered as the human-readable “No protocol parameter changes” message. One regression test extension: decode_recognises_drep_and_spo_stake_distr_tags in local_state_query_upstream.rs::tests now covers all three new tags (26, 28, 30) in one parameterised test rather than three separate cases. Test count: 4739 → 4740 (one new variant added through the extension; not a separate test function). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4740 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Updated Conway-era query end-to-end coverage: constitution ✓, drep-state ✓, drep-stake-distribution ✓, treasury ✓, committee-state ✓, filtered-vote-delegatees ✓ (internal), spo-stake-distribution ✓, future-pparams ✓, stake-pools ✓, stake-distribution ✓, pool-state ✓, stake-snapshot ✓ — only gov-state remains (substantial 7-element ConwayGovState record with Proposals tree + DRepPulsingState cache). Open follow-ups: (1) gov-state body shape; (2) tag 31 GetProposals, 32 GetRatifyState, 35 QueryStakePoolDefaultVote, 36 GetPoolDistr2 — remaining Conway-era dispatchers; (3) live stake-distribution plumbing (R163/R173 follow-up) to replace the empty placeholders with real per-pool/per-DRep stake; (4)–(8) carry-overs from R163/R166/R167/R168/R169/R173. Reference: Cardano.Ledger.Conway.LedgerStateQuery.GetDRepStakeDistr (Map DRep Coin); Cardano.Ledger.Conway.LedgerStateQuery.GetFilteredVoteDelegatees (type VoteDelegatees = Map (Credential 'Staking) DRep); Cardano.Ledger.Conway.LedgerStateQuery.GetSPOStakeDistr (Map (KeyHash 'StakePool) Coin). Full operational record in docs/operational-runs/archive/2026-04-30-round-184-drep-spo-stake-distr.md.
  • Conway future-pparams LSQ dispatcher tag 33 (Round 183, 2026-04-30 Conway-governance series) — adds GetFuturePParams (tag 33) so cardano-cli conway query future-pparams decodes end-to-end against yggdrasil; continues the Conway-governance dispatcher series after R180/R181/R182 (constitution, drep-state, treasury, committee-state). Code change: new EraSpecificQuery::GetFuturePParams variant (singleton query, no parameters) in crates/network/src/protocols/local_state_query_upstream.rs; decode_query_if_current recognises (1, 33) (singleton wire form [1, [33]] = 0x82 0x01 0x81 0x18 0x21); new dispatcher arm in node/src/local_server.rs emits the response as Maybe (PParams era) = Nothing (empty CBOR list 0x80) per upstream Cardano.Ledger.Conway.LedgerStateQuery.GetFuturePParams — without a queued PParams update ready for next-epoch adoption, yggdrasil emits Nothing and cardano-cli renders this as "No protocol parameter changes will be enacted at the next epoch boundary.". Initial misstep + correction: round started by emitting the FuturePParams era ADT shape (Sum NoPParamsUpdate 0 = [0] = 0x81 0x00) per upstream Cardano.Ledger.Core.PParams.FuturePParams; cardano-cli rejected with DeserialiseFailure 4 "expected list len or indef" — the underlying BlockQuery result type for GetFuturePParams is actually Maybe (PParams era) (the LSQ-facing wrapper), not the FuturePParams ADT directly; switched to the Maybe shape and the response decoded end-to-end. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query future-pparams --testnet-magic 2 returns "No protocol parameter changes will be enacted at the next epoch boundary." end-to-end (correct empty state for preview’s chain at slot ~5K with no queued PParams update). Regression checks pass: constitution returns real Conway data, drep-state returns [], treasury returns 0, committee-state returns {"committee": {}, "epoch": 0, "threshold": null}. One new regression test: decode_recognises_future_pparams_tag_33 covering the singleton wire form 0x82 0x01 0x81 0x18 0x21. Test count progression: 4738 → 4739. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4739 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Updated Conway-era query end-to-end coverage: constitution ✓, drep-state ✓, treasury ✓, committee-state ✓, future-pparams ✓, stake-pools ✓, stake-distribution ✓, pool-state ✓, stake-snapshot ✓ — every commonly-used cardano-cli conway query subcommand except gov-state now decodes end-to-end against yggdrasil. Open follow-ups: (1) gov-state body shape (substantial — 7-element ConwayGovState record with Proposals tree + DRepPulsingState cache); (2) tag 26 GetDRepStakeDistr, 30 GetSPOStakeDistr, 31 GetProposals, 32 GetRatifyState, 35 QueryStakePoolDefaultVote — additional Conway-era dispatchers for completeness; (3)–(8) carry-overs from R163/R166/R167/R168/R169/R173. Reference: Cardano.Ledger.Conway.LedgerStateQuery.GetFuturePParams (returns Maybe (PParams era) — the LSQ-facing wrapper, distinct from the internal FuturePParams ADT in Cardano.Ledger.Core.PParams). Full operational record in docs/operational-runs/archive/2026-04-30-round-183-future-pparams.md.
  • Conway committee-state LSQ dispatcher tag 27 (Round 182, 2026-04-30 Conway-governance series) — adds GetCommitteeMembersState (tag 27) so cardano-cli conway query committee-state decodes end-to-end against yggdrasil; builds on R180/R181’s constitution/drep-state/treasury/account-state dispatchers. Code change: new EraSpecificQuery::GetCommitteeMembersState { cold_creds_cbor, hot_creds_cbor, statuses_cbor } variant in crates/network/src/protocols/local_state_query_upstream.rs carrying three filter-set parameters; decode_query_if_current recognises (4, 27) and slices the three filter-set CBOR items separately (query wire form is [27, cold_set, hot_set, status_set] = 4-element list including the tag); new helper encode_committee_members_state_for_lsq(snapshot) in node/src/local_server.rs emits the upstream 3-element CommitteeMembersState record [csCommittee_map, csThreshold, csEpochNo] with threshold as StrictMaybe Nothing (0x80 = zero-element list — yggdrasil’s CommitteeState doesn’t track the threshold separately) and epoch from snapshot’s current_epoch. Filter-set parameters carried for protocol compatibility but not applied — cardano-cli filters client-side. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query committee-state --testnet-magic 2 returns {"committee": {}, "epoch": 0, "threshold": null} end-to-end (correct empty state for preview’s chain at slot ~5K with no committee yet established). Regression checks pass: constitution returns real Conway data, drep-state returns [], treasury returns 0. One new regression test: decode_recognises_committee_members_state_tag_27 covering the 4-element wire form. Test count progression: 4737 → 4738. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4738 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Updated Conway-era query end-to-end coverage: constitution ✓, drep-state ✓, treasury ✓, stake-pools ✓, stake-distribution ✓, pool-state ✓, stake-snapshot ✓, committee-state ✓ — every commonly-used cardano-cli conway query subcommand except gov-state now decodes end-to-end against yggdrasil. Open follow-ups: (1) gov-state body shape (substantial — 7-element ConwayGovState record); (2)–(8) carry-overs from R163/R166/R167/R168/R169/R173 + tag 21/22/26/30/31/32/33 dispatchers for completeness. Reference: Cardano.Ledger.Conway.LedgerStateQuery.GetCommitteeMembersState; Cardano.Ledger.Conway.Governance.CommitteeMembersState (3-element record). Full operational record in docs/operational-runs/archive/2026-04-30-round-182-committee-members-state.md.
  • DRepState LSQ Map shape (Round 181, 2026-04-30 R180-followup) — closes the most tractable item from R180’s body-shape follow-up list: aligns yggdrasil’s GetDRepState (tag 25) response with cardano-cli’s expected CBOR map shape so cardano-cli conway query drep-state --all-dreps decodes end-to-end. Code change: new helper encode_drep_state_for_lsq(snapshot) in node/src/local_server.rs emits the snapshot’s DrepState as a CBOR map (encCBOR @(Map a b)) instead of the storage-format array-of-pairs that DrepState::encode_cbor produces; GetDRepState dispatcher arm switched to use the new helper (R180 routed through snapshot.drep_state().encode_cbor() which cardano-cli rejected at depth 3 with expected map len or indef). The credential-set filter parameter remains accepted but not applied — cardano-cli filters client-side after decoding the full map. Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli conway query drep-state --all-dreps --testnet-magic 2 returns [] end-to-end (empty array — preview’s chain at slot ~5K has no registered DReps yet, correct for the snapshot state). Cumulative Conway-era query end-to-end coverage now: constitution ✓ (real data), drep-state --all-dreps ✓ (R181 shape fix), treasury ✓, stake-pools ✓, stake-distribution ✓, pool-state ✓, stake-snapshot ✓ (real per-pool entries); gov-state and committee-state remain follow-ups (dispatcher routes, body shapes pending — ConwayGovState is a 7-element record with complex sub-types like Proposals tree and DRepPulsingState cache; committee-state (tag 27) needs both dispatcher and body shape). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4737 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Open follow-ups: (1) gov-state body shape (substantial — Proposals tree + DRepPulsingState); (2) committee-state dispatcher (tag 27) + body shape; (3)–(8) carry-overs from R163/R166/R167/R168/R169/R173. Reference: Cardano.Ledger.Conway.LedgerStateQuery.GetDRepState (result type Map (Credential 'DRepRole) (DRepState)). Full operational record in docs/operational-runs/archive/2026-04-30-round-181-drep-state-map-shape.md.
  • Conway governance LSQ queries (Round 180, 2026-04-29 R179-followup) — extends R179’s era-blockage fix with dispatchers for the remaining Conway-era governance queries cardano-cli surfaces under cardano-cli conway query ...: constitution (tag 23), gov-state (tag 24), drep-state (tag 25), and the consensus-side AccountState (tag 29). yggdrasil’s LedgerStateSnapshot already tracked all four data sources (enact_state.constitution(), governance_actions(), drep_state(), accounting()); the gap was just the wire dispatcher. Code change: four new EraSpecificQuery variants (GetConstitution, GetGovState, GetDRepState { credential_set_cbor }, GetAccountState) in crates/network/src/protocols/local_state_query_upstream.rs with decoder branches for (1, 23) → GetConstitution, (1, 24) → GetGovState, (2, 25) → GetDRepState, (1, 29) → GetAccountState; four dispatcher arms in node/src/local_server.rs reusing existing snapshot encoders (GetConstitution → snapshot.enact_state().constitution().encode_cbor(), GetGovState → CBOR map of governance_actions(), GetDRepState → snapshot.drep_state().encode_cbor() with credential filter accepted but not applied (cardano-cli filters client-side), GetAccountState → 2-elem [treasury, reserves] from accounting()). Operational verification on preview with YGG_LSQ_ERA_FLOOR=6: cardano-cli conway query constitution returns real Conway constitution data end-to-end ({"anchor": {"dataHash": "ca41a91f...", "url": "ipfs://..."}, "script": "fa24fb305126805cf2164c161d852a0e7330cf988f1fe558cf7d4a64"}); cardano-cli conway query stake-pools after Shelley-era sync returns the real registered pool set (R179’s tag-corrected dispatcher confirmed working with real chain data); cardano-cli conway query stake-snapshot --all-stake-pools returns real per-pool entries with placeholder mark/set/go (R173/R179 GetCBOR-wrapped dispatcher). Pending body-shape work: gov-state, committee-state, and drep-state --all-dreps fail at depth 3 with expected list len or indef / expected map len or indef — the dispatcher tags route correctly (path arrives), but yggdrasil’s existing inner encoders for governance_actions, drep_state, committee_state use shapes that don’t match cardano-cli 10.16’s Conway decoders; tracked as a follow-up requiring upstream Conway governance encoder reference (R180’s dispatcher arms are already in place; only the body shape needs adjustment). One new regression test: decode_recognises_conway_governance_tags covering all four new tag dispatches. Test count progression: 4736 → 4737. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4737 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Updated LSQ era-specific tag coverage: tags 1, 3, 5, 6, 7, 9, 10, 11, 15, 16, 17, 19, 20, 23, 24, 25, 29, 37 — every commonly-used cardano-cli query path (including Conway governance) now routes correctly through yggdrasil’s wire layer. Open follow-ups: (1) GovState/DRepState/CommitteeState body shape alignment with cardano-cli 10.16’s Conway decoders; (2) live stake-snapshot plumbing; (3)–(7) carry-overs from R163/R166/R167/R168/R169; (8) tag 21 GetPoolDistr / 22 GetStakeDelegDeposits / 26 GetDRepStakeDistr / 27 GetCommitteeMembersState / 30 GetSPOStakeDistr / 31 GetProposals / 32 GetRatifyState / 33 GetFuturePParams — additional Conway-era dispatchers for completeness. Reference: Ouroboros.Consensus.Shelley.Ledger.Query.encodeShelleyQuery (tag table); Cardano.Ledger.Conway.Governance.Constitution; Cardano.Ledger.Conway.LedgerStateQuery.GetDRepState. Full operational record in docs/operational-runs/archive/2026-04-29-round-180-conway-governance-queries.md.
  • Era blockage end-to-end fix (Round 179, 2026-04-29 R178-followup) — closes the R178 follow-up: with YGG_LSQ_ERA_FLOOR=6 set, all five era-gated cardano-cli queries (stake-pools, stake-distribution, stake-address-info, pool-state, stake-snapshot) now decode end-to-end against yggdrasil instead of failing with DeserialiseFailure 2 "expected list len". Three independent root causes identified and fixed: (1) wrong tag table — R163/R171/R172/R173 used tags 13/14/17/18 for GetStakePools/GetStakePoolParams/GetPoolState/GetStakeSnapshots, but upstream Ouroboros.Consensus.Shelley.Ledger.Query.encodeShelleyQuery actually uses tags 16/17/19/20 (slots 13/14/17/18 in upstream are DebugChainDepState/GetRewardProvenance/GetStakePoolParams/GetRewardInfoPools); the bug was masked R163-R178 because cardano-cli’s client-side era gate refused to send these queries and the wrong-tag dispatcher path was never exercised end-to-end; corrected the decoder via (1, 16) → GetStakePools, (2, 17) → GetStakePoolParams, (2, 19) → GetPoolState, (2, 20) → GetStakeSnapshots. (2) cardano-cli query stake-distribution uses tag 37 (GetStakeDistribution2, post-Conway no-VRF variant) not tag 5; tag 37 returns the upstream Cardano.Ledger.Core.PoolDistr record ([map, NonZero Coin] 2-element list) vs tag 5’s bare Map; added (1, 37) → GetStakeDistribution alias and changed encode_stake_distribution_map to emit the 2-element shape; cardano-cli further rejected 0 for pdTotalStake because it’s typed NonZero Coin (“Encountered zero while trying to construct a NonZero value”) — emit 1 lovelace as placeholder. (3) query pool-state and query stake-snapshot use GetCBOR (tag 9) wrapping — cardano-cli wraps these via tag 9 which encodes the inner query as a recursive era-specific query and asks the server to respond with the inner result encoded as tag(24) bytes(<inner>); yggdrasil never recognised tag 9; added (2, 9) → EraSpecificQuery::GetCBOR { inner_query_cbor } variant + dispatch_inner_era_query recursive helper that synthesises a [era_index, inner_query_cbor] outer wrapper, recursively classifies via decode_query_if_current, and returns the bare inner-response body for the GetCBOR arm to wrap; StakeSnapshots totals also use NonZero — emit 1-lovelace placeholders for ssStakeMarkTotal/ssStakeSetTotal/ssStakeGoTotal. Code change: re-tagged decoder + added GetStakeDistribution2 alias + added GetCBOR variant + new recursive helper in crates/network/src/protocols/local_state_query_upstream.rs and node/src/local_server.rs; body-shape fix for PoolDistr (encode_stake_distribution_map) and StakeSnapshots NonZero totals (encode_stake_snapshots); updated all dispatcher doc comments and test fixtures to reflect corrected tag numbers (tag-13/14/17/18 → 16/17/19/20). Operational verification (preview, YGG_LSQ_ERA_FLOOR=6): cardano-cli query stake-pools → [], query stake-distribution → {}, query pool-state --all-stake-pools → {}, query stake-snapshot --all-stake-pools → { "pools": {}, "total": { "stakeMark": 1, "stakeSet": 1, "stakeGo": 1 } }; all four decode end-to-end with empty/placeholder data appropriate to a fresh-sync preview chain that hasn’t crossed natural Babbage hard-fork. Preprod regression check (no era floor, Allegra at slot 90440): all 11 pre-existing cardano-cli operations continue to work unchanged (tip, protocol-parameters, era-history, slot-number, utxo --whole-utxo, tx-mempool info/next-tx/tx-exists). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4736 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Test count progression: 4735 → 4736 (added decode_recognises_stake_distribution2_tag_37; updated five existing tests for corrected tag numbers and new PoolDistr / StakeSnapshots envelope shapes). Updated LSQ era-specific tag coverage: tags 1, 3, 5, 6, 7, 9 (GetCBOR), 10, 11, 15, 16, 17, 19, 20, 37 — every common cardano-cli query surface now routes correctly. Open follow-ups: (1) live stake-snapshot plumbing for non-placeholder data; (2)–(7) carry-overs from R163/R166/R167/R168/R169 + tag 21 GetPoolDistr / 23-35 Conway governance dispatchers for completeness. Reference: Ouroboros.Consensus.Shelley.Ledger.Query.encodeShelleyQuery (canonical tag table); Cardano.Ledger.Core.PoolDistr (NonZero Coin pdTotalStake). Full operational record in docs/operational-runs/archive/2026-04-29-round-179-era-blockage-end-to-end.md.
  • YGG_LSQ_ERA_FLOOR bypasses cardano-cli’s era gate (Round 178, 2026-04-28 era blockage fix) — addresses operator complaints about the “era blockage” where R163/R171/R172/R173 wire-correct dispatchers for query stake-pools / query stake-distribution / query stake-address-info / query pool-state / query stake-snapshot were unreachable via cardano-cli 10.16 because cardano-cli client-side gates each at Babbage+ and refuses to send them to a node reporting Alonzo era; preview / preprod fresh syncs spend thousands of slots in early-PV Alonzo (PV=(6,0) = Alonzo per upstream *Transition table) before the chain naturally crosses the Babbage hard-fork. Code change: effective_era_index_for_lsq reads YGG_LSQ_ERA_FLOOR=N env var (parsed as u32, valid range 0..=6) and clamps the reported LSQ era ordinal to at least N — when unset / unparseable / out-of-range the helper preserves R160’s existing wire_era.max(pv_derived_era) behaviour; lower-than-derived floors are no-ops (never demote — would confuse cardano-cli’s era-progression expectations). The helper feeds both the GetCurrentEra HardForkBlockQuery response (which cardano-cli query tip reads to populate the era field) AND the per-era PP-encoder selection inside dispatch_upstream_query, so a floored era automatically routes PP responses through the matching era-shape encoder. Operational verification: before R178, cardano-cli query tip reports "era": "Alonzo" and cardano-cli query stake-pools fails client-side with This query is not supported in the era: Alonzo; after R178 with YGG_LSQ_ERA_FLOOR=6, tip reports "era": "Conway" and cardano-cli sends the wire query (era gate bypassed end-to-end). Known follow-up: bypassing cardano-cli’s era gate exposes a separate downstream issue — cardano-cli 10.16’s HFC envelope decoder for Conway-era responses (from a node-to-client wire version that includes DijkstraEra in the era list) expects a different result-body shape than yggdrasil’s R156 [1, body] envelope, surfacing as DeserialiseFailure 2 "expected list len"; hypothesis space includes a 2-element [era_index, value] envelope superseding pre-Conway [1, value], additional Either Mismatch (Era, Value) wrapping, or alternate inner-value shapes. Without a running upstream Babbage+ Cardano node to capture real wire bytes the exact shape can’t be confidently pinned — tracking as R178-followup: capture upstream Conway-era HFC response wire fixtures and align yggdrasil’s encode_query_if_current_match + era-specific encoders. R178 is honest about this trade-off: documented as opt-in for partial-sync chains exercising the era-gated query paths, with response-shape compatibility still pending. One new regression test: era_floor_env_var_promotes_reported_era covers the matrix (no env var → derived era; floors 5/6 → Babbage/Conway; lower-than-derived → no-op; out-of-range/unparseable → no-op); env-var manipulation is serialised via a static Mutex so concurrent test execution doesn’t race on the process-wide env table. Test count progression: 4734 → 4735. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4735 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Why this matters: era gate is the first-line operational blocker for exercising the R163/R171/R172/R173 dispatchers — without bypassing it, operators on partial syncs of preview/preprod can’t even reach yggdrasil’s response code paths; R178 closes that operational gap with a documented opt-in env var so operators can smoke-test era-gated routing, compare yggdrasil’s response bytes against future upstream fixtures, and run end-to-end CI against the response-shape work in flight without needing a multi-hour preprod sync to natural Babbage transition. Open follow-ups: (1) R178-followup capture upstream Conway-era HFC response wire fixtures; (2)–(7) carry-overs from R163/R166/R167/R168/R169. Reference: Ouroboros.Consensus.HardFork.Combinator.Ledger.Query — decodeQueryIfCurrent envelope structure; Cardano.Ledger.Core.Era *Transition ProtVer table; cardano-cli’s era-gating in Cardano.CLI.EraBased.Query.Run. Full operational record in docs/operational-runs/archive/2026-04-28-round-178-era-floor-env-var.md.
  • encode_filtered_delegations_and_rewards correctness fixes (Round 177, 2026-04-28 R163 audit) — audits the R163 dispatcher for upstream tag 10 (GetFilteredDelegationsAndRewardAccounts) and finds three hidden bugs. Issue 1 (non-determinism): function iterated credentials.iter() directly where credentials is a HashSet<StakeCredential> — iteration order varies across runs even for identical logical input; CBOR map entries should emit in canonical ascending-key order to match upstream Map.toAscList; pre-fix, two calls with the same filter set could produce different byte streams. Issue 2 (O(n²) lookup): for each requested credential, the function called stake_creds.iter().find(|(c, _)| *c == cred) — a linear scan over every registered stake credential; with N delegated credentials and M filter credentials this was O(N·M); the BTreeMap behind StakeCredentials already exposes get(cred) for O(log N) lookup. Issue 3 (kind-discriminator stripping): the function compared via addr.credential.hash() == cred.hash(), stripping the AddrKey-vs-Script discriminator from StakeCredential — a request for Script(h) could receive an AddrKey(h) reward balance (same 28-byte hash, cryptographically distinct credentials); switched to RewardAccounts::find_account_by_credential(cred) which compares the full StakeCredential (kind + hash). Code change: rewrite of node/src/local_server.rs::encode_filtered_delegations_and_rewards — pre-sort the filter into a Vec<&StakeCredential> via sort() so subsequent iteration is canonical; replace inner linear scans with BTreeMap::get and find_account_by_credential lookups; annotated with a Round 177 rationale comment. One new regression test: encode_filtered_delegations_and_rewards_is_deterministic builds two HashSets with identical credentials but different insertion orders, calls the encoder, and asserts byte-identical outputs (also pins the empty-snapshot baseline 0x82 0xa0 0xa0). Test count progression: 4733 → 4734. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4734 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Operational verification: after rebuild and a fresh preview sync at default --batch-size 50, dispatcher continues to operate (cardano-cli query stake-address-info is era-blocked client-side at Alonzo so isn’t directly callable on preview yet, but the deterministic-encoding test plus unchanged sync rate ~14 blk/s confirms no regression). Why this matters: determinism matters for future byte-for-byte parity checks against upstream cardano-node responses; O(N·M) → O(M·log N) matters for mainnet-class chains (100 credentials × 10k pools = 1M comparisons pre-fix, ~1300 post-fix); kind-discriminator stripping is a real correctness concern since AddrKey and Script credentials occasionally share hash byte prefixes. Open follow-ups unchanged from R176: live stake-snapshot plumbing, GetGenesisConfig ShelleyGenesis serialisation, apply-batch duration histogram, multi-session peer accounting, pipelined fetch + apply, deep cross-epoch rollback recovery. Reference: Cardano.Ledger.Shelley.LedgerStateQuery.GetFilteredDelegationsAndRewardAccounts; Cardano.Ledger.Shelley.LedgerState.DState.dsStakeMembers, dsStakeRewards. Full operational record in docs/operational-runs/archive/2026-04-28-round-177-filtered-delegations-fixes.md.
  • Decoder strictness cleanup (Round 176, 2026-04-28 R174 sweep completion) — finds and fixes the remaining instances of the R174 over-permissive optional-tag bug. R174 tightened decode_pool_hash_set (R171 helper) and decode_stake_credential_set (R163 helper) to only accept tag 258 in the optional CIP-21 set wrapper position, but missed the older decode_address_set and decode_txin_set helpers added back in R157. Those two had the exact same if peek_major == Some(6) { dec.tag()?; } pattern that silently strips any arbitrary tag. Issues fixed: (1) decode_address_set (R157) accepted any CBOR tag in the optional 258 wrapper position — a malformed GetUTxOByAddress payload with tag 30 / 24 / any other tag would have its tag silently stripped; tightened to require tag 258 specifically; (2) decode_txin_set (R157) had the same issue for GetUTxOByTxIn payloads — same tightening applied. Code change: same tightening pattern as R174 applied to both helpers in node/src/local_server.rs — explicit tag_number == 258 check + descriptive error message; both annotated with a Round 176 rationale comment that points to R174 as the prior fix. Four new regression tests: decode_address_set_rejects_non_258_tag (feeds tag 30 → expects “expected tag 258” error), decode_address_set_accepts_tagged_set_form (positive case for canonical tag(258) [* bytes] shape), decode_address_set_accepts_untagged_array_form (positive case for legacy untagged-array shape), decode_txin_set_rejects_non_258_tag. Test count progression: 4729 → 4733. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4733 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Operational verification: after rebuild and a fresh preview sync at default --batch-size 50, both GetUTxOByAddress and GetUTxOByTxIn end-to-end paths continue to succeed (cardano-cli query utxo --whole-utxo and cardano-cli query utxo --tx-in <txin>); sync rate unchanged at ~14 blk/s. This completes the R174 strictness sweep — all five CBOR set-decoder helpers in node/src/local_server.rs (decode_pool_hash_set, decode_stake_credential_set, decode_address_set, decode_txin_set, decode_maybe_pool_hash_set) now have consistent strict tag-258 validation. Open follow-ups unchanged from R175: live stake-snapshot plumbing, GetGenesisConfig ShelleyGenesis serialisation, apply-batch duration histogram, multi-session peer accounting, pipelined fetch + apply, deep cross-epoch rollback recovery. Reference: CIP-21 (CBOR set tag 258); RFC 8949 §3.4 (CBOR major types). Full operational record in docs/operational-runs/archive/2026-04-28-round-176-decoder-strictness-cleanup.md.
  • Registry-cooling completeness for R168 hooks (Round 175, 2026-04-28 issue sweep) — sweeps the session-teardown paths in run_reconnecting_verified_sync_service_chaindb_inner and run_reconnecting_verified_sync_service_shared_chaindb_inner for missing companion calls to R168’s registry_mark_bootstrap_cooling. R168 wired the cooling at two of the five session.mux.abort() sites (synchronize-failure path and batch-error punish path) but missed the KeepAlive-failure and session-switching paths — meaning a KeepAlive timeout or hot-peer handoff would leave the bootstrap peer marked PeerHot in the registry until the next session’s promote-to-Hot overrode it (no-op since status is already Hot). In the window between mux abort and re-bootstrap, /metrics would over-report yggdrasil_active_peers by one — not a functional bug (sync itself proceeds correctly) but a metric anomaly that confuses operator dashboards during transient peer churn. Issues fixed: (1) KeepAlive-failure mux abort (both inner functions) — added cooling call alongside the existing mux.abort() and record_reconnect_failure(); (2) session-switching mux abort (both inner functions, “switching sync session to higher-tip hot peer” trace) — added cooling so the previous bootstrap peer demotes from PeerHot immediately, mirroring the handoff in /metrics. Code change: four new registry_mark_bootstrap_cooling call sites in node/src/runtime.rs (applied via replace_all since both inner functions have identical structure); each annotated with a Round 175 rationale comment. The third inner function (run_reconnecting_verified_sync_service_with_tracer) doesn’t carry a peer_registry field and never registered a Hot bootstrap peer in the first place — its KeepAlive path was inadvertently matched by the replace_all during the fix and corrected with a comment explaining why no cooling is needed there. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4729 passed / 0 failed / 1 ignored (test count unchanged — cooling completeness is a behavioural-correctness fix during transient state transitions that’s not naturally reachable in unit-test-fixture-driven scenarios; operational verification covers the end-to-end behaviour), cargo build --release -p yggdrasil-node clean. Operational verification: after rebuild and a fresh preview sync at default --batch-size 50, /metrics reports the correct peer counts (active_peers=1, established_peers=1, known_peers=1, reconnects=0); sync rate unchanged at ~14 blk/s. Why this matters: pre-R175, the yggdrasil_active_peers gauge could briefly over-report during KeepAlive timeouts under network instability (abort fires before next reconnect re-promotes a peer, leaving registry showing old peer as Hot for the entire reconnect-backoff window — up to ~60 s exponential backoff per R166) and during multi-peer hot-handoff (runtime switches to higher-tip peer without demoting previous one, double-counting active peers until new bootstrap fires); both are now corrected — the gauge transitions cleanly across reconnects with no spurious double-counting. Open follow-ups unchanged from R174: live stake-snapshot plumbing, GetGenesisConfig ShelleyGenesis serialisation, apply-batch duration histogram, multi-session peer accounting (R168 structural follow-up; R175 only completes the single-session cooling path), pipelined fetch + apply, deep cross-epoch rollback recovery. Reference: Ouroboros.Network.PeerSelection.Governor — the warm/hot status lifecycle R168’s hooks track. Full operational record in docs/operational-runs/archive/2026-04-28-round-175-registry-cooling-completeness.md.
  • Decoder strictness fixes (Round 174, 2026-04-28 R171/R172/R173 follow-up) — sweep through the recent dispatcher additions for hidden bugs, found and fixed three subtle issues in the CBOR decoders for set / Maybe Set payloads where over-permissive checks could silently mis-parse malformed wire bytes. Issue 1: decode_pool_hash_set accepted any CBOR tag in the optional 258 wrapper position, not just 258. Pre-fix: if dec.peek_major() == Some(6) { dec.tag()?; } strips any tag without verifying it’s the canonical CIP-21 set tag — a malformed payload with tag 30 (UnitInterval), tag 24 (CBOR-in-CBOR), or any other tag would have its tag silently stripped and the next byte parsed as an array length. Tightened to require tag 258 specifically; non-258 tags now surface as a CborDecodeError. Issue 2: decode_stake_credential_set had the same issue — accepted any tag in the optional 258 wrapper. Same tightening applied for parity. Issue 3: decode_maybe_pool_hash_set over-matched on the Nothing shortcut. Pre-fix if dec.peek_major() == Some(7) matches CBOR major type 7 — that’s not just null (0xf6); major 7 also covers undefined (0xf7), false/true, half/single/double-precision floats, and the break stop-code. Any of these would silently shortcut to Nothing instead of erroring. Switched to the existing precise peek_is_null() accessor (matches only 0xf6). Also generalised the error message from “GetPoolState Maybe payload” to “Maybe (Set PoolKeyHash) payload” since R173 reuses the helper for GetStakeSnapshots. Three new regression tests: decode_pool_hash_set_rejects_non_258_tag (feeds tag 30 → expects “expected tag 258” error), decode_stake_credential_set_rejects_non_258_tag (parity check), decode_maybe_pool_hash_set_rejects_undefined (feeds 0xf7 → expects error rather than silent Nothing). All pre-existing positive-path tests continue to pass — the tightening doesn’t change behaviour for valid inputs. Test count progression: 4726 → 4729. Why this matters: pre-R174, a malformed cardano-cli or third-party LSQ client sending a tag-30 wrapper or CBOR undefined could trigger silent decoder mis-behaviour — yggdrasil would either parse garbage as a pool-hash set (likely producing zero matches and returning empty results that look correct) or shortcut a Just <set> query to Nothing (returning all pools instead of the filtered subset); neither is exploitable in any obvious way (LSQ runs over a Unix socket so the threat model is local clients, not adversarial network input) but the silent mis-parse would mask client bugs and complicate debugging. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4729 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Operational verification: after rebuild and fresh preview sync at default --batch-size 50, parity sweep continues to work — query tip returns Alonzo era / block 1960; query utxo --whole-utxo returns the faucet bootstrap entries with proper Alonzo TxOut shape; sync rate unchanged at ~14 blk/s. Open follow-ups unchanged from R173: live stake-snapshot plumbing, GetGenesisConfig ShelleyGenesis serialisation, apply-batch duration histogram, multi-session peer accounting, pipelined fetch + apply, deep cross-epoch rollback recovery. Reference: CIP-21 (CBOR set tag 258); RFC 8949 §3.4 (CBOR major types). Full operational record in docs/operational-runs/archive/2026-04-28-round-174-decoder-strictness-fixes.md.
  • Upstream GetStakeSnapshots (era-specific tag 18) dispatcher (Round 173, 2026-04-28 Haskell-node parity) — completes the era-specific tag-table coverage for the common cardano-cli query operations: implements upstream era-specific BlockQuery tag 18 (GetStakeSnapshots), the Babbage+ query that powers cardano-cli query stake-snapshot --all-stake-pools (and --stake-pool-id <id>). After R171 (tag 14 GetStakePoolParams) and R172 (tag 17 GetPoolState), this closes the wire-protocol parity for every commonly-used upstream tag. Code change: new EraSpecificQuery::GetStakeSnapshots { maybe_pool_hash_set_cbor: Vec<u8> } variant in crates/network/src/protocols/local_state_query_upstream.rs carrying the same raw Maybe (Set PoolKeyHash) payload shape as R172’s GetPoolState; decode_query_if_current recognises (2, 18) and slices the Maybe payload. In node/src/local_server.rs: new encode_stake_snapshots(snapshot, filter) emits the upstream StakeSnapshots era record as a 4-element CBOR list [ssStakeSnapshots :: Map PoolKeyHash [mark_pool, set_pool, go_pool], ssStakeMarkTotal :: Coin, ssStakeSetTotal :: Coin, ssStakeGoTotal :: Coin]; intersection semantics match upstream Map.restrictKeys; sorted ascending by pool keyhash for deterministic CBOR (Map.toAscList). Reuses R172’s decode_maybe_pool_hash_set helper (same wire shape). Known limitation (carry-over to R163’s open follow-up): until the live mark/set/go rotation from LedgerCheckpointTracking::stake_snapshots (held in the sync runtime) is plumbed into LedgerStateSnapshot (the LSQ-facing snapshot), every per-pool entry reports [0, 0, 0] and the three totals are zero; the wire protocol is correct end-to-end and the data populates once the snapshot is threaded through (matches R163’s GetStakeDistribution empty-map behaviour). Four new regression tests: decode_recognises_stake_snapshots_tag_with_just_filter (pins 82 01 82 12 82 01 d9 0102 81 581c <28 bytes>), decode_recognises_stake_snapshots_tag_with_nothing_filter (pins 82 01 82 12 81 00), get_stake_snapshots_empty_snapshot_no_filter_emits_envelope (0x84 0xa0 0x00 0x00 0x00), get_stake_snapshots_empty_snapshot_with_filter_emits_envelope. Test count progression: 4722 → 4726. Operational verification: after rebuild and a fresh preview sync at default --batch-size 50, cardano-cli query stake-snapshot --all-stake-pools --testnet-magic 2 correctly returns This query is not supported in the era: Alonzo. (cardano-cli’s client-side era gating); R173’s dispatcher auto-unblocks at Babbage+ and produces proper non-zero data once R163’s live-snapshot plumbing lands. Verification gates: cargo fmt --all -- --check clean (one auto-format applied), cargo lint clean, cargo test-all 4726 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Cumulative cardano-cli LSQ era-specific tag coverage: tags 1, 3, 5, 6, 7, 10, 11, 13, 14, 15, 17, 18 — every common upstream era-specific tag now has a wire-correct dispatcher; remaining tags (2 GetNonMyopicMemberRewards, 4 GetProposedPParamsUpdates, 8 DebugEpochState, 12 DebugNewEpochState, 16 GetRewardInfoPools, plus Conway-only tags 21–33) are lower-priority for cardano-cli parity — most are debug queries or used by reward-calculator tools, not by the standard cardano-cli query command surface. Open follow-ups: (1) live stake-snapshot plumbing into LedgerStateSnapshot (the R163 follow-up R173 also depends on — threads LedgerCheckpointTracking::stake_snapshots into the LSQ snapshot so GetStakeDistribution and GetStakeSnapshots return non-zero data); (2)–(6) carry-overs from R163/R166/R167/R168/R169. Reference: Cardano.Ledger.Shelley.LedgerStateQuery.GetStakeSnapshots — era-specific BlockQuery sum-type encoder for tag 18; the StakeSnapshots era record shape. Full operational record in docs/operational-runs/archive/2026-04-28-round-173-stake-snapshots-tag18.md.
  • Upstream GetPoolState (era-specific tag 17) dispatcher (Round 172, 2026-04-28 Haskell-node parity) — continues the parity arc started in R171: implements upstream era-specific BlockQuery tag 17 (GetPoolState), the actual Babbage+ query that powers cardano-cli query pool-state --all-stake-pools (and --stake-pool-id <id>). yggdrasil already tracked all four PState components — psStakePoolParams, psFutureStakePoolParams, psRetiring, psDeposits — in its pool_state (R163 + the existing future_params map staged by SNAP), but the canonical era-specific tag-17 query returned Unknown { tag: 17 } → null. Code change: new EraSpecificQuery::GetPoolState { maybe_pool_hash_set_cbor: Vec<u8> } variant in crates/network/src/protocols/local_state_query_upstream.rs; decode_query_if_current recognises (2, 17) and slices the Maybe payload. In node/src/local_server.rs: new decode_maybe_pool_hash_set(bytes) parses the upstream Maybe (Set PoolKeyHash) wrapper — [0] → Nothing (return state for all pools), [1, set] → Just <set> (filter to the supplied pool hashes), bare null (CBOR major 7) also accepted as Nothing for forward-compatibility with upstream encoders that skip the list wrapper; new encode_pool_state(snapshot, filter) emits the upstream PState 4-tuple as a 4-element CBOR list [psStakePoolParams, psFutureStakePoolParams, psRetiring, psDeposits], each component sorted ascending by pool keyhash for deterministic CBOR (matches upstream Map.toAscList); when filter is Some(<set>), every map is intersected with the supplied pool-hash set (matches upstream’s maybe id Map.restrictKeys); when filter is None, every registered pool appears. The psFutureStakePoolParams component pulls from pool_state.future_params() (already maintained by yggdrasil’s SNAP rule per register_with_deposit staging). Dispatcher routes the new variant into the encoder, keeping the existing era-mismatch envelope wrapping (encode_query_if_current_match). Seven new regression tests: decode_recognises_pool_state_tag_with_just_filter (pins 82 01 82 11 82 01 d9 0102 81 581c <28 bytes>), decode_recognises_pool_state_tag_with_nothing_filter (pins 82 01 82 11 81 00), get_pool_state_empty_snapshot_no_filter_emits_four_empty_maps (0x84 0xa0 0xa0 0xa0 0xa0), get_pool_state_empty_snapshot_with_filter_emits_four_empty_maps, decode_maybe_pool_hash_set_accepts_zero_discriminator, decode_maybe_pool_hash_set_accepts_one_discriminator_with_set, decode_maybe_pool_hash_set_accepts_null_as_nothing. Test count progression: 4715 → 4722. Operational verification: after rebuild and a fresh preview sync at default --batch-size 50, cardano-cli query pool-state --all-stake-pools --testnet-magic 2 correctly returns This query is not supported in the era: Alonzo. (cardano-cli’s client-side era gating, separate from R172’s dispatcher); R172 itself is verified by the regression tests plus end-to-end build + sync (sync rate unchanged at ~14 blk/s, all 11 working cardano-cli operations continue to succeed). Verification gates: cargo fmt --all -- --check clean (one auto-format applied), cargo lint clean, cargo test-all 4722 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Cumulative cardano-cli LSQ era-specific tag coverage: tags 1, 3, 5, 6, 7, 10, 11, 13, 14, 15, 17 — adding tag 18 (GetStakeSnapshots) would unlock cardano-cli query stake-snapshot once Babbage is reached (requires the live stake-snapshot rotation also pending for R163’s GetStakeDistribution). Open follow-ups: (1) tag 18 GetStakeSnapshots; (2)–(6) carry-overs from R163/R166/R167/R168/R169. Reference: Cardano.Ledger.Shelley.LedgerStateQuery.GetPoolState — era-specific BlockQuery sum-type encoder for tag 17; Cardano.Ledger.Shelley.LedgerState.PState — record shape. Full operational record in docs/operational-runs/archive/2026-04-28-round-172-pool-state-tag17.md.
  • Upstream GetStakePoolParams (era-specific tag 14) dispatcher (Round 171, 2026-04-28 Haskell-node parity) — closes a Haskell-node parity gap by handling upstream era-specific BlockQuery tag 14 (GetStakePoolParams) end-to-end. yggdrasil already had the data (pool_state per R163) and a yggdrasil-CLI tag-12 dispatcher for individual pool lookups, but the canonical upstream tag-14 era-specific query (used by cardano-cli query pool-state --stake-pool-id <id> once a chain reaches Babbage+) returned Unknown { tag: 14, .. } → null. The query is era-blocked client-side at Alonzo so cardano-cli itself still rejects it pre-Babbage; this round wires the dispatcher so the response auto-unblocks the moment preview / preprod / mainnet hit Babbage with no further code changes. Code change: new EraSpecificQuery::GetStakePoolParams { pool_hash_set_cbor: Vec<u8> } variant in crates/network/src/protocols/local_state_query_upstream.rs; decode_query_if_current recognises (2, 14) and slices the pool-hash-set payload out of the inner CBOR. In node/src/local_server.rs: new decode_pool_hash_set(bytes) parses the CBOR set/array of 28-byte pool keyhashes — tolerates both the canonical tag(258) [* bytes(28)] (CIP-21 set tag) and the legacy untagged-array shapes; new encode_filtered_stake_pool_params(snapshot, pool_hashes) emits the upstream Map (KeyHash 'StakePool) PoolParams shape filtered by the supplied set (looks up each hash in snapshot.pool_state(), sorts the matched pairs by keyhash for deterministic CBOR matching upstream Map.toAscList, emits <keyhash_bytes> <pool.params().encode_cbor> per entry; unknown pools are silently dropped per upstream Map.intersection semantics). Dispatcher routes the new variant into the encoder, keeping the existing era-mismatch envelope wrapping (encode_query_if_current_match). Five new regression tests: decode_recognises_stake_pool_params_tag (pins the 82 01 82 0e d9 0102 81 581c <28 bytes> wire form), get_stake_pool_params_empty_filter_emits_empty_map (empty filter → 0xa0), get_stake_pool_params_unknown_filter_emits_empty_map (intersection drops unknown pools → 0xa0), decode_pool_hash_set_accepts_tagged_set_form, decode_pool_hash_set_accepts_untagged_array_form. Test count progression: 4710 → 4715. Operational verification: after rebuild and a fresh preview sync at default --batch-size 50, cardano-cli query pool-state --all-stake-pools --testnet-magic 2 correctly returns This query is not supported in the era: Alonzo. (cardano-cli’s client-side era gating, separate from R171’s dispatcher); R171 itself is verified by the regression tests plus end-to-end build + sync (sync rate unchanged at ~14 blk/s, all 11 working cardano-cli operations continue to succeed). Verification gates: cargo fmt --all -- --check clean (one auto-format applied), cargo lint clean, cargo test-all 4715 passed / 0 failed / 1 ignored, cargo build --release -p yggdrasil-node clean. Cumulative cardano-cli LSQ era-specific tag coverage: tags 1, 3, 5, 6, 7, 10, 11, 13, 14, 15 now have dispatchers (tag 17 GetPoolState and tag 18 GetStakeSnapshots remain as the Babbage+ follow-ups for full query pool-state --all-stake-pools and query stake-snapshot support). Open follow-ups: (1) tag 17 GetPoolState — the actual Babbage+ pool-state query (returns PState = pools + retiring + reverse delegation + deposit map); (2) tag 18 GetStakeSnapshots for cardano-cli query stake-snapshot (requires the live stake-snapshot rotation also pending for R163’s GetStakeDistribution); (3)–(6) carry-overs from R163/R166/R168/R169. Reference: Cardano.Ledger.Shelley.LedgerStateQuery.GetStakePoolParams — era-specific BlockQuery sum-type encoder for tag 14. Full operational record in docs/operational-runs/archive/2026-04-28-round-171-stake-pool-params-tag14.md.
  • Per-era applied-block counters (Round 170, 2026-04-28 observability) — closes the R169 follow-up #1 by exposing seven per-era applied-block counters (yggdrasil_blocks_byron, …_shelley, …_allegra, …_mary, …_alonzo, …_babbage, …_conway). Combined with R169’s yggdrasil_current_era gauge, dashboards can graph the share of blocks applied per era during a long sync without scraping cardano-cli query tip history; the sum of the seven counters provides a sanity-check parity row against the existing yggdrasil_blocks_synced total. Code change: new blocks_per_era: [AtomicU64; 7] field on NodeMetrics in node/src/tracer.rs (indexed parallel to Era::era_ordinal()), matching MetricsSnapshot::blocks_per_era: [u64; 7], new setter NodeMetrics::add_blocks_for_era(era_ordinal: u8, n: u64) with bounds-check (out-of-range ordinals silently no-op so a future eighth era doesn’t crash the metric path). Prometheus exposition adds seven # HELP/TYPE counter blocks explicitly named per era (convention prefers enumerated counters over labels for low-cardinality dimensions with stable values). node/src/runtime.rs::record_verified_batch_progress tallies per-era counts locally across the batch’s RollForward steps then makes one add_blocks_for_era call per era (keeps atomic-write count to ≤ 7 per batch instead of one per block). Test surface fix: the existing every_metrics_snapshot_field_is_exported_in_prometheus_text reflective test was extended (not replaced) to recognise the seven explicit names when checking blocks_per_era, mirroring the existing exception for uptime_ms → yggdrasil_uptime_seconds. Operational verification: after rebuild and a fresh preview sync at default --batch-size 50, /metrics reports yggdrasil_blocks_alonzo 99 with all other era counters at 0 — matching preview’s Test*HardForkAtEpoch=0 shape (blocks decode as Alonzo from genesis, R169’s current_era 4 agrees), and sum(yggdrasil_blocks_*) = 99 = yggdrasil_blocks_synced confirms the per-era tally is consistent with the existing total counter. Verification gates: cargo fmt --all -- --check clean (one auto-format applied), cargo lint clean, cargo test-all 4710 passed / 0 failed / 1 ignored (test count unchanged — new code exercised end-to-end by every sync run; reflective Prometheus-export test extended to cover the per-era expansion). Open follow-ups: (1) apply-batch duration histogram for fetch-vs-apply bound diagnosis (carry-over from R169); (2)–(5) carry-overs from R163/R166/R167/R168. Reference: Cardano.Ledger.Core.Era ordering. Full operational record in docs/operational-runs/archive/2026-04-28-round-170-per-era-block-counters.md.
  • Current-era Prometheus gauge (Round 169, 2026-04-28 observability) — adds yggdrasil_current_era to the /metrics endpoint so operator dashboards observe Byron→…→Conway era progression directly without parsing cardano-cli query tip JSON. Closes a small but persistent operational-alignment gap: the metric set already exposes slot, block number, mempool stats, peer counts, and checkpoint state — but the era was the one piece that required out-of-band shell to read. Code change: new current_era: AtomicU64 field on NodeMetrics plus matching MetricsSnapshot::current_era: u64, new setter NodeMetrics::set_current_era(u64), Prometheus exposition adds the gauge with HELP enumerating the ordinal mapping (0=Byron, 1=Shelley, 2=Allegra, 3=Mary, 4=Alonzo, 5=Babbage, 6=Conway) per Era::era_ordinal(). Setter invocation lands in node/src/runtime.rs at both production post-apply sites (run_reconnecting_verified_sync_service_chaindb_inner and run_reconnecting_verified_sync_service_shared_chaindb_inner), right after apply_verified_progress_to_chaindb returns — reads tracking.ledger_state.current_era.era_ordinal() (updated by apply_block_validated per applied block) and writes the cast-to-u64 ordinal into the gauge. Operational verification: after rebuild and a fresh preview sync at default --batch-size 50, /metrics reports yggdrasil_current_era 4 — matching preview’s Test*HardForkAtEpoch=0 shape (blocks decode as Alonzo from genesis, R160’s PV-aware era classification reports Alonzo to cardano-cli). Important semantic: the gauge tracks the wire era of the latest applied block (the ledger’s current_era field updated inside apply_block_validated); the PV-aware promotion that cardano-cli sees for chain-tip queries (R160) is computed at query-dispatch time and is intentionally not reflected here — operators consult this gauge for raw on-disk era progression which is the relevant metric for sync dashboards and storage provisioning. Verification gates: cargo fmt --all -- --check clean, cargo lint clean (one ref-of-ref clippy nit fixed by destructuring as Some(tracking) instead of Some(ref tracking)), cargo test-all 4710 passed / 0 failed / 1 ignored (test count unchanged — gauge exercised end-to-end by every sync run; existing metrics_snapshot_renders_in_prometheus_text family covers the surrounding gauges). Open follow-ups: (1) per-era block counters — seven yggdrasil_blocks_{byron,…,conway} counters would let dashboards graph era split during long syncs (~30 LOC, deferred until a dashboard build asks for it); (2) apply-batch duration histogram for fetch-vs-apply bound diagnosis; (3)–(6) carry-overs from R163/R166/R167/R168. Reference: Cardano.Ledger.Core.Era ordering. Full operational record in docs/operational-runs/archive/2026-04-28-round-169-current-era-metric.md.
  • Bootstrap-peer registry promotion fixes /metrics peer counts (Round 168, 2026-04-28 observability) — fixes the metric anomaly visible across R165–R167 where /metrics reported yggdrasil_active_peers 0 / yggdrasil_known_peers 0 / yggdrasil_established_peers 0 while sync was demonstrably running (blocks_synced advancing, current_slot advancing, no reconnects). Root cause: bootstrap_with_attempt_state opens a direct outbound connection to the configured upstream peer (or topology fallback) and bypasses the governor’s normal warm→hot promotion flow — which is the only code path that calls PeerRegistry::set_status(_, PeerHot). PeerSelectionCounters::from_registry (called from the governor’s per-tick metrics update) then iterates the registry and counts entries by status: the bootstrap peer was inserted at seed_peer_registry startup time with PeerSourceBootstrap but its status remained PeerCold, so it never contributed to active/established/known counters even while serving ChainSync + BlockFetch. Fix: two new helpers (registry_mark_bootstrap_hot / registry_mark_bootstrap_cooling) in node/src/runtime.rs wrap PeerRegistry::insert_source + set_status behind Option<&Arc<RwLock<PeerRegistry>>> (no-op when no registry). The hot-mark is invoked alongside pool_register_peer at session establishment in both production sync paths (run_reconnecting_verified_sync_service_chaindb_inner and run_reconnecting_verified_sync_service_shared_chaindb_inner), mirroring the existing BlockFetch-pool registration pattern. The cooling-mark is invoked alongside pool_unregister_peer at session teardown (both the synchronize_chain_sync_to_point intersect-failure path and the reconnect-batch error disposition path). The BatchErrorDisposition::ReconnectAndPunish branch’s existing set_status(addr, PeerCold) continues to override Cooling → Cold for offending peers. The entry stays in the registry (with PeerSourceBootstrap) across cooling so the next reconnect attempt can resume from the same status row — matching upstream’s cooldownPeerInfo post-session bookkeeping. Operational verification: after rebuild and a fresh preview sync at default --batch-size 50, /metrics reports yggdrasil_known_peers 1, yggdrasil_established_peers 1, yggdrasil_active_peers 1 (vs 0/0/0 in R165–R167 under identical sync conditions); cardano-cli queries continue to work. Verification gates: cargo fmt --all -- --check clean (one auto-format applied), cargo lint clean, cargo test-all 4710 passed / 0 failed / 1 ignored (test count unchanged — anomaly only manifests in the production runtime’s session-establishment path, exercised end-to-end by every fresh sync). Open follow-ups: (1) multi-session peer accounting — once max_concurrent_block_fetch_peers > 1 activates parallel fetches across multiple peers, the registry promotion will need to fan out per peer (currently single-session); (2)–(5) carry-overs from R163/R166/R167. Reference: Ouroboros.Network.PeerSelection.Governor — peerSelectionStateToView / KnownPeerInfo.peerStatus; Cardano.Diffusion.NodeToNode.outbound-governor for the warm→hot session lifecycle. Full operational record in docs/operational-runs/archive/2026-04-28-round-168-bootstrap-peer-metric.md.
  • Mid-sync rollback epoch fixup + extended preview verification (Round 167, 2026-04-28 R166 follow-up + operational alignment) — closes the Round 166 follow-up around mid-sync rollback recovery and verifies the combined R166+R167 fix holds through a real epoch transition and a graceful restart→recover→resume cycle. Fix: node/src/sync.rs::update_ledger_checkpoint_after_progress, inside the rollback branch’s non-initial-sync path (after recover_ledger_state_chaindb returns), force current_epoch to match the recovered tip’s slot via the active tracking.epoch_size schedule (epoch_schedule.slot_to_epoch(tip_slot)). Reward distribution is NOT redone — the recovered ledger state stays identical to the checkpoint for everything except current_epoch (re-firing apply_epoch_boundary would require reconstructing historical stake snapshots, deferred as a Phase-3 follow-up). Long-running preview verification: 5m47s fresh preview sync (DB wiped, default --batch-size 50) progressed through the epoch 0→1 transition with non-zero reward effects (treasuryDelta=87558, unclaimedRewards=350235), reaching block 88960 / slot 88960 / Alonzo era / syncProgress 0.08; all 11 working cardano-cli operations confirm end-to-end post-boundary; era-blocked queries (stake-pools, stake-distribution, pool-state) correctly fail client-side with This query is not supported in the era: Alonzo. per yggdrasil’s PV-aware era classification. Restart recovery cycle: killed yggdrasil mid-sync at slot ~13960 then restarted from the same DB — Node.Recovery event reported recovered ledger state from coordinated storage checkpointSlot=12960 point=BlockPoint(SlotNo(13960)) replayedVolatileBlocks=50, the first session-start RollBackward fired correctly (rollbackCount=1 in the first batch), forward sync resumed at ~14 blocks/sec without PPUP errors, all cardano-cli operations continued to work post-restart. The R167 fixup branch did not fire in the 30-second restart window because the volatile depth (~1000 slots) stayed within preview’s first 86400-slot epoch — by design the fixup is dormant in the common case (checkpointIntervalSlots=2160 ≪ epoch length) and only kicks in for deep cross-epoch rollbacks. Known limitation: the pathological case of a checkpoint in epoch N + a rollback to epoch N+M (M≥1) with no intermediate checkpoint is currently unreachable at default config (checkpointIntervalSlots=2160 < 432K-slot epoch length on preprod), but for full correctness the carry-over follow-up is to plumb EpochSchedule + StakeSnapshots into recover_ledger_state and re-fire apply_epoch_boundary for every crossed boundary during replay. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4710 passed / 0 failed / 1 ignored (test count unchanged — the fixup is exercised by production sync recovery paths; a synthetic unit test would require constructing a contrived multi-epoch rollback scenario absent from existing fixtures). Reference: Cardano.Ledger.Shelley.Rules.NewEpoch — PPUP validation reads current_epoch. Full operational record in docs/operational-runs/archive/2026-04-28-round-167-mid-sync-rollback-epoch-fixup.md.
  • Initial-sync rollback fix unblocks --batch-size > 30 (Round 166, 2026-04-28 apply-path correctness) — fixes the apply-path bug behind Round 165’s PPUP wrong epoch crashes at --batch-size ≥ 50, then bumps the default to 50 (~14 blocks/sec on preprod, vs ~9 at 30 and ~5 at the original 10). Root cause: every fresh ChainSync session begins with the upstream server confirming the requested intersect by sending MsgRollBackward to that point, so a from-genesis sync’s first batch shows up as [RollBackward(Origin), RollForward(blocks 1..N)] with rollback_count = 1. update_ledger_checkpoint_after_progress takes its rollback branch on rollback_count > 0 and calls recover_ledger_state_chaindb, which replays the entire volatile suffix (including the new RollForward blocks) via LedgerState::apply_block — a path that does NOT fire epoch-boundary processing, so current_epoch stays at 0 even as the tip advances through Byron epochs and into Shelley. The first Shelley block carrying a PPUP proposal targeting epoch 4 then trips validate_ppup_proposal’s wrong-epoch check. The bug only manifested at large batch sizes because preprod has only ~140 Byron blocks: smaller batches kept the Byron→Shelley transition out of the first batch (where the rollback branch runs), so subsequent batches’ boundary-aware forward path correctly advanced current_epoch block-by-block. Fix: detect the initial-sync rollback shape (rollback target Origin AND tracking.base_ledger_state.tip == Point::Origin) and bypass the heavy recover_ledger_state_chaindb call — reset to the base ledger state and let the forward portion of progress apply through the boundary-aware path (advance_ledger_with_epoch_boundary). recover_ledger_state itself is not touched (it remains correct for startup-recovery callers, where the latest ledger checkpoint already has the right current_epoch). Verification: at --batch-size ∈ {30, 50, 100} on fresh preprod syncs (DB wiped each time), epoch boundaries newEpoch 0→1→2→3→4 fire as expected; rates 30→~9 blk/s, 50→~14 blk/s ✓, 100→~10 blk/s (peer-side fetch latency dominates past 50). All 11 working cardano-cli operations confirm end-to-end at the new default after a fresh preprod sync reached block 115440, epoch 4, era Allegra, slot 115440 in ~92s. Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4710 passed / 0 failed / 1 ignored (test count unchanged — no new behaviour to pin in unit tests; the fix is exercised end-to-end by every initial preprod/preview sync). Open follow-ups: (1) mid-sync rollback boundary skipping — when the rollback target is BlockPoint(...) (not Origin), recover_ledger_state still walks the volatile suffix via apply_block without firing boundaries; harmless within a single epoch but a deep rollback spanning an epoch boundary would corrupt current_epoch (proper fix: plumb EpochSchedule + StakeSnapshots into recover_ledger_state or make apply_block_validated epoch-schedule-aware); (2) pipelined fetch + apply — sync_batch_apply_verified / apply_verified_progress_to_chaindb currently run fetch → verify → apply sequentially per batch; (3) .clone() reduction in LedgerState (359 sites in the apply path); (4)–(5) carry-over from R161/R163. Reference: Ouroboros.Network.Protocol.ChainSync.Server — MsgRollBackward confirmation behaviour at session start. Full operational record in docs/operational-runs/archive/2026-04-28-round-166-rollback-recovery-fix.md.
  • Sync-speed default tuning — bump --batch-size 10 → 30 (Round 165, 2026-04-28 throughput) — out-of-the-box preprod sync improves from ~5 blocks/sec / ~119 slots/sec at the prior default to ~9 blocks/sec / ~180–230 slots/sec at the new default by amortising per-batch overhead (RPC round-trips, lock acquisition, tracer/metric updates) across roughly 3× more blocks. Code change: a single-line default change in node/src/main.rs:91 (#[arg(long, default_value = "30")] batch_size: usize) plus rustdoc explaining the cap. Empirical sweep: --batch-size 10 baseline ~5 blk/s; --batch-size 30 ~9 blk/s ✓; --batch-size 50 and --batch-size 100 both crash with PPUP wrong epoch: current 0, target 4, expected 0 (VoteForThisEpoch). Root cause of the batch>30 cap: crates/ledger/src/state.rs::validate_ppup_proposal rejects PPUP proposals whose target epoch differs from the current epoch. When a single batch straddles an epoch boundary, the apply path processes the whole batch at the start-of-batch’s epoch counter, so a PPUP submitted in epoch N is incorrectly checked against epoch N+k for blocks falling into the next epoch. Splitting the apply path per-epoch (so the boundary triggers ledger rotation mid-batch) is the proper fix, deferred to a future round. Parity verified at new default: rebuilt target/release/yggdrasil-node and ran a fresh preprod sync (database wiped) — within ~7m30s era progressed Byron → Shelley → Allegra (block 4288, slot 171240, syncProgress 1.47%); all 11 working cardano-cli operations confirm end-to-end (query tip, query era-history, query protocol-parameters, query slot-number for two timestamps, query utxo --whole-utxo, three query tx-mempool flavours). Verification gates: cargo fmt --all -- --check clean, cargo lint clean, cargo test-all 4710 passed / 0 failed / 1 ignored (test count unchanged from R164 — pure default-value tweak). Open follow-ups: (1) per-epoch apply split — splits the apply path so an epoch boundary triggers ledger rotation mid-batch, unblocking --batch-size > 30 and removing the PPUP-wrong-epoch crash; (2) pipelined fetch + apply — sync_batch_apply_verified currently runs fetch → verify → apply sequentially per batch, so pipelining (decode/verify next batch while the previous one is applying) compounds on the batch-size win; (3) .clone() reduction in LedgerState (359 sites in the apply path); (4) carry-over from R163: live stake-distribution computation and GetGenesisConfig ShelleyGenesis serialisation; (5) carry-over from R161: Babbage TxOut datum_inline/script_ref operational verification once preview crosses Alonzo. Full operational record in docs/operational-runs/archive/2026-04-28-round-165-sync-speed.md.
  • Cumulative cardano-cli operational parity sweep — Rounds 144-163 verified end-to-end (Round 164, 2026-04-28 parity sign-off) — full operational verification of all 11 working cardano-cli commands against fresh preprod (Shelley era, slot ~92420) and preview (Alonzo era, slot ~5360) syncs. Comprehensive test sweep confirms cumulative parity state across all era-aware codecs added in Rounds 144-163. Preprod parity (Shelley era, slot 92420): query tip → {block:88100, epoch:4, era:"Shelley", slotInEpoch:1700, slotsToEpochEnd:430300, syncProgress:1.40} ✓; query protocol-parameters → 17-element Shelley shape with correct genesis values (txFeePerByte:44, txFeeFixed:155381, maxBlockBodySize:65536, minPoolCost:340000000, minUTxOValue:1000000) ✓; query era-history → 2-era preprod summary CBOR (Byron+Shelley, with Round 162’s bignum-encoded synthetic far-future end at slot 2^48) ✓; query slot-number 2026-12-31T00:00:00Z → 142992000, 2050-01-01T00:00:00Z → 868924800 (R162 unblocked far-future timestamps that pre-fix returned Past horizon) ✓; query utxo --whole-utxo → 3 Byron-genesis bootstrap entries with correct addresses + lovelace balances (29.7T+100T+100T+100T) ✓; query utxo --address addr_test1vz09v9... → filtered to single matching UTxO (R157) ✓; query utxo --tx-in a00696a0...#0 → resolved to specific output via R158’s era-tagged TxIn decoder ✓; query tx-mempool info → {capacityInBytes:0, numberOfTxs:0, sizeInBytes:0, slot:89540} (R158 LocalTxMonitor tag fix) ✓; query tx-mempool next-tx → {nextTx:null, slot:89540} ✓; query tx-mempool tx-exists 0123…ef → {exists:false, slot:89540, txId:"0123…ef"} (R158 era-tagged MsgHasTx) ✓. Preview parity (Alonzo era, slot 5360): query tip → {block:5360, epoch:0, era:"Alonzo"} ✓ — preview’s PV=(6,0) intra-era Alonzo correctly classified by R160’s PV-aware era promotion; query protocol-parameters → 24-element Alonzo shape with cost models, ex-unit prices (priceMemory:0.0577, priceSteps:7.21e-5), max-tx/block ex-units (10M mem / 10G steps; 50M mem / 40G steps), maxValueSize:5000, collateralPercentage:150, maxCollateralInputs:3, utxoCostPerByte:34480 (R159) ✓; query era-history → preview’s 1-era 86400-slot-epoch summary (R153 network-aware Interpreter) ✓; query slot-number 2030-01-01 → 226800000 ✓; query utxo --whole-utxo → faucet bootstrap entries with datum:null, datumhash:null Alonzo-shape TxOut fields (R157 era-aware TxOut encoding) ✓. Operational metrics (preprod): yggdrasil_blocks_synced=201, current_slot=89540, current_block_number=203, blockfetch_workers_registered=10 (knob=2 multi-peer), blockfetch_workers_migrated_total=10, chainsync_workers_registered=1, known_peers=32, active_peers=4. Captures saved to /tmp/ygg-r164-{preprod,preview}-{tip,pparams,utxo}.txt. Cumulative parity arc Rounds 144→164: NtC handshake fixes (R144-R148) → cardano-cli tip JSON (R149-R152) → network-aware Interpreter for preprod/preview/mainnet (R153) → era-PV admission for HFC transition signals (R154) → tx-size fee parity Mary-era-compat (R155) → protocol-parameters Shelley shape (R156) → utxo whole/address/tx-in (R157) → tx-mempool LocalTxMonitor tag fix + era-tagged MsgHasTx (R158) → Alonzo PP shape (R159) → Babbage PP + PV-aware era classification (R160) → Conway PP + PV→era regression tests (R161) → era-history coverage to slot 2^48 + bignum relativeTime (R162) → stake-pools/distribution/genesis-config/stake-address-info dispatcher infrastructure (R163) → cumulative verification (R164). Test count progression: 4644 → 4710 (+66 tests across Rounds 144-163). Open follow-ups: (1) live stake-distribution computation via mark/set/go snapshot rotation; (2) GetGenesisConfig ShelleyGenesis serialisation; (3) preview cross-Alonzo→Babbage sync to operationally verify R163’s stake-* dispatchers; (4) Babbage TxOut datum_inline/script_ref operational verification. Full operational record in docs/operational-runs/archive/2026-04-28-round-164-cumulative-parity-sweep.md.
  • New subfolder-level AGENTS.md files should only be added where a folder has a stable domain boundary.