Home / Input Output / formal-ledger-specifications
May 20, 10-11 AM (1)
May 20, 11-12 PM (1)
May 20, 12-1 PM (4)
May 20, 1-2 PM (1)
May 20, 2-3 PM (0)
May 20, 3-4 PM (0)
May 20, 4-5 PM (0)
May 20, 5-6 PM (0)
May 20, 6-7 PM (0)
May 20, 7-8 PM (0)
May 20, 8-9 PM (0)
May 20, 9-10 PM (0)
May 20, 10-11 PM (0)
May 20, 11-12 AM (0)
May 21, 12-1 AM (4)
May 21, 1-2 AM (4)
May 21, 2-3 AM (1)
May 21, 3-4 AM (3)
May 21, 4-5 AM (1)
May 21, 5-6 AM (0)
May 21, 6-7 AM (0)
May 21, 7-8 AM (0)
May 21, 8-9 AM (2)
May 21, 9-10 AM (2)
May 21, 10-11 AM (0)
May 21, 11-12 PM (0)
May 21, 12-1 PM (1)
May 21, 1-2 PM (1)
May 21, 2-3 PM (0)
May 21, 3-4 PM (0)
May 21, 4-5 PM (0)
May 21, 5-6 PM (0)
May 21, 6-7 PM (1)
May 21, 7-8 PM (0)
May 21, 8-9 PM (0)
May 21, 9-10 PM (0)
May 21, 10-11 PM (1)
May 21, 11-12 AM (0)
May 22, 12-1 AM (0)
May 22, 1-2 AM (0)
May 22, 2-3 AM (0)
May 22, 3-4 AM (0)
May 22, 4-5 AM (0)
May 22, 5-6 AM (0)
May 22, 6-7 AM (0)
May 22, 7-8 AM (0)
May 22, 8-9 AM (0)
May 22, 9-10 AM (0)
May 22, 10-11 AM (0)
May 22, 11-12 PM (0)
May 22, 12-1 PM (0)
May 22, 1-2 PM (0)
May 22, 2-3 PM (0)
May 22, 3-4 PM (0)
May 22, 4-5 PM (0)
May 22, 5-6 PM (0)
May 22, 6-7 PM (0)
May 22, 7-8 PM (0)
May 22, 8-9 PM (0)
May 22, 9-10 PM (0)
May 22, 10-11 PM (0)
May 22, 11-12 AM (0)
May 23, 12-1 AM (0)
May 23, 1-2 AM (0)
May 23, 2-3 AM (0)
May 23, 3-4 AM (0)
May 23, 4-5 AM (0)
May 23, 5-6 AM (0)
May 23, 6-7 AM (0)
May 23, 7-8 AM (0)
May 23, 8-9 AM (0)
May 23, 9-10 AM (0)
May 23, 10-11 AM (0)
May 23, 11-12 PM (0)
May 23, 12-1 PM (0)
May 23, 1-2 PM (0)
May 23, 2-3 PM (0)
May 23, 3-4 PM (0)
May 23, 4-5 PM (0)
May 23, 5-6 PM (0)
May 23, 6-7 PM (0)
May 23, 7-8 PM (0)
May 23, 8-9 PM (0)
May 23, 9-10 PM (0)
May 23, 10-11 PM (0)
May 23, 11-12 AM (0)
May 24, 12-1 AM (0)
May 24, 1-2 AM (0)
May 24, 2-3 AM (0)
May 24, 3-4 AM (0)
May 24, 4-5 AM (0)
May 24, 5-6 AM (0)
May 24, 6-7 AM (0)
May 24, 7-8 AM (0)
May 24, 8-9 AM (0)
May 24, 9-10 AM (0)
May 24, 10-11 AM (0)
May 24, 11-12 PM (0)
May 24, 12-1 PM (0)
May 24, 1-2 PM (0)
May 24, 2-3 PM (0)
May 24, 3-4 PM (0)
May 24, 4-5 PM (0)
May 24, 5-6 PM (0)
May 24, 6-7 PM (0)
May 24, 7-8 PM (0)
May 24, 8-9 PM (0)
May 24, 9-10 PM (0)
May 24, 10-11 PM (0)
May 24, 11-12 AM (0)
May 25, 12-1 AM (0)
May 25, 1-2 AM (0)
May 25, 2-3 AM (0)
May 25, 3-4 AM (0)
May 25, 4-5 AM (0)
May 25, 5-6 AM (0)
May 25, 6-7 AM (0)
May 25, 7-8 AM (0)
May 25, 8-9 AM (3)
May 25, 9-10 AM (0)
May 25, 10-11 AM (0)
May 25, 11-12 PM (0)
May 25, 12-1 PM (0)
May 25, 1-2 PM (0)
May 25, 2-3 PM (0)
May 25, 3-4 PM (0)
May 25, 4-5 PM (0)
May 25, 5-6 PM (0)
May 25, 6-7 PM (0)
May 25, 7-8 PM (0)
May 25, 8-9 PM (0)
May 25, 9-10 PM (0)
May 25, 10-11 PM (0)
May 25, 11-12 AM (0)
May 26, 12-1 AM (0)
May 26, 1-2 AM (0)
May 26, 2-3 AM (0)
May 26, 3-4 AM (0)
May 26, 4-5 AM (0)
May 26, 5-6 AM (0)
May 26, 6-7 AM (4)
May 26, 7-8 AM (5)
May 26, 8-9 AM (0)
May 26, 9-10 AM (1)
May 26, 10-11 AM (0)
May 26, 11-12 PM (0)
May 26, 12-1 PM (0)
May 26, 1-2 PM (1)
May 26, 2-3 PM (7)
May 26, 3-4 PM (0)
May 26, 4-5 PM (0)
May 26, 5-6 PM (0)
May 26, 6-7 PM (0)
May 26, 7-8 PM (0)
May 26, 8-9 PM (0)
May 26, 9-10 PM (0)
May 26, 10-11 PM (0)
May 26, 11-12 AM (0)
May 27, 12-1 AM (0)
May 27, 1-2 AM (0)
May 27, 2-3 AM (0)
May 27, 3-4 AM (1)
May 27, 4-5 AM (0)
May 27, 5-6 AM (0)
May 27, 6-7 AM (0)
May 27, 7-8 AM (0)
May 27, 8-9 AM (0)
May 27, 9-10 AM (1)
May 27, 10-11 AM (0)
51 commits this week May 20, 2026 - May 27, 2026
Bridge CERTS evolution to closed-form cert-deposit accounting
Adds the per-step and RTC-induction bridging lemmas that prove the actual `CertState` produced by a `CERTS` chain has the same three deposit pots (and hence the same `coinFromDeposits`) as the closed-form `updateCertDeposits` applied to the initial state and the cert list.  This is the cert-deposit half of the `LEDGER-pov` chain; combined with the `posNeg-deposits` cancellation identity, it closes the deposit-accounting equation against the UTXO batch-balance equation.

