Jun 02, 1-2 PM (66)
Jun 02, 2-3 PM (102)
Jun 02, 3-4 PM (23)
Jun 02, 4-5 PM (17)
Jun 02, 5-6 PM (27)
Jun 02, 6-7 PM (29)
Jun 02, 7-8 PM (18)
Jun 02, 8-9 PM (9)
Jun 02, 9-10 PM (19)
Jun 02, 10-11 PM (33)
Jun 02, 11-12 AM (22)
Jun 03, 12-1 AM (13)
Jun 03, 1-2 AM (31)
Jun 03, 2-3 AM (16)
Jun 03, 3-4 AM (0)
Jun 03, 4-5 AM (7)
Jun 03, 5-6 AM (12)
Jun 03, 6-7 AM (80)
Jun 03, 7-8 AM (16)
Jun 03, 8-9 AM (24)
Jun 03, 9-10 AM (22)
Jun 03, 10-11 AM (39)
Jun 03, 11-12 PM (76)
Jun 03, 12-1 PM (93)
Jun 03, 1-2 PM (28)
Jun 03, 2-3 PM (62)
Jun 03, 3-4 PM (26)
Jun 03, 4-5 PM (24)
Jun 03, 5-6 PM (23)
Jun 03, 6-7 PM (15)
Jun 03, 7-8 PM (17)
Jun 03, 8-9 PM (19)
Jun 03, 9-10 PM (9)
Jun 03, 10-11 PM (31)
Jun 03, 11-12 AM (14)
Jun 04, 12-1 AM (12)
Jun 04, 1-2 AM (4)
Jun 04, 2-3 AM (1)
Jun 04, 3-4 AM (5)
Jun 04, 4-5 AM (1)
Jun 04, 5-6 AM (0)
Jun 04, 6-7 AM (14)
Jun 04, 7-8 AM (10)
Jun 04, 8-9 AM (11)
Jun 04, 9-10 AM (19)
Jun 04, 10-11 AM (11)
Jun 04, 11-12 PM (14)
Jun 04, 12-1 PM (53)
Jun 04, 1-2 PM (39)
Jun 04, 2-3 PM (60)
Jun 04, 3-4 PM (12)
Jun 04, 4-5 PM (4)
Jun 04, 5-6 PM (7)
Jun 04, 6-7 PM (46)
Jun 04, 7-8 PM (27)
Jun 04, 8-9 PM (4)
Jun 04, 9-10 PM (2)
Jun 04, 10-11 PM (24)
Jun 04, 11-12 AM (7)
Jun 05, 12-1 AM (6)
Jun 05, 1-2 AM (8)
Jun 05, 2-3 AM (1)
Jun 05, 3-4 AM (1)
Jun 05, 4-5 AM (1)
Jun 05, 5-6 AM (5)
Jun 05, 6-7 AM (9)
Jun 05, 7-8 AM (12)
Jun 05, 8-9 AM (8)
Jun 05, 9-10 AM (11)
Jun 05, 10-11 AM (12)
Jun 05, 11-12 PM (8)
Jun 05, 12-1 PM (52)
Jun 05, 1-2 PM (61)
Jun 05, 2-3 PM (26)
Jun 05, 3-4 PM (24)
Jun 05, 4-5 PM (17)
Jun 05, 5-6 PM (7)
Jun 05, 6-7 PM (14)
Jun 05, 7-8 PM (12)
Jun 05, 8-9 PM (6)
Jun 05, 9-10 PM (2)
Jun 05, 10-11 PM (20)
Jun 05, 11-12 AM (9)
Jun 06, 12-1 AM (6)
Jun 06, 1-2 AM (0)
Jun 06, 2-3 AM (3)
Jun 06, 3-4 AM (4)
Jun 06, 4-5 AM (0)
Jun 06, 5-6 AM (24)
Jun 06, 6-7 AM (1)
Jun 06, 7-8 AM (2)
Jun 06, 8-9 AM (3)
Jun 06, 9-10 AM (0)
Jun 06, 10-11 AM (3)
Jun 06, 11-12 PM (6)
Jun 06, 12-1 PM (2)
Jun 06, 1-2 PM (2)
Jun 06, 2-3 PM (2)
Jun 06, 3-4 PM (18)
Jun 06, 4-5 PM (1)
Jun 06, 5-6 PM (6)
Jun 06, 6-7 PM (0)
Jun 06, 7-8 PM (6)
Jun 06, 8-9 PM (0)
Jun 06, 9-10 PM (1)
Jun 06, 10-11 PM (27)
Jun 06, 11-12 AM (9)
Jun 07, 12-1 AM (14)
Jun 07, 1-2 AM (2)
Jun 07, 2-3 AM (0)
Jun 07, 3-4 AM (0)
Jun 07, 4-5 AM (1)
Jun 07, 5-6 AM (1)
Jun 07, 6-7 AM (3)
Jun 07, 7-8 AM (0)
Jun 07, 8-9 AM (0)
Jun 07, 9-10 AM (1)
Jun 07, 10-11 AM (2)
Jun 07, 11-12 PM (2)
Jun 07, 12-1 PM (5)
Jun 07, 1-2 PM (35)
Jun 07, 2-3 PM (2)
Jun 07, 3-4 PM (4)
Jun 07, 4-5 PM (2)
Jun 07, 5-6 PM (4)
Jun 07, 6-7 PM (0)
Jun 07, 7-8 PM (0)
Jun 07, 8-9 PM (17)
Jun 07, 9-10 PM (1)
Jun 07, 10-11 PM (21)
Jun 07, 11-12 AM (9)
Jun 08, 12-1 AM (9)
Jun 08, 1-2 AM (5)
Jun 08, 2-3 AM (3)
Jun 08, 3-4 AM (4)
Jun 08, 4-5 AM (2)
Jun 08, 5-6 AM (9)
Jun 08, 6-7 AM (5)
Jun 08, 7-8 AM (25)
Jun 08, 8-9 AM (36)
Jun 08, 9-10 AM (40)
Jun 08, 10-11 AM (24)
Jun 08, 11-12 PM (22)
Jun 08, 12-1 PM (40)
Jun 08, 1-2 PM (48)
Jun 08, 2-3 PM (33)
Jun 08, 3-4 PM (27)
Jun 08, 4-5 PM (12)
Jun 08, 5-6 PM (23)
Jun 08, 6-7 PM (14)
Jun 08, 7-8 PM (3)
Jun 08, 8-9 PM (6)
Jun 08, 9-10 PM (19)
Jun 08, 10-11 PM (29)
Jun 08, 11-12 AM (8)
Jun 09, 12-1 AM (5)
Jun 09, 1-2 AM (3)
Jun 09, 2-3 AM (1)
Jun 09, 3-4 AM (3)
Jun 09, 4-5 AM (26)
Jun 09, 5-6 AM (5)
Jun 09, 6-7 AM (23)
Jun 09, 7-8 AM (50)
Jun 09, 8-9 AM (35)
Jun 09, 9-10 AM (45)
Jun 09, 10-11 AM (51)
Jun 09, 11-12 PM (44)
Jun 09, 12-1 PM (70)
Jun 09, 1-2 PM (0)
2,837 commits this week Jun 02, 2026 - Jun 09, 2026
Gov property #414: state that GA deposits are eventually refunded
Add the statement stub for issue #414 as a CHAIN-level claim in a new
module Ledger.Conway.Specification.Chain.Properties.EventuallyRefunded:

