WebAssembly proposals: the phase tracker that decides what WebAssembly will grow next

A generated file with a JSON source and a schema

The repository is called WebAssembly proposals, and the first thing the README says is a warning that the file is autogenerated from proposals.json by generate_markdown.py, that you should not edit the file directly, and that instead you should update proposals.json and run the generation script following the procedure in howto.md.

That is the design decision, and it is the reason the repository is more than a document. The human readable index is a rendering, and the rendering comes from a machine readable source. There is a `proposals.json` file, a `proposals.schema.json` file that describes its shape, and a `generate_markdown.py` script that turns one into the other.

The top level of the repository matches. There is the `README.md`, the `finished-proposals.md` and `inactive-proposals.md` files, the `proposals.json` and `proposals.schema.json`, the `generate_markdown.py` script, the `howto.md` procedure document, and a `create-merge-commit.png` image. There is also a `.github/` directory.

The consequence for a reader is that this is a queryable source of truth about the WebAssembly roadmap rather than a curated page. Anything that wants to know which proposals are in which phase can read the JSON and validate it against the schema, and the generated Markdown is guaranteed to agree with the data because it is produced from it. The `howto.md` file exists so that adding a proposal is a pull request with a well defined shape, which is the mechanism that keeps the file honest as the ecosystem churns.

The primary language of the repository is recorded as Python, which is the generator script, and the only topic tag is `meta`, which is a fair description of what this repository is.

Six phases, and what each one commits you to

The proposals are sorted into the phases of the standardisation process, and the phase headings are the part that carries the meaning.

Phase 5 is the Feature is Standardized (WG), and the note under it says these proposals have not yet been merged to the spec, with merged proposals listed in the finished proposals file. So phase 5 is the last step before the specification itself changes, and the distinction between phase 5 and finished is exactly the distinction between agreed and merged.

Phase 4 is Standardize the Feature (WG), phase 3 is Implementation Phase (CG plus WG), phase 2 is Proposed Spec Text Available (CG plus WG), phase 1 is Feature Proposal (CG), and phase 0 is Pre-Proposal (CG).

The abbreviations are the groups that have to be involved, and the phases are a standardisation process document. Proposals follow this process document, which lives in the WebAssembly meetings repository under process/phases.md.

So the phase number is a commitment level, and reading it correctly is most of the skill. A phase 1 proposal is an idea someone has written up, a phase 2 proposal has spec text, a phase 3 proposal is being implemented in engines, and a phase 5 proposal is about to become part of the standard. A tool that only supports one of these is in a very different position depending on which row it sits in.

The phase 0 note is the most interesting of the headings, because it does not list proposals at all. Phase 0 proposals are tracked in the design repository issue tracker, on GitHub, rather than in this file. So the repository starts at the point where someone has written a proposal, and everything before that lives in issues.

There is also a separate set of documents for the two ends of the lifecycle. Finished proposals are in one file and inactive proposals in another, both linked from the top of the README, so a proposal that has stalled is not lost, it is filed.

Champions are the people you can watch

The second column of every table is a name, and that is the part of the file with a long half life.

Every proposal has a champion, and a champion is a person who is on the hook for the proposal. The process document defines what that means, but the practical effect in this file is that you can follow a proposal by following a person, and you can see when someone is carrying several proposals at once.

The names repeat enough for that to be useful. Conrad Watt appears at phase 4 for Threads, at phase 2 for Relaxed dead code validation, at phase 2 for Acquire-Release Atomics and at phase 1 for Shared-Everything Threads. That is a spread across the whole process, from a nearly standardised feature down to a new idea, and it is the profile of someone who works on the WebAssembly specification full time rather than filing an occasional proposal.

Francis McCabe appears twice in phase 5, for JS Promise Integration and Web Content Security Policy, and once at phase 3 for Stack Switching. A proposal in phase 5 with a champion who also has work in phase 3 is a proposal whose champion is still shipping features, which is a good sign for the quality of the phase 4 and phase 5 text.

Andreas Rossberg has three phase 1 entries, Type Imports, the WebAssembly C and C++ API and Profiles, which reflects the pattern of a language implementer bringing several ideas forward at once. Brendan Dahl has two phase 2 entries, Multibyte Array Access and FP16.

And there are a few names that appear in the phase 1 list alongside people who are more established, which is the point of a public process. A phase 1 proposal from someone new is cheap to add and expensive to standardise, and the phase number tells you where the cost is concentrated.

So the champion column is not decoration. It is the mechanism by which a reader can judge whether a proposal has momentum, and by which the community can find the person to ask about a specific phase transition.

What is in each phase right now

Reading the tables gives a current picture of where the platform is heading, and the distribution across the phases is itself informative.