New proofs (PR branch):

+  `CERT-deposits-updateCertDeposit` in `Certs.Properties.PoVLemmas`.  Per-step, case-split on the `CERT` rule's eight `DCert` constructors; `refl` in seven cases, `POOL-rereg` discharged via the pool-deposit alignment invariant.

+  `CERTS-deposits-updateCertDeposits` in `Certs.Properties.PoV`.  RTC induction mirroring `CERTS-pov`.  Factored through `updateCertDeposit-list`, a pure pot-only `foldl` that is the rule-intrinsic counterpart of `updateCertDeposits`; the bridge `pots-updateCertDeposits` handles the inheritance of non-deposit `CertState` fields.

+  `CERTS-coinFromDeposits-updateCertDeposits`.  Coin projection of the main lemma, immediately usable by `LEDGER-pov`.

Both bridging lemmas are parameterised over (a) two deferred set/map facts (`∪ˡ-singleton-mem-≡`, `Is-just-isPoolRegistered⇒∈-dom`) to be discharged from the standard library; and (b) the pool-deposit alignment invariant `PoolDepositsAligned` plus, for the RTC sibling, its `CERT`-step preservation lemma — both follow by inspection of the `POOL` sub-rules.

Master-touching changes

+  **Bug fix in `updateCertDeposits`**.  Was setting `DState.deposits` to `depositsᵍ` (the `GState` delta) instead of `depositsᵈ`.  The `depositsᵈ` name was bound by destructuring but otherwise unused — almost certainly an unintended typo.

