How to show a crypto portfolio in a pitch deck

A portfolio screen in a deck is a product illustration, not evidence. Here is how to make it legible at slide scale, and where the real numbers actually go.

Published: 27 August 2026

What the slide is actually doing

A portfolio screen in a deck answers one question and only one: what does this product look like when someone is using it? It is a product illustration. It is not proof of assets under management, not proof of users, and not proof of revenue — those live on a chart with a source and a date, on a different slide.

Conflating the two is the mistake that turns a design decision into a diligence problem. Keep the jobs separate and the rest of this article is mostly typography.

Make it legible at slide scale

This is where most decks quietly fail. A phone screenshot is tall and narrow; a slide is short and wide. Dropping a full-height phone into a 16:9 slide shrinks it by roughly a factor of four, and everything inside shrinks with it.

The arithmetic, using a wallet screen exported at 1179 × 2556 where the token name is set at about 54 px and the balance at about 142 px:

Slide canvas	Phone height on slide	Scale	Token name	Balance
1920 × 1080	1080 px (full bleed)	0.42×	≈ 23 px	≈ 60 px
1920 × 1080	864 px (80%)	0.34×	≈ 18 px	≈ 48 px
1280 × 720	720 px (full bleed)	0.28×	≈ 15 px	≈ 40 px
1280 × 720	576 px (80%)	0.23×	≈ 12 px	≈ 32 px

Twelve pixels of soft, downscaled grey type on a projector at the back of a room is not readable, and an investor reading a PDF at 40% zoom is in the same position. Note also that Keynote defaults to a 1920 × 1080 canvas while PowerPoint's widescreen default is 13.333 × 7.5 inches — 1280 × 720 at 96 pixels per inch — so the same deck can lose a third of its effective resolution simply by being rebuilt in another tool.

One more reason to care about the source resolution: a deck is rarely viewed at the size it was built. It gets exported to PDF, zoomed on a laptop, projected, and screenshotted into a follow-up email. An image that was already soft on slide one is unreadable by the time it has been through that chain, which is why the mockup should start at full device resolution even though the slide will never display all of it.

Crop instead of shrinking

The fix is not a bigger phone. It is showing less of it:

• Crop to the region that carries the point — the balance header and two token rows, not the whole screen with a tab bar and empty space.
• Show the full device once, early, to establish that it is a phone. After that, crops read fine.
• If you must show the whole screen, put it against a wide element — a caption column, an annotation — rather than centring it in a sea of background.

Choosing the numbers

Invented values in a product illustration are normal. Careless ones are what gets noticed:

Element	Rule	Reason
Total balance	Mid-range, uneven	Six round figures read as a placeholder; an implausibly large one reads as a claim
Token list	Sums to the header total	The arithmetic is the first thing a numerate reader checks
24h change	Modest, mixed signs	An all-green screen with large gains reads as a promise of returns
Token choice	Assets your product actually supports	A chain you do not support on the hero slide invites the wrong question
Wallet name	Neutral and obviously demo	A real person's or company's name creates a problem you do not need
Third-party logos	Only with the right to use them	Token and exchange marks are trademarks like any other

Label it on the slide

One line of small type under the mockup — illustrative UI, sample data — does the whole job. It costs a few pixels and it removes any ambiguity about whether the screen is a claim. Do it especially when the deck will be sent rather than presented, because a deck that circulates without you loses every verbal caveat you would have given in the room.

This is also the line that separates a mockup from a misrepresentation. Presenting invented balances as real holdings, assets under custody or user funds to raise money is not a stylistic choice — it is a false statement to investors, and no amount of design polish changes that. Label the illustration and the problem never exists.

Where the real numbers go

Give traction its own slide and its own visual language, so nobody has to work out which figures on screen are real:

• Charts, not phone screens, for anything measured.
• A stated period and a stated source under each chart.
• Cohort or retention framing rather than a single cumulative total.
• If a number is small, show it small and say what it is — early numbers are expected at an early stage. Dressed-up ones are not.

There is a practical benefit to the separation beyond honesty. A deck where the product slide is obviously a product slide and the traction slide is obviously a traction slide is faster to read, and it lets you update the two on different clocks: the mockup changes when the design changes, the chart changes every month. Decks that mix them end up rebuilt from scratch every time either one moves.

Producing the image

Two constraints matter: native resolution, so the screen stays sharp when the deck is exported to PDF or projected, and cheap variants, because the numbers on that slide will change three times before the deck is final. Rebuilding a wallet screen by hand for each revision is the reason so many decks ship a blurry crop of a six-month-old screenshot. A generator solves the second constraint — My Larp Wallet renders the screen from typed-in values and exports at 1179 × 2556, so a change of figure is a change of figure, not an afternoon.

Before the deck goes out

1. Every mockup labelled as illustrative.
2. Nothing smaller than roughly 18 px once placed on the slide.
3. Token values summing to the displayed total.
4. No performance figure inside a mockup.
5. Real metrics on their own slide, with period and source.