# Putting a crypto portfolio screen in a pitch deck Source: https://flexdger.com/blog/crypto-portfolio-pitch-deck Updated: 2026-09-25 Published: 2026-08-28 Topic: Crypto wallet mockups (https://flexdger.com/blog/crypto-wallets) > How to show a crypto wallet or portfolio screen in a pitch deck: type that survives a projector, numbers read as illustration, and where real traction goes. The screen is there to show the product, not to prove anything. Size it so the back of the room can read it, pick numbers that behave, label it, and keep real traction elsewhere. **Short answer:** Show one phone-sized portfolio screen built from a small, obviously illustrative dataset, label it as illustrative UI on the slide itself, and put your real traction on a separate chart: a mockup demonstrates the product, it never stands in as evidence of assets or revenue. ## The back-row test Picture the slide on a projector with someone reading it from the far end of the room. A phone screenshot is tall and narrow, and a slide is short and wide, so pasting a full-height phone into a 16:9 frame scales it down to roughly a quarter of its height. Every element inside shrinks by the same factor. Take a wallet screen captured at `1179 × 2556`, with the token name set at about 54 px and the balance at about 142 px. Here is what the slide does to it: - **1920 × 1080 canvas, phone at full height (1080 px):** scale 0.42×, so the token name lands near 23 px and the balance near 60 px. - **1920 × 1080, phone at 80% (864 px):** scale 0.34×, token name near 18 px, balance near 48 px. - **1280 × 720, phone at full height (720 px):** scale 0.28×, token name near 15 px, balance near 40 px. - **1280 × 720, phone at 80% (576 px):** scale 0.23×, token name near 12 px, balance near 32 px. Twelve pixels of soft grey type will not survive a projector. The same goes for a reader scrolling a PDF at 40% zoom. Also watch the tool: Keynote starts from a 1920 × 1080 canvas, but PowerPoint's widescreen default is 13.333 × 7.5 inches, which is 1280 × 720 at 96 pixels per inch. Rebuild a deck from one to the other and it can lose a third of its effective resolution without anyone touching the artwork. A deck also travels. It gets exported to PDF, zoomed on a laptop, projected and pasted into a follow-up email. An image that was soft on slide one is illegible by the end of that chain, so start the mockup at the full device resolution even though the slide will never show every pixel. ## Show less of the phone A bigger phone is not the cure. A smaller window onto it is: - Crop to what makes the point, for instance the balance header plus two token rows, instead of the full screen with its tab bar and empty space. - Show the complete device once, near the start, so the audience knows it is a phone. Later crops then read without confusion. - If the full screen has to appear, set it beside something wide, such as a caption column or annotation, instead of centring it on a field of background. ## Numbers that behave Nobody minds invented values in a product illustration. What gets noticed is carelessness, so apply these rules: - **Total balance:** pick something mid-range and uneven. A string of round figures looks like a placeholder, and an outsized total looks like a claim. - **Token rows:** make them sum to the header total. Readers who like arithmetic try this first. - **24h change:** keep it modest with mixed signs. A screen of large green gains reads as a promise of returns. - **Which tokens:** stick to assets your product really supports. A chain you do not support, on the hero slide, prompts the wrong question. - **Wallet name:** choose something neutral that is clearly a demo. A real person's or company's name creates trouble you do not need. - **Logos:** use third-party marks only if you have the right to. Token and exchange logos are trademarks like any other. ## One line of small type settles the question Under the mockup, add something like *illustrative UI, sample data*. It takes a few pixels and ends any doubt about whether the screen is a claim. This matters most when the deck is sent instead of presented, because a deck in circulation loses every caveat you would have said aloud. The label is also where a mockup stops and a misrepresentation begins. Showing invented balances as real holdings, assets under custody or user funds in order to raise money is no design choice. It is a false statement to investors, and polish does not alter that. Label the illustration and the issue never arises. ## Real traction, elsewhere Give traction a slide of its own, in a different visual style, so the audience never has to sort real figures from sample ones: - Use charts, not phone screens, for anything that was measured. - Put a period and a source under every chart. - Prefer cohort or retention views to one cumulative total. - When 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. Keeping the two apart helps in a practical way too. A product slide that obviously is one, next to a traction slide that obviously is one, is quicker to read, and each can be refreshed on its own schedule: the mockup when the design shifts, the chart every month. Decks that blend them tend to be rebuilt from nothing whenever either changes. ## Making the image You need two things: native resolution, so the screen stays crisp through PDF export and projection, and cheap variants, because the figures will change several times before the deck is final. Redrawing a wallet screen by hand for each revision is why so many decks end up with a blurry crop of a six-month-old screenshot. [Flexdger Wallet](https://flexdger.com/) handles the second part: it draws the screen from values you type, in the browser on your phone, and a screenshot there comes out at the phone's native resolution (`1179 × 2556` on an iPhone 14 Pro). Changing a figure means changing a figure and not losing an afternoon. [A live wallet screen for decks and demos](https://flexdger.com/for/demos-and-decks) covers both needs. ## Final check before sending 1. Each mockup is marked as illustrative. 2. Nothing on the slide ends up smaller than roughly 18 px. 3. Token values add up to the total on display. 4. No performance figure appears inside a mockup. 5. Real metrics sit on a separate slide, with their period and source. ## Questions ### Should the numbers on a deck mockup add up? Yes. The token rows should sum to the total in the header, because a numerate reader checks that first. Keep the 24h changes modest and of mixed sign, since an all-green screen reads as a promise of returns. ### Does a portfolio mockup count as evidence of assets? No. A mockup demonstrates the product and never stands in as evidence of assets or revenue. Presenting it as such is misrepresentation whatever tool produced it. ### Where do real traction numbers belong? On their own slide, as charts with a stated period and a stated source, apart from the mockup, so nobody has to guess which figures are real. ### Can a larp wallet or wallet simulator appear in a deck? Yes, as an illustration of the product, labelled as illustrative UI. A larp wallet, or crypto wallet app simulator, draws a wallet screen that reads as real from figures you type yourself. Nothing is held in it and no chain is ever read, so it can never represent your holdings.