Linear RAT (LRAT) Proof Format

• Linear RAT (LRAT) is a clausal proof format that extends DRAT by bundling explicit hints with clause additions to certify propositional unsatisfiability.
• It uses RUP and RAT rules to add or delete clauses with guided propagation, converting search-intensive checks into a streamlined, linear verification process.
• Implemented in systems like Coq, ACL2, and Lean 4, LRAT supports certified unsatisfiability proofs and smooth theorem import through reflection.

Searching arXiv for the specified LRAT papers and closely related SAT-certificate work. Linear RAT (LRAT) is a clausal proof format for certifying propositional unsatisfiability. It refines DRAT by attaching proof hints to clause additions, so that verification becomes a guided sequence of RUP and RAT checks rather than a search-intensive reconstruction procedure. In the 2016 formulation, LRAT was introduced to facilitate simple and fast validation algorithms suitable for implementation in trusted systems such as theorem-prover-supported languages, with certified checkers demonstrated in Coq and ACL2 (Cruz-Filipe et al., 2016). A later Lean 4 account presents LRAT certificates as the interface by which SAT solver refutations can be imported into an interactive theorem prover by reflection, including cube-and-conquer composition and semantic lifting from CNF-level unsatisfiability to problem-level theorems (Szeider, 1 Jul 2026).

1. Logical basis and derivation rules

LRAT is defined over propositional CNF formulas. A clause may be introduced either by Reverse Unit Propagation (RUP) or by Resolution Asymmetric Tautology (RAT). In the Lean-oriented formulation, a clause $C$ is RUP-derived with respect to $F$ when

$$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$

that is, unit propagation from $F \cup \{\neg C\}$ derives a conflict. A clause $C$ has the RAT property on pivot literal $\ell \in C$ with respect to $F$ when, for every clause $D \in F$ with $\neg \ell \in D$, the resolvent

$$R_{C,D,\ell}\;=\;(C\setminus\{\ell\})\cup (D\setminus\{\neg\ell\})$$

is itself RUP-derived from $F$0 (Szeider, 1 Jul 2026).

This yields two addition rules and one deletion rule. The RUP-add rule admits $F$1 when unit propagation from $F$2 reaches contradiction; the RAT-add rule admits $F$3 when every required resolvent check reduces to RUP; and deletion simply removes a clause from the active formula (Szeider, 1 Jul 2026). A full LRAT certificate is therefore a sequence of add- and delete-steps ending in the empty clause.

The 2016 exposition presents the same proof-theoretic content through the operational viewpoint of clause-indexed additions and deletions. There, every clause is identified by a positive integer index, and a clausal proof is a sequence of such indexed proof steps. This emphasizes that LRAT is not merely a semantic criterion; it is a certificate language designed so that each admissible addition is accompanied by enough structure to validate the corresponding RUP or RAT obligation directly (Cruz-Filipe et al., 2016).

2. Syntax, clause indices, and proof hints

In the 2016 formalization, an LRAT proof is a sequence of lines, each of which is either a deletion or an addition. A clause $F$4 is encoded as a list of literals ending in $F$5, and an addition line has the form $F$6, where $F$7 is a fresh clause index and the first literal $F$8 is the pivot if the clause has length greater than one. The hint list consists of nonzero integers: positive indices indicate clauses used in unit propagation, while negative indices $F$9 designate RAT candidates, meaning that clause $$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$0 contains the complement of the pivot and must be checked through a resolvent-based AT check (Cruz-Filipe et al., 2016).

In that account, LRAT extends DRAT by recording exactly the information that a checker would otherwise have to recover by search. For each clause index $$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$1 with $$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$2, the proof records a negative hint $$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$3, in ascending order of $$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$4, followed immediately by a block of positive hints giving the exact unit-propagation steps that witness the AT check on the resolvent with $$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$5. The intended consequence is that the checker can process each candidate clause in one left-to-right pass over the hint list, with no search and no repeated scanning of the full formula (Cruz-Filipe et al., 2016).

The Lean 4 presentation uses a slightly different on-disk description. In the standard textual LRAT format, each line is either a deletion

$$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$6

or an addition

$$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$7

