Who is the user?
Name the actor: trader, wallet user, merchant, miner, exchange, issuer, developer, fund, or app operator.
Reality check
Kaspa has a protocol story. Product claims need a different test: who uses it, what they do, where liquidity comes from, what wallet flow exists, and what evidence proves the claim.
Use this for app and product claims. Use Claims Checker for protocol status. Use Builder Evidence when a demo or txid is being used to prove a builder claim.
Keyword pre-check
This checks whether the pitch mentions the basic product questions that a real review would need to answer.
Copy the review prompt, then compare the pitch against Status, Claims, and Sources before posting.
Prompt updates as you type.
Product reality
Name the actor: trader, wallet user, merchant, miner, exchange, issuer, developer, fund, or app operator.
Send, swap, borrow, hedge, launch, redeem, escrow, stake, report, integrate, or verify. Vague "platform" language is weak.
Source the first market: issuer, LP, market maker, stablecoin, treasury, buyers, or earned revenue. "Community" is not enough.
Show the wallet flow, transaction shape, custody model, recovery path, and what the user sees when something fails.
Separate live mainnet, app tooling, testnet proof, targeted upgrade, roadmap, and research.
Use source links, accepted transactions, code, docs, audits, release notes, working app paths, or reproducible commands.
Model abuse, oracle failure, liquidity exits, wallet mistakes, insider allocation, bot traffic, downtime, and legal or custody risk.
Real products need repeated behavior after launch: retention, support, integrations, revenue, routes, or measurable usage.
Real versus fake
| Claim type | Real signal | Weak signal | Kaspa question |
|---|---|---|---|
| Launchpad | Issuance, wallet flow, liquidity path, visible holders, abuse controls. | A token button and a roadmap. | What can launch today, and where does liquidity come from? |
| DeFi | Risk parameters, oracle model, liquidation path, audit trail, liquidity, working transactions. | Using "DeFi" for any token page. | Is this live mainnet, TN10/TN12 testnet evidence, future Toccata work, or only an app idea? |
| AI agent | Agent signs, pays, receives, proves work, or triggers a bounded workflow. | Chatbot copy wrapped around a token. | What action happens on Kaspa, and who can verify it? |
| Wallet | Clear signing, recovery, balances, history, error states, and source verification. | Nice screens without transaction handling. | Does a normal user know what they are signing? |
| Institutional use | Custody, compliance, reporting, settlement, liquidity, support, and integration requirements. | One vague partnership post. | Which institution, which requirement, and what evidence? |
Translate back to Kaspa
| Observed behavior | Consequence | Kaspa gap | Possible experiment |
|---|---|---|---|
| Low-friction asset launches | Creation, liquidity, and attention collapse into one flow. | No Kaspa-native launch and liquidity rail yet. | A restrained post-Toccata asset tool with wallet safety, source labels, and abuse warnings. |
| Swap aggregation | Users want one route across liquidity sources. | No native DEX layer or routing surface yet. | Track early swap attempts by quote quality, liquidity source, and signing UX. |
| Hackathon intake | Deadlines, judges, examples, and funding create repeatable builder submissions. | Builder activity is less structured publicly. | Public Kaspa build sprint with source-backed judging criteria and shipped demos. |
| Wallet-first apps | Users judge the chain through signing, balances, errors, history, and support. | Consumer wallet UX is still fragmented across needs. | Map wallet tasks from new user action to accepted transaction evidence. |
| Exploit response | Real DeFi needs monitoring, audits, incident process, and recovery language. | Kaspa app risk culture is early. | Require every app pitch to publish failure modes before claiming production readiness. |