+  **Bug fix in `updateCertDeposits`**.  Was using `foldr`, processing certs right-to-left.  The `CERTS` rule processes certs left-to-right (via `BS-ind`'s head-first decomposition).  For non-commutative cert sequences this is unsound: e.g. `[delegate c keyDeposit, dereg c (just keyDeposit)]` for a fresh credential should end with `c ∉ deposits` per `CERTS`, but `foldr` (which processes the `dereg` on the fresh state first as a no-op, then the `delegate`) ends with `c ∈ deposits`.  Switched to `foldl`.  Conway's `updateCertDeposits` is recursive left-to-right (equivalent to `foldl`); Dijkstra's own `applyToRewards` uses `foldl`.

+  **Refactor**.  Extracted `updateCertDepositsStep` as a named function from `updateCertDeposits`' inner lambda, so that downstream proofs can state and use its per-step pots equation.

+  **Hoist**.  Moved `updateCertDeposit`, `updateCertDeposits`, `coinFromDeposits`, `depositsChange`, `newCertDeposits`, `refundCertDeposits` from `Utxo.lagda.md` to `Certs.lagda.md`.  These depend only on `Certs`-level definitions (`PParams`, `DCert`, `CertState`); the previous location forced any proof referencing them to take the larger `TransactionStructure` / `AbstractFunctions` parameter set, blocking placement of the bridging lemmas in `Certs.Properties.PoV{,Lemmas}`.  `govProposalsDeposits` remains in `Utxo.lagda.md` (depends on `GovProposal`).

PR-branch-only changes:

+  `Ledger.lagda.md`. Replaced the local `coinFromDeposit` (singular) with the hoisted `coinFromDeposits` (plural).  `HasCoin-LedgerState` has three summands: `getCoin(UTxOState) + rewardsBalance(DState) + coinFromDeposits(CertState)`.  Gov-action deposits are stored in `GState.deposits` (keyed by `returnAddr`'s stake credential) and are therefore already counted by the third summand.
Adapt LEDGER computational instance to certState-threaded UTxOEnv
UTxOEnv now carries the pre-batch CertState directly rather than a
precomputed DepositsChange, so the LEDGER computational instance no
longer needs separate environments for the valid and invalid cases.
The two old builders (utxoΓ-valid : CertState → CertState → UTxOEnv,
utxoΓ-invalid : UTxOEnv) collapse into a single

   utxoΓ : UTxOEnv
   utxoΓ = ⟦ slot , pparams , treasury , utxo₀ , certState
           , allScripts , RewardsOf certState ⟧

with certState (= the pre-batch state) used in both the LEDGER-V and
LEDGER-I cases.  This resolves the [NotInScope] error from
calculateDepositsChange (which no longer exists) and removes the
vestigial CertState → CertState arguments to utxoΓ-valid that were
unused after the refactor.

The completeness side gets one small additional change: the implicit
argument order in the LEDGER-V destructuring is reorganised to match
the constructor's declared order
   {utxoState₁ , govSt₁ , certSt₁ , certSt₂ , govSt₂ , utxoSt₂}
so the subsequent computeSubledgers / computeEntities / computeGov /
computeUtxow pattern matches against the right intermediate states.

Also adds a "Design Note: Cert-State Threading and Deposit Accounting"
subsection to Utxo.lagda.md explaining the rationale for the
refactor.  Key points:

+  The UTXO rule has been promoted from a consumer of CertState data
   to a secondary executor of certificate accounting:
   updateCertDeposit recomputes the deposit evolution that the
   CERT/ENTITIES rules also produce as part of their operational
   semantics.
+  The same certificate-deposit logic now exists in two places --
   inside the DELEG/POOL/GOVCERT sub-rules of CERT, and inside
   updateCertDeposit in Utxo.lagda.md.
+  Any drift between the two is a soundness problem, since it would
   admit transactions whose UTxO-side balance equation accepts but
   whose actual CertState evolution doesn't balance.  The note states
   the consistency obligation as a lemma to be discharged alongside
   LEDGER-pov.
Adapt LEDGER computational instance to certState-threaded UTxOEnv
UTxOEnv now carries the pre-batch CertState directly rather than a
precomputed DepositsChange, so the LEDGER computational instance no
longer needs separate environments for the valid and invalid cases.
The two old builders (utxoΓ-valid : CertState → CertState → UTxOEnv,
utxoΓ-invalid : UTxOEnv) collapse into a single

   utxoΓ : UTxOEnv
   utxoΓ = ⟦ slot , pparams , treasury , utxo₀ , certState
           , allScripts , RewardsOf certState ⟧

with certState (= the pre-batch state) used in both the LEDGER-V and
LEDGER-I cases.  This resolves the [NotInScope] error from
calculateDepositsChange (which no longer exists) and removes the
vestigial CertState → CertState arguments to utxoΓ-valid that were
unused after the refactor.

The completeness side gets one small additional change: the implicit
argument order in the LEDGER-V destructuring is reorganised to match
the constructor's declared order
   {utxoState₁ , govSt₁ , certSt₁ , certSt₂ , govSt₂ , utxoSt₂}
so the subsequent computeSubledgers / computeEntities / computeGov /
computeUtxow pattern matches against the right intermediate states.

Also adds a "Design Note: Cert-State Threading and Deposit Accounting"
subsection to Utxo.lagda.md explaining the rationale for the
refactor.  Key points:

+  The UTXO rule has been promoted from a consumer of CertState data
   to a secondary executor of certificate accounting:
   updateCertDeposit recomputes the deposit evolution that the
   CERT/ENTITIES rules also produce as part of their operational
   semantics.
+  The same certificate-deposit logic now exists in two places --
   inside the DELEG/POOL/GOVCERT sub-rules of CERT, and inside
   updateCertDeposit in Utxo.lagda.md.
+  Any drift between the two is a soundness problem, since it would
   admit transactions whose UTxO-side balance equation accepts but
   whose actual CertState evolution doesn't balance.  The note states
   the consistency obligation as a lemma to be discharged alongside
   LEDGER-pov.