Welcome to the website of the 27th International Conference on Verification, Model Checking, and Abstract Interpretation (VMCAI 2026).

VMCAI provides a forum for researchers from the communities of Verification, Model Checking, and Abstract Interpretation, facilitating interaction, cross-fertilization, and advancement of hybrid methods that combine these and related areas. VMCAI 2026 will be the 27th edition in the series. VMCAI 2026 will take place during January 12-13, 2026 as a physical (in-person) event in Rennes, France, co-located with POPL 2026.

Sponsorship

VMCAI is welcoming diamond, silver and bronze sponsors.

Keynotes

_Call for Artifacts

VMCAI 2026 makes available the option to submit an artifact along with a paper. Artifacts are any additional material that substantiates the claims made in the paper, and ideally makes them fully replicable. For some papers, these artifacts are as important as the paper itself because they provide crucial evidence for the quality of the results. The goal of artifact evaluation is twofold. On the one hand, we want to encourage authors to provide more substantial evidence to their papers and to reward authors who create artifacts. On the other hand, we want to simplify the independent replication of results presented in the paper and to ease future comparison with existing approaches. Artifacts of interest include (but are not limited to):

• Software, Tools, or Frameworks
• Data sets
• Test suites
• Machine checkable proofs
• Any combination of them
• Any other artifact described in the paper

Artifact submission is optional. However, we highly encourage the authors to also submit an artifact. A successfully evaluated artifact can increase your chance of being accepted since the evaluation result of your artifact is taken into account during paper reviewing. Artifact evaluation is single blind, artifacts should not be anonymous.

Badges

We award three types of badges, following the ACM guidelines:

• Available for artifacts that are publicly available under a DOI, e.g., on Zenodo or figshare.
• Functional for artifacts that are successfully evaluated by the artifact evaluation committee.
• Reusable for functional artifacts that exceed in quality and additionally provide careful documentation to allow for future repurposing.

Important Dates AoE (UTC-12)

The artifact evaluation will be done in parallel with the evaluation of the submitted paper. Since VMCAI has a tight schedule, we ask authors who intend to submit their artifact for evaluation to register it in advance, so that on the artifact submission deadline, the AE committee members are already ready to start the test phase. The registration amounts to creating the submission in EasyChair.

What	When
Artifact registration	September 17, 2025
Artifact submission deadline	September 22, 2025
Artifact test phase notification	September 28, 2025
Artifact end of response period	October 1, 2025
Artifact notification	November 6, 2025

All artifacts are evaluated by the artifact evaluation committee. Each artifact will be reviewed by at least two committee members. Reviewers will read the paper and explore the artifact to evaluate how well the artifact supports the claims and results of the paper. The evaluation is based on the following questions.

• Is the artifact consistent with the paper and the claims made by the paper?
• Are the results of the paper replicable through the artifact?
• Is the artifact complete, i.e., how many of the results of the paper are replicable?
• Is the artifact well-documented?
• Is the artifact easy to use?

The artifact evaluation is performed in the following two phases.

• In the test phase, reviewers look for setup problems (e.g., corrupted or missing files, crashes on simple examples, etc.). If any problems are detected, the authors are informed of the outcome and asked for clarification. The authors will only get 3 days to respond to the reviews in case problems are encountered. Since this fixing period is rather short, we highly recommend the authors to test their artifact thoroughly before sending the submission.
• In the assessment phase, reviewers will try to reproduce any experiments or activities and evaluate the artifact wrt. the questions detailed above.

Artifact Submission

Submission page: https://easychair.org/conferences/?conf=vmcai2026 (Choose the option to submit to the artifact evaluation track). An artifact submission consists of:

• the title artifact-NN-XX where XX is the title of your paper and NN is the paper’s submission number in Easychair,
• an abstract that summarizes the artifact and explains its relation to the paper,
• the URL (preferably a DOI) from which a .zip or .tar.gz archive file containing the artifact can be downloaded,
• the SHA256 checksum of the archive file, and
• the .pdf file of the submitted paper.

Note The URL (preferably a DOI) and SHA256 checksum should be included in the abstract of the artifact submission. It is also recommended to indicate which badges you are applying for.

The URL must point to independent services, such as Zenodo and figshare, to help protect the anonymity of the reviewers.

