The Island: a playable model of zkDeal

Start with a trade that takes more than one step

Imagine two villages making a deal. One supplies grain; the other supplies oil. They need to agree a price, check quantities, allocate the goods and authorize release. If the first village delivers before the second has finished, something can go wrong in between. A price moves. A promise is broken. One side is left exposed.

zkDeal's central idea is to put related work inside a room with explicit rules, then use a proof to connect the completed result to Ethereum. The Island turns that abstract sequence into a small world you can watch. Villages trade, rooms fill with activity, provers work, and a distant Monolith records accepted checkpoints.

The game runs in your browser. No wallet or tokens are needed. Take the hand, move around the island and inspect a room. You can learn the main distinction simply by watching: work happening inside a room is different from a result accepted at the checkpoint.

The rooms make provisional work visible

Each circular room hosts a bounded deal. Its inspector shows the participants, policy, stage and deadline. Follow one through the sequence:

1. Commit: agree who participates and what rules govern the deal.
2. Import: bring the starting assets into the episode.
3. Execute: accumulate steps such as matching, allocation and approvals. This is provisional work.
4. Prove: package the combined result into a receipt.
5. Checkpoint: the Monolith accepts the result and advances the shared recovery point.

That fourth-to-fifth-stage boundary matters. A busy room, a pile of blocks or a prover working hard is not yet an accepted result. In the actual protocol, verification binds a candidate transition to the committed policy and starting state. The game represents that with visible blocks, a receipt and a checkpoint effect.

The Monolith stands for the acceptance boundary

Proof effects travel toward the Monolith, and its checkpoint number advances. Think of it as the island's picture of Ethereum: a common place where accepted results become the reference point for what comes next.

A room can do several pieces of work before that boundary advances. It can also continue through further batches. The useful question is not just “Has something happened?” but “Which result has been accepted?” This is why the game gives the Monolith such a prominent position on the horizon.

A deadline can pass without a settlement

Watch a room miss its deadline. Its provisional episode dissolves; it does not become a successful settlement merely because time ran out. In this simplified game, the villagers recover their staked grain after the failure and release stages. The most recently accepted checkpoint remains the reference point.

Real recovery is more specific. It depends on the room profile, authorizations, escrow terms and available data. There is no universal promise that every asset returns instantly. The game compresses those distinctions so the first lesson is easy to see: an unproved candidate result must not silently become final state.

For the precise distinctions, use the website's failure simulator and the article on three ways capital returns to Ethereum L1.

Why the world has rivals, rain and a wolf

Open caravans make exposure visible. Fortuna moves prices, MEV takes advantage of open trade, and Terminus squeezes room deadlines. Across the water, Volusia favors volume while Castrum Strictum favors tighter submissions. These characters exaggerate the pressure around a workflow; a bounded room still needs sensible rules and enough time to complete.

Your miracles change that environment. Rain helps village harvests, counsel supports trust, warnings help caravans and haste helps a room's provers. They cost belief, making intervention a choice rather than a free reset. Grab and guide the wolf toward a room to witness a checkpoint and collect a receipt in the chronicle.

Rain, belief, the wolf and rival gods are game mechanics. They are not protocol operations, tokens, cryptographic guarantees or a model of real proving costs. Their job is to make the consequences of timing and coordination interesting enough to explore.

Other players share a horizon, not a hosted game server

Players using the same room name can discover one another through public WebTorrent trackers and exchange game state over browser-to-browser WebRTC connections. Peer proof events appear as comets; selected world values are shared, while village life and most actions stay local.

The website serves static files through its CDN. It does not run a game server, matchmaking backend, TURN relay or prover for these sessions. Public discovery and direct connections are best effort: if trackers or a network prevent peers from meeting, the island still works solo. A peer's simulated receipt is not a cryptographically verified proof, and this cooperative shared state is not a trustless ledger.

Try a five-minute experiment

1. Open the game and select a circular room. Read its rules and watch blocks accumulate before a checkpoint is accepted.
2. Follow a proof toward the Monolith. Compare the room's current activity with the last accepted checkpoint.
3. Watch an open caravan or a room under deadline pressure. Notice the difference between exposed trade and a failed provisional episode.
4. Try rain or haste, then move the wolf near a room and open the chronicle. Separate the playful interventions from the acceptance rule they help you observe.

The game's lesson is deliberately small: agree the boundary, do the work, prove the combined result, then advance the checkpoint. For actual verification, continuing-room semantics and recovery rules, return to the protocol lifecycle and the room-model walkthrough.