26th International Conference on Verification, Model Checking, and Abstract Interpretation (VMCAI 2025)VMCAI

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

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 2025 will be the 25th edition in the series.

VMCAI will take place during January 20-21, 2025 as a physical (in-person) event. For each accepted paper at least one author is required to register for the conference and present the paper in person.

Sponsorship

VMCAI is welcoming diamond, silver and bronze sponsors.

Call for Papers

VMCAI 2025 is the 26th International Conference on Verification, Model Checking, and Abstract Interpretation. The conference will be held during January 20-21, 2025. 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.

Scope

The program will consist of refereed research papers as well as invited lectures and tutorials. 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
• Analysis of numerical properties
• Analysis of smart contracts
• Analysis of neural networks
• Case Studies on all of the above topics

Submissions can address any programming paradigm, including concurrent, constraint, functional, imperative, logic, and object-oriented programming.

Important Dates AoE (UTC-12)

September 9, 2024: Paper submission deadline

October 25, 2024: Notification

November 11, 2024: Camera-ready version due

Submissions

Submissions are required to follow Springer’s LNCS format. The page limit depends on the paper’s category (see below). In each category, additional material beyond the page limit may be placed in a clearly marked appendix, to be read at the discretion of the reviewers and to be omitted in the final version. Formatting style files and further guidelines for formatting can be found at the Springer website. Submission is via EasyChair. Note: submissions will open on August 26th.

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.

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

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 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.)

Call for Artifacts

VMCAI 2025 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 all 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 singly blind, artifacts do not need to be anonymous.

Badges

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

• Available for artifacts that are publically available under a DOI.
• 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. The artifact submission deadline is 1 week after the paper submission.

What	When (updated)
Artifact submission deadline	September 16, 2024

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 check if the artifact is functional, i.e., they look for setup problems (e.g., corrupted, 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 get 3 days to respond to the reviews in case problems are encountered.
• 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=vmcai2025ae

An artifact submission consist of:

• the title “[artifactNN] XX” where XX is the title of your paper and NN is its submission number,
• an abstract that summarizes the artifact and explains its relation to the paper,
• a 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
• a .pdf file of the submitted paper.

The URL must be a Zenodo, Figshare, Google Drive, Dropbox, Github, Bitbucket, or (public) Gitlab URL, 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 the results.
   • The review will be singly blind. Please make sure that you do not (accidentally) learn the identify of the reviewers (e.g., through analytics, logging).

2. A LICENSE file. Your license needs to allow the artifact evaluation chairs to download and distribute the artifact to the artifact evaluation committee members and the artifact evaluation committee members must be allowed to evaluate the artifact, e.g., use, execute, and modify the artifact for the purpose of artifact evaluation.

3. A README.pdf 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:

   1. 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 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.

   2. 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 to provide evaluation scripts (where applicable).
      • Precisely state the resource requirements (RAM, number of cores, CPU frequency, etc.), which you used to test your artifact.
      • 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. In this case, please also include a script to replicate only a subset of the results.

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. 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 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 you 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., please use either gz or xz.

Virtual Machines

We discourage to package 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.

Publication of Artifacts

The artifact evaluation committee uses the submitted artifact only for the artifact evaluation. It may not publicize the artifact or any parts of it during or after completing evaluation. Artifacts and all associated data will be deleted at the end of the evaluation process. We encourage the authors of artifacts to make their artifacts also permanently available, e.g., on Zenodo or figshare, and refer to them in their papers via a DOI. All artifacts for which a DOI exists that is known to the artifact evaluation committee are granted the availability badge.

The prize for the award is generously sponsored by Springer.