About The Initiative

Our Mission

We are designing a single open intermediate language that all major languages can compile to and that is implemented on all major backends, including web, mobile, and embedded devices.

Our Plan

We are collaborating with the WebAssembly Community Group to make WebAssembly accessible to more languages, interoperable with existing infrastructure, and repurposable beyond the web.

Our Vision

We aim to create a world in which computation is generated, shared, and consumed just as conventiently and safely as data.

For more details, read our prospectus.

First Questions

What is SOIL?

SOIL is not yet-another-standard/platform/project—it is the aspiration that there be a Single Open Intermediate Language that supports all major languages on all major platforms. We believe WebAssembly is well positioned to become such an intermediate language, but there are many research challenges to making that happen, and we are working with the WebAssembly Community Group to understand those challenges and develop practical solutions. Thus SOIL is the abstract ideal that we hope to make real with a future extended version of WebAssembly.

What about the JVM and the CLI/CLR/.NET?

Both of these (proprietary) systems were designed to primarily support a single language, and while many languages have managed to shoehorn into those designs, these solutions have been less than ideal—the fact that both of these systems needed extensions specifically to support dynamically typed languages are demonstrative of their failure to be language agnostic. WebAssembly operates at a much lower level, providing each language the freedom to specify its own optimized implementation without the need for built-in support.

What about LLVM?

LLVM is primarly designed to be an intermediate representation for a compiler toolchain rather than an intermediate language for communicating across platforms. This difference in roles is apparent in, say, how LLVM uses undefined behavior in contrast to WebAssembly. LLVM uses undefined behavior to enable complex optimizations—an intra-platform compilation device. WebAssembly uses undefined behavior to enable simple operations to be implemented efficiently across many platforms—an inter-platform communication device.

What is the first step?

While designing an ideal SOIL is an abstract and multifaceted problem, our first major step for WebAssembly is a concrete and focused objective. We want to design a means for garbage-collected languages to communicate their memory layouts and low-level feature implementations within an extended WebAssembly. This will enable browsers to independently verify that every access is safe, removing the need for a sandbox, and it will enable browsers to manage the memory of these programs themselves using the same garbage collector as for JavaScript and the DOM, enabling memory to mix freely across these systems to provide smooth interop. Some of us had already been working with the WebAssembly Community Group on the GC extension for WebAssembly, and this initiative was partly formed to coordinate the research effort needed for that extension.

Academic Researchers

We are an international team of world-class researchers coordinating our efforts with each other and with industry to develop a single open intermediate language for all languages on all platforms.

Ross Tate

I have worked with many industry teams on researching principled designs with efficient implementations, and I am eager to develop such a design for the next generation of WebAssembly to make it support a broad range of major industry languages.


Ross Tate

Cornell University
Amal Ahmed

My research focuses on low-level types and language interops. I am excited to make WebAssembly not only a platform for many languages but one where a single code base can cleanly interweave multiple languages together.

Amal Ahmed

Northeastern University
Steve Blackburn

I have co-led the design of a language-neutral IR for managed languages and have extensive experience in the design and implementation of garbage collectors. I am excited to bring memory safety to WebAssembly.

Steve Blackburn

Australian National University
Deian Stefan

I work on language design, runtime systems, program analyses, and verification for security. I am excited to use and extend Wasm to build more secure systems and applications.

Deian Stefan

University of California, San Diego
Adrian Sampson

My research combines programming languages and computer architecture. I'm interested in thinking of safe low-level languages like WebAssembly as the next generation of ISAs for machines in the post-Moore era.

Adrian Sampson

Cornell University
Stephen Chong

WebAssembly is an opportunity to develop foundations for the web in which security has been considered at every level, from design to deployment, enabling new notions of trust and new applications that can build upon that trust.

Stephen Chong

Harvard University
Arjun Guha

I work on programming-language design and implementation, systems, and web security. I am deeply interested in making WebAssembly more expressive with algebraic effects and more secure with containers.

Arjun Guha

University of Massachusetts, Amherst
Zachary Tatlock

In something as fundamental as WebAssembly, even a forgotten obscure corner case can lead to a world-wide vulernability. With mechanical verification, I aim to ensure that WebAssembly provides a new robust foundation for the web.

Zachary Tatlock

University of Washington

Corporate Partners

The WebAssembly Initiave aims to collaborate heavily with industry—we just launched and are currently in the midst of making formal arrangements with industry partners so that they can be fully integrated with our research process. If you are considering partnering with the SOIL Initiative, please contact Laura Batten, Director of Corporate and Foundation Relations for Cornell CIS at +1 607 255 3952.

Research Challenges

The WebAssembly Community Group has discovered that making WebAssembly into an efficient common intermediate language for all major languages is not just a matter of standardization and implementation—the following are just the first research challenges to overcome in order to make the web accessible to more languages, let alone looking beyond the web.

Customizable Memory Layout

We need a way to support the diverse range of memory layouts that languages rely upon for good performance.

Multimodal Memory Manager

We need a garbage collector that can manage memory across programs from multiple languages with different layouts.

Auditable Memory Access

Browsers need a way to independently check or enforce that all memory accesses in a program will be safe and secure.

Environment Interoperability

Programs need a fast and secure means to directly interact with their environment, such as JavaScript and the DOM.

Quick Load Times

Programs need to be small, quick to audit, and easy to compile so that they can be booted as they are downloaded.

Formal Standardization

We need a formal standard or verified implementation so that programs can count on consistent cross-platform behavior.