Rust developers working on the Internet Computer have been handed something many have been quietly hoping for—more memory and more room to grow. Wasm64 is now available for Rust canisters, and it’s shaking up how developers approach memory-intensive applications on the ICP platform. With the release of the new ICP Rust Canister Development Kit (CDK), compiling for Wasm64 is no longer a future plan—it’s a real, testable, deployable option. And for those who have previously bumped up against memory limits, that’s welcome news.
The upgrade to Wasm64 means moving past the long-standing 4 GiB ceiling imposed by Wasm32’s 32-bit address space. Developers can now allocate up to 6 GiB of heap space—an increase that will immediately benefit a wide range of use cases that rely on intensive data handling or require larger runtime memory.
For those less familiar with the underlying tech, Wasm—short for WebAssembly—is a low-level binary instruction format designed to be compact, efficient and portable. Originally built to let code written in languages like Rust or C++ run in web browsers, it’s now a widely adopted standard in blockchain environments. On the Internet Computer, Wasm powers canisters—the smart contracts that handle everything from data storage to complex logic execution. Developers write in a high-level language like Rust, compile it to Wasm, and deploy it on-chain where it runs deterministically across the decentralised network. It’s fast, secure and consistent, which makes it ideal for smart contract environments.
The difference between Wasm32 and Wasm64 comes down to memory addressing. Wasm32 uses a 32-bit address space, limiting heap size to 4 GiB. That was fine for a long time, but for developers building increasingly ambitious applications, it has become a ceiling. Wasm64 opens up 64-bit memory addressing, allowing the heap to stretch to 6 GiB and, eventually, more. For data-heavy apps, simulations, or anything needing in-memory crunching, that added capacity is a meaningful shift.
The transition isn’t automatic. Existing Wasm32 canisters need to be rebuilt and re-deployed in Wasm64 mode. Changing the target to wasm64-unknown-unknown is the key step once the Rust toolchain has been configured. But live canisters cannot be transformed mid-flight. That means a careful approach is needed when replacing production deployments. Developers are being urged to test thoroughly before making the switch, especially given the experimental nature of this new capability.
The execution team is still working through some of the thornier technical challenges that come with enabling even larger heaps. Specifically, the issue lies in deterministically tracking memory access during runtime—a necessary component for ensuring consistent execution across the decentralised network. For now, 6 GiB is the new frontier, but it’s clear that the team is working toward lifting that cap even further.
This isn’t the first time Wasm64 has been mentioned in the ICP ecosystem. Developers have anticipated its wider adoption, especially as demands on canister memory have grown. Until now, those hitting the 4 GiB limit had to make trade-offs—compress data more aggressively, limit in-memory processing, or shard functionality across multiple canisters. With Wasm64, the constraints loosen. A single canister can now feasibly handle more without outsourcing memory load.
For some, this marks a notable moment in the evolution of smart contract development on ICP. It expands the range of what’s possible without fundamentally altering the canister model. This isn’t a reinvention, but a significant extension—like switching from a tiny sketchpad to a full canvas.
The ICP Rust CDK update is what made this leap possible. The new development kit brings with it updated support for the Wasm64 target, and while it may sound like a backend detail, it changes the developer experience in real terms. Building large, complex applications that maintain performance and avoid the overhead of splitting logic across multiple canisters suddenly feels more achievable.
One might imagine machine learning inference, intensive data analytics, or large-scale simulations fitting comfortably within a single canister now. These were the kind of workloads previously considered impractical in the ICP context due to heap constraints. With 6 GiB to work with, developers have more room to manoeuvre.
There’s a caveat, though. Just because a canister can technically access 6 GiB doesn’t mean everyone should immediately max out their usage. The advice from the team is measured—test, monitor, and migrate thoughtfully. The jump in addressable memory introduces fresh considerations in performance tuning and memory management. Sloppy programming or unoptimised logic will eat into that extra headroom quickly.
Another thing to keep in mind: this isn’t a universal unlock. Wasm64 needs to be explicitly targeted. That means developers have control, but also responsibility. It’s not just a compiler flag—it’s a strategic decision. Once a canister is running Wasm64, there’s no mixing and matching across versions or falling back mid-execution. Recompilation and redeployment are part of the game. It’s not just about pointing to a different toolchain—it’s about understanding the performance and memory implications of a new mode of operation.
The roadmap beyond 6 GiB is still taking shape. The execution team is actively exploring how to track memory access deterministically, which is crucial for the ICP’s consensus model. The platform can’t afford ambiguity—every replica must come to the same result for every instruction. That’s easy enough when memory is small and predictable, but trickier when pages expand and access patterns become harder to pin down. This is where the engineering finesse comes in. Solving that will unlock even greater heap sizes and perhaps a rethink of how large-scale apps are designed within the Internet Computer architecture.
For now, developers eager to experiment with Wasm64 have what they need. Documentation is available, and there’s even an example linked from the release notes. For those already running Wasm32 canisters, it’s an opportunity to weigh the cost-benefit of reworking their codebase. The decision won’t be universal—some may stick with Wasm32 for the time being, especially if memory needs are modest. Others, particularly those working at the edge of what the platform could previously handle, will likely be first movers.
The Wasm64 release reflects a subtle shift in mindset. It encourages thinking bigger—not abstractly, but literally. Bigger data, bigger models, bigger possibilities. And though the jump from 4 GiB to 6 GiB might seem incremental in numeric terms, in development terms it’s a signal: the limits are expanding, and the Internet Computer is ready to support the next wave of complex, memory-rich applications.
It’s still early days for Wasm64 on ICP, and the community will no doubt shape its adoption pace. The increased heap size might prompt more developers to explore what Rust can do on-chain. It could draw in projects that previously found ICP’s limits restrictive. Or it might simply enable smoother scaling for projects already embedded in the ecosystem.
Either way, Wasm64 doesn’t promise magic. It offers room—and in the world of smart contract development, room is often the difference between constraint and creativity.
