MoXIchecker: Direct SMT-Based Model Checker

• MoXIchecker is a symbolic model checker for MoXI, directly constructing and solving SMT-based verification tasks without lower-level translations.
• It employs a solver-agnostic architecture via PySMT and supports multiple algorithms including bounded model checking, k-induction, and IC3/PDR.
• Evaluation shows MoXIchecker reliably handles richer theories, like linear and nonlinear arithmetic, outperforming previous BTOR2-based approaches.

Searching arXiv for MoXIchecker and related MoXI papers. MoXIchecker is a symbolic model checker for MoXI, an intermediate verification language introduced in 2024 to promote standardization and open-source implementations for symbolic model checking by extending SMT-LIB 2 with constructs to define state-transition systems. Rather than translating MoXI verification tasks to lower-level hardware-oriented formats, MoXIchecker solves them directly, using PySMT as a solver-agnostic backend for SMT-based verification algorithms. Its defining role is to provide an extensible, direct verification engine for MoXI tasks, especially for theories such as integer and real arithmetic that cannot be precisely expressed with fixed-length bit-vectors in BTOR2 (Ates et al., 2024).

1. Origin and verification setting

MoXI is described as a new intermediate verification language whose purpose is to standardize the representation of symbolic model-checking problems while enabling modular, reusable tool chains. It is based on SMT-LIB 2, but extends it with constructs to define state-transition systems, including system declarations, initial conditions, transition relations, invariance constraints, and reachability queries. This positioning makes MoXI suitable as an interchange format between front-end translators and back-end verification engines (Ates et al., 2024).

The earlier MoXI tool suite provided an SMV-to-MoXI translator, a MoXI-to-BTOR2 translator, and a translation-based model checker called MoXI-MC-FLOW. In that workflow, a MoXI task is translated to an equisatisfiable BTOR2 task and then analyzed by mature BTOR2 model checkers such as AVR, BTORMC, and PONO. The principal limitation identified for that approach is that BTOR2 is tailored to fixed-width bit-vectors and arrays, so more expressive theories such as integers, reals, and nonlinear arithmetic cannot be precisely represented. The paper states that integers are typically approximated by fixed-width bit-vectors, which introduces overflow and underflow and breaks soundness and completeness (Ates et al., 2024).

Against this background, MoXIchecker is presented as the first model checker that solves MoXI verification tasks directly. This suggests a methodological shift from translation-centric verification toward SMT-level verification over the original intermediate language itself. A plausible implication is that MoXIchecker is intended not merely as another backend, but as an infrastructural component for a more interoperable verification ecosystem centered on MoXI (Ates et al., 2024).

2. Direct verification on MoXI

