How to Explain a Crypto Product Simply: A Three-Pass Rewrite

To explain a crypto product simply, rewrite your description three times. First pass: delete every term a smart outsider would have to look up. Second pass: name one specific person who uses the product and the moment they reach for it. Third pass: describe what their life looks like before your product and after it, in plain verbs. What survives all three passes is the sentence you put on your homepage, in your pitch and in every press release.

I use this method with founders whose product is genuinely good and whose description is genuinely unreadable. It takes about an hour. It works better on paper than in a meeting, because in a meeting everyone defends their favourite word.

Why do crypto teams struggle to explain their own product?

Because they've explained it to the wrong audience thousands of times. Founders spend their first year talking to engineers, auditors, investors who specialise in crypto, and a Discord full of power users. Every one of those conversations rewards precision and technical vocabulary. By the time the team needs to talk to a journalist or a first-time user, the precise version is the only version they have.

Then the market changes who you're talking to. Every team says it wants mainstream users, and far fewer do the slow work of explaining the product to them:

everyone wants to onboard the next billion users in web3 but who is actually doing the hardwork to do so? Shilika Jain on X, 30 Jan 2025

A big part of that hard work is unglamorous: writing a version of your description that works on the least technical person in the room, and then saying it the same way every time. That version doesn't appear by accident. You have to write it.

What is the three-pass rewrite?

Each pass has one job. Don't try to do all three at once, because you'll stall on the hardest one.

Start with whatever description you have today. Your homepage hero line, your deck's first slide, or the boilerplate at the bottom of your last press release all work. Paste it at the top of a blank page and run the passes underneath it so you can see the distance travelled.

Pass one: how do you strip jargon without losing accuracy?

Read your description and underline every word that a smart outsider, say a business reporter at a general newspaper, would have to look up. Then replace each one with what it does, not what it is.

The rule I give teams: describe the effect, not the mechanism. "Zero-knowledge proof" is a mechanism. "Proves something is true without showing the private details" is an effect. "Account abstraction" is a mechanism. "No seed phrase to write down" is an effect.

The best version of this pass makes the technology invisible. I put it this way in 2024:

the true chain abstraction moment happens when a user uses your dapp without knowing which chain you're built on! Shilika Jain on X, 25 Sep 2024

That's the standard for your copy too. A user shouldn't need to know which chain you're on to understand why they'd use you. Chain, consensus model and token standard belong in your docs and in your conversations with crypto-native press. They rarely belong in the first sentence.

Accuracy worries come up every time. Engineers fear the plain version will be wrong. It won't be wrong if you describe the effect truthfully. It'll just be incomplete, and incomplete is fine for a first sentence. The second paragraph can add precision for the readers who want it. I keep a longer list of terms to cut, with plain replacements, in my crypto jargon cut list.

Pass two: why name a specific user?

Because "users" is not a person, and a reader can't imagine a category. After pass one, most descriptions read like "A platform that lets people move money between networks faster." Cleaner, but still floating. Pass two pins it to someone.

Ask the team three questions and write the answers down:

1. Who used the product last week and came back the week after?
2. What were they trying to do in the minute before they opened it?
3. What would they have done if your product didn't exist?

The answers are usually narrower than the founders expect. A cross-chain tool turns out to be mainly used by small trading teams paying contractors. A wallet turns out to be mainly used by people who already lost funds on an exchange once. That narrowness feels like a risk. It's the opposite. A specific user makes the explanation stick, and broader audiences still recognise themselves in a specific story.

I've always cared most about products ordinary people can actually use:

Since the time I started working in the crypto/web3 space, I've always been a huge proponent of projects that are building stuff that normies can use! stuff that's tangible, in-real real world application! Shilika Jain on X, 31 Dec 2023

Pass two is where "tangible" comes from. If you can't name the person and the moment, the product may not be tangible yet, and no amount of rewriting will fix that.

Pass three: how do you show the before and after?

Write two short sentences. One describes the user's situation without your product. One describes it with your product. Use verbs a person does: send, wait, check, lose, sign, pay, ask. Avoid verbs a system does: enables, facilitates, empowers, powers.

The gap between the two sentences is your value. If the gap is small, the explanation will feel small, and that's useful information too.

A clean before and after also hands journalists a story shape. A reporter needs a change to write about. "Company launches product" is not a change. "Creators used to lose royalties on resales, now the chain enforces them" is. That's close to the angle we used for the Rari Chain mainnet launch on Arbitrum in January 2024: royalties protected at chain level, rather than another network going live. You can read how that campaign ran in the RARI Chain case study.

