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.

SOIL Seminar


A forum for developers of and researchers of low-level languages to exchange thoughts, projects, updates, and questions.


Biweekly, alternating between Monday at 12pm ET and Friday at 4pm ET.

See Dates


The past presentations can be found here.

E-mail the director if you would like to present!

Next Presentation

Monday, November 9th at 12pm ET

Interface Types Introduction and Update

Luke Wagner

The presentation will recap the motivation and requirements for the Interface Types proposal as well as the design space considered. The presentation will then walk through some details of the recently updated proposal and end with a description of the next planned steps.

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

Northeastern University
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

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.

Stack Management

Modern runtimes and paradigms need to be able to manage and inspect stacks and stack frames just as they do heaps and objects.

Auditable Security

Browsers need a way to independently check or enforce that all operations 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 decomposable into small, quick to audit, and easy to compile units that they execute as they download.

Formal Standardization

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