MoXIchecker accepts MoXI verification tasks in JSON form and directly constructs SMT formulas corresponding to the verification problem. The central semantic objects are the initial condition $I(s)$, the transition relation $T(s,s')$, the invariance condition $\mathrm{Inv}(s)$, and the reachability condition $Q(s)$. A reachability-safety task is therefore represented as $(I,T,\mathrm{Inv},Q)$ (Ates et al., 2024).

The specification considered is the LTL formula

$\mathrm{spec}(M) = \mathbf{G}\neg Q,$

that is, “always not $Q$.” The system is safe if no reachable state satisfies $Q$. Operationally, $\mathrm{Inv}(s)$ is conjoined with $I(s)$ and with the transition constraints to restrict analysis to admissible states. States are tuples of values for the system variables, and the formulas $T(s,s')$0 and $T(s,s')$1 characterize initial and one-step successor states in the usual symbolic-transition-system sense (Ates et al., 2024).

This direct treatment distinguishes MoXIchecker from the BTOR2-based flow at both the semantic and implementation levels. No translation to a lower-level circuit language is required, so there is no circuit encoding overhead and no approximation of richer theories into fixed-width encodings. The paper also emphasizes that avoiding the BTOR2 detour reduces confounding factors when comparing algorithms, because the algorithms operate on the same SMT-level model rather than through distinct hardware-oriented encodings (Ates et al., 2024).

3. Architecture and implementation model

The architecture of MoXIchecker consists of four stages: input, formula construction, verification, and output. It reads a MoXI verification task in JSON following the MoXI JSON schema; defines PySMT symbols for state variables, including primed next-state variables; builds SMT formulas for $T(s,s')$2, $T(s,s')$3, $T(s,s')$4, and $T(s,s')$5; invokes one of several verification engines; and returns a verdict of safe or unsafe (Ates et al., 2024).

Its backend is PySMT, a Python library that abstracts over SMT solvers. The paper characterizes this as solver-agnosticism: MoXIchecker’s code does not depend on solver-specific APIs, changing solvers is a configuration choice rather than a code change, and the verification algorithms are written uniformly in terms of PySMT formula objects and solver operations such as assertions, push/pop, and solving. In the reported experiments, the solvers used are Z3 and MathSAT5 (Ates et al., 2024).

The implementation is explicitly described as extensible. The reasons given are threefold: it accommodates verification tasks involving more complex theories not limited by lower-level languages, it facilitates the implementation of new algorithms, and it is solver-agnostic by using the API of PySMT. The paper further notes a clean separation between the frontend, which parses JSON and builds SMT formulas, and the algorithms, which operate on symbolic transition systems through PySMT (Ates et al., 2024).

The current version has explicit limitations. It does not yet support composition of multiple subsystems via the :subsys attribute in define-system, and it does not yet support fairness constraints via the :fairness attribute in check-system. Witness generation is also absent, even though MoXI specifies formats for verification witnesses such as error traces and invariants. The focus is therefore on reachability safety rather than full LTL with fairness (Ates et al., 2024).

4. Supported theories and extensibility

MoXIchecker currently supports the quantifier-free SMT-LIB 2 fragments QF_BV, QF_ABV, QF_LIA, QF_LRA, QF_NIA, and QF_NRA. Concretely, this covers bit-vectors, arrays over bit-vectors, linear integer arithmetic, linear real arithmetic, nonlinear integer arithmetic, and nonlinear real arithmetic. The inclusion of these fragments is central to the system’s identity, because it marks a substantial departure from verification flows constrained by BTOR2’s bit-vector-and-array orientation (Ates et al., 2024).

The contrast with the translation-based MoXI tool suite is explicit. In that flow, integer tasks are encoded using 32-bit bit-vectors, which the paper identifies as a source of unsound or incomplete behavior because overflow and underflow become artifacts of the encoding rather than properties of the original system. Real arithmetic has no support there. MoXIchecker instead relies on SMT solvers that natively support these theories, thereby avoiding such approximations (Ates et al., 2024).

Extensibility is described at both the theory level and the algorithmic level. As long as PySMT and an SMT solver support a theory, MoXIchecker can be extended to parse formulas in that theory from the MoXI JSON and use those formulas in verification algorithms without changing the algorithmic logic. On the algorithmic side, the architecture explicitly anticipates new algorithm modules alongside BMC, k-induction, and IC3/PDR (Ates et al., 2024).

The paper illustrates this extensibility with a custom incremental k-induction implementation that reuses solver stacks via push/pop. That implementation improves over the example in PySMT’s model_checking.py in both performance and number of tasks solved. This serves as an instance of the framework’s intended role as a platform for verification-algorithm development, not only as a fixed verifier (Ates et al., 2024).

5. Verification algorithms

MoXIchecker implements three main algorithms: bounded model checking, k-induction, and IC3/PDR. All are applied to reachability-safety tasks of the form $T(s,s')$6 (Ates et al., 2024).

Bounded model checking searches for counterexamples up to a bound $T(s,s')$7 using the formula

$T(s,s')$8

If this formula is satisfiable, there exists a trace of length at most $T(s,s')$9 that reaches a target state, so the system is unsafe. If it is unsatisfiable, then there is no counterexample of length at most $\mathrm{Inv}(s)$0 (Ates et al., 2024).

For k-induction, MoXIchecker uses the standard base and step cases. The base case checks the absence of counterexamples up to depth $\mathrm{Inv}(s)$1; the step case assumes the property for a window of length $\mathrm{Inv}(s)$2 and proves it for the next state. The paper gives the step-case SAT query as

$\mathrm{Inv}(s)$3

If both the base and step cases are unsatisfiable for some $\mathrm{Inv}(s)$4, the property is proved inductively (Ates et al., 2024).

A concrete example is provided by a 3-bit counter. The state variable $\mathrm{Inv}(s)$5 is a 3-bit bit-vector, the initial condition is $\mathrm{Inv}(s)$6, the transition is $\mathrm{Inv}(s)$7, the target condition is that $\mathrm{Inv}(s)$8, and the invariance condition is true. The paper states that MoXIchecker’s k-induction proves safety because 0 is even and adding 2 preserves parity (Ates et al., 2024).

IC3/PDR is also implemented. The paper describes it at a high level as maintaining a sequence of frames $\mathrm{Inv}(s)$9 that over-approximate reachable states, blocking counterexample states by refining frames, and proving safety when a fixpoint is reached. Rather than developing a new implementation from first principles, MoXIchecker integrates the existing IC3/PDR implementation from PySMT into its framework (Ates et al., 2024).

6. Evaluation and comparative performance

The evaluation addresses two research questions: how effective and efficient MoXIchecker is relative to MoXI-MC-FLOW on QF_BV tasks, and whether MoXIchecker can solve tasks involving richer theories that the BTOR2-based flow fails on (Ates et al., 2024).

For the QF_BV benchmark, the paper uses 382 tasks, of which 225 are safe and 157 are unsafe. MoXIchecker is evaluated with MathSAT5 and Z3, with and without incremental solving, while MoXI-MC-FLOW is evaluated with AVR and PONO. The reported result is that MoXIchecker with MathSAT5 and incremental solving delivers the most correct results. The paper also states that MoXIchecker solved 17 tasks that MoXI-MC-FLOW failed to translate to BTOR2 (Ates et al., 2024).

In efficiency terms, the paper reports that, despite being written in Python, MoXIchecker achieves comparable performance to C++ hardware model checkers because approximately 90% of time is spent in the SMT solver. The quantile plot described in the paper places MoXIchecker’s curves below those of MoXI-MC-FLOW, especially at small runtimes, which is interpreted as lower startup overhead. For tasks solved by both, MoXIchecker is reported as faster on 117 out of 161 tasks (Ates et al., 2024).

For tasks involving richer theories, the evaluation uses nine handcrafted tasks spanning QF_LIA, QF_LRA, QF_NIA, and QF_NRA, with examples including Fibonacci sequence, integer counters, nonlinear growth over reals, and oscillating ratios. MoXIchecker correctly solves all 9 tasks. By contrast, MoXI-MC-FLOW uses 32-bit bit-vectors to encode integer tasks and thereby exhibits unsound or incomplete behavior, and it has no support for real tasks, which it reports as unsupported (Ates et al., 2024).

These results support two claims made in the paper: that MoXIchecker is reliable because it avoids incorrect results due to theory approximation, and that it is versatile because it handles integer and real arithmetic, including nonlinear arithmetic. This suggests that its most significant empirical contribution lies not only in replacing an existing backend, but in broadening the practical scope of MoXI-based verification itself (Ates et al., 2024).

7. Position within the verification ecosystem

MoXIchecker is situated within a broader trend toward SMT-based model checking, alongside systems such as nuXmv, Kind, PONO, and IC3/PDR-based tools, but its distinctive feature is that it is anchored in MoXI as the intermediate language rather than in a tool-specific input format. The paper presents this as a matter of standardization and interoperability: a common intermediate language enables reusable translators from source languages to MoXI, multiple model checkers operating on the same format, and more comparable experiments across tools and algorithms (Ates et al., 2024).

Its practical workflow reflects this role. A task may be prepared by translating from SMV using the MoXI tool suite, by writing MoXI directly, or by writing in MoXI JSON format following the schema. MoXIchecker then processes the JSON input, applies the chosen algorithm and solver configuration, and returns a safe or unsafe verdict. At present it does not yet export witness traces, so its outputs are verification verdicts rather than diagnostic artifacts (Ates et al., 2024).

The paper also emphasizes an open-source and educational dimension. MoXIchecker’s Python implementation is presented as a lightweight platform for algorithm experimentation and as a reference implementation built on PySMT. A plausible implication is that the system is intended to lower the barrier to implementing and evaluating new symbolic model-checking algorithms over a common benchmark and interchange format, while avoiding entanglement with low-level hardware encodings (Ates et al., 2024).

Future work identified by the authors includes extending MoXI language support to system composition, fairness, and witness output in MoXI’s witness format; improving existing algorithms through more efficient encodings and advanced heuristics; adding new algorithms such as interpolation-based model checking and CEGAR; and applying MoXIchecker to software programs and cyber-physical systems. In that sense, MoXIchecker is both a concrete verifier and a research vehicle for an SMT-centric MoXI ecosystem (Ates et al., 2024).