Motoko 1.13 Turns Local Candid Files Into a Type-Safe ICP Boundary

The latest Motoko release changes where Internet Computer developers can define an interface. Version 1.13.0, released on August 3, 2026, adds an idl: URI scheme for importing a local Candid file as a types-only Motoko module.

A project can now write import S "idl:foo.did". The imported module exposes S.Self for the service actor type and named Candid types. When a name is unambiguous, Motoko PascalCases it—for example, user_id becomes S.UserId. The release notes also state that this path does not require a principal or an --actor-idl flag.

The practical shift is modest but important: a local .did file can become the source of truth for compile-time interface types while implementation remains in Motoko. That can reduce duplicated type declarations in multi-canister repositories and make interface changes easier to review as ordinary version-controlled file changes. This is an engineering implication of the new import mechanism, not a claim that runtime compatibility checks disappear.

The feature is especially relevant when a canister consumes another service whose interface is available in the repository. Instead of converting the Candid definition into hand-written Motoko types, developers can import the file and refer to the generated service type. Tooling can then catch mismatches during compilation rather than leaving every interface error to deployment or integration testing.

Motoko 1.13.0 also makes multi-value WebAssembly code generation permanently enabled. The old --experimental-multi-value and --no-experimental-multi-value options remain only for command-line compatibility and no longer change compiler behavior. For builders, the headline is therefore not a new application API but a tighter boundary between Candid interface files, Motoko’s type checker, and the WebAssembly toolchain.

The release is a useful signal for ICP teams maintaining larger codebases: interface artifacts are becoming easier to consume directly, while legacy compiler switches are being retired gradually. Teams should test their build scripts for assumptions about the removed flag behavior and review generated or imported types before upgrading production canisters.