# Moxzi 0.1.0-alpha.10 — fast Rust inside Motoko, faster Candid, and builds you can check

**URL:** <https://forum.dfinity.org/t/moxzi-0-1-0-alpha-10-fast-rust-inside-motoko-faster-candid-and-builds-you-can-check/76238>\
**Category:** Showcase\
**Created:** [October 26, 2026, 2:42pm UTC](https://forum.dfinity.org/t/moxzi-0-1-0-alpha-10-fast-rust-inside-motoko-faster-candid-and-builds-you-can-check/76238 "2026-10-26T14:42:45Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [October 26, 2026, 2:42pm UTC](https://forum.dfinity.org/t/moxzi-0-1-0-alpha-10-fast-rust-inside-motoko-faster-candid-and-builds-you-can-check/76238/1 "2026-10-26T14:42:45Z")

</div>

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](https://forum.dfinity.org/t/motoko-compiler-plugins-for-fast-computation/76041) and [PR #6443](https://github.com/caffeinelabs/motoko/pull/6443) proposed calling fast native code from Motoko, built the first plugins (now at [Neutrinomic/motoko\_plugins](https://github.com/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:

```none
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](https://forum.dfinity.org/t/motoko-compiler-plugins-for-fast-computation/76041) (@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](https://github.com/icdevsorg/moxzi-kernels) (MIT OR Apache-2.0). `moxzi kernel verify` rebuilds 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](https://forum.dfinity.org/t/motoko-compiler-plugins-for-fast-computation/76041); 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 `Text` field as `Bool`, 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](https://forum.dfinity.org/t/motoko-compiler-plugins-for-fast-computation/76041) — 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](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](https://github.com/icdevsorg/moxzi-kernels), is maintained by [ICDevs.org](http://ICDevs.org) (a 501c3 non-profit). If the kernels are useful to you, please consider supporting that work at [https://icdevs.org/donation.html](https://icdevs.org/donation.html).

Questions, bug reports and “this broke my project” are all very welcome — reply here.