Running a world as an exhibition

An exhibition is the easiest home for a ChainBloom world, because a show already has an opening, a closing and a shape. This page is the practical half: the desk, the sign, the queue, the money, and the box of information you keep when the walls come down.

The station#

Put one staffed station in the room. Not a kiosk. A person.

A visitor at the station is going to sign a real Bitcoin transaction, and the moment they hesitate is the moment your programme either earns trust or loses it. The station needs a member of staff who can say, in their own words, what happens when the visitor presses the last button and why nobody can take it back.

What the station holds:

A screen running the ChainBloom workspace inside InScribe. It has four surfaces: Explore for confirmed , Lanes for the live held by the connected address, Act to build a plan and review, sign and broadcast it, and Learn.
A dedicated wallet holding only the coins for this programme. Never the institution's general wallet. A wallet that does not know about ChainBloom can spend a output as ordinary change, and if that spend confirms, the path becomes abandoned with the reason INVALID_CONFIRMED_SPEND. Nothing replaces it. Keeping programme coins apart is the cheapest insurance you will buy.
A printed one-page briefing for staff, including the sentence about irreversibility and what to say when a transaction is slow.
A second screen or a print showing the world so far, so people waiting can see what they are joining.

How many people can actually contribute#

There is a hard limit worth knowing before you design the queue. A step is rejected if the path's own previous event is in the same block or later, and the validation rules emit UNCONFIRMED_LINEAGE_PARENT. A path advances at most once per block.

About 144 blocks arrive in a day, so a single path can take at most about that many steps in a day, and in practice far fewer. With 8 paths open you have 8 independent queues, not one. If you expect a crowd, more paths help; a longer opening does not.

What the wall text must say#

Wall text is where institutions get careless, because the honest sentences are less exciting than the dishonest ones. Five things belong on the wall, in plain words.

What the world is. The invitation, in one paragraph. How many paths, how long it stays open, what a step is asked to mean.
What taking part costs. A network fee paid to Bitcoin miners, plus 1,000 satoshis held in the path while it is alive and released when the path is completed. Say who pays it: the visitor or the venue.
That it cannot be undone. Once a step is confirmed in a block, no one can remove it, edit it or reorder it. Not the visitor, not the artist, not the museum.
That there is nothing to own. No token, no edition, no certificate, nothing to sell later. If your marketing department writes otherwise, this is the sentence that has to win.
Where to read more. A short URL to your own programme page, and from there to what is running, so nobody is misled about what can be browsed today.

What must not be on the wall: any number describing future value, any claim that the record proves who made something, and any implication that the museum can withdraw a contribution on request.

Visitors who do not have a wallet#

Most of your audience will not have one, and it is a mistake to build the programme around the few who do. Offer three tiers and let people choose without embarrassment.

Watch. The world on a screen, with the ordered history beside it. No wallet, no cost, no account. This is the default experience and it should be good on its own. See accessibility for the plain ordered list that makes it work for everyone.

Contribute through the host. The visitor chooses what the step should be, and the station signs from the programme wallet. This is the tier most people will use. It is honest as long as the wall text says the venue holds the keys: the record shows the venue's address, and the visitor's authorship lives in your own documentation, not on the chain.

Contribute themselves. The visitor connects their own wallet and signs. Reserve this for people who arrive wanting it. Do not spend twenty minutes of a queue installing a wallet for someone who came to see a show.

Network fees on an institutional budget#

The fee is not a fixed price. It is the fee rate on the day multiplied by the size of the transaction, and fee rates move.

For budgeting, the useful shape is: total fees are roughly the number of contributions times the fee for one step. Set an internal ceiling per contribution, and have the station check the fee before signing rather than after. When ChainBloom is connected to an index, the build response returns an unsigned transaction plus a preview with the path mappings, outputs, total input, miner fee, change, fee rate, locktime and any warnings. Read the miner fee off that preview and stop if it is above your ceiling.

Two more budget facts worth having in the paperwork:

The 1,000 satoshis per live path are held, not spent. They come back when the path is completed. Finance will ask; that is the answer.
Creating the world funds one root carrier per path, so a world with the maximum 8 paths locks 8 times 1,000 satoshis from the first day.

Fees and confirmation explains how to read a fee before signing and what to do when a transaction sits unconfirmed for longer than you would like.

Opening and closing dates versus block heights#

Your show closes on a date. The world closes at a . These are not the same thing and confusing them is the most common planning mistake.

When the world is created, the creator picks a duration in blocks, between 144 and 52,560. The end point is endHeightExclusive, which is the height of the block that confirmed the creation plus the duration. It is fixed at that moment and cannot be moved, extended or shortened by anyone.

Blocks are not a calendar. A run of slow blocks pushes the real end date later; a run of fast ones pulls it earlier. So:

Convert your closing date to blocks using about 144 blocks a day, then add real margin measured in days, not hours.
Create the world well before the private view, not on the morning of it. The world does not exist until the creating transaction confirms, and every path's first step must come in a strictly later block.
End the show deliberately. On the last night, complete each path on purpose. A completed path records a terminal reason of CLOSE_<reason>, and the world becomes ended once no live paths remain. A path left running until the duration elapses expires with the reason WORLD_DURATION_ELAPSED, which reads on the record as an exhibition that stopped rather than finished.

After the show#

The work does not need your website to survive, but it does need you to write down four things before the install comes down.

The world id, which is the transaction id of the creating transaction.
The network it was made on.
The , 16 bytes, which any renderer needs to reproduce the same visual arrangement.
The event list, which is each contribution's transaction id and the block height it confirmed in.

With those, anyone can rebuild the world from the chain, in the same order, without you. An independent replay sorts worlds and paths by id and events by height and then by position within the block, which is exactly why two people replaying separately get the same result.

What you cannot archive is the look. Rendering is deliberately outside the rules (see src/render.ts), so a gallery in ten years may draw your world in a way you would not recognise, and it will not be wrong. If the specific appearance matters to the work, archive your renderer's source and a high-resolution capture alongside the four items above, and label the capture as one interpretation rather than as the record.

The carriers are the loose end. Any path you did not complete still holds 1,000 satoshis on an address somebody has to keep the keys to. Decide before deinstall who that somebody is, and put it in the same document as the world id.