Inventory & Items
Universal items that work across worlds and runtimes, and the four-tier execution model that decides what the client may do and what the server must own.
Items in HELIX are universal: an item a player owns exists across worlds and renders on every
runtime (each item ships per-runtime renditions — e.g. a web GLB and an Unreal static mesh).
Helix.inventory is how a world reads and uses what a player owns.
Reading inventory
Prop
Type
if (await Helix.inventory.hasItem('vip_hat_001')) {
await Helix.inventory.equipItem('vip_hat_001');
}Execution tiers
The most important thing to understand about items is who is allowed to run their logic. Every item declares a tier:
Prop
Type
The golden rule, restated
If it affects inventory, currency, or ownership, the server is authoritative. If it only affects visuals or local gameplay, the client can be trusted. Tier 3 logic runs on the server, full stop.
Consuming an item (Tier 3)
Consumption is server-authoritative and idempotent — a retried network call can't double-spend:
// server-side (HelixServer / HelixInstance context)
const result = await Helix.inventory.consumeItem({
itemId: 'health_potion_001',
quantity: 1,
idempotencyKey: requestId,
});
// result.mintResults describes any items/currency atomically granted in returnItem lifecycle hooks
Interactive items implement lifecycle hooks the runtime calls for you:
onEquip, onUnequip, onPlace, onRemove, onInteract, onUpdate, onStateChangedReference
- Web SDK →
Helix.inventory - Server authority → How HELIX works
- Economy → LIX & Economy
Memory Store
Volatile, low-latency storage shared across all instances of a world. TTL-required. Great for leaderboards, matchmaking, and hot counters — never the source of truth.
Social & Presence
Friends, presence, and invites — the social graph that powers HELIX's virality loop, available identically on every runtime.