Sharding
Execution sharding for Dojo worlds: table-like on-chain state, proxy-routed shard sessions, operator-run Katana, Torii indexing, and component-enforced CRDT settlement.
Database-like state, settlement-safe shards
Large on-chain apps need database-like reads and writes without hand-managing storage slots or losing settlement safety.
Dojo world stores model/entity state, Torii indexes world events, and proxy/operator/component move large sessions onto forked Katana safely.
- Boundary note
- Dojo gives a database-style model layer over Starknet storage.The analogy explains model/entity reads and writes; settlement still proves exact slots, baselines, and CRDT rules.
- Evidence path
- Dojo model storage / Torii event indexing / Proxy addr@id routingPublic proof path: Dojo layout, Torii indexing, proxy routing, operator lifecycle, component settlement.
- What it proves
- Demonstrates the hard boundary: fast forked play matters only when settlement proves which writes may re-enter live state
- Frames sharding as a general Dojo data scaling path, not only a game-specific trick
How the data moves through the system
First read the data path. Then use the code hooks as pointers to the mechanisms that make the claim inspectable.
Dojo is a model layer for Starknet storage: models define schema, entities act like rows, and macros derive slot keys.
The world contract stores models, entity writes, permissions, and deterministic Poseidon storage derived from model/entity fields.
Torii watches world events, materializes entities into SQLite-backed state, and serves frontend queries and gRPC streams.
The proxy emits game_contract and shard_id; the operator stores work as world_contract_addr@shard_id.
The daemon watches proxy events, enforces per-game capacity, starts Katana and Torii, gathers proofs, retries, and settles.
Existing Dojo worlds add the component, set proxy and registry once, then use its request, end, and settle paths.
App code writes models/entities; Dojo derives the deterministic Starknet slots behind that API.
StoreSetRecord and update events become indexed entities, so the UI subscribes to model state instead of scanning blocks.
On-chain counters stay per world; the operator's addr@id key lets many worlds run shards without id collisions.
ContractComponent locks slots, snapshots Add values, forwards requests to proxy, and applies only registered slots on settlement.
Service mode watches ShardingRequested, spawns forked Katana, starts shard Torii, tracks state, retries failures, and submits atomic settlement.
How the system progresses
A short staged view of the system from start to final output.
Define model state
Developers define Dojo models; macros and layouts decide how fields become storage slots in the world.
Request a shard
Game code calls the component; it locks slots, snapshots Add baselines, and asks proxy to emit the shard request.
Operate and settle
The operator boots Katana, exposes Torii, collects diffs and proofs, then submits verified values for component-side CRDT merge.
Index state for UI
World or shard Katana emits Store events; Torii indexes them into entity tables and streams changes to clients.
Public proof path: Dojo layout, Torii indexing, proxy routing, operator lifecycle, component settlement.
- Inspect Dojo world Store events, Torii StoreSetRecord processors, and world-scoped entity storage.
- Inspect proxy active-shard maps, ShardingRequested events, and operator ShardKey state keyed by world address plus shard id.
Finish the evidence first. The full-screen environment is the closing section.
Open the full-screen environment for this project
One project mechanism, isolated from the article.
Settlement Boundary Explorer
Dojo world state, proxy routing, operator-run Katana, Torii, and CRDT settlement.
Model/entity path: Dojo world, proxy, operator, forked Katana, Torii, CRDT merge.
Open environment