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 (41)
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 (51)
Jun 09, 8-9 AM (35)
Jun 09, 9-10 AM (45)
Jun 09, 10-11 AM (51)
Jun 09, 11-12 PM (46)
Jun 09, 12-1 PM (86)
Jun 09, 1-2 PM (84)
Jun 09, 2-3 PM (36)
Jun 09, 3-4 PM (38)
Jun 09, 4-5 PM (16)
Jun 09, 5-6 PM (18)
Jun 09, 6-7 PM (18)
Jun 09, 7-8 PM (19)
Jun 09, 8-9 PM (16)
Jun 09, 9-10 PM (16)
Jun 09, 10-11 PM (28)
Jun 09, 11-12 AM (10)
Jun 10, 12-1 AM (11)
Jun 10, 1-2 AM (16)
Jun 10, 2-3 AM (11)
Jun 10, 3-4 AM (19)
Jun 10, 4-5 AM (5)
Jun 10, 5-6 AM (2)
Jun 10, 6-7 AM (46)
Jun 10, 7-8 AM (82)
Jun 10, 8-9 AM (18)
Jun 10, 9-10 AM (59)
Jun 10, 10-11 AM (46)
Jun 10, 11-12 PM (134)
Jun 10, 12-1 PM (48)
Jun 10, 1-2 PM (33)
Jun 10, 2-3 PM (32)
Jun 10, 3-4 PM (28)
Jun 10, 4-5 PM (35)
Jun 10, 5-6 PM (12)
Jun 10, 6-7 PM (12)
Jun 10, 7-8 PM (38)
Jun 10, 8-9 PM (11)
Jun 10, 9-10 PM (9)
Jun 10, 10-11 PM (20)
Jun 10, 11-12 AM (7)
Jun 11, 12-1 AM (10)
Jun 11, 1-2 AM (2)
Jun 11, 2-3 AM (0)
Jun 11, 3-4 AM (2)
Jun 11, 4-5 AM (8)
Jun 11, 5-6 AM (12)
Jun 11, 6-7 AM (34)
Jun 11, 7-8 AM (106)
Jun 11, 8-9 AM (36)
Jun 11, 9-10 AM (20)
Jun 11, 10-11 AM (105)
Jun 11, 11-12 PM (25)
Jun 11, 12-1 PM (38)
Jun 11, 1-2 PM (37)
Jun 11, 2-3 PM (14)
Jun 11, 3-4 PM (20)
Jun 11, 4-5 PM (5)
Jun 11, 5-6 PM (7)
Jun 11, 6-7 PM (26)
Jun 11, 7-8 PM (90)
Jun 11, 8-9 PM (11)
Jun 11, 9-10 PM (5)
Jun 11, 10-11 PM (25)
Jun 11, 11-12 AM (5)
Jun 12, 12-1 AM (8)
Jun 12, 1-2 AM (2)
Jun 12, 2-3 AM (2)
Jun 12, 3-4 AM (4)
Jun 12, 4-5 AM (7)
Jun 12, 5-6 AM (15)
Jun 12, 6-7 AM (46)
Jun 12, 7-8 AM (19)
Jun 12, 8-9 AM (28)
Jun 12, 9-10 AM (22)
Jun 12, 10-11 AM (29)
Jun 12, 11-12 PM (42)
Jun 12, 12-1 PM (24)
Jun 12, 1-2 PM (26)
Jun 12, 2-3 PM (22)
Jun 12, 3-4 PM (37)
Jun 12, 4-5 PM (23)
Jun 12, 5-6 PM (2)
3,179 commits this week Jun 05, 2026 - Jun 12, 2026
fix: revert 'forecast stake distribution hack' introduced for testing
  It is not okay to change production behavior to accomodate tests; this is dangerous and will send even send a wrong test signal. We should test the code that ends up in production.

  Note that I've kept some of the ideas behind the hack to make the stake distribution resolution a bit more flexible while remaining correct. This is mostly just deferring the error to later; but no longer tries to return a placeholder stake distribution when not found.

Signed-off-by: KtorZ <[email protected]>
feat: replace opaque 'targets file' with a documented option + fix bootstrap epoch semantic
  There are really two things in this commit:

  1. The create-snapshots command no longer takes in an opaque 'targets file' whose format is unspecified; but instead expect three arguments with a documented format. For example, bootstrapping on preprod to start in epoch 120, one can run:

     ```console
     cargo run -- create-snapshots --network preprod \
       --epoch 120 \
       --snapshot 49334363.8ddbb034a040f5436cc28dd4f5ebdcf7dea58109cc0ab8e9a59e2cfcfc874d5a::49334359.8dca1950a31f0abfb81485cabf20c6f47a3c50db66f540ad15fdde186edd2a82 \
       --snapshot 49766361.0878562e94a75a34ad2e9949b3f6b9c7037bf02070a15b7d949c364bafa8c0f4::49766359.79688f066f1e234acc94ee0682438fbae65bdc02ac9e4ae54e598d6e24798395 \
       --snapshot 50198378.f41a322165e3b3b7227cecc76937dd0458dbae19fa06afab42a0a4c83caed769::50198349.72077c9ca15faf1cec5f9e866564d0dfee27311eeab46285cf16d19ec4065ef7
     ```

     Alternatively, an env var with comma-separated values can also be used.

  2. The 'epoch' argument was confusing for the bootstrap and create-bootstrap methods as it referred to the epoch of the 1st snapshot; forcing users to do some mental gymnastic and having to know that Amaru requires 3 past epochs. It's more intuitive to have the CLI ask for the *target* epoch that a user wants to bootstrap into. This means that all invocations of create-snapshots or bootstrap must now be shifted by 3.

  Also; the code was using raw primitive types (String, u64, ...) everywhere; which I switched to Hash, Epoch and Slot to be consistent with our past decisions (cf EDR-009).