where $$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$8 is the new clause’s unique index, $$F\;\cup\;\{\neg C\}\quad\vdash_{\!\mathrm{UP}\;}\bot,$$9 are its literals, $F \cup \{\neg C\}$0 is the pivot literal, with $F \cup \{\neg C\}$1 for pure RUP, and $F \cup \{\neg C\}$2 are hint-clause indices for unit propagation or RAT resolvents. The same account also notes that binary LRAT uses a compact variable-length coding of the same sequences, and that solver-side hints are produced by tracing watched-literal BCP or by extracting resolution chains (Szeider, 1 Jul 2026).

These two descriptions should be read as complementary presentations of the same certificate discipline. One emphasizes signed hints tied to an implicit pivot convention, while the other emphasizes an explicit pivot field. In both cases, the defining feature is the presence of proof hints that specify how RUP and RAT obligations are to be discharged.

3. Validation procedure and complexity

The 2016 checker model assumes as input an original CNF $F \cup \{\neg C\}$3 and a proof $F \cup \{\neg C\}$4, maintains a map $F \cup \{\neg C\}$5 from indices to clauses, and uses a watch structure for unit propagation. On a deletion step, the checker removes the listed clauses from $F \cup \{\neg C\}$6. On an addition step, it parses the new clause $F \cup \{\neg C\}$7, determines the pivot literal, resets local watch state, and processes the hints in order. Positive hints invoke a propagation action, while negative hints identify a RAT candidate clause $F \cup \{\neg C\}$8 for which the checker must validate the corresponding resolvent via guided propagation. If all checks succeed, the new clause is inserted under its index. The checker returns success when the empty clause is present (Cruz-Filipe et al., 2016).

The Lean account presents the same algorithmic structure using a map $F \cup \{\neg C\}$9. For each certificate step, deletion removes identifiers from $C$0; addition either performs a guided RUP check when $C$1, or iterates over clauses $C$2 with $C$3 and checks RUP of each resolvent $C$4. If all subchecks succeed, the checker inserts the new clause, and if that clause is empty, returns success immediately (Szeider, 1 Jul 2026).

A central purpose of LRAT is to make this algorithm linear in the size of the certificate data actually consumed by the checker. In the 2016 analysis, if $C$5 is the number of proof lines and $C$6 is the total number of hints, then the checker runs in

$C$7

amortized time, because each hint is processed exactly once and watches ensure that each propagation step runs in amortized $C$8. Space usage stores the current clause set and watch pointers, giving $C$9 clauses in memory at once, or $\ell \in C$0 when each clause has average length $\ell \in C$1 (Cruz-Filipe et al., 2016).

This complexity characterization differentiates LRAT from DRAT checking as described in the same source. Without hints, a checker must scan the active formula to find all clauses containing the complement of the pivot and perform unit propagation from scratch on each required resolvent. LRAT avoids that reconstruction cost by making the certificate itself carry the relevant propagation schedule (Cruz-Filipe et al., 2016).

4. Soundness, completeness, and certified verification

The 2016 exposition states a soundness theorem for LRAT checking: if $\ell \in C$2 returns $\ell \in C$3, then $\ell \in C$4 is unsatisfiable. It also states a completeness theorem for the format: for every valid DRAT proof $\ell \in C$5 of unsatisfiability of $\ell \in C$6, there exists an LRAT proof $\ell \in C$7, obtained by adding the required hints, such that $\ell \in C$8 returns $\ell \in C$9 (Cruz-Filipe et al., 2016).

A major consequence is that proof production and proof checking can be separated with a high-assurance checker that is substantially simpler than a full DRAT-trim implementation. The Coq implementation in the 2016 account represents the working formula as a map from indices to well-formed clauses. It uses lemmas RAT_lemma_1 and RAT_lemma_2, a function RAT_check_run driven by an oracle list of hints, and the theorem RAT_theorem to show that successful checking preserves satisfiability. The final extracted checker is justified by $F$6 (Cruz-Filipe et al., 2016)

The ACL2 implementation reads clauses and proofs into applicative hash-tables, checks each step through a function refutation-p, defines satisfiability through an exists quantifier, and proves the top-level theorem $F$7 (Cruz-Filipe et al., 2016)

The Lean 4 account gives the soundness theorem of the core checker in the form

$F$0

This shifts the emphasis from standalone certificate validation to theorem import: the certificate checker is part of the trusted logical infrastructure used to derive internal unsatisfiability theorems (Szeider, 1 Jul 2026).

5. Reflection in Lean 4 and LRAT-Catcher