Phase 5, closest to the specification, has two entries. JS Promise Integration, championed by Francis McCabe, and Web Content Security Policy, also championed by Francis McCabe.

Phase 4 has three. Threads, championed by Conrad Watt, Compact Import Section by Ryan Hunt, and Wide Arithmetic by Alex Crichton and Jamey Sharp.

Phase 3 has four. ESM Integration, championed by Asumu Takikawa, Ms2ger and Guy Bedford, Stack Switching by Francis McCabe and Sam Lindley, Custom Page Sizes by Nick Fitzgerald, and Custom Descriptors and JS Interop by Thomas Lively.

Phase 2 has nine, which is the largest group. Relaxed dead code validation by Conrad Watt and Ross Tate, Numeric Values in WAT Data Segments by Ezzat Chamudi, Extended Name Section by Ben Visness, Rounding Variants by Kloud Koder, Compilation Hints by Emanuel Ziegler, JS Primitive Builtins by Sébastien Doeraene, Acquire-Release Atomics by Conrad Watt and Rezvan Mahdavi Hezaveh, Multibyte Array Access by Brendan Dahl, and FP16, also by Brendan Dahl.

Phase 1 has thirteen. Type Imports by Andreas Rossberg, Component Model by Luke Wagner, WebAssembly C and C++ API by Andreas Rossberg, Flexible Vectors by Petr Penzin and Tal Garfinkel, Memory control by Deepti Gandluri and Ben Visness, Reference-Typed Strings by Andy Wingo, Profiles by Andreas Rossberg, Shared-Everything Threads by Andrew Brown, Conrad Watt and Thomas Lively, Frozen Values by Léo Andrès and Pierre Chambart, More Array Constructors by Nick Fitzgerald, JIT Interface by Ben Titzer, Type Reflection for WebAssembly JavaScript API by Ilya Rezvov, and JS Text Encoding Builtins by Daxpedda.

The shape of that list is the interesting part. A large phase 1 means a lot of ideas are entering the funnel, and the names cluster in two directions. One is the JavaScript interop cluster, with Promise Integration, ESM Integration, Custom Descriptors and JS Interop, JS Primitive Builtins, JS Text Encoding Builtins and Type Reflection, which together suggest the boundary between WebAssembly and JavaScript is the busiest frontier. The other is the memory and type system cluster, with Custom Page Sizes, Flexible Vectors, Memory control, Reference-Typed Strings, Frozen Values, Type Imports, Multibyte Array Access and FP16, which is a fairly wide rewriting of how a WebAssembly module holds and passes its data.

And a few names recur across phases, which is a good sign of someone maintaining a proposal they care about. Conrad Watt appears in phase 4 for Threads, phase 2 for Relaxed dead code validation, phase 2 for Acquire-Release Atomics and phase 1 for Shared-Everything Threads. Francis McCabe appears twice in phase 5 and once in phase 3. Andreas Rossberg has three phase 1 entries. Brendan Dahl has two phase 2 entries.

Where implementation status is actually tracked

The repository draws a clear line between what it knows and what it does not.

Implementation status of most proposals in various wasm engines is available on webassembly.org/features/.

That division is sensible, because the two questions are different in kind. A proposal's phase is about the standardisation process and who has committed to what. Whether V8, SpiderMonkey or Wasmtime has shipped a flag for it is about individual engine roadmaps, and those change on a completely different schedule, often daily, and are maintained elsewhere.

So if you are evaluating whether you can rely on a feature today, the phase table is the wrong place to look and the features page is the right one. If you are evaluating whether the platform will have the feature in a decade, the phase table is the better signal, since a feature in phase 2 with a named champion is a stronger promise than a shipped experimental flag.

The contributing guidance points elsewhere too. For new proposals, the repository says to see Contributing to WebAssembly in the design repository for the most up-to-date information on contributing proposals to standard.

The design repository is also where phase 0 proposals are tracked, and it is where the contribution process itself is documented. The split between this repository and the design repository is a good model for how a large open standard is run. This one is the index and the status board, the design one is where the argument happens, and the meetings repository holds the process document that defines what the phases mean.

For a working engineer, the practical sequence is to watch this repository for the phase, check webassembly.org/features/ for whether an engine has it today, and read the proposal repository itself when you need to know the shape of the API.

Editorial conclusion

The WebAssembly proposals repository fits a developer who wants to know what is actually moving toward the specification rather than what a conference talk promised, because the phase number is the real signal and the champion column tells you who is doing the work. Skip it if you need implementation status in a specific engine, since the repository points to webassembly.org/features for that and keeps a different question. Before you base a design on any of it, read the phase definitions in the process document, because a phase 1 proposal and a phase 4 proposal are very different commitments. The last push was on 2026-10-07.

Frequently asked questions

Official sources

1. Issues
2. README
3. WebAssembly/proposals on GitHub