You can generate the checksum using the following command-line tools:

• Linux: sha256sum <file>
• Windows: CertUtil -hashfile <file> SHA256
• MacOS: shasum -a 256 <file>

Submission Contents

Your artifact archive file must contain the following:

1. The main artifact, i.e., data, software, libraries, scripts, etc. required to replicate the results of your paper.

   • We recommend you provide easy to use scripts for the user to reproduce and analyze the results, i.e., scripts to run tools with the intended configuration and scripts to visualize their outcome as tables/plots. The review will be single blind. Please make sure that you do not (accidentally) learn the identity of the reviewers (e.g., through analytics, logging).

2. The logs from your experiments (optional).

   • We encourage you to include the logs from your experiments in a way that the reviewers can run the provided analysis scripts on them to help identify potential issues. If the full set of logs is too large, providing a representative subset would be better.

3. A LICENSE file.

   • Your license needs to allow the artifact evaluation committee members to download and evaluate the artifact, e.g., use, execute, and modify the artifact for the purpose of artifact evaluation.
4. A README file that introduces the artifact to the user and guides the user through the replication of your results. Ideally, it should consist of the following parts:
   • A Getting Started Guide detailing how to set up the artifact and prepare it for replicating the results from the paper. We would appreciate it if you supported the reviewers not only for the main review phase but also for the smoke testing phase. To this end, it would be helpful to provide instructions that allow installation and rudimentary testing (i.e., in such a way that technical difficulties would pop up) in as little time as possible, together with the expected outcome of such rudimentary testing (to know whether it was successful). Note that for issues not caught during the smoke test phase, you will not be able to respond.
   • Step-by-Step Instructions for replicating the results from the paper.
     • Please document which claims or results of the paper can be replicated with the artifact and how (e.g., which experiment must be performed). Please also explain which claims and results cannot be replicated and why.
     • Describe in detail how to replicate the results in the paper, especially describe the steps that need to be performed to replicate the results in the paper. To simplify the reviewing process, we recommend providing evaluation scripts (where possible).
     • Precisely state the resource requirements (RAM, number of cores, CPU frequency, etc.), which you used to test your artifact.
     • Provide a rough estimate of the time needed to run the experiments.
     • For tasks that require a large amount of resources (hardware or time), we recommend to provide a possibility to replicate a subset of the results with reasonably modest resource and time limits, e.g., within 8 hours on a reasonable personal computer equipped with 8 GB of RAM. In this case, please also include a script to replicate only a subset of the results.

Note that if you submit your artifact as a Docker image, the README file must also be provided outside the image, to allow copy-and-paste of commands lines for running the scripts.

Artifact Packaging Guidelines

The preferred way to package your artifact is a Docker image. This is to ensure that your artifact can be run on both traditional x86 (e.g. AMD and Intel processors) and newer ARM (e.g. Apple Silicon) platforms without virtualization. To ensure that your artifact performs similarly on x86 and ARM, we recommend you submit one of the following:

• a Docker build script (i.e. a Dockerfile) if building the Docker image runs in reasonable time, or
• pre-compiled Docker images for both x86 and ARM platforms.

Beware: if you provide only an x86 image then Docker will emulate it on arm platforms, and vice versa. Emulation will significantly impair performance.

Docker Images

Below is a quick start guide for producing Docker images provided you have an adequate Dockerfile to generate your artifact. Please refer to the official Docker documentation, in particular the one for cross-compilation for further details and troubleshooting.

To create and export a Docker image native to your platform, you can do:

docker build . -t <artifact-name>:latest
docker save -o <artifact-name>_<your_arch>.tar <artifact-name>:latest

For cross-compilation, Docker version 19.03 or newer provides buildx on most platforms. First, create a new cross-compile builder:

docker buildx create --name mybuilder --driver docker-container --bootstrap
docker buildx use mybuilder

Then, cross-compile and export a Docker image:

docker buildx build --platform linux/<other_arch> -t <artifact-name>:latest --load .
docker save -o <artifact-name>_<other_arch>.tar <artifact-name>:latest

We recommend that you compress the resulting Docker images to reduce the overall size of you artifact. Please use a compression that is compatible with Docker load, i.e., either gz or xz.

Virtual Machines

