{"id":"44a339d3-f83f-4163-91c6-6b396b078676","arxiv_id":"2607.03406","paper_version":2,"verdict":"ACCEPT","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"low","formal_verification":"full","parameter_count":0,"one_line_summary":"LeanDY unifies compositional type-based and inductive trace-based verification in Lean, supporting stateful protocols, XOR conditional secrecy, and a mechanized payment-channel formalization with liveness.","lead":"LeanDY is a Lean library that combines type-based and trace-based symbolic proofs for cryptographic protocols that use state, XOR, and conditional secrecy. It lets researchers modularly verify complex protocols such as blockchain payment channels, including punishment and chain-liveness properties that automated tools usually cannot handle.","discovery_kind":"new_method","skeptic_critique":{"model":"grok-4.5","headline":"No significant objection identified","rationale":"The paper's strongest claim is that a single mechanized framework supports secrecy/authentication for stateful unbounded protocols, recursive conditional secrecy for XOR, and a non-trivial payment-channel case study that includes both punishment safety and chain-liveness-dependent properties. The reader's weakest_assumption correctly identifies the external liveness hypotheses of Listing 3; those hypotheses are load-bearing for the on-chain punishment guarantee but are not load-bearing for the methodological claim that LeanDY can state and prove such theorems. The modeling choices (Dolev-Yao, single canonical chain extracted from MsgSent events, external liveness) are explicit and standard for the intended symbolic setting. Machine-checked theorems, the LAC-guided DSL, and the publicly claimed artifact supply independent support. No stronger internal concern (e.g., unsound labeling of XOR, broken transition_valid, or circular use of the type system) is visible in the technical report. Therefore the ACCEPT verdict stands without adjustment.","tokens_in":32639,"tokens_out":507,"duration_ms":4575,"concrete_test":"Clone the public LeanDY artifact [32], build the payment-channel development, and confirm that punish.eventually_on_chain type-checks with the stated hypotheses and that the safety lemmas of Sec. 4.2.4 (ready_state_imp_valid_tx, transaction structure) hold without the liveness assumptions. If the theorems compile as claimed, the central expressiveness claim stands.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The reader's weakest_assumption correctly flags that punish.eventually_on_chain (Listing 3 / Sec. 4.2.5) is conditional on participant and miner liveness hypotheses plus single-chain reconstruction from the trace. Those assumptions are stated explicitly in the theorem statement (hlpunish, hlminer, hheight_final, htime_budget) and in the model design (List.get_blockchain). They do not undermine the central claim that LeanDY can express and machine-check such conditional liveness properties together with stateful secrecy/authentication and XOR conditional secrecy in one library. The type-system soundness (Property 2), transition_valid, and the payment-channel safety lemmas are independent of those external hypotheses. No hidden circularity or internal inconsistency appears in the argument as presented.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.5","summary":"The paper presents LeanDY, a Lean library for symbolic Dolev–Yao protocol verification that unifies compositional type-based reasoning with inductive trace-based proofs, extending the design of DY*. Guided by language-and-automation co-design, it provides an eDSL for protocol exchanges, a general trace invariant (valid_trace) parameterized by user predicates, secrecy labels that form a complete lattice over trace properties (including conditional-swap/releasable labels and meet/join), and automation (prove_* tactics, intro_valid_exchange, Aesop configurations) that discharges routine valid_exchange goals while allowing interactive Lean proofs for protocol-specific obligations. The framework supports mutable state, dynamic compromise, and recursive conditional secrecy for XOR via basis-generated labeling environments. As a substantial case study, the authors formalize SegWit-style UTXO blockchain primitives (TXIDs, witnesses, scripts via a decidable Script type class, spendable pointers, prefix-based chain validity) and an in-depth two-party payment-channel protocol, proving transaction-structure safety lemmas and a conditional punishment-liveness theorem (punish.eventually_on_chain) under explicit participant- and miner-liveness hypotheses.","tokens_in":32846,"tokens_out":1506,"duration_ms":21346,"significance":"If the development is as claimed, this is a solid and timely contribution to mechanized symbolic protocol analysis. It addresses a genuine gap between push-button tools (ProVerif/Tamarin) with limited expressiveness for state, liveness, and XOR, and fully interactive general-purpose provers with little protocol-specific automation. Strengths that should be credited explicitly: (i) machine-checked core results (type-system soundness Property 2, transition_valid, valid_exchange preservation) and a non-trivial case study with safety lemmas and a liveness theorem stated with explicit hypotheses; (ii) a reusable library design (UserPreds, CryptoPreds, ValidParsable, from_basis labeling) rather than a one-off protocol proof; (iii) a unified treatment of recursive conditional secrecy for XOR with dynamic compromise, previously not combined in a single mechanized framework; (iv) publicly available code. The payment-channel formalization, including chain-liveness-dependent punishment, is a convincing expressiveness demonstration for layer-2 protocols that automated tools struggle with.","major_comments":[{"comment":"Sec. 3.1.3–3.2 and Property 2 / transition_valid: The central soundness claims are stated as Lean theorems, which is a major strength, but the manuscript never states whether the accompanying library is sorry-free for these results and for the payment-channel development, nor which lemmas (if any) remain as axioms or incomplete proofs. For a journal archival claim of a mechanized framework, please add an explicit inventory (e.g., number of theorems, remaining sorries, and which results are fully checked vs. sketched in the paper only).","section":null},{"comment":"Sec. 4.2.5, Listing 3 (punish.eventually_on_chain): The theorem is correctly conditional on hlpunish, hlminer, htime_budget, hnot_corrupt, h_old, and hno_race, and the single-chain reconstruction (List.get_blockchain) is an explicit modeling choice. The central claim that LeanDY can express such properties is therefore intact. However, the security discussion should more sharply separate (a) what is proved about the protocol under those hypotheses from (b) what is assumed about the network and miners, and should discuss how fragile the conclusion is if miner_liveness fails for even a short window relative to toSelfDelay. A short threat-model paragraph would prevent over-reading the result as unconditional Lightning security.","section":null},{"comment":"Sec. 3.2.2 and the LAC claims: The paper asserts protocol-specific automation that gracefully hands control back for cryptographic goals, illustrated on a small authentication example. The payment-channel case study is the real stress test, yet there is no quantitative report (LOC of protocol vs. proof, fraction of goals closed by intro_valid_exchange / aesop_type_system, manual proof effort for signing invariants and liveness). Without this, the claim that LeanDY improves on extrinsic DY* / F* workflows remains qualitative. Adding a short evaluation table for the payment-channel development would make the automation contribution load-bearing rather than anecdotal.","section":null}],"minor_comments":[{"comment":"Fig. 1 and Sec. 2: The conditional-release running example is clear, but the notation [L1/L2]_E is introduced before the general Label structure (corrupt0) of Sec. 3.1.3; a forward pointer would help readers who start from the example.","section":null},{"comment":"Sec. 3.1.2: Nonces are fixed a priori (η decided before execution), a deliberate departure from DY*. The text should briefly discuss the modeling cost for protocols that generate unboundedly many fresh nonces at runtime, even if the payment-channel Nonce inductive type is finite-parameterized by timepoints.","section":null},{"comment":"Sec. 4.1.2 Script type class: Abstracting the Bitcoin VM to a decidable eval is reasonable; please note explicitly which real script features (e.g., OP_CHECKLOCKTIMEVERIFY edge cases, script size limits, non-standard scripts) are out of scope so that the gap to BIP-compliant validation is clear.","section":null},{"comment":"Sec. 5 Related Work: The comparison with Wallez’s extrinsic DY* and with TLA+/Why3 Lightning efforts is present but could more crisply list feature-by-feature differences (XOR conditional labels, basis automation, blockchain liveness in one library). A small comparison table would help.","section":null},{"comment":"Typos / polish: “♂radiation-alt” in Sec. 2 appears to be a corrupted compromise symbol; “LAC” is expanded inconsistently; Listing 2 uses “Id.run do” without explaining the Id monad to non-Lean readers. A light copy-edit pass is warranted.","section":null},{"comment":"Availability: The GitHub link [32] is given; please also pin a commit or artifact DOI for long-term reproducibility of the exact development corresponding to this technical report.","section":null}],"recommendation":"minor_revision","confidential_remarks":"The manuscript is labeled a technical report and is long; if the venue has strict page limits, the blockchain/payment-channel material could be split into a companion paper, but for a journal that accepts substantial formalizations this length is appropriate. Novelty relative to DY* and the recent extrinsic DY* line is real (XOR conditional secrecy + Lean automation + blockchain liveness case study) but should be stated more sharply in the camera-ready to avoid “yet another DY* port” misreading. No integrity concerns; code availability is a plus."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"This is a usable advance, not a conceptual revolution. LeanDY takes the DY* design, ports and extends it into Lean with a proper eDSL, conditional-swap labels, automatic XOR labeling via a basis, and a SegWit-style blockchain model, then uses it for a non-trivial payment-channel formalization that includes punishment and chain-liveness arguments.\n\nWhat is new is the combination in one mechanized setting: compositional type-based reasoning for secrecy/authentication of stateful unbounded protocols, recursive conditional secrecy for XOR (including the chained-release pattern), and the ability to drop into interactive Lean proofs for cross-layer and liveness goals. The type-system soundness (Property 2), transition_valid, and valid_exchange preservation are stated as Lean theorems. The payment-channel development is the real demonstration: they model funding, commitments, revocation, ToLocal/ToRemote scripts, and prove both ordinary safety lemmas and punish.eventually_on_chain under explicit participant- and miner-liveness hypotheses. Code is claimed public. That is more than most protocol-verification papers deliver.\n\nSoft spots are modest and mostly declared. The liveness theorem is conditional on external hypotheses (defense exchange fires within punish_time blocks, miners include valid txs within miner_time, single canonical chain reconstructed from the trace). Those assumptions are written into the theorem statement; they do not hide inside the type system or the safety lemmas. The blockchain model is deliberately simplified (no full VM, no fees, no cooperative close). Automation is protocol-specific rather than push-button for everything; when it fails you fall back to Lean, which is the point of the LAC design. No circularity or load-bearing sorries are visible in the technical report.\n\nThis is for people who already work in symbolic protocol verification or formal methods for blockchain layer-2. If you care about Lightning-style protocols, XOR conditional secrecy, or reusable Lean libraries that mix automation with interactive proofs, read it and look at the code. It deserves a serious referee; I would accept it for peer review and would cite the library and the payment-channel development if I were working in the area.","headline":"Solid Lean library that actually unifies type-based automation with interactive trace proofs for stateful/XOR protocols and payment-channel liveness; the case study is real work, not a toy.","tokens_in":33414,"tokens_out":527,"would_cite":true,"duration_ms":6192,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"LeanDY unifies type-based and trace-based proofs so stateful, unbounded, XOR-using protocols can be verified modularly in Lean, including payment-channel punishment under chain liveness.","keywords":["symbolic protocol verification","Lean","type systems","trace invariants","conditional secrecy","XOR","payment channels","blockchain liveness"],"falsifier":"Exhibit a well-typed payment-channel execution under the stated participant and miner liveness bounds in which a revoked commitment is published and the corresponding punishment transaction never appears on the reconstructed chain before the to_self_delay expires.","tokens_in":33527,"feed_emoji":"🔗","tokens_out":603,"duration_ms":5542,"temperature":0.7,"pith_summary":"Protocol verification has long split into automated tools that struggle with state, time, unbounded runs, and conditional secrecy, versus interactive theorem proving that is flexible but weakly automated for protocol work. This paper argues that the two styles can be combined: compositional type-based reasoning for modularity and automation, plus inductive trace-based reasoning when more expressivity is needed. The result is LeanDY, a Lean library that lets users write protocols in a small domain-specific language, obtain protocol-specific automation for well-typed exchanges, and fall back to interactive proofs for cross-layer or liveness goals. The library handles dynamic compromise, mutable state, and recursive conditional secrecy for XOR, including chained release patterns. To show the approach scales, the authors build a SegWit-style blockchain model and fully formalize two-party payment channels, proving both ordinary safety facts and that a revoked close is eventually punished if defenders and miners meet explicit liveness bounds.","feed_headline":"Lean library verifies payment channels under chain liveness","feed_subtitle":"Type-based automation plus interactive traces cover XOR secrecy and punishment","key_machinery":"The valid_exchange property for each message exchange, lifted by the transition function to preservation of the valid_trace invariant; secrecy is expressed by monotone, trace-dependent labels (including releasable conditional swaps and meets for XOR) whose lattice structure and soundness relative to a Dolev-Yao attacker supply the automation.","core_discovery":"LeanDY shows that a single mechanized framework can support secrecy and authentication for stateful unbounded protocols together with recursive conditional secrecy for XOR, and that the same framework can verify payment-channel punishment mechanisms and properties that depend on chain liveness by combining type-based exchange proofs with interactive trace reasoning.","pith_inferences":[],"forward_implications":[],"fun_headline_variants":["LeanDY verifies payment-channel punishments under chain liveness","Type-and-trace framework checks stateful protocols and XOR secrecy","LeanDY unifies modular types with interactive traces for protocols","Formalizing SegWit primitives and payment channels in LeanDY","Single Lean framework covers unbounded secrecy and channel liveness"],"cache_read_input_tokens":16512,"weakest_assumption_plain":"The on-chain punishment guarantee holds only if defenders react within a fixed block budget, miners eventually include valid transactions within another fixed budget, and a single canonical chain can be reconstructed from the protocol trace.","fun_headline_variants_meta":{"raw":{"variants":["LeanDY verifies payment-channel punishments under chain liveness","Type-and-trace framework checks stateful protocols and XOR secrecy","LeanDY unifies modular types with interactive traces for protocols","Formalizing SegWit primitives and payment channels in LeanDY","Single Lean framework covers unbounded secrecy and channel liveness"]},"model":"grok-4.5","effort":"low","cost_usd":0.003802,"raw_usage":{"total_tokens":1227,"prompt_tokens":794,"num_sources_used":0,"completion_tokens":83,"cost_in_usd_ticks":38020000,"prompt_tokens_details":{"text_tokens":794,"audio_tokens":0,"image_tokens":0,"cached_tokens":256},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":350,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":794,"tokens_out":83,"duration_ms":14481,"temperature":1.0,"reasoning_tokens":350,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-12T02:42:20.075541+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"Exhibit a well-typed payment-channel execution under the stated participant and miner liveness bounds in which a revoked commitment is published and the corresponding punishment transaction never appears on the reconstructed chain before the to_self_delay expires.","supporting_citations":[],"review_version":1}