The application, question by question

Every coaching question in the application, unpacked: what it's really asking, what reviewers look for, the common mistakes, and a worked example. Use the index to jump to the question you're on.

What problem are you solving?

Everything else in your application hangs off this answer — your solution, market, and traction only make sense relative to the problem you claim. It is also where most applications fall over, because most founders describe a theme instead of a problem.

What this question is really asking

Not “what space are you in” but whose day is broken, and how badly. A real problem has a specific owner: a person or team you can name, a pain you can measure, and a workaround they’re forced into today because no good option exists. If nobody is currently paying — in money, time, or leaked value — to avoid this pain, it is not yet a problem; it’s an observation.

What reviewers look for

A named sufferer. “Solana traders moving $5k+ per swap” is a problem owner. “DeFi users” is a demographic.
Sharpness. How often does this bite, and what does each bite cost? Numbers beat adjectives every time.
The workaround. What do these people do today? The workaround is the strongest evidence the pain is real — nobody builds a manual process around a problem that doesn’t hurt.
Solana-native fit. We want problems a Solana-native product is uniquely placed to fix, not a general crypto gripe with a Solana label on it.

Common mistakes

Stating an industry truism (“DeFi is hard to use”, “onboarding is broken”) with no owner and no cost. Describing your solution’s absence as the problem (“there is no platform that does X”). Citing a problem so broad that ten unrelated products could claim it — if your problem statement would fit a competitor’s deck unchanged, it isn’t yours yet.

A worked example

Solana traders moving $5k+ get sandwiched by MEV bots on 30–40% of swaps. Today they either eat the slippage or manually split orders across DEXs — slow, error-prone, and it still leaks value.

Notice what this does: a countable owner (traders above a size threshold), a measured frequency (30–40% of swaps), a real cost (slippage, leaked value), and the workaround that proves the pain (manual order-splitting). One sentence of who, one of what they do about it. That’s the bar.

What's your solution?

The problem question earns you the right to be believed; this one earns you the right to be funded. Reviewers already accept the pain is real — now they need to see the specific machine that removes it, not a mood board of what the product will eventually feel like.

What this question is really asking

Not “what’s the vision” but what did you build, and what happens, step by step, when someone uses it. Say exactly what runs on-chain (programs, transactions, accounts touched) versus what your servers do off-chain (routing, signing coordination, private submission) — and connect each piece back to the specific problem you named, not to DeFi in general.

What reviewers look for

Mechanism, not mission. A reviewer should be able to redraw your system diagram from your answer alone.
On-chain / off-chain clarity. Which parts are trustless and verifiable on Solana, and which parts are your infrastructure doing coordination work?
A tight link to the problem. The solution should read like the direct inverse of the pain you described — if you swapped in a different problem statement, would this answer still make sense? If yes, it’s too generic.
User experience that’s actually specified. What does the person using this do, concretely, in what order?

Common mistakes

Describing an aspiration instead of a product: “a platform that makes DeFi easy for everyone” tells a reviewer nothing about what happens when a transaction is submitted. Naming every feature you could eventually build instead of the one mechanism that exists today. Skipping the on-chain/ off-chain split entirely, which is often where the real technical bet — and the real risk — actually lives.

A worked example

A swap router that splits large orders across Jupiter routes and submits them in Jito bundles through a private mempool, so trades over $5k settle at the quoted price with no sandwich exposure. Users connect a wallet and swap exactly as they do today.

This works because it names the mechanism (order-splitting plus private bundle submission), draws the on-chain/off-chain line (Jupiter routes and settlement on-chain; bundling and private submission off-chain), and states the exact outcome — no sandwiching on trades over $5k — that answers the problem stated earlier, without adding a single feature that isn’t already built.

Who's on the team?

Ideas are cheap; execution against this specific problem is not. Reviewers use this answer to judge whether you’re the team that’s hard to bet against for this problem, not whether you’re generically capable people.

What this question is really asking

Not “are you smart and motivated” but why you two (or three, or four), specifically, for this problem. Name each founder, their role, and the track record that maps directly onto the hard part of what you’re building — plus whether they’re full-time and whether they’ve actually shipped something together before, versus just met at a hackathon last month.

What reviewers look for

Named people, named roles. Not “our team” — who does what, and why that split makes sense.
Track record tied to this problem. Prior experience should connect to the specific mechanism or market, not just “worked in crypto.”
Commitment. Full-time versus part-time changes the risk calculus enormously; say which, plainly.
History together. Founders who’ve already built something as a pair are a materially different bet than two strangers who agreed to co-found last week.

Common mistakes

“Experienced and passionate team” with no names, no roles, and nothing verifiable — a reviewer can’t check passion. Listing credentials that don’t connect to the problem (a finance background with no mention of why it matters here). Omitting full-time status, which reads as evasive, or omitting how long the team has actually worked together.

