WebAssembly runtimes have minimal memory overhead compared to JavaScript engines like V8, which require significantly more memory. That gap, cited by the Bytecode Alliance — founded by Mozilla, Fastly, Intel, and Red Hat — is not a browser curiosity. It is a systems-level rethink. Wasm starts 100 times faster than JavaScript and ships at 10,000 times smaller size. Docker's own co-founder, Solomon Hykes, said it plainly: if WebAssembly and WASI had existed in 2008, Docker wouldn't have needed to exist. In previous discussions, we highlighted the importance of deterministic memory snapshots for save-states and multiplayer sync, emphasizing their critical role in system stability. Now the question is: what happens when OpenClaw's entire memory architecture has to run inside a browser sandbox? WebAssembly, a W3C standard since 2019, is now on version 3.0, showcasing its rapid evolution and adoption. It is the first mainstream language designed with formal semantics from the start — not retrofitted safety, but safety by construction. It uses a binary format for compact transmission and executes via Just-In-Time compilation, leveraging hardware fully. The result is near-native performance despite running inside a sandboxed environment with no direct system calls. That surprises engineers who assume sandboxing means slowdown. It doesn't have to. Here is where OpenClaw's memory architecture hits a hard constraint. Traditional heap memory is flexible — the OS hands out virtual address space dynamically, pointers roam freely, and allocators like tcmalloc negotiate with the kernel. WebAssembly replaces all of that with a single, contiguous linear memory buffer. One flat array. No pointer arithmetic outside its bounds. No direct system calls. This is the sandboxed linear memory model, and it is non-negotiable. Adapting OpenClaw's pool allocators involves using the linear buffer as the backing store, with pool slots as fixed offsets, aligning with Wasm's model. The relative addressing discipline we built for snapshot portability pays off again here, Sergey: offsets transfer cleanly into Wasm's flat model where raw pointers would not. Wasm also supports threading via shared memory and atomics, but the concurrency model is constrained — not the free-threaded environment of a native Linux process. That matters for the async asset loading pipeline we covered in lecture four. It's crucial to understand that porting to WebAssembly involves more than just recompiling; it requires significant architectural adjustments. The linear memory model, the absence of system calls, the threading constraints, and the requirement to route all I/O through WASI — the WebAssembly System Interface — mean that a non-trivial portion of any native codebase requires rearchitecting, not just recompiling. Wasm is architecture-agnostic, removing the need for x86 or ARM-specific binaries, and it runs beyond browsers — Node.js modules, Docker containers, edge computing, IoT devices where JavaScript cannot even fit. Those are real deployment wins. But they come after the porting work, not instead of it. For you, Sergey, here is the synthesis that matters: every architectural decision in this course — pool allocators for contiguous memory, relative addressing for portable snapshots, async loading to protect the render thread — was preparation for exactly this constraint. Porting OpenClaw to WebAssembly is not a new problem. It is the same problem restated: take a system built for one memory environment and make it run faithfully in another. The linear memory model is the new DirectDraw. The discipline is identical. The sandbox is just the latest cage.