Motoko packages

Two packages sit on the Motoko side of the system.

neutron-motoko-wasm — the vendored compiler

Neutron compiles Motoko with a bundled WebAssembly build of the compiler. This matters more than it sounds:

• The browser can compile. Installing an app compiles a complete actor in a browser Worker. That is possible because the compiler itself is a Wasm module the browser can load.
• Every path uses the same compiler. Browser installs, the CLI, the provisioner, and the kernel's own assembly build check all use this exact pinned build.
• A moc on your PATH is never used. Neutron does not resolve or execute a host Motoko compiler for app compilation. An unrelated Motoko installation on your machine cannot affect a build.

The package also exposes the compiler wrapper used by browser, Bun, and Node callers: loadMotoko(), compiler disposal, AST inspection, interpretation, Wasm/Candid/stable-signature compilation, and stable-signature compatibility.

mo:neutron-capabilities — the leaf types

This is what an app's Motoko code imports. It exports versioned leaf interface types and nothing else.

import NeutronCapabilities "mo:neutron-capabilities";

Available leaf types include:

Type	Capability
DeferredTimersV1	App-scoped keyed one-shot timers
BackendCallsV1	Brokered outbound canister calls
RandomnessV1	32 fresh bytes from a kernel-owned raw_rand broker
ChainKeySigningV1	Threshold assertion signing
StableStoreV1	Bounded binary key/value storage
HttpsOutcallsV1	Declared-endpoint HTTPS requests
VetKeysPublicV1	Public-only vetKeys slot and key lookup
CertifiedAssetsV2	Scoped certified asset publication

Plus request/response types for compiler-bound handlers: HttpPostUpdateHandlerRequestV1 / …ResponseV1, PublicIngressRequestV1 / PublicIngressResultV1, and PublicIngressCyclesV1.

What it deliberately does not export

No factories. No installation scope. No universal authority-bearing aggregate.

There is no NeutronCapabilities.create(...), no AppScope type an app can name, and no "environment" object the package can hand you. Importing the package gives you types, not power.

Backend capability values arrive through the compiler-generated environment record passed to Init, and only for backend interfaces selected by the manifest. That record can also contain compiler-derived installation identity, managed-memory bindings, and declared app calls.

public type AppBackendEnvironment = {
  installation : { network_id : Blob };
  stable_memory : { private_data : Memory.Mem };
  app_calls : {
    contacts : { lookup : ({ principal : Principal }) -> ContactResult };
  };
  capabilities : {
    backend_calls : NeutronCapabilities.BackendCallsV1;
    stable_store : NeutronCapabilities.StableStoreV1;
  };
};

You declare this type locally, listing only what you need. The compiler generates a matching anonymous record; Motoko's structural typing verifies the two agree, and record width subtyping lets you ignore fields you did not name.

Guessing a compiler-local name — another app's memory, NeutronKernel, a generated function helper, this — does not add it to the record. There is nothing to guess: the record is constructed from your manifest.

Why the leaves are shaped the way they are

Each leaf is an attenuated closure, not a handle to a subsystem. For example:

• HttpsOutcallsV1 exposes only request. It contains no management actor, URL parser, cost primitive, transform callback, registry lease, or cycle-attachment function.
• ChainKeySigningV1 exposes only public_key and sign_assertion. No key name, derivation path, raw digest operation, or retry control.
• StableStoreV1 exposes bounded get / conditional put / revision delete / live list / usage / clear-page. No AppScope, namespace allocator, Region, pointer, offset, or stable-memory primitive.

The kernel keeps the dangerous parts. The app gets a verb.

See Capabilities for the full inventory and the policy each broker enforces.