A worked example

Two co-founders: Ana led the routing engine at a top-5 Solana DEX; Boris ran two MEV bots doing $2M/day and knows the attack surface from the other side. Both full-time, three years working together.

This works because both roles are named and both track records point directly at the hard part of the problem — Ana knows routing from the defender’s side, Boris knows MEV from the attacker’s side, so together they cover the whole attack surface. “Full-time” and “three years working together” remove the two biggest unstated risks in any early team.

What's your unique insight?

Anyone can build a competent product; the insight is what tells a reviewer you’re building the right one. This is the belief about how the market actually works that most smart, well-funded competitors either don’t hold or actively disagree with.

What this question is really asking

Not “what feature do you have” but what do you believe about this market that a competent competitor would argue with. A real insight is a claim about cause and effect — where the value actually leaks, what users actually optimize for, which constraint actually binds — that changes what you build if you’re right, and that you could be wrong about.

What reviewers look for

A belief, not a feature. The insight should be stateable as “most people think X, but actually Y” — if it can’t be phrased that way, it’s probably a feature description in disguise.
Falsifiability. Could this insight turn out to be wrong? If it’s unfalsifiable, it’s not sharp enough to be useful.
Contrast with competent competitors. Not “nobody has thought of this” but “capable teams have looked at this and reached a different, worse conclusion” — say why.
A visible line to the product. The insight should explain a real design decision you made, not sit disconnected from the solution.

Common mistakes

Restating a trend everyone already agrees with (“we believe on-chain trading is the future”) — that’s consensus, not insight, and it implies no risk and no edge. Presenting a feature (“we have better routing”) as if it were a belief about the market. Stating something so vague it can’t be argued with, which is the tell that it isn’t falsifiable.

A worked example

Everyone optimizes for best quoted price, but on Solana the real leak is landing the transaction — validators reorder for MEV. Winning is a mempool and bundling problem, not a pricing problem, and almost no retail-facing product treats it that way.

This works because it names the consensus view (optimize for quoted price), states a specific, checkable disagreement with it (the leak is in landing, not pricing), and is falsifiable — if execution quality turned out not to matter, the whole product thesis would be wrong. It also explains, directly, why the solution is built around bundling rather than routing alone.

What makes you defensible?

A good problem attracts good competitors. This question asks what happens the day after you prove the market exists — specifically, what stops an incumbent or a fast follower from shipping your feature next quarter and using their existing distribution to bury you.

What this question is really asking

Not “are you better” but why won’t the obvious copier copy this. Name the real competitors by name, then explain the specific reason — incentive or capability — that keeps them from matching you. An incentive reason means copying you would hurt something they already have (a partner relationship, a revenue line); a capability reason means they structurally can’t build it quickly (data, relationships, or technical depth they don’t have).

What reviewers look for

Named competitors. Vague gestures at “the competition” signal you haven’t actually mapped the field.
Why not “can’t” but “won’t” or “structurally can’t.” Most competitors could build a similar feature eventually; the moat is the reason they won’t, or can’t do it well, not that the code is hard to write.
A real moat category. Distribution, proprietary tech, data, or relationships — say which, concretely, not as a buzzword.
Durability. Does the moat get stronger over time (compounding data, deepening relationships) or is it a temporary lead that erodes?

Common mistakes

“We’re faster and more user-friendly than competitors” — every early-stage team believes this about itself, and UX leads erode within a quarter once a competitor notices. Listing competitors without explaining why they won’t respond. Claiming a moat that’s actually just a current feature gap, which closes as soon as a well-funded team decides to prioritize it.

A worked example

Jupiter owns routing but won’t run private orderflow that competes with its LP relationships; standalone MEV-protection tools are B2B with no retail UX. Our moat is Jito validator relationships for guaranteed bundle inclusion plus a consumer-wallet integration nobody else has wired.

This works because it names the two real competitor categories, gives an incentive reason the first won’t copy (it would conflict with existing LP relationships) and a capability reason the second can’t match (no retail UX), and grounds the moat in two concrete, ongoing assets — validator relationships and a shipped integration — rather than a temporary feature lead.

How big is the market?

Size alone doesn’t tell a reviewer anything about whether you can capture it. This question is really about whether your numbers are built from something real and countable, and whether you’ve identified the specific slice you enter through before you own the whole thing.

What this question is really asking

Not “how big is the total category” but how big is the flow you can actually count today, and what’s the wedge inside it that’s yours first. Start from a number you can defend — daily volume, transaction count, a segment size — and work up to a revenue estimate, rather than starting from a market-research total and working down.

What reviewers look for