We discourage packaging artifacts as virtual machine images as they are tricky if not impossible to run under MacOS running on Apple Silicon. However, should you be unable to use Docker, we will accept virtual machines compatible with VirtualBox. Please indicate the use of a virtual machine image and the platform it is intended for in the abstract of your submission.

Call for Papers

!! Deadline extension to Sep 15 AoE !!

VMCAI provides a forum for researchers from the communities of Verification, Model Checking, and Abstract Interpretation, facilitating interaction, cross-fertilization, and advancement of hybrid methods that combine these and related areas. VMCAI 2026 will be the 27th edition in the series. VMCAI 2026 will take place during January 12–13, 2026 as a physical (in-person) event in Rennes, France, co-located with POPL 2026. For each accepted paper, at least one author is required to register for the conference and present the paper in person.

List of Topics

The program will consist of refereed research papers as well as invited talks. Research contributions can report new results as well as experimental evaluations and comparisons of existing techniques. Topics include, but are not limited to:

• program verification
• model checking
• abstract interpretation
• abstract domains
• program synthesis
• static analysis
• type systems
• deductive methods
• program logics
• first-order theories
• decision procedures
• interpolation
• Horn clause solving
• program certification
• separation logic
• probabilistic programming and analysis
• error diagnosis
• detection of bugs and security vulnerabilities
• program transformations
• hybrid and cyber-physical systems
• concurrent and distributed systems
• verification for quantum computation
• analysis of numerical properties
• analysis of smart contracts
• analysis of neural networks
• case studies on all of the above topics

Submission Guidelines

Submissions are required to follow Springer’s LNCS format (see Springer’s webpage for author instructions and templates). The page limit depends on the paper’s category (see below). Submission is done via EasyChair.

Submissions will undergo a single-blind review process. VMCAI 2026 accepts paper submissions in three categories: regular papers, tool papers, and case studies. Papers in each category have a different page limit and will be evaluated differently.

All accepted papers will be published in Springer’s Lecture Notes in Computer Science series. The corresponding author of each paper will need to complete and sign a License-to-Publish form to be submitted together with the camera-ready version.

Regular papers clearly identify and justify an advance to the field of verification, abstract interpretation, or model checking. Where applicable, they are supported by experimental validation. Regular papers should contain original research and sufficient detail to assess the merits and relevance of the contribution, and will be evaluated on the basis of a combination of correctness, technical depth, significance, novelty, clarity, and elegance. Regular papers are restricted to 20 pages in LNCS format, not counting references.

Tool papers present a new tool, a new tool component, or novel extensions to an existing tool. They should provide a short description of the theoretical foundations with relevant citations, and emphasize the design and implementation concerns, including software architecture and core data structures. A regular tool paper should give a clear account of the tool’s functionality, discuss the tool’s practical capabilities with reference to the type and size of problems it can handle, describe experience with realistic case studies, and where applicable, provide a rigorous experimental evaluation. Papers that present extensions to existing tools should clearly focus on the improvements or extensions with respect to previously published versions of the tool, preferably substantiated by data on enhancements in terms of resources and capabilities. Authors are strongly encouraged to make their tools publicly available and submit an artifact. Tool papers are restricted to 12 pages in LNCS format, not counting references.

Case studies are expected to describe the use of verification, model checking, and abstract interpretation techniques in new application domains or industrial settings. Papers in this category do not necessarily need to present original research results but are expected to contain novel applications of formal methods techniques as well as an evaluation of these techniques in the chosen application domain. Such papers are encouraged to discuss the unique challenges of transferring research ideas to a real-world setting and reflect on any lessons learned from this technology transfer experience. Case study papers are restricted to 20 pages in LNCS format, not counting references. (Shorter case study papers are also welcome.)

Authors can include a clearly marked appendix at the end of their submissions that is exempt from the page limit restrictions. However, the reviewers are not obliged to read the contents of these appendices. Simultaneous submission to other conferences with proceedings or submission of material that has already been published elsewhere is not allowed.

Artifacts

VMCAI 2026 makes available the option to submit an artifact along with a paper. Artifacts are any additional material that substantiates the claims made in the paper, and ideally makes them fully replicable. Artifact evaluation is done alongside paper review and its results may affect the decision.