A zone per org. A VM per zone.
Organization Zones partition Sigil into deterministic WASI runtimes. Each zone is owned by exactly one organisation, runs its own WASM module under its own state root, and communicates with other zones only through typed CrossZoneMessage envelopes. Seven transactions cover deploy, invoke, commit, cross-zone send, module upgrade, and the WASI-validator registry that bounds what semantics are allowed.
Platforms
Each zone is its own deterministic VM.
An Organization Zone is owned by exactly one org_did, pinned to one module_hash, and runs under a single state root. The runtime is deterministic by construction — same module, same state, same args, same result on every validator. Four parallel platforms; four independent execution lanes.
Deploy
DeployZone provisions a runtime.
An organisation publishes its zone with org_did, module_hash, and config. The zone starts with an empty state root and its own execution lane. It does not share memory with any other zone. Its WASI runtime is hot the moment it commits.
Invoke
InvokeZone calls a function inside it.
A typed call lands at zone_id with function, args, and a gas_budget. The WASI runtime executes against the zone's working state and produces a state-change set. Execution is local — no other zone observes the run until the commit lands.
Commit
CommitState atomically advances the zone.
The working state-changes vector is verified against the post-invocation snapshot and the zone's state_root advances. The transition is atomic — every entry in state_changes lands together, or none of them do. The new root is on-chain and final under MACA.
Cross-Zone
CrossZoneMessage is the only inter-zone channel.
A source_zone signs a typed message envelope; the target_zone receives it as input on its next invocation. There is no shared memory, no global registry zones can mutate, no synchronous return path. Causality is recorded in the chain, not in the runtimes.
Validators
RegisterWasiValidator gates what semantics are allowed.
The WASI-validator registry is itself on-chain. Each entry binds a name (e.g. oas-verify) to a module_hash and a set of TransactionCategory values it validates. RemoveWasiValidator retires a gate. The set of allowed semantic validators is a public, signed fact — not a runtime flag.
Upgrade
UpgradeModule rolls forward without halting the zone.
The zone's module_hash is swapped for new_module_hash under the controller's authority. State survives the swap; the new module observes the old keys. No halt, no migration window. The new code answers the next invocation.
Seven typed transactions
Every move is a signed envelope.
There is no shared memory between zones, no global registry zones can mutate, and no synchronous return path between zones. Causality is recorded in the chain itself. Each zone is a clean, deterministic VM under exactly one organisation.
Transaction Types
7
Runtime
WASI
Per Zone
1 org
Cross-Zone
Typed
The WASI-validator registry
Semantic validators are on-chain facts.
RegisterWasiValidator binds a name — oas-verify, attestation-verify, lineage-verify — to a module_hash and a vector of TransactionCategory values that the validator gates. RemoveWasiValidator retires a gate. What semantics a zone may use is a public, signed record, not a runtime flag.
Hot module swap
UpgradeModule rolls forward without halting the zone.
The module_hash is swapped for new_module_hash under the controller's authority. State persists across the swap — the new code observes the old keys. There is no halt, no migration window. The new module answers the next invocation.
One organisation. One module. One state root.
An Organization Zone is the unit of execution autonomy on Sigil. Stand one up, run your org's logic deterministically, talk to other orgs over typed envelopes, and upgrade live.