Bottom-up math. A number built from something countable (daily volume, active wallets, transaction frequency) that a reviewer could roughly re-derive themselves.
A specific entry wedge. Which slice of the market do you win first, and why is it winnable before the rest?
Growth direction. Is the wedge itself growing, shrinking, or flat — and is that trend independent of your own effort?
Believable capture math. What share of the wedge, at what price, gets you to a real revenue number — shown, not asserted.

Common mistakes

Top-down sizing: “the DeFi market is worth billions and growing fast,” then implicitly assuming “if we get 1% of that” without ever justifying the 1%. Citing a total addressable market with no connection to the wedge you actually enter through. Growth claims with no source or mechanism behind them — “fast” is not a number.

A worked example

Solana DEX volume is ~$2B/day; swaps over $5k (our wedge) are ~15% of that and exactly the trades bots target. Earning 5 bps on even 2% of that flow is ~$2M/year, and the high-value-trader cohort is the fastest-growing segment.

This works because every step is countable and checkable: total daily DEX volume, the wedge’s share of it, a modest capture assumption, and a fee rate, chained into a revenue figure a reviewer can sanity-check line by line. It also names the wedge explicitly (large swaps) and ties growth to a segment, not a vague market-wide trend.

How will you reach customers?

A distribution plan is not a list of marketing tactics — it’s an answer to one question: where do your first thousand users actually come from, and why does that channel cost you almost nothing to run. This is where reviewers separate founders who have found a specific unlock from founders who are still hoping.

What this question is really asking

Not “what marketing will you do” but which single channel gets you your first real users, and why does it work cheaply. Good GTM usually looks like an unfair shortcut — an existing audience you can plug into, not a campaign you have to build from scratch.

What reviewers look for

One channel, deeply understood. A founder who can describe exactly how the first 1,000 users arrive — which platform, which audience segment, why they’d convert — beats a founder listing five channels shallowly.
A reason it’s cheap. Whether it’s an existing community, a partner’s user base, or a wedge inside a larger platform, the channel should cost attention and hustle, not a paid-acquisition budget you don’t have.
Specificity of the first cohort. Not “crypto Twitter” but a named community, bot, or partner with a headcount you can point to.
Why this channel first. Why it’s the cheapest, fastest-converting option available today, ahead of everything else you could try.

Common mistakes

Listing generic channels — “Twitter marketing and community” — that any startup could claim and that require an audience you don’t yet have. Naming a strategy instead of a mechanism: no target audience, no reason those people would respond, no path from post to paying user.

A worked example

Integrate as a swap option inside two Solana trading Telegram bots (~40k active traders combined) on a fee-share; they already have our exact high-value users and no protection to offer. First 1,000 users come from one bot’s power-user tier in week one.

This works because it names the exact channel (two specific bots), the audience size (~40k), why it’s cheap (fee-share, not paid spend), and the precise path for the first cohort (one bot’s power-user tier, week one) — a reviewer can picture the whole funnel.

How do you make money?

A business model is the arithmetic that turns usage into revenue — price, take rate, and what one customer is actually worth. This question tests whether you’ve done that arithmetic yet, or whether “we take a fee” is still standing in for a plan.

What this question is really asking

Not “do you plan to charge money” but what exactly do you charge, on what base, and what does that produce per user or per transaction. The numbers don’t need to be final — they need to be real enough that a reviewer can multiply them out and get something plausible.

What reviewers look for

A stated price and take rate. A basis-point fee, a flat fee, a subscription tier — named, not implied.
Unit economics. What a typical transaction or a typical active user is worth to you, shown as a calculation, not a claim.
Marginal cost awareness. Whether revenue drops mostly to margin or gets eaten by per-transaction costs you can name.
Honesty about known vs. projected. Clear separation between numbers you’ve actually observed (from a beta, a pilot, a partner deal) and numbers you’re modeling forward.

Common mistakes

Stopping at “we take a small fee on transactions” with no rate, no base, and no resulting per-user number — this is a direction, not a business model. Projecting revenue from a take rate you haven’t validated with anyone, and presenting it with the same confidence as observed numbers.

A worked example

5 bps on protected swap volume, split 60/40 with integration partners. The average protected swap is ~$12k, so ~$3.60 net each; a monthly-active high-value trader does ~20 such swaps — ~$72/user/month at near-zero marginal cost.

Every number chains into the next: fee rate, revenue split, average trade size, net take per swap, trades per user per month, and a resulting per-user revenue figure — each step a reviewer can check independently.

What traction do you have?

Traction is proof that something outside your own effort is happening — real users, real money, or a real commitment from someone who isn’t you. This question rewards specificity: numbers attached to dates beat any adjective you could reach for.

What this question is really asking

Not “are people excited” but what has actually happened, when, and how fast is it moving. If you’re pre-launch, the question becomes: what’s the single sharpest piece of evidence you have that this works — a signed letter of intent, a live pilot, or a waitlist with a real conversion rate, not just a headcount.

