Hi everyone,
moxzi alpha.10 is out. If you haven’t met it: moxzi is a Motoko compiler written in Motoko. The same compiler runs on your laptop, in your browser, and as a canister on the Internet Computer, where it can build your project on chain so anyone can check what was compiled from what. It follows moc 2.0.0 and adds a few things of its own.
This release has one big new feature, a lot of speed, and a round of “make it trustworthy” work. Here’s the tour, no compiler background required.
1. Native kernels: fast Rust inside your Motoko canister
This work started with @infu: the Motoko compiler plugins thread and PR #6443 proposed calling fast native code from Motoko, built the first plugins (now at Neutrinomic/motoko_plugins), and published the measurements that showed how much was on the table. Those measurements are the bar everything below is compared against. Thank you, @infu.
Cryptography and hashing are where Motoko is slowest: it lacks the low-level tricks that crypto code lives on. A native kernel lets a Motoko function run an existing, well-known Rust crate instead (RustCrypto, dalek, zkcrypto, libcrux…), compiled to a tiny WebAssembly library and linked only into canisters that call it.
The clever part is what doesn’t change: the Motoko function keeps its Motoko body. Under stock moc, or if you don’t opt in, that body runs exactly as before. With moxzi you opt in from your own mops.toml, pinning the exact bytes:
moxzi kernel add moxzi-hash
That writes [kernels] moxzi-hash = "sha256:…". A dependency can never add native code behind your back, and if the bytes don’t match your pin, the build stops.
What it buys (instructions per call; lower is cheaper):
| Motoko | with kernel | |
|---|---|---|
| SHA-256 of 1 MB | 405 M | 76 M |
verify an IC certificate (mo:ic-agent) |
~2 B | 0.37 B |
…and the ten kernel packages (hashing, secp256k1, P-256, Ed25519, BLS12-381, ML-DSA, RSA, Base58, Bech32, Bitcoin) match or beat the plugins @infu benchmarked in the thread (@infu’s numbers; we measured our kernels the same way). There’s a separate post with the full table and the security story.
Native code in a canister deserves suspicion, so:
- The source is public and rebuilds byte for byte: icdevsorg/moxzi-kernels (MIT OR Apache-2.0).
moxzi kernel verifyrebuilds a kernel and checks it against its pin; a Docker command does the same on Linux. - We tested our own crypto for timing leaks — both instruction counts and the compiled code itself — and fixed what we found.
- Honest status: no independent expert audit yet. Fine for experiments and verification work; don’t guard real value with the hand-written parts until there is one.
Want to write your own? moxzi kernel build turns a Rust crate into a kernel; the docs walk through a CRC-32 example end to end.
2. Faster Candid, same bytes
Every message a canister sends or receives is encoded as Candid. moxzi now generates straight-line encoding code for your types instead of a general-purpose walk:
- encoding 1,024 small records: 832 K → 165 K instructions (5× faster),
- a 1,024-case variant: 9.8 M → 0.48 M (20×),
and the bytes are identical to moc’s, checked on hundreds of random values and over 14,000 corrupted inputs. An opt-in fast decoder (--candid-fast-path) does the same for incoming messages whose types match yours.
The benchmark records come from @infu’s CandidX plugin in the plugins thread; that plugin encodes the same 1,024 records in about 352 K instructions, and it is what got us looking at the built-in encoder in the first place.
3. Builds you can check
The point of building on chain is that the result is reproducible: same source, same bytes, wherever it was built. This release fixes the cases where that wasn’t true:
- On-chain builds are byte-identical to local builds again, however the work is split into messages. (A long build used to come out with functions in a different order.)
- Stable signatures are always valid. In rare programs two different types could get the same name in the signature moxzi writes — one case even described a
Textfield asBool, which would have misled an upgrade check. - Security fix: on the shared on-chain compiler, one caller’s build could in rare cases compile another caller’s library file. Fixed, and covered by a test.
- Projects that import from folders next to them (
../other-lib/src) now build, locally and on chain. - Paid on-chain builds settle cleanly and keep their signed attestation of what was linked.
4. More of the Motoko world just works
We took every library @infu referenced in the plugins thread — json, serde, cbor, CandidX, sha2, blake3, ecdsa, bitcoin, bls12-381, core — and ran their own test suites under moxzi and moc. That found and fixed eleven moxzi bugs, three of which produced wrong values silently (negative numbers through a type alias, nested options, and let-else). Every library now behaves identically under both compilers.
Along the way, candy 0.3.2, rep-indy-hash 0.1.2 and icrc75-mo 0.3.1 were published without GitHub dependencies, so projects no longer need the old base-0.7.3 alias to build.
Try it
- Install or update: https://moxzi.ai (one command on macOS and Linux).
- Native kernels: the new “Native kernels” chapter in the docs.
- Full list of changes: the changelog.
moxzi is built by RIVVIR Tech. The native kernels repository, icdevsorg/moxzi-kernels, is maintained by ICDevs.org (a 501c3 non-profit). If the kernels are useful to you, please consider supporting that work at https://icdevs.org/donation.html.
Questions, bug reports and “this broke my project” are all very welcome — reply here.