Pitch video for a Web3 protocol: explaining it without a whiteboard

Most protocol pitch videos are a diagram with a voice over it. Here is how to explain a mechanism on screen so a stranger follows it in ninety seconds.

September 5, 2026 · 9 min read

Ask a protocol team for a pitch video and you usually get the same artifact back. A camera moves across a system diagram. Boxes light up in sequence. A voice explains that liquidity is routed through a vault, then rehypothecated, then settled, and by the second box nobody outside the team is still following.

That video is not wrong, exactly. Everything in it is true. It fails because it was made from the inside: it shows the architecture the engineers built rather than the change a user experiences. Architecture is what you are proud of. Mechanism is what someone can repeat to a colleague an hour later, and repetition is the only distribution a protocol pitch really has.

The good news is that this is a structural problem, not a budget problem. Protocols with no interface, no users yet and no visual identity have made pitch videos that land, because they decided what the film had to teach before anyone opened a design tool.

Decide who the pitch is for before deciding what it shows

The phrase "pitch video" covers at least four different films in crypto, and teams routinely try to make one film do all four jobs. It cannot, because each audience needs a different level of the same explanation.

Pick one audience per cut. The mistake is not making several films, it is making one film that hedges between four viewers and convinces none of them. Most teams need the user cut first, because everything else in the launch borrows from it, and the investor cut is closer to the film we describe in our piece on a video for a seed fundraising deck.

Explain the mechanism, not the architecture

A protocol is a set of rules that changes what is possible for someone. That sentence, filled in with your specifics, is the film. The contracts, the modules, the routing layer and the oracle setup are how you keep the promise, and almost none of it belongs on screen in the first ninety seconds.

The test we use is the restatement test. Show the cut to someone who works in crypto but not on your protocol, wait an hour, then ask them to explain what it does. If what comes back is your mechanism in their words, the film works. If what comes back is an adjective, usually "faster" or "more efficient", the film taught them nothing and the diagram was doing the talking.

Getting there usually means going down one rung on the abstraction ladder, not up. Teams reach for the abstract framing because it sounds bigger, and abstraction is exactly what makes a protocol forgettable.

What goes on screen when there is no product to film

This is the real constraint. A SaaS company films its interface. A protocol at pitch stage often has a testnet, a doc site and a Figma file, which is why the diagram keeps winning by default. There are better options, and they cost about the same.

• Follow one unit through the system. One deposit, one loan, one trade, one proof. A single object moving through steps is legible in a way a whole system view never is.
• Show the before and the after side by side. Five steps and two counterparties on the left, one action on the right. The saving is the pitch.
• Build the interface you are going to ship, at design fidelity, and animate that. It doubles as your launch page art direction rather than being thrown away.
• Use numbers on screen only where they are real and checkable: an audit, a testnet figure, a live TVL. A fabricated chart is the fastest way to lose a technical viewer.
• Let motion carry the causality. What follows what, what unlocks what: sequence explains a mechanism better than any label does.
• Keep one visual system across the film so the protocol looks like one thing, which is the whole argument of our Web3 branding piece.

What to avoid is easier to list: rotating globes, glowing blockchains, hooded figures, stock crowds, and the token logo spinning in space. They read as filler because they carry no information, and a technical audience registers filler as an absence of substance.

The order that holds

Almost every protocol pitch that works runs the same four beats, in the same order. The order matters more than the production value.

1. 01The friction, stated as a situation someone recognizes rather than as a market claim. Ten to fifteen seconds.
2. 02The mechanism, in one sentence and one visual sequence. This is the center of the film and deserves half its running time.
3. 03The proof: audits, live deployments, integrations, the testnet number, the names already building on it. Short, factual, no adjectives.
4. 04The one thing to do next. Read the docs, join the testnet, book a call. One action, not four.

Two failure patterns come from breaking this order. Opening on the team or the funding round spends your best seconds on something the viewer does not care about yet. Ending on three competing calls to action means the viewer picks none of them. The launch sequencing around all of this is set out in our Web3 launch video piece.

Length, placement, and how many cuts you actually need

Length is decided by where the film gets watched, not by how much you have to say. A protocol explanation can fill twenty minutes. Nobody is giving you twenty minutes.

The efficient way to cover that spread is one build and several cuts, not four productions. Structure the ninety second version properly, then derive the short social cut and the long room version from the same system and the same assets.

For the fastest slot on that list, the launch day post, there is a middle path worth naming, and we should disclose that it is ours. ShipTeaser is an automated product from the same founder as this studio: you give it a URL and it returns a 15 second 1080p motion graphics teaser built for muted feeds, with an optional music bed, and the first one is free without a card. It works from your own page, so what it shows is genuinely yours, but it has no narrative spine and no visual system behind it. It fills a feed slot on a busy week. It is not the film that has to make your mechanism legible.

What makes a protocol pitch read as vapour

Crypto viewers are trained skeptics, and they discount hard. The tells that trigger it are consistent across the pitches we get sent for a second opinion.

• Superlatives with no mechanism behind them. Fastest, safest and most capital efficient all read as unverified until the film shows why.
• Numbers with no source on screen. If a figure cannot be traced to an audit, a dashboard or a block explorer, leave it out.
• Partner logos used as decoration when the relationship is a conversation, not an integration.
• A roadmap doing the work the product should be doing. Future tense stacked five deep is the clearest signal that nothing ships yet.
• Borrowed visual language. If the film looks like the last three protocols in the same category, the viewer files you with them.
• A tone that treats the audience as an army rather than as users making a decision.

The cure for all six is the same: replace the claim with the mechanism that produces it. A pitch that explains how something works is much harder to dismiss than one that insists it is good, and that is also why the technical explanation discipline in our SaaS explainer video piece transfers cleanly to protocols.

How we build one at BuildLore

We start with a working session that produces two artifacts: the one sentence mechanism and the single unit we are going to follow through the system. Nothing gets designed until both are agreed, because every visual decision after that point is downstream of them, and reversing them later is what turns a two week build into a five week one.

From there it is a narrative spine, a visual micro system, then the ninety second build, then the cuts. That is the shape of our Launch Sprint, and the same system carries into the announcement assets and the launch page art direction rather than being rebuilt for each surface. You can see how these systems hold across protocols and apps in our selected work.

One habit is worth stealing whether or not you work with a studio: before approving anything, run the restatement test on someone outside the team. It is a cheap check, it happens before the expensive part, and it catches the exact failure that most protocol pitch videos ship with.