A crypto wallet demo that survives a live audience: a run sheet

Wallet demos fail in public for reasons that never showed up in rehearsal: shared wifi, prices that moved, a send stuck waiting on a chain. This run sheet covers what to decide before the day, how to size screens for a projector, how to keep movement without surprises, and when the real app must run.

Published: 22 September 2026 · Last reviewed: 25 September 2026

The run sheet, in the order you will need it

Treat the demo as a show with a script, not as a tour of software. A script has beats, a beat needs one picture, and a picture can be prepared. The software cannot be, because it depends on things you do not own on the day. Below is what to settle, in order, and why each item exists.

Settle before the day

• The numbers. Tokens, quantities, the day's change, account name, accent colour. Decide once, then stop touching them.
• One image for each beat. A frame for every thing you plan to say, numbered in the order you will say it.
• Where the files live. On the machine that drives the screen. Not in a cloud folder, not on a shared drive, not behind a link.
• The phone, if you mirror one. Do Not Disturb on, auto-lock off, brightness fixed, rotation locked.
• The exit. Even when you intend to run live software, keep the exported frames one keystroke away.

What breaks in the room and never in rehearsal

A wallet demo has more parts than the slide before it, and most are someone else's. Venue wifi is shared with four hundred laptops, so a price feed times out and the fiat column turns into dashes. A real balance moved overnight, so the figure you practiced is not the figure on screen. A send waits on a chain: an Ethereum block takes twelve seconds and nobody treats a single block as settled, while a Bitcoin block averages ten minutes. None of this is a bug. A live system is behaving normally at the one moment you cannot pause it. To look at a composed screen before the talk, open the crypto wallet simulator.

Sizing for the wall

A screenshot from a 6.1-inch iPhone measures 1179 × 2556 px. The room almost always runs 1920 × 1080. Fit that phone to the height and it is about 500 px wide, a quarter of the screen, with everything shrunk by the same factor of 0.42. Text that is comfortable at arm's length is unreadable from row twelve. So crop to the rows that carry the point, put the phone next to text rather than in the centre, and read the numbers aloud instead of pointing at them.

Motion without surprises

A frozen screenshot feels like a slide, and an audience notices. In a composed screen the market prices are real and refresh every few seconds, so the fiat column moves while you talk and the screen behaves like an application. The quantities underneath are typed and stay still, which means the sentence you rehearsed keeps matching what is on the wall. If the venue wifi drops, prices simply freeze at their last value; quantities and script do not change.

That is the one trade a real account cannot offer: movement without a story that shifts under you. It remains a mockup. It holds nothing, reaches no chain and signs nothing.

Cases where the real software has to run

Composed screens answer questions about the interface and none about the software. An integration check, a signing flow, latency under real conditions, an acceptance pass with a client, a bug reproduced in front of the person who reported it: each of these needs the code running, and no picture stands in.

When that is your case, plan the failure rather than hoping past it. Bring a wired connection, or a hotspot you tested in that very room. Fund the account the day before. And agree with yourself on an exit: if a send has not confirmed in fifteen seconds, you keep talking and put up the frame.

One sentence of disclosure

Early in the talk, say that these are composed screens and the numbers are yours. It takes two seconds and removes the question that would otherwise land in Q and A. The image is not evidence of funds, and no caption turns it into one.