Week 36 · 2026

Highlights

A quiet week by the counters (2 PRs merged, 3 opened, 23 commits, no issue activity) but a loud one in substance: Hydra 2.4.0 shipped on Tuesday, and 2.4.1, a security release, superseded it on Wednesday. Anyone running 2.3.0 or 2.4.0 should upgrade to 2.4.1 immediately.

Reactive. Hydra 2.4.0 is the first release since 2.3.0 (W29). Its headline is a pair of security fixes to incremental commits: a snapshot now identifies exactly which deposit it approves and the on-chain validators enforce it, so an increment can only claim the deposit the parties actually signed, and a recover transaction can only spend a single deposit. Those fixes change the Hydra scripts and the snapshot signature payload, so the upgrade is breaking: open heads must be closed and fanned out first, and the persisted hydra.db migrates to CBOR on first start with no downgrade path. The rest of the release is this quarter's work as covered in these notes: the CBOR database and opt-in binary client API (W34), the Blockfrost speedups (W33, W35), linux/arm64 docker images (W35), the Typst/Agda specification (W35), the etcd crash under sustained load (W33) and log flushing (W35), plus close transactions on large heads no longer missing their validity window, layer 2 validity bounds working past the era-history forecast horizon on long-running nodes, unclaimable deposits rejected up front with a new DepositTooLarge error, and deposit validity windows no longer capped at a flat 100 seconds (the operator-precedence quirk found in the timing analysis for #2850, which fixed it). Configuration changes to note: --deposit-period is now a protocol parameter embedded on-chain at init and must be identical across parties, the new --deposit-activation flag separately controls when deposits become active, SyncedStatusReport is gone from the WebSocket API, and hydra-tui renamed --cardano-signing-key to --funds-signing-key.

A day later, 2.4.1 replaced it and 2.4.0 was marked deprecated. When confirming a snapshot, hydra-node re-applied the requested transactions through an optimized path that skipped signature verification and Plutus script evaluation, on the assumption they had been validated on receipt; an unvalidated transaction could reach that path, so a malicious head participant could get a transaction with an invalid signature or failing script into a confirmed snapshot and steal funds (GHSA-cg83-6w6r-6hx3). 2.4.1 removes the optimization: transactions are now always fully validated, signatures and scripts included, when processing a snapshot request. It is a drop-in replacement for 2.4.0, with the Hydra scripts, snapshot signature and database format unchanged.

All three PRs opened last week have now merged: the smoke-test speedup (#2850, Tuesday), the mixed-value fanout generators (#2851, Thursday), and the partial-fanout chunk-size search (#2849, Monday after the week closed). All three were described in W35. Of this week's three: the Commit/DecommitFinalized rollback fix (#2852) closes a gap in deposit rollback recovery (#2741) where CommitFinalized clears the deposit id and drops the pending deposit, so a chain rollback past the increment transaction leaves the node with nothing to re-post; #2854 moves isolated functionality out of the core packages into seven new libs/ packages (event sourcing, a persistent queue, JSON tracing, labelled io-classes, tagged CBOR encoding, secret handling and test port allocation), 146 files, merged Monday; and #2856 is an experiment putting head size 4000 through the PR benchmarks, following the chunk-size work (#2848, #2849).

Maintenance and DevX (M5). hydra-explorer deployment housekeeping after last week's EC2 redeploy: its secrets are now managed with agenix.

KPI & Outcome Achievement (M6). Routine only: the W35 note published.