API Reference

TL;DR: From inside your C# script, you call Unity types normally (Transform, GameObject, Debug.Log, …) plus a set of CVR-specific types (Player, Prop, World, …). The CCK WasmModule package provides the C# shim you compile against; at runtime those calls go through WASM imports implemented by CVR’s binder layer. This section documents the underlying WASM import surface so you can reason about what is and isn’t reachable.

Three layers

Your C# script  -- compiles against -->  CCKWasmModule shim (private)
                                              |
                             exports WASM imports like
                                              |
Guest WASM module  -- imports from -->  CVR host binder layer
                                              |
                        each import resolves to a
                                              |
Host C# delegate  ---  calls UnityEngine / CVR systems ---  CheckAccess

The three pages

• CVR Host Functions — every CVR_* and FileStorage_* import exposed to WASM guests. Grouped by subsystem (Player, Avatar, World, Prop, Portal, Networking, FileStorage, LocalPlayer, AvatarPoint, Util, WorldPermissions). Each entry lists the import name, shape, and access masks.
• UnityEngine Surface — the UnityEngine, UnityEngine.*, and TMPro types that have generated bindings. If a Unity type isn’t listed here, calls on it either hit an empty stub (safe no-op) or the guest shim refuses at compile.
• Not Exposed — explicitly disallowed or conspicuously absent APIs (Input, Application, System.IO, System.Net, Reflection.Emit, etc.) and what to use instead.

Reading the tables

• Import name — the string the WASM module imports from the CVR or UnityEngine / TMPro module. You never see this name in script code — the shim handles it.
• Shape — parameter and return types in WASM terms:
  • i32 — 32-bit int (used for pointers and lengths in guest linear memory).
  • i64 — 64-bit int (used for wrapped object handles and timestamps).
  • f32, f64 — floats.
  • ptr[T] notation in docs means “i32 pointer into guest memory where a T lives”.
• Access masks — (Object, Owner, Scope) tuple the binding enforces via WasmAccessManager.CheckAccess. Two-axis entries omit Scope. Any means the axis imposes no restriction.

Guest-to-host, host-to-guest

Two patterns recur across the binder layer:

• Getter / reader — guest passes (selfId, outPtr); host reads the property and writes the value at outPtr in guest memory.
• Setter / mutator — guest passes (selfId, inPtr); host reads the input at inPtr and assigns.
• Allocator callback — for variable-length output (strings, arrays), the host calls the guest-exported _alloc(size) to get a fresh buffer inside guest memory, writes to it, then writes (ptr, len) back into a pair of pointer fields supplied by the guest.

See Architecture → Binding layer for the canonical code sample.

Handle hygiene

All host-owned objects return 64-bit wrapped handles. A few rules:

• Handles are not pointers. Never dereference, arithmetic, or serialize them across sessions.
• A handle is valid only while the host object still exists. Once the GameObject is destroyed, the handle is stale; the next use will throw or return a null handle.
• Equality between handles (a == b) compares the index+version pair; it is safe for identity checks within a single session.

Related

• Architecture
• Permissions