moxzi

moxzi

We heard you like Motoko, so we put a Motoko compiler in your Motoko so you can Motoko while you Motoko.

A Motoko compiler written in Motoko — and runtimes that put your actors on a laptop, a server, a browser tab, and the Internet Computer. Same bytes, all four.

See it run → Install Documentation AI skills

2026-08-25: the compiler compiled itself on the Internet Computer — 177 files, 2,345 messages, an hour of block time, and the artifact is byte-identical to the local build. The receipts →

Install now

macOS and Linux, four platforms. No dfx, no moc, no Node — the compiler and linker are wasm files that ship in the archive.

curl -fsSL https://moxzi.ai/install.sh | sh

It picks the build for your platform, verifies its SHA-256 against the release's SHA256SUMS before unpacking anything, and installs to ~/.local — binaries on your PATH, the two wasm files beside them in lib/moxzi/. It refuses on a mismatch, and refuses outright if it cannot fetch the checksums: this project's whole argument is that you can check bytes instead of trusting them, and an installer that skipped that would be arguing the other side.

echo 'persistent actor { public query func greet(n : Text) : async Text { "Hello, " # n # "!" } };' > hello.mo
moxzi build hello.mo -o hello.wasm

The wasm is a real canister module: dfx canister install --wasm hello.wasm deploys it to the Internet Computer unchanged.

Install guide CLI quickstart What is in this release

The compiler is the artifact

The moxzi compiler is an ordinary Motoko program. It has no privileged runtime, no native extensions and no build machine of its own — so anywhere a Motoko actor can run, the compiler can run too. A canister can compile Motoko because a canister can run an actor. A browser tab can compile Motoko for the same reason.

Because it is one compiler rather than four ports of one, the wasm it emits is byte-identical in all four places. The wasm compiling your code on your laptop is the wasm a canister runs for a paid build, and the outputs match to the byte.

Why it matters: a build produced on-chain, by a compiler anyone can audit, from sources anyone can hash, is provenance no local toolchain can offer. Every artifact names the compiler that made it, by hash.

Actors, everywhere

moxzi — the CLI

Build Motoko to deployable wasm in under a second. Full mops package support. Byte-identical to on-chain builds, with provenance stamped in the artifact.

moxzid — the server

Host actors off-chain with IC semantics: rollback, timers, upgrades, cycles, outcalls, kill‑9‑proof durability. Serve an actor's http_request as a real website — even mount one as a WebDAV drive.

moxzi-web — the browser

The same runtime in a tab: install, call, upgrade, persist to IndexedDB, preempt runaway messages, real HTTPS outcalls. The compiler runs in the tab too — byte-identical.

The on-chain builder

Escrowed, metered, refunding builds on the Internet Computer. Upload nothing at all with mops-tag builds. One command: moxzi build --remote.

Proof over promises

One command runs the native test suite, 32 behaviour gates, two flagship demos and two corpus sweeps — 149 programs zero-diverging between browser and native, 221 byte-identical across independent compiler builds. Every claim on this site maps to something you can run.

The full claim → proof table Every number, in one place