- gaDepositInPot: a governance-action deposit is still held in a chain state
- CHAINStar: reflexive-transitive closure of CHAIN over a list of blocks
- GADepositsEventuallyRefunded: every held GA deposit is eventually removed
  from the deposit pot once the chain progresses past its expiry epoch

The proof is left as future work ("coming soon"). Wire the module into the
Chain.Properties aggregator, list the claim in the properties index, and note
it in the changelog.
chore(deps): Bump modernc.org/sqlite from 1.51.0 to 1.52.0 (#512)
Bumps [modernc.org/sqlite](https://gitlab.com/cznic/sqlite) from 1.51.0 to 1.52.0.
- [Changelog](https://gitlab.com/cznic/sqlite/blob/master/CHANGELOG.md)
- [Commits](https://gitlab.com/cznic/sqlite/compare/v1.51.0...v1.52.0)

---
updated-dependencies:
- dependency-name: modernc.org/sqlite
  dependency-version: 1.52.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
chore(deps): Bump golang.org/x/crypto from 0.52.0 to 0.53.0 (#510)
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.52.0 to 0.53.0.
- [Commits](https://github.com/golang/crypto/compare/v0.52.0...v0.53.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-version: 0.53.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
chore(deps): Bump golang.org/x/crypto from 0.52.0 to 0.53.0
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.52.0 to 0.53.0.
- [Commits](https://github.com/golang/crypto/compare/v0.52.0...v0.53.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-version: 0.53.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Fix worst-case ClosedDatum pre-funding: use N not N-1 contesters
  The init tx pre-funds the head output with enough ADA to cover the
  largest possible ClosedDatum (all parties having contested). The
  previous calculation used N-1 contesters, but the datum can grow
  to N entries when every party contests. For a single-party head,
  N-1=0 so the pre-funded amount was computed with an empty contesters
  list, leaving 103,440 lovelace short; the wallet's ensureMinUTxO
  then topped up the contest output, which the strict
  mustPreserveHeadValue (H4) check on-chain correctly rejected.

Signed-off-by: Sasha Bogicevic <[email protected]>
Cache BLS12-381 accumulator hash as lazy field in HydraAccumulator
  getAccumulatorHash (which runs a BLS12-381 multi-scalar multiplication)
  was called three times per snapshot: once in `sign`, once in
  `mkSeenSnapshot`, and once in `toJSON`. All three operate on the same
  HydraAccumulator value.

  Change HydraAccumulator from a newtype to a data type with a lazy
  _cachedHash field. The thunk is computed at most once per value via
  normal Haskell sharing — subsequent callers return the already-evaluated
  ByteString immediately.

Signed-off-by: Sasha Bogicevic <[email protected]>
Add contract tests for CloseAny, CloseInitial mutations, and ContestCommit
  Three coverage gaps in the contract test suite are filled:

  - CloseAny: new test module exercising the NoThing → CloseAny redeemer
    path, including the unique on-chain snapshotNumber > 0 check (21
    mutations; signature/number failures all map to FailedCloseAny because
    that path wraps both checks in a single traceIfFalse).

  - CloseInitial: expanded from 2 to 15 mutations, adding the three
    CloseInitial-specific checks (snapshotNumber == 0, version == 0,
    accumulatorCommitment == G1 generator → FailedCloseInitial) plus the
    ten shared close checks (parties, headId, contestation period, validity
    bounds, minting, contesters, value, required signer).

  - ContestInc: new test module contesting with a commit-type snapshot
    (utxoToCommit = Just depositedUTxO), exercising the ToCommit
    accumulator commitment path that ContestDec (decommit path) left
    uncovered.

Signed-off-by: Sasha Bogicevic <[email protected]>
Pre-fund head output with worst-case ClosedDatum min-UTxO at init time
  The geq → == change in mustPreserveHeadValue prevents stuck-head griefing
  but requires the head output ADA to never need a wallet bump at Close or
  Contest time. Since ClosedDatum with N-1 contesters is larger than
  OpenDatum, compute minUTxO(ClosedDatum_{N-1}, V_tokens) at initTx and
  set that as the head output ADA. This ADA is returned to participants at
  fanout and remains stable through Increments (headAdaOverhead = headADA -
  utxoADA stays constant as both sides grow by deposit_ADA).

  Move InitTx out of prepareTxToPost (STM) into postTx (IO) so getPParams
  — a new TinyWallet field — can be called to fetch live protocol params
  for the min-UTxO calculation.

Signed-off-by: Sasha Bogicevic <[email protected]>
Enforce strict value equality in Close/Contest: prevent stuck-head griefing
  mustPreserveHeadValue used geq (≥) rather than == for the Close and
  Contest transitions. This allowed a malicious contester to add extra ADA
  to the head output — a griefing attack where the added value would cause
  the fanout's strict == conservation check to fail, permanently locking
  the head.

  The geq was a defensive measure for datum-growth min-UTxO scenarios, but
  neither closeTx nor contestTx ever changes the head value (both call
  modifyTxOutDatum only), and using geq to "top up" would break the fanout
  anyway. The correct invariant is ==, which matches the spec.

  Add ContestIncreaseHeadValue mutation test to document the property.

Signed-off-by: Sasha Bogicevic <[email protected]>
Fix CRS substitution: validate txOutAddress in withCRSLookup
  withCRSLookup only checked txOutReferenceScript (script hash) but not
  txOutAddress. An attacker could create a UTxO at any address, attach the
  legitimate CRS script as a reference, and provide malicious G2 identity
  elements as datum — bypassing the KZG membership check and fanning out
  arbitrary outputs after the contestation deadline.

  Fix: add addressCredential (txOutAddress resolved) == ScriptCredential
  expectedHash check. Since expectedHash is already compiled into the head
  validator, no new parameters are needed. Move CRS UTxO publishing to the
  CRS script address (which already always-fails) so the on-chain check is
  self-consistent. Update the test generator to match.

  Add WrongAddressCRS mutation tests to FinalPartialFanout, PartialFanout,
  and FanOut (the full fanout path had no CRS mutation coverage at all).

Signed-off-by: Sasha Bogicevic <[email protected]>
Fix fanout for pre-settled UTxOs: remove isG1Generator, add headAdaOverhead
  When a UTxO is settled on-chain via Increment or Decrement before Close,
  its scalar remains in the snapshot's KZG accumulator but its value has
  already left (or entered) the head. Fanning out only the remaining UTxOs
  produces a subset membership proof, but the old on-chain check required
  isG1Generator(proof) — only true when the subset equals the full
  accumulator. This caused H39 FanoutUTxOHashMismatch for any CloseUsed
  scenario.

  Fix (two inseparable halves):

  1. Remove `&& isG1Generator proof` from headIsFinalizedWith and
     checkFinalPartialFanout. Fanout and final-partial-fanout now accept
     any valid subset membership proof.

  2. Replace the `geq` conservation check with strict equality using a new
     `headAdaOverhead :: Integer` field in ClosedDatum and
     FanoutProgressDatum. This field holds the fixed lovelace overhead in
     the head UTxO not attributable to any L2 UTxO (the min-UTxO cost set
     at CollectCom). It closes the security hole that geq would leave: a
     valid subset proof + >= would let an attacker leave value unaccounted.

  Off-chain: fanoutTx receives a separate utxoForProof argument (the full
  snapshot UTxO set including pre-settled ones) to rebuild the accumulator
  matching the ClosedDatum commitment, while the fanned-out outputs cover
  only the UTxOs whose values are still in the head. closeTx computes
  headAdaOverhead as lovelace(headInputValue) - lovelace(UTxOs currently
  in head), with case analysis on incrementalAction × (version ==
  openVersion). contestTx propagates it unchanged; partialFanoutTx threads
  it through FanoutProgressDatum.

  checkContest preserves headAdaOverhead so it cannot be altered after the
  initial Close. checkPartialFanout also preserves it across intermediate
  steps.

Signed-off-by: Sasha Bogicevic <[email protected]>