Cardano Updates

Until the semantics discussion is resolved

Kept a note about this and bumped seeds from faucet.

The utxo is not instantly available, but e2e tests need to wait for the
snapshot to be confirmed.

This is going to be an issue for most of these tests:

The contestation period is used for the upper bound of increment txs
(and others): so it must not be too big for a deposit with a small
deadline / depositPeriod to be able to be picked up.

This does not work for > 1 cluster size yet though

This is always empty now any deposit/increment would require a signed
snapshot.

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

The DepositActivated aggregate handler was unconditionally setting
currentDepositTxId for all deposits, including empty ones. This caused
empty deposits to be tracked even though withNextActive correctly
filters them out for ReqSn, leading to CommitApproved instead of the
expected DepositExpired.

Guard the assignment so empty deposits (deposited == mempty) do not
update currentDepositTxId, consistent with the existing filter logic.
Update test assertions to reflect the eager currentDepositTxId
behaviour introduced in f3109b77b.

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

  After commit 7e570004b introduced immediate snapshot requests on ReqTx
  receipt, several tests were left broken:

  - Tests expecting ReqSn from the timer now need to check the ReqTx
    outcome directly (timer sees RequestedSnapshot and returns noop)
  - The single-member head property checks both ReqTx and timer outcomes
    since seenSnapshot can be ahead of confirmedSnapshot
  - The timer-re-broadcasts-in-SeenSnapshot property is updated to assert
    the opposite: no re-broadcast, preventing the etcd echo feedback loop
  - NodeSpec: emits a single ReqSn with the first tx only; subsequent txs
    queue for the next snapshot

  Root fix in HeadLogic.hs: add `alreadySentForThisSn` guard in
  `onOpenNetworkReqTx.maybeRequestSnapshot` to prevent re-broadcasting
  ReqSn with updated content when already in RequestedSnapshot state.
  Without this, each new ReqTx would send a new ReqSn for the same
  snapshot number with different txId content, causing signature mismatches
  with peers who already signed the first broadcast.

  Also fixes incomplete pattern warning in VisualizeLogs for TimerInput.

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

  withHydraNode waits for NodeSynced before yielding the client, consuming
  all messages (including Committed) in the process. Switch the restarted
  node to withHydraNodeCatchingUp so the Committed message is observed
  directly during chain replay. Also scale all wait timeouts by blockTime.

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

  Bug 1 — CommitFinalized leaves stale decommitTx in state:
  After a snapshot confirming a decommit is confirmed on-chain via
  IncrementTx, the `decommitTx` field was not cleared. This caused the
  next ReqSn to re-include the already-posted decommit, leading to an
  invalid snapshot request. Fix: clear `decommitTx` in the CommitFinalized
  aggregate case when the confirmed snapshot carried a decommit.

  Bug 2 — Leader stuck in RequestedSnapshot after stale ReqSn echo fails:
  When a leader's own ReqSn echo failed validation (e.g. stale decommit or
  expired deposit), the Error outcome left seenSnapshot as RequestedSnapshot
  forever — the timer was noop in that state so the head could never make
  progress. Fix: add `abortOwnEchoOnFail` wrapper in onOpenNetworkReqSn
  that converts RequireFailed on own echo to a new SnapshotRequestAborted
  state change, resetting seenSnapshot to LastSeenSnapshot so the timer can
  retry with fresh content.

  Bug 3 — onChainTick fires DepositExpired/DepositActivated on every tick:
  Deposit status was recomputed from scratch on each tick, causing
  DepositExpired and DepositActivated events to fire repeatedly for already-
  transitioned deposits. Fix: filter to only emit events for deposits whose
  status actually changed in this tick.

  Also fixes restartedNodeCanObserveCommitTx cluster test: the restarted
  node now uses withHydraNodeCatchingUp so the Committed message is not
  consumed by the NodeSynced wait before the assertion can see it.

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

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

  Restore WaitOnDepositActivation (was regressed to noop on this branch) so
  non-leader nodes retry a ReqSn that includes a deposit they haven't yet
  activated, matching master behaviour.

  Update four BehaviorSpec tests to reflect the immediate-ReqSn model introduced
  in 7e570004b:
  - "snapshots are created": tx 40 lands in sn=1 alone; txs 41+42 batch into sn=2
  - "depending transactions confirmed in order": firstTx → sn=1, secondTx → sn=2
  - "conflicting transactions": SnapshotConfirmed fires before TxInvalid
  - "commit snapshot only approved when deposit settled": relax positive assertion
    to [n1] — n2 dropped n1's AckSn while waiting for deposit activation and
    never independently confirms; n2 still observes CommitFinalized on-chain

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

  The versionNeedsSnapshot timer fires an empty version-bump snapshot
  after each IncrementTx. When Close is sent before that snapshot
  confirms at the closing node, the node correctly contests with the
  better snapshot, extending the contestation deadline by one
  contestation period (10 * blockTime).

  The previous buffer of 3 * blockTime was too short in that case,
  causing a timeout before ReadyToFanout arrived. Extended to
  13 * blockTime to cover the contest round plus block-latency buffer.

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

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

Timer inputs fire at 200 Hz but carry no additional information if one
is already pending. Previously, tryEnqueue only dropped ticks when the
queue was full (100 items), allowing stale timer ticks to pile up and
crowd out chain/network events.

Add a lastWasTimer flag that suppresses a new timer tick if the last
enqueued item was already one. Any real event (chain, network, client)
via enqueue resets the flag, allowing the next tick through. This
ensures at most one timer tick is ever pending between real events.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>