Signed-off-by: KtorZ <[email protected]>
fix(ledger): forecast testnet stake distribution lookups
Port of lambdasistemi 36ea009c onto upstream/main's rewritten state.rs.

Generated private testnets (db-synthesizer / amaru-bootstrap) can serve
block headers from the next leader schedule before the stable ledger
has materialized that epoch's snapshot. Add an opt-in forecast on
StakeDistributionObserver::get_pool that falls back to the latest
cached distribution when the requested epoch is strictly newer; only
enabled for NetworkName::Testnet(_).

Public networks (mainnet/preprod/preview) keep the existing strict
lookup behaviour.

Signed-off-by: paolino <[email protected]>
fix(consensus): guard against ln(1-f) panic when active_slot_coeff >= 1
assert_leader_stake currently computes c = ln(1 - active_slot_coeff)
unconditionally. For genesis params with activeSlotsCoeff = 1.0
(used by the antithesis short-epoch fixture in
lambdasistemi/amaru-bootstrap and by the live consumer test in
lambdasistemi/amaru-bootstrap#35) this is ln(0), and pallas-math's
FixedDecimal::ln panics with "ln of a value in (-inf,0] is undefined".

When f = 1, every slot is leader-elected with probability 1 — the
leader-stake assertion is trivially satisfied for any pool with
non-zero relative stake. Mirroring the pre-existing zero-active-stake
guard added in b69fa13e, short-circuit to Ok before the ln call.

The math is continuous at f -> 1 (exp(x*c) with c -> -inf collapses
to 0, which is < recip_q, so the ordering is LT = Ok), so the guard
does not change behaviour for any f < 1.

Surfaced by the live amaru-run consumer test in
lambdasistemi/amaru-bootstrap#35 once
lambdasistemi/amaru#2 (saturating epoch subtraction) let header
validation reach this code path on a cold-start short-epoch chain.

Signed-off-by: Paolo Veronelli <[email protected]>
Signed-off-by: paolino <[email protected]>
fix(bootstrap): honor era-history sidecar when importing testnet tvar snapshots
The node-snapshot (tvar) import path derived the current era's epoch size
from the network default (86400), ignoring custom-testnet genesis. Load the
history.<slot>.<hash>.json sidecar (as the .cbor path already does via
make_era_history) and use it to interpret the snapshot, but only for
Testnet(_); public networks keep the snapshot-derived history unchanged.

Signed-off-by: paolino <[email protected]>
fix(ledger): saturate epoch subtraction in stake distribution lookups
Two sites in amaru-ledger/src/state.rs were doing unchecked Epoch
subtraction on a u64-backed Epoch, producing u64::MAX-1 (or panicking,
depending on overflow checks) when the latest snapshot or the
slot-derived current epoch was below the rewards/leader-schedule
horizon (epoch < 2):

- StakeDistributionObserver::get_pool: `current_epoch - 2` becomes
  saturating_sub(2). Headers validated very early in the chain (or
  with a custom era history that maps slots to low epoch numbers)
  no longer surface a misleading
  "no stake distribution available for pool access 18446744073709551614"
  — the error now correctly says "pool access 0" and points at a
  real missing snapshot.

- initial_stake_distributions: `latest_epoch - Epoch::from(2)` and
  `- Epoch::from(1)` become saturating_sub(2) / saturating_sub(1).
  Bundles produced by amaru-bootstrap from cold-start short-epoch
  testnets (e.g. lambdasistemi/amaru-bootstrap#34's antithesis
  reproducer) where the most_recent_snapshot is epoch 0 or 1 no
  longer hit a u64 underflow on Ledger::new; for_epoch(0) is
  exercised normally and surfaces a sensible StoreError if the
  snapshot is genuinely absent.

This is a defensive correctness improvement only — it does not change
behaviour for any chain past epoch 2. Surfaced by the new live
amaru-run consumer test in lambdasistemi/amaru-bootstrap#35.

Signed-off-by: Paolo Veronelli <[email protected]>
Signed-off-by: paolino <[email protected]>
fix(localstatequery): gate GetAccountState on Conway era
GetAccountState is a Conway-era query; add the same era guard the other
Conway governance client methods (GetConstitution, GetGovState, GetDRepState)
use, so calling it on a pre-Conway chain returns a clear error instead of
sending an unsupported query.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Signed-off-by: Chris Guiney <[email protected]>