LRAT-Catcher is a standalone, general-purpose tool that imports a DIMACS formula together with an LRAT certificate into Lean 4 as a theorem by running the formally verified LRAT checker from Lean core as compiled native code via reflection (Szeider, 1 Jul 2026). The checker interface exposed in the Lean account is $F$8 and the key design choice is to evaluate checkLrat inside the elaborator rather than construct a large explicit proof term (Szeider, 1 Jul 2026).

Two reduction modes are provided. Kernel reflection, enabled by the “+kernel” flag, uses the trusted Lean kernel’s decide to normalize the equation checkLrat … = true; this introduces no more axioms than the kernel’s three standard axioms, namely propext, Quot.sound, and Classical.choice, but is slow and practical only for small certificates. Native reflection, the default mode, compiles checkLrat to native code and runs it via the native tactic; this adds one extra “native engine” axiom to the trusted base, but checking is hundreds of times faster and can handle hundreds of megabytes of certificate text in an ordinary Lean process (Szeider, 1 Jul 2026).

The same system supports a variant lrat_reflect_cnf for certificates against a Lean-defined CNF expression, and it supports cube-and-conquer runs entirely inside Lean. In that workflow, one supplies a base DIMACS file, a cube set, one LRAT leaf certificate per cube, and a cover certificate witnessing unsatisfiability of the negated-cubes CNF. A once-proved composition theorem,

$F$1

combines the leaf refutations with the cover refutation into a single theorem $F$2 (Szeider, 1 Jul 2026).

This deployment clarifies the role of LRAT in proof assistants. LRAT is not only a certificate format for offline validation; it is also a transport format for moving industrial SAT refutations into a foundational environment while preserving a small and explicit trusted base.

6. Relation to DRAT and empirical behavior

The 2016 comparison between DRAT and LRAT identifies three principal differences. First, LRAT proofs carry extra hint lists, and empirically this increases proof size by 10–20 % over the equivalent DRAT file. Second, because LRAT avoids repeated scans and UCP searches, even a certified LRAT checker in Coq or ACL2 runs as fast as, or faster than, an unverified DRAT-trim check of the DRAT file. Third, the LRAT checker is a simple linear pass over hints, with no low-level clause enumeration or pivot guessing, which makes the Coq and ACL2 formalizations straightforward and modular in contrast to the more intricate full DRAT-trim algorithm (Cruz-Filipe et al., 2016).

Aspect	DRAT	LRAT
Proof size	Baseline	Increases proof size by 10–20 %
Checking workflow	Requires scanning $F$3 and performing UCP from scratch on resolvents	Uses recorded hints in a simple linear pass
Formal verification	More intricate data structures and watched-literal machinery	Straightforward and modular certified formalizations

The Lean 4 evaluation adds a second comparison axis: not only LRAT versus DRAT, but also different ways of consuming LRAT certificates inside a theorem prover. Four workflows are compared on pigeonhole formulas and on Schur and Ramsey instances: native reflection, kernel reflection, external cake_lpr, and Mathlib’s lrat_proof. Native reflection scales far beyond kernel reflection and explicit proof-term import; cake_lpr is fastest and lightest but yields only an asserted axiom rather than a kernel-checked theorem; and lrat_proof, which is RUP only and has no RAT support, grows superlinearly in formula size and is killed around 64 MB of certificate, whereas native reflection stays under 9 GB even at 628 MB (Szeider, 1 Jul 2026).

The same evaluation reports that $F$4 is proved by a 256-leaf cube-and-conquer run with 777 MB total certificates in 316 s at 4.6 GB peak, and $F$5 by a 1024-leaf run with 49 GB trimmed certificates in 83 min at 188 GB peak on a 756 GB machine. In each case, the only trusted axioms are Lean’s three standard axioms plus at most one “native” axiom per reflected check, and the cover-and-lift composition adds no further axioms (Szeider, 1 Jul 2026).

A common misconception is that LRAT is simply DRAT with auxiliary annotations of convenience. The published accounts instead characterize the hints as the mechanism that changes the checker from a search-heavy validator into a guided verification pass. Another plausible implication is that the practical significance of LRAT depends not only on asymptotic complexity but also on where the checker is embedded: in Coq and ACL2 it enables certified standalone validation, while in Lean 4 it serves as a bridge from SAT-solver certificates to reusable internal theorems (Cruz-Filipe et al., 2016, Szeider, 1 Jul 2026).