What does a three-pass rewrite look like in practice?

Here are two worked rewrites. The products are fictional composites so I can show every step without exposing a client's draft copy, but the patterns are the ones I see most often.

Example A: a cross-chain payments tool

• Starting copy: "An intent-based, modular interoperability layer enabling trust-minimised cross-chain stablecoin settlement."
• After pass one (strip): "A tool that moves digital dollars from one blockchain to another without a middleman holding them."
• After pass two (name): "For small companies that pay overseas contractors in digital dollars, when the contractor uses a different network than they do."
• After pass three (show): "Today, paying a contractor on another network means bridging, swapping and waiting while the money sits in someone else's contract. With this tool, you send dollars from your network and they arrive as dollars on theirs."

Example B: a self-custody savings app

• Starting copy: "A non-custodial, MPC-secured yield vault with automated rebalancing across blue-chip DeFi protocols."
• After pass one (strip): "An app that earns interest on your crypto while you keep control of it."
• After pass two (name): "For people who left an exchange after it froze withdrawals and don't want to trust another company with their savings."
• After pass three (show): "Before, earning interest meant handing your coins to a company and hoping. Now your savings earn while staying in an account only you can open, and you don't have to write down a 24-word recovery phrase."

Notice what happened to length. The final versions are longer than the starting copy. That's expected. Simple doesn't mean short on the first draft. Once the meaning is clear, you compress: Example B's hero line might end up as "Earn on your crypto without handing it to anyone." You can only compress safely after the passes, because before them you don't know which words carry the meaning.

How do you know the simple version works?

Test it on people who owe you nothing. I use a three-step check before any explanation goes into a press release or onto a homepage:

• The repeat test. Read it once to someone outside crypto. Ask them to tell it back. If they paraphrase it correctly, keep it. If they say "so it's a blockchain thing," go back to pass two.
• The team test. Ask five people on your team to write the one-sentence description from memory. If you get five versions, the explanation isn't settled yet, regardless of how good it reads.
• The reporter test. Ask whether a journalist could write a headline from the after sentence alone. If the headline would need your product name to make sense, the change isn't clear enough.

Once it passes, the sentence goes everywhere at once: website, deck, bios, boilerplate, the founder's first answer in every interview. That consistency is a large part of what I build into Web3 PR campaigns, because coverage only amplifies a story that's already clear.

When should you not simplify?

There are real trade-offs, and I'd rather you know them up front.

• Developer and infrastructure audiences. If your buyer is a protocol engineer choosing a data layer, the technical terms are how they assess you. Stripping them can read as hiding something. Keep a simple sentence for press and a precise one for docs and developer channels.
• Crypto-native trade press on a technical beat. A reporter covering rollups for a crypto outlet already knows the vocabulary. Over-explaining wastes their time. The three passes still help you find the angle, but the pitch can use their language.
• Regulated claims. Plain words like "safe," "guaranteed" or "earn" can turn into promises with legal weight. Simplify the description, not the risk disclosure. Run consumer-facing copy past counsel.
• When the product isn't clear yet. If pass two produces five different users depending on who you ask, the problem may be the product, not the words. Rewriting copy won't settle a strategy question.

The deeper version of this argument, why most crypto companies have an explanation problem rather than a product problem, is in my field note on the crypto explanation problem. This post is the practical half of it.

FAQ

How long should a simple crypto product explanation be?

Aim for one sentence of 10 to 20 words for the hero version, plus a two-sentence before and after for press and pitch use. If you need more than one sentence to say what the product does, you probably haven't finished pass two. Longer explanations belong in the second paragraph, not the first.

Should I mention the blockchain or token at all?

Mention it when it changes something the user cares about, such as cost, speed or who controls the funds. Leave it out of the first sentence when it's only an implementation detail. You can always add it in the next line for readers who want it.

Who should do the rewrite, the founder or marketing?

The founder should be in the room for pass two, because they know who the real users are. Someone outside the product team should hold the pen for pass one, since insiders don't notice their own jargon. I usually run all three passes with the founder and one product lead in a single working session.

Can an analogy replace the three passes?

Not reliably. An analogy can make the after sentence vivid, but it can also bring in assumptions that aren't true about your product. Get the plain version right first, then decide whether an analogy adds anything. I cover how to test one in my post on crypto product analogies.

If your product is strong and your sentence isn't, book a 30-minute session and we'll run the three passes on your copy together.