Moonbit-ic-cdk – A MoonBit-powered Canister Development Kit for ICP

:rocket: Say hello to moonbit-ic-cdk — The first MoonBit-powered Canister Development Kit for building on the Internet Computer (ICP)


:crescent_moon: Why MoonBit + ICP?

WebAssembly (WASM) is at the core of canister smart contracts on ICP. But here’s the catch:

Most non-Rust CDKs on ICP struggle with WASM compatibility, performance bottlenecks, or simply developer complexity.

MoonBit changes that.

It’s a purpose-built, all-in-one programming language toolchain designed for WebAssembly from the ground up.

With MoonBit, you get:

  • :package: Significantly smaller WASM binaries than most toolchains
  • :high_voltage: Faster compile times and runtime performance
  • :writing_hand: A simple, pragmatic, and data-oriented syntax
  • :light_bulb: Easier to learn than Rust (but still powerful enough to build robust dapps)

That’s exactly why we built moonbit-ic-cdk — to make building on ICP faster, lighter, and more accessible.


:hammer_and_wrench: What’s inside

moonbit-ic-cdk

Module Description
ic-types Core IC types like Nat, Principal, Result
ic-principal MoonBit-native Principal implementation and utilities
ic0 Wasmtime FFI bindings to the IC system API
ic0-api-warp Higher-level abstraction over ic0, inspired by Rust’s ic-cdk
example A working canister, fully written in MoonBit and deployed on-chain

:compass: Roadmap

:white_check_mark: Phase 1:

  • Core types + system API
  • Successful deployment on-chain

:hammer_and_wrench: Coming Soon:

  • Inter-canister calls
  • JSON (de)serialization
  • Management canister API
  • Documentation

:handshake: We’re collaborating directly with the MoonBit core team to bring WASM-native development into the heart of ICP.


:books: Resources

12 Likes

I haven’t heard of moonbit before
Where is this language used right now and how would it compare to Motoko

1 Like

Hi @Gekctek

Moonbit is a very new language designed to embrace WebAssembly (Wasm). Its core development team is based in Hong Kong, and they’ve previously held several meetups in places like Singapore. They also showcased the language at last year’s Rust China conference.Previously, the Moonbit core team had a brief conversation with DFINITY as well.

Currently, Moonbit is gaining significant popularity in Asia, especially among teams working with Wasm. Many of these teams are choosing Moonbit to build their components, particularly for implementing cryptographic algorithms that can be called from JavaScript.

Motoko is an excellent language—I started using it back in 2021 and have built many DApps with it. However, compared to Motoko, Moonbit has broader recognition in the Asian region. The Moonbit team is also heavily focused on integrating AI into the compiler, with the goal of enhancing developer productivity.
Their approach includes:

  • AI-friendly language design, featuring safety mechanisms, easy testing, and reduced hallucinations from LLMs.
  • Built-in AI assistant to automate testing and documentation, streamlining development workflows.
  • Intelligent code generation with high accuracy and fast response times.

I hope to bring these developers into the ICP ecosystem through the moonbit-cdk, so that ICP can be adopted in more non-crypto industries.

3 Likes

Maybe worth adding this to

3 Likes
1 Like

Hi, I’ve updated the upcoming Roadmap for ic-moonbit-cdk:

:motorway: Roadmap

:hourglass_not_done: In the next 1–3 months

  1. JSON serialization support JSON will become the default serialization format for accepting arguments and returning values in canisters. Developers will no longer need to manually handle encoding or decoding logic.
  2. Improvements to ic-types-moonbit Extend support for all IC-specific types and provide better tools for debugging type-level behavior.
  3. Enhancements for http_request endpoint and candid-related types To make MoonBit a first-class choice for building on-chain websites, Moonbit CDK will prioritize building components needed for serving HTTP-based content directly from canisters.
  4. Async support for canister-to-canister calls If MoonBit adds native support for async primitives, moonbit-ic-cdk will implement async handling and enable MoonBit-based canisters to perform inter-canister calls.

:crystal_ball: Future plans (dependent on async support)

  1. Management Canister API support Enable low-level operations such as canister creation, upgrade, and controller management from within MoonBit canisters.
  2. Full-featured CDK API Provide ergonomic abstractions for stable memory, timers, traps, and certified variables—bringing MoonBit CDK closer to Rust’s ic-cdk.
  3. Candid support and implementation in MoonBit Long-term plan includes providing a MoonBit-native implementation of the Candid interface description language.
1 Like

Edit: I see it now under Future plans point 3.

What’s the general idea behind a Candid implementation?

  • With Motoko the types basically map one to one.
  • With the Rust SDK there’s automatic mapping to Rust types.
  • With the Azle SDK you need to annotate methods with Candid types.

Does the MoonBit language support automatic mapping approaches like the Rust SDK or is an approach like the Azle SDK more straightforward in MoonBit?

Hi @sea-snake , I’m glad you’re interested in this topic!

At this stage, it seems that MoonBit can adopt a similar approach to the Rust CDK. While developing the V1 version, I experimented with serialization/deserialization (de/se) of some basic types and found that handling the raw bytes correctly was often sufficient — although it’s necessary to include some additional headers, such as those defined by DIDL (e.g. length prefixes and type descriptors).

However, my current focus is on supporting JSON serialization and deserialization, since MoonBit has relatively good native support for JSON. I believe the first wave of MoonBit CDK users will also be more familiar with JSON-based workflows.

In V2, I plan to prioritize implementation of point 1 and point 2 from the roadmap. Support for Candid will be introduced in V3. Here’s the planned progression:

  • V1: Developers need to interact with low-level APIs and handle serialization manually in many cases.
  • V2: Developers will be able to use a higher-level API similar to the Rust CDK, and deploy services such as web server–like frontend hosting directly on IC.
  • V3: Focus on deeper compatibility with IC blockchain features, such as threshold signatures and certified data (certification).

If you have other suggestions, feel free to reach out — I’m still planning things carefully. Thanks for your interest and support!

1 Like