HELIX 3 Docs
Introduction

How HELIX works

The core nouns — World, Build, Instance, Player, Event — and the lifecycle of a player opening a world.

HELIX has a small, deliberate vocabulary. Learn these five nouns and the rest of the docs read cleanly.

Public vocabulary

World · Build · Instance · Player · Event. These are the only words the SDK and docs use for the runtime. Provider-specific terms (rooms, matches, servers) never appear in the public API — they're implementation details HELIX hides behind the SDK.

The nouns

Prop

Type

The lifecycle

What happens when someone opens your world from a link:

Launch. A player opens your World. HELIX authenticates them (or spins up an instant guest) and issues a short-lived Launch Ticket.

Init. Your client boots and calls Helix.init({ worldId, launchTicket }). The SDK validates the ticket and exposes the player's identity, wallet, and inventory.

Join an Instance. The player joins a running Instance of the current Build (or HELIX creates one). The platform issues an Instance Ticket that the runtime verifies before admitting them.

Play. Client and server exchange Events. The server is authoritative for anything that touches wallet, inventory, or ownership; the client is trusted only for visuals and local gameplay.

Persist. State that must survive the session is written through Cloud Save. Transient cross-instance state (leaderboards, matchmaking) uses Memory Store.

Server authority — the golden rule

Never trust the client for value

If an action affects inventory, currency, or ownership, the server is authoritative. If it only affects visuals or local gameplay, the client can be trusted. This single rule decides where every piece of your logic belongs — see the Universal Item Contract.

Where this lives in the SDK

You orchestrate all of this from the Web SDK (client) and the server SDK (HelixInstance). The platform pieces — auth, wallet, storage, inventory — are the Platform API, identical across runtimes.

On this page