What reviewers look for

Numbers with dates. “210 wallets” means nothing without a timeframe; “210 wallets in 6 weeks” is a rate a reviewer can extrapolate.
Growth over totals. A week-over-week or month-over-month growth rate tells reviewers more than a cumulative total, because it shows direction, not just size.
The strongest single proof point. If you’re pre-revenue, lead with the sharpest evidence you have — a signed LOI, a pilot with a named partner, a waitlist’s actual conversion rate — rather than burying it under vaguer metrics.
Verifiable specifics. Named partners, dollar amounts, and dates a reviewer could in principle check, not aggregate impressions.

Common mistakes

Substituting adjectives for numbers — “lots of interest,” “a growing waitlist,” “strong engagement” — none of which a reviewer can size or compare. Reporting only a cumulative total with no rate, which hides whether momentum is accelerating, flat, or already stalling.

A worked example

Private beta live 6 weeks: 210 wallets, $18M protected volume, $9k in fees, 40% week-over-week volume growth. A Telegram-bot partner (12k users) has a signed integration LOI going live next month.

This works because every figure carries a timeframe (6 weeks, week-over-week, next month), mixes usage and revenue with a forward-looking commitment (the signed LOI), and gives a growth rate alongside the totals rather than instead of them.

Why now, and why Solana?

Every good startup answer to “why now” points at something that changed recently and specifically — not a rising tide that’s been rising for years. Pair that with why Solana, specifically, is the chain this has to be built on, and you’ve answered the two questions that decide whether timing is working for you or against you.

What this question is really asking

Not “is Solana growing” but what concretely changed that makes this buildable and winnable today, and not two years ago — and what about Solana’s own infrastructure, not just its speed and fees, does your product actually depend on. A real “why now” names an event or a shift; a real “why Solana” names a primitive your product couldn’t work without.

What reviewers look for

A dated shift. A protocol upgrade, a new primitive going live, a cost or latency threshold crossed recently — something with a “before this couldn’t work, after it can” shape.
Dependence on Solana-specific infrastructure. Naming the actual primitive — validator behavior, a client, an auction mechanism — your product relies on, not generic chain attributes any L1 or L2 could claim.
Why not an incumbent chain. A reason this specifically doesn’t transplant cleanly to EVM chains or elsewhere.
Timing tied to opportunity, not just capability. The shift should explain why the market is winnable now, not merely why the tech now exists.

Common mistakes

Leaning on general momentum — “Solana is fast and cheap and adoption is growing” — which has been roughly true for years and explains nothing about why this specific product is timely. Citing ecosystem growth without connecting it to a mechanism your product actually uses.

A worked example

Jito’s bundle auctions and public ShredStream only stabilized in 2024, making guaranteed private inclusion possible for the first time — before that this product couldn’t reliably land. It’s Solana-specific because the reorder/MEV dynamics and Jito infra don’t exist the same way on EVM chains.

This works because it names a specific infrastructure milestone with a rough date, states plainly what wasn’t possible before it, and ties the Solana-specificity to a named piece of infra (Jito) rather than to speed or fees.

What's your ask?

The ask is where a reviewer checks whether you actually know your own plan — a specific number tied to a specific milestone reads completely differently from a round figure and a general hope for help. This is often the shortest answer in the application and the easiest one to get precisely right.

What this question is really asking

Not “how much money do you want” but what capital, tied to which milestone, and what non-capital support would move you fastest. Precision here is a proxy for how well you understand your own roadmap — a founder who knows the number knows the plan behind it.

What reviewers look for

A capital amount tied to a milestone. Not a round number in isolation, but an amount paired with what it buys you and by when.
A believable use of funds. Enough specificity — hires, infrastructure costs, a runway length — that the number is clearly derived, not guessed.
Named non-capital support. The specific intros, hires, or partnerships that would unblock you fastest, not a generic wish for “support.”
Milestone-awareness. The ask should read as evidence you know exactly what has to happen next, and what stands between you and it.

Common mistakes

Asking for “funding and support to grow” — a request so generic it could apply to any startup at any stage, revealing no actual plan. Naming a capital figure with no milestone attached, so a reviewer can’t tell whether it’s ambitious, padded, or too small to matter.

A worked example

$400k to reach $100M protected volume/month over 9 months (two infra hires

Jito staking for priority inclusion). Beyond capital: warm intros to 3–4 major Solana trading-bot and wallet teams, and help hiring a validator-ops engineer.

This works because the capital amount is tied to a concrete volume milestone and a timeframe, the use of funds is itemized (two hires, staking costs), and the non-capital ask names exactly who they need to meet and what role they need to fill.

Ready to put this into practice?

Start application