Crypto app demo video: which scenes must be real and which can be staged

Your demo video for a crypto card, DeFi dashboard or tax tool opens in a place you do not control: the user's wallet. This guide sorts the scenes into "must be real" and "may be staged", covers store preview rules and a 1965 Supreme Court case, and shows how to film the funding step.

Published:

Hardware wallet app screen composed in Flexdger Wallet: a portfolio named Beacon, a total balance and its change for the day above a row of Transfer, Swap and Buy buttons, a market row and a perpetuals card, then the list of holdings with each amount and its move for the day, in a dark theme with a lavender accent.
Composed in Flexdger Wallet. Every figure on it was typed in; nothing is held, sent or received, and no chain is read.

Two kinds of scene in one video

Almost no crypto product is a wallet. A card that spends stablecoins, a dashboard reading DeFi positions, a tax tool that imports addresses, a payment link for merchants: all of them begin in somebody else's wallet. So a demo video mixes two kinds of scene. Some belong to your product and are claims about it. One or two belong to the user's world and only set the stage.

The stage scene is where teams get into trouble. Filming the founder's wallet puts a real address, real holdings and real history in a video meant to circulate; why showing crypto online makes you a target explains the stakes, and what the hide balance toggle still shows covers why masking a total does not fix it. A brand-new testnet wallet is safe but empty, so the story has no starting point. A used testnet wallet is cluttered with faucet tokens that have strange names and amounts and pull attention from the product.

Prop or proof: a 1965 rule that still applies

The US Supreme Court drew the line in FTC v. Colgate-Palmolive Co., decided April 5, 1965. A shaving cream ad seemed to show the product shaving sandpaper, but the sandpaper was a mock-up, plexiglass with sand sprinkled on it. The Court held that using an undisclosed mock-up as proof of a product claim is deceptive. It also set that apart from a commercial in which mashed potato stands in for ice cream: there the stand-in is not offered as proof of the claim.

Applied to a crypto demo:

Numbers inside your app deserve extra care. Seed a staging account with plausible sample data that stays consistent from scene to scene, so the 2,400 USDC that leave the wallet at the funding step are the 2,400 USDC that arrive at the result. Use the real rates and fees of the recording day, and put the date in a caption if they move. Never display a balance, a yield or a speed the product cannot deliver.

What the app stores allow

Previews are the one place where the rules are written down. Apple's App Review Guidelines ask for screenshots that show the app in use (2.3.3) and allow previews to use only video screen captures of the app itself, with narration and text overlays permitted for explanation (2.3.4). Google Play asks for a preview of the real in-app experience, with at least 80% of the video representative of the user experience, and notes that only the first 30 seconds autoplay. It refuses age-restricted videos and asks you to switch off ads on the video you link.

Consequence: a store preview is your app and nothing else. No simulated third-party wallet, no scene borrowed from another app. If the funding step matters, show it the way your own app presents it. Resolutions and frame counts are in app preview video specs.

One structure, three audiences

A demo follows one user through one task. The same skeleton stretches or shrinks depending on where the video will be shown.

For the cutaways between scenes, from cash to wallet screens, money b-roll lists shots.

How to record the funding step

  1. Point a staging build at a testnet or your payment provider's sandbox, so real money never moves on camera.
  2. Create a wallet for the shoot from a new recovery phrase. MetaMask's help center explains that an EVM account keeps one address on every chain, so a personal account used on testnet still reveals the mainnet address.
  3. Fund it with round, believable amounts and hide stray test tokens.
  4. Hold the approval prompt on screen long enough to be read. Users must recognize it later, and hurrying past it suggests something to hide.
  5. Silence notifications and record in a clean browser profile with no personal tabs or extensions.
  6. Label every simulated frame on screen, for instance with a small "Illustration" tag.

Capture settings and cursor technique are in recording a wallet screen video.

A simulated wallet for the stage scene

This is where a different kind of tool earns its place.

A larp wallet, or crypto wallet app simulator, builds a believable wallet screen from figures you type, for a video, a sketch, a pitch deck or a demo. It holds nothing and reads no chain.

Enter the starting point your user story needs, for example 2,400 USDC and a little ETH, and capture the screen. It also helps with storyboards and slides drawn before the product exists. We make one of these apps, Flexdger Wallet. Product teams use this kind of screen for empty and full states, layout tests and support documentation, and five uses for product teams goes through them. For hackathon builds, the web3 hackathon demo video applies the same split between story frames and the working demo.

Setting the scene, nothing more

A simulated wallet can set a scene. It can never replace your own interface, show a feature that does not exist, or present balances as traction, customer deposits or returns. Keep it out of store previews, label it wherever it appears, and record everything your product does for real. Our terms of use forbid using our screens to make anyone believe in assets that do not exist, or to obtain an investment on the strength of an invented financial position.

If your demo also shows a desktop dashboard, see which panels a crypto dashboard needs and the number rules that keep it readable on camera.

Sources

Questions

Where do I start with a demo video for my app?

Choose one user and one task, script it, and screen-record the real app doing that task from first tap to result. Add a voice and captions, trim the waiting, and put the core early, since on Google Play only the first 30 seconds of a preview autoplay. Use a staging build with demo accounts so no customer or founder data shows.

What should a fintech demo show?

The main task end to end in the real interface: how money gets in, what the product does with it, what the user sees at the end, with real steps and fees. Sample balances should read as sample data, never as returns, performance or customer deposits.

Are mockups acceptable?

Outside your product, such as the user's wallet before connecting, a labeled mockup is fine on a site or in a pitch. In store previews it is not: Apple's guideline 2.3.4 limits previews to video screen captures of the app itself, and Google Play expects at least 80% of the video to represent the user experience. Never mock up your own product to show features that do not exist.

How long should the video run?

Store previews follow store rules: Apple's run 15 to 30 seconds, and Google Play autoplays only the first 30 seconds. Websites and pitches have no rule, yet one task shown in about a minute holds attention better than a tour of every screen.

Can my own wallet appear in the recording?

Better not. A shared video that shows a wallet can expose an address, holdings and history that anyone can look up. On EVM networks one account has one address on every chain, testnets included. Make a dedicated wallet for recording and keep personal funds out of the frame.

Keep reading