Home / Input Output / formal-ledger-specifications
Apr 07, 2-3 PM (0)
Apr 07, 3-4 PM (0)
Apr 07, 4-5 PM (0)
Apr 07, 5-6 PM (0)
Apr 07, 6-7 PM (2)
Apr 07, 7-8 PM (1)
Apr 07, 8-9 PM (1)
Apr 07, 9-10 PM (1)
Apr 07, 10-11 PM (0)
Apr 07, 11-12 AM (0)
Apr 08, 12-1 AM (0)
Apr 08, 1-2 AM (2)
Apr 08, 2-3 AM (3)
Apr 08, 3-4 AM (1)
Apr 08, 4-5 AM (0)
Apr 08, 5-6 AM (2)
Apr 08, 6-7 AM (0)
Apr 08, 7-8 AM (0)
Apr 08, 8-9 AM (0)
Apr 08, 9-10 AM (0)
Apr 08, 10-11 AM (0)
Apr 08, 11-12 PM (1)
Apr 08, 12-1 PM (0)
Apr 08, 1-2 PM (1)
Apr 08, 2-3 PM (0)
Apr 08, 3-4 PM (1)
Apr 08, 4-5 PM (0)
Apr 08, 5-6 PM (0)
Apr 08, 6-7 PM (0)
Apr 08, 7-8 PM (0)
Apr 08, 8-9 PM (0)
Apr 08, 9-10 PM (0)
Apr 08, 10-11 PM (0)
Apr 08, 11-12 AM (0)
Apr 09, 12-1 AM (0)
Apr 09, 1-2 AM (0)
Apr 09, 2-3 AM (0)
Apr 09, 3-4 AM (0)
Apr 09, 4-5 AM (1)
Apr 09, 5-6 AM (4)
Apr 09, 6-7 AM (1)
Apr 09, 7-8 AM (0)
Apr 09, 8-9 AM (0)
Apr 09, 9-10 AM (0)
Apr 09, 10-11 AM (1)
Apr 09, 11-12 PM (0)
Apr 09, 12-1 PM (0)
Apr 09, 1-2 PM (0)
Apr 09, 2-3 PM (0)
Apr 09, 3-4 PM (0)
Apr 09, 4-5 PM (0)
Apr 09, 5-6 PM (0)
Apr 09, 6-7 PM (0)
Apr 09, 7-8 PM (0)
Apr 09, 8-9 PM (0)
Apr 09, 9-10 PM (0)
Apr 09, 10-11 PM (0)
Apr 09, 11-12 AM (0)
Apr 10, 12-1 AM (0)
Apr 10, 1-2 AM (0)
Apr 10, 2-3 AM (0)
Apr 10, 3-4 AM (0)
Apr 10, 4-5 AM (0)
Apr 10, 5-6 AM (0)
Apr 10, 6-7 AM (1)
Apr 10, 7-8 AM (1)
Apr 10, 8-9 AM (0)
Apr 10, 9-10 AM (0)
Apr 10, 10-11 AM (0)
Apr 10, 11-12 PM (0)
Apr 10, 12-1 PM (0)
Apr 10, 1-2 PM (1)
Apr 10, 2-3 PM (0)
Apr 10, 3-4 PM (0)
Apr 10, 4-5 PM (0)
Apr 10, 5-6 PM (0)
Apr 10, 6-7 PM (0)
Apr 10, 7-8 PM (0)
Apr 10, 8-9 PM (0)
Apr 10, 9-10 PM (0)
Apr 10, 10-11 PM (8)
Apr 10, 11-12 AM (8)
Apr 11, 12-1 AM (3)
Apr 11, 1-2 AM (1)
Apr 11, 2-3 AM (1)
Apr 11, 3-4 AM (0)
Apr 11, 4-5 AM (0)
Apr 11, 5-6 AM (0)
Apr 11, 6-7 AM (0)
Apr 11, 7-8 AM (0)
Apr 11, 8-9 AM (0)
Apr 11, 9-10 AM (0)
Apr 11, 10-11 AM (0)
Apr 11, 11-12 PM (0)
Apr 11, 12-1 PM (0)
Apr 11, 1-2 PM (0)
Apr 11, 2-3 PM (0)
Apr 11, 3-4 PM (0)
Apr 11, 4-5 PM (0)
Apr 11, 5-6 PM (0)
Apr 11, 6-7 PM (0)
Apr 11, 7-8 PM (0)
Apr 11, 8-9 PM (0)
Apr 11, 9-10 PM (0)
Apr 11, 10-11 PM (0)
Apr 11, 11-12 AM (0)
Apr 12, 12-1 AM (1)
Apr 12, 1-2 AM (1)
Apr 12, 2-3 AM (3)
Apr 12, 3-4 AM (1)
Apr 12, 4-5 AM (0)
Apr 12, 5-6 AM (0)
Apr 12, 6-7 AM (0)
Apr 12, 7-8 AM (0)
Apr 12, 8-9 AM (0)
Apr 12, 9-10 AM (0)
Apr 12, 10-11 AM (0)
Apr 12, 11-12 PM (0)
Apr 12, 12-1 PM (0)
Apr 12, 1-2 PM (0)
Apr 12, 2-3 PM (0)
Apr 12, 3-4 PM (0)
Apr 12, 4-5 PM (0)
Apr 12, 5-6 PM (0)
Apr 12, 6-7 PM (0)
Apr 12, 7-8 PM (0)
Apr 12, 8-9 PM (0)
Apr 12, 9-10 PM (0)
Apr 12, 10-11 PM (0)
Apr 12, 11-12 AM (0)
Apr 13, 12-1 AM (0)
Apr 13, 1-2 AM (0)
Apr 13, 2-3 AM (0)
Apr 13, 3-4 AM (0)
Apr 13, 4-5 AM (0)
Apr 13, 5-6 AM (0)
Apr 13, 6-7 AM (0)
Apr 13, 7-8 AM (0)
Apr 13, 8-9 AM (0)
Apr 13, 9-10 AM (0)
Apr 13, 10-11 AM (0)
Apr 13, 11-12 PM (0)
Apr 13, 12-1 PM (0)
Apr 13, 1-2 PM (0)
Apr 13, 2-3 PM (0)
Apr 13, 3-4 PM (0)
Apr 13, 4-5 PM (0)
Apr 13, 5-6 PM (0)
Apr 13, 6-7 PM (0)
Apr 13, 7-8 PM (0)
Apr 13, 8-9 PM (0)
Apr 13, 9-10 PM (0)
Apr 13, 10-11 PM (0)
Apr 13, 11-12 AM (0)
Apr 14, 12-1 AM (0)
Apr 14, 1-2 AM (1)
Apr 14, 2-3 AM (12)
Apr 14, 3-4 AM (4)
Apr 14, 4-5 AM (1)
Apr 14, 5-6 AM (0)
Apr 14, 6-7 AM (0)
Apr 14, 7-8 AM (0)
Apr 14, 8-9 AM (0)
Apr 14, 9-10 AM (0)
Apr 14, 10-11 AM (0)
Apr 14, 11-12 PM (0)
Apr 14, 12-1 PM (0)
Apr 14, 1-2 PM (0)
Apr 14, 2-3 PM (0)
71 commits this week Apr 07, 2026 - Apr 14, 2026
[Dijkstra] CIP-159-10: Apply batch-wide direct deposits in LEDGER rule (#1122)
After all sub-rule transitions (`SUBLEDGERS`, `CERTS`, `GOVS`, `UTXOW`),
apply batch-wide direct deposits to the final CertState via
`applyDirectDeposits` and `allDirectDeposits`.

`Ledger.lagda.md`:
+  Update `LEDGER-V` output: compute `certStateFinal` by applying
   `allDirectDeposits` to `certState₂`, use `certStateFinal` in the
   output `LedgerState` and in `rmOrphanDRepVotes`;
+  `LEDGER-I` unchanged (invalid batches don't apply deposits);
+  Document direct deposit application ordering and phantom asset
   prevention rationale.

`Ledger/Properties/Computational.lagda.md`:
+  Update `computeProof` valid branch to compute `certStateFinal` and use
   it in the output `LedgerState`.
[Dijkstra] CIP-159-10: Apply batch-wide direct deposits in LEDGER rule (#1122)
After all sub-rule transitions (`SUBLEDGERS`, `CERTS`, `GOVS`, `UTXOW`),
apply batch-wide direct deposits to the final CertState via
`applyDirectDeposits` and `allDirectDeposits`.

`Ledger.lagda.md`:
+  Update `LEDGER-V` output: compute `certStateFinal` by applying
   `allDirectDeposits` to `certState₂`, use `certStateFinal` in the
   output `LedgerState` and in `rmOrphanDRepVotes`;
+  `LEDGER-I` unchanged (invalid batches don't apply deposits);
+  Document direct deposit application ordering and phantom asset
   prevention rationale.

`Ledger/Properties/Computational.lagda.md`:
+  Update `computeProof` valid branch to compute `certStateFinal` and use
   it in the output `LedgerState`.
[Dijkstra] CIP-159-08: Phantom asset attack prevention (#1120)
Add batch-wide withdrawal bound check to prevent phantom asset attacks
when nested transactions combine deposits and withdrawals.

`Transaction.lagda.md`:
+  Define allWithdrawals batch aggregation helper (mirrors
   allDirectDeposits)

`Utxo.lagda.md`:
+  Define NoPhantomWithdrawals predicate using allWithdrawals
+  Add NoPhantomWithdrawals premise to UTXO rule
+  Document phantom asset attack and spend-side safety analogy

`Utxo/Properties/Computational.lagda.md`:
+  Update Computational-UTXO for new premise tuple arity (21+h → 22+h)
[Dijkstra] CIP-159-08: Phantom asset attack prevention (#1120)
Add batch-wide withdrawal bound check to prevent phantom asset attacks
when nested transactions combine deposits and withdrawals.

`Transaction.lagda.md`:
+  Define allWithdrawals batch aggregation helper (mirrors
   allDirectDeposits)

`Utxo.lagda.md`:
+  Define NoPhantomWithdrawals predicate using allWithdrawals
+  Add NoPhantomWithdrawals premise to UTXO rule
+  Document phantom asset attack and spend-side safety analogy

`Utxo/Properties/Computational.lagda.md`:
+  Update Computational-UTXO for new premise tuple arity (21+h → 22+h)
[Dijkstra] CIP-159-07: Use explicit legacy premises instead of allowedLanguagesLegacyMode
Address Carlos's review: `allowedLanguagesLegacyMode` is intended for use
*within* legacy mode to select among V1–V3 versions, not to gate entry
into legacy mode.

`Utxow.lagda.md`:
+  Revert allowedLanguagesLegacyMode to its original form (remove
   UsesV4Features check)
+  Add explicit `Is-∅ (dom txDirectDeposits)` and
   `Is-∅ (dom txBalanceIntervals)` premises to UTXOW-legacy
+  Update `UTXOW-legacy-⋯` pattern synonym for 13 premises
+  Revise documentation to describe the premise-based approach

`Utxow/Properties/Computational.lagda.md`:
+  Update computeProof and completeness for the new legacy tuple arity.
[Dijkstra] CIP-159-07: Version gating for CIP-159 fields (#1119)
Extend `UsesV4Features` to detect CIP-159 transaction fields and update
`allowedLanguagesLegacyMode` to forbid them in legacy mode.

+  Add hasDirectDeposits and hasBalanceIntervals constructors to
   `UsesV4Features`, detecting non-empty
   `txDirectDeposits`/`txBalanceIntervals`.
+  Prepend `UsesV4Features` check to `allowedLanguagesLegacyMode`,
   returning ∅ when V4 features are present (making legacy rule unsatisfiable).
+  Update `Dec-UsesV4Features` instance for the two new constructors.
+  Document the CIP-159/CIP-118 interaction for version gating.

No changes to `Utxow/Properties/Computational.lagda.md`; premise shapes are
unchanged since no new fields are added to `UTXOW-legacy` or `UTXOW-normal`.
[Dijkstra] CIP-159-07: Use explicit legacy premises instead of allowedLanguagesLegacyMode
Address Carlos's review: `allowedLanguagesLegacyMode` is intended for use
*within* legacy mode to select among V1–V3 versions, not to gate entry
into legacy mode.

`Utxow.lagda.md`:
+  Revert allowedLanguagesLegacyMode to its original form (remove
   UsesV4Features check)
+  Add explicit `Is-∅ (dom txDirectDeposits)` and
   `Is-∅ (dom txBalanceIntervals)` premises to UTXOW-legacy
+  Update `UTXOW-legacy-⋯` pattern synonym for 13 premises
+  Revise documentation to describe the premise-based approach

`Utxow/Properties/Computational.lagda.md`:
+  Update computeProof and completeness for the new legacy tuple arity.
[Dijkstra] CIP-159-07: Version gating for CIP-159 fields (#1119)
Extend `UsesV4Features` to detect CIP-159 transaction fields and update
`allowedLanguagesLegacyMode` to forbid them in legacy mode.

+  Add hasDirectDeposits and hasBalanceIntervals constructors to
   `UsesV4Features`, detecting non-empty
   `txDirectDeposits`/`txBalanceIntervals`.
+  Prepend `UsesV4Features` check to `allowedLanguagesLegacyMode`,
   returning ∅ when V4 features are present (making legacy rule unsatisfiable).
+  Update `Dec-UsesV4Features` instance for the two new constructors.
+  Document the CIP-159/CIP-118 interaction for version gating.

No changes to `Utxow/Properties/Computational.lagda.md`; premise shapes are
unchanged since no new fields are added to `UTXOW-legacy` or `UTXOW-normal`.
[Dijkstra] CIP-159-05: Update UTxO rules for direct deposits and balance intervals (#1117)
CIP-159 changes the transaction balancing rules and introduces Phase-1
balance interval validation.  This commit updates the UTxO transition
system accordingly.

`Utxo.lagda.md`:
+  Add accountBalances : Rewards field to UTxOEnv and SubUTxOEnv for
   pre-batch account balance lookups;
+  Add HasAccountBalances type class and instances;
+  Update producedTx to include direct deposit amounts on the produced
   side of the preservation-of-value equation;
+  Add direct deposit registration premise to UTXO and SUBUTXO
   (`dom DirectDepositsOf ⊆ dom AccountBalancesOf`);
+  Add balance interval validation premise to UTXO and SUBUTXO
   (∀ (c,interval) ∈ BalanceIntervalsOf, InBalanceInterval using
   pre-batch account balances).

`Utxo/Properties/Computational.lagda.md`:
+  Update Computational-UTXO for new premise tuple arity (19+h → 21+h)

`Ledger.lagda.md`:
+  Add accountBalances field to SubLedgerEnv;
+  Populate accountBalances in SUBLEDGER-V, SUBLEDGER-I, LEDGER-V,
   LEDGER-I using RewardsOf certState₀ (pre-batch balances).
[Dijkstra] CIP-159-04: Update certificate rules for partial withdrawals (#1116)
CIP-159 changes withdrawal semantics from "all-or-nothing" (withdrawal
amount must equal the full account balance) to "partial" (any amount up
to the current balance may be withdrawn).

`Certs.lagda.md`:
+  Define _≤ᵐ_ relation and Dec-≤ᵐ decision procedure for comparing a
   Coin value against a Maybe Coin (just bal → amt ≤ bal; nothing → ⊥).
+  Define applyWithdrawals helper (fold-based pointwise subtraction of
   withdrawal amounts from account balances).
+  Relax PRE-CERT precondition to three premises: credential is a
   registered key hash, credential is in dom rewards, and withdrawal
   amount ≤ balance (via ≤ᵐ with lookupᵐ?).
+  Update PRE-CERT effect from zeroing withdrawn credentials to pointwise
   subtraction via applyWithdrawals.
+  Document partial withdrawal semantics and version restriction deferral.

`Certs/Properties/Computational.lagda.md`:
+  Add scoped ⁇-≤ᵐ instance (positioned after DELEG/POOL/GOVCERT/CERT
   proofs to avoid instance pollution).
+  Update Computational-PRE-CERT for the new three-premise precondition.
[Dijkstra] CIP-159-08: Phantom asset attack prevention (#1120)
Add batch-wide withdrawal bound check to prevent phantom asset attacks
when nested transactions combine deposits and withdrawals.

`Transaction.lagda.md`:
+  Define allWithdrawals batch aggregation helper (mirrors
   allDirectDeposits)

`Utxo.lagda.md`:
+  Define NoPhantomWithdrawals predicate using allWithdrawals
+  Add NoPhantomWithdrawals premise to UTXO rule
+  Document phantom asset attack and spend-side safety analogy

`Utxo/Properties/Computational.lagda.md`:
+  Update Computational-UTXO for new premise tuple arity (21+h → 22+h)
[Dijkstra] CIP-159-04: Update certificate rules for partial withdrawals (#1116)
CIP-159 changes withdrawal semantics from "all-or-nothing" (withdrawal
amount must equal the full account balance) to "partial" (any amount up
to the current balance may be withdrawn).

`Certs.lagda.md`:
+  Define _≤ᵐ_ relation and Dec-≤ᵐ decision procedure for comparing a
   Coin value against a Maybe Coin (just bal → amt ≤ bal; nothing → ⊥).
+  Define applyWithdrawals helper (fold-based pointwise subtraction of
   withdrawal amounts from account balances).
+  Relax PRE-CERT precondition to three premises: credential is a
   registered key hash, credential is in dom rewards, and withdrawal
   amount ≤ balance (via ≤ᵐ with lookupᵐ?).
+  Update PRE-CERT effect from zeroing withdrawn credentials to pointwise
   subtraction via applyWithdrawals.
+  Document partial withdrawal semantics and version restriction deferral.

`Certs/Properties/Computational.lagda.md`:
+  Add scoped ⁇-≤ᵐ instance (positioned after DELEG/POOL/GOVCERT/CERT
   proofs to avoid instance pollution).
+  Update Computational-PRE-CERT for the new three-premise precondition.
[Dijkstra] CIP-159-10: Apply batch-wide direct deposits in LEDGER rule (#1122)
After all sub-rule transitions (`SUBLEDGERS`, `CERTS`, `GOVS`, `UTXOW`),
apply batch-wide direct deposits to the final CertState via
`applyDirectDeposits` and `allDirectDeposits`.

`Ledger.lagda.md`:
+  Update `LEDGER-V` output: compute `certStateFinal` by applying
   `allDirectDeposits` to `certState₂`, use `certStateFinal` in the
   output `LedgerState` and in `rmOrphanDRepVotes`;
+  `LEDGER-I` unchanged (invalid batches don't apply deposits);
+  Document direct deposit application ordering and phantom asset
   prevention rationale.

`Ledger/Properties/Computational.lagda.md`:
+  Update `computeProof` valid branch to compute `certStateFinal` and use
   it in the output `LedgerState`.