--- name: benchmarking description: Establish what a crypto project actually IS, then benchmark it against every comparable, before any valuation. Load on every project analysis, token screen and contract-address paste, after research-sources and BEFORE three-frame-valuation. Classifies the category from the product, builds a three-ring peer set and comparison table, then goes deep on technology, founders, on-chain numbers and X versus those peers. Carries the mandatory rented-versus-owned stack split, the five product questions (what they do, potential, competitors, ease of copy, moat), the DEMAND TEST that judges product-market fit at day zero from latent demand rather than adoption numbers that cannot exist yet, and the graded operator read covering dev reactivity, whether his claims survive the chain, buyback cadence and pump economics. Also load whenever a comp, competitor, sector, moat, founder, product-market fit, "is the dev legit", "what is this like" or "how does it compare" comes up. --- # Benchmarking Runs between the data layer and the valuation layer: ``` research-sources -> BENCHMARKING -> three-frame-valuation -> gem-hunter -> verdict ``` **Nothing is valued before it is benchmarked.** The three frames each need a peer set. Inventing one produces category error, and category error moves the answer by an order of magnitude. Two receipts, both from the same week: - PFWA was comped to PONS and PAIR, both launchpads, giving a ceiling of $9M to $30M. It is a prediction market. The real sector's biggest token was **PRDT at $25.3M**, and the actual winners had no token at all. The ceiling was $3M to $10M. - SCL was comped to DELTA at $29.4M because a 59k-follower promoter called it "a $DELTA competitor". True on product, false as a comp: DELTA had $1.51M of managed TVL, SCL had zero. Correct tier was $1.5M to $4M. **A promoter's comp is a claim to test, never a category.** --- ## Step 1: Classify. What is this, actually? **Classify from the product, never from the ticker, never from what promoters call it.** Read the landing copy and the contract, then answer two questions in one line each: 1. **What does a user actually DO here?** 2. **Who pays whom, and does any of it reach a token holder?** Assign a primary category, and a secondary if it straddles. Working list, extend it when something genuinely new appears: `prediction market` · `launchpad` · `spot DEX` · `perp DEX` · `lending / CDP` · `liquidity manager` · `payout / dividend token` · `index / basket` · `RWA or tokenised-equity wrapper` · `tooling / infra` · `agent or AI` · `gaming / NFT` · `meme with a product` · `meme with a website` · `meme with nothing` Then place it in the return bucket with the six-question regime screen: does holding it pay automatically with no claim step · is it plumbed into the tokenised equities · does it wear the chain's identity · could it ship unchanged elsewhere · must the holder operate anything · is the payout visible on chain and what is its dollar magnitude. Measured 30-day medians, Robinhood Chain, Aug 2026: pays automatically **+1,925%** · wears the chain's identity **+378%** · meme with a website **+341%** · **infrastructure the holder must operate +29%** · tokenised equity itself **+13%**. **Write the category down explicitly before searching for comps.** If the category changes later, every comp has to be rebuilt. --- ## Step 2: Build the peer set. Aim for 8 to 15, in three rings. **Ring 1 — same category, same chain.** Who else does this here? These decide the competitive question. **Ring 2 — same category, other chains.** These decide the ceiling. Include the biggest name in the category globally even if it is on a chain nobody cares about. **Ring 3 — adjacent category, same chain.** These decide what this chain pays for a shipped, non-scam product regardless of sector, which is usually where the price already is. ### Where to find them | Source | Call | Gives | |---|---|---| | **DefiLlama protocols** | `api.llama.fi/protocols`, filter on `category` | The single best comp source. Categories are pre-assigned. Filter by `chain` for Ring 1 and Ring 3 | | **DefiLlama fees** | `api.llama.fi/overview/fees?excludeTotalDataChart=true`, filter on `category` | 30d and 24h fees and revenue per peer | | **CoinGecko categories** | `api.coingecko.com/api/v3/coins/markets?vs_currency=usd&category=&order=market_cap_desc` | The tokenised subset with caps and FDVs. Slugs like `prediction-markets`, `launchpad`, `real-world-assets` | | **DexScreener / GeckoTerminal** | `search?q=`, and `pools?sort=h24_volume_usd_desc` | Same-chain peers by traded volume. **Never rank by liquidity** | | **X** | `" competitor"`, `"alternative to "`, `"same as "` | Promoters name competitors for free, and name the ones you would not find | ### The two questions in this step that decide everything **1. Is this category tokenised at all?** Receipt: in prediction markets the actual businesses have no token. Polymarket $358,555,970 TVL and $32,839,316 of 30d fees. Predict Fun $10,707,058 TVL. PredictStreet $4,103,586. The largest token in the entire sector is **PRDT at $25,343,318**, then Overtime $12.2M, Limitless $10.9M, OPINION $9.8M. **If the winners in a category have no token, the token ceiling is set by the category's also-rans, not by the category's size.** Check this before quoting any sector TAM. **2. Who is the same-chain competitor without a token?** A ticker search will never surface it. Find it in DefiLlama's chain-filtered protocol list. Receipt: **Meridian Predict on Robinhood Chain, $261,946 TVL, no token, 723x the TVL of the tokenised candidate.** That single fact reframed the whole screen and no amount of X reading would have produced it. --- ## Step 3: The comparison table. Every cell gets a figure or an explicit "not tracked". Mandatory columns. Do not drop a column because it is inconvenient; an empty column is itself information. | Column | How to get it | Trap | |---|---|---| | Market cap and FDV | DexScreener `marketCap`, not GeckoTerminal `fdv_usd` | An FDV/mcap gap above 2x is unlock overhang. `mcap == fdv` means 100% circulating, rare and worth stating | | **TVL / deposits / open interest** | Measure on chain first, DefiLlama second | DefiLlama understates (stale adapters, unpriced chain tokens). The project overstates. Find its own `/tvl` or `/stats` endpoint in the JS bundle | | 30d fees and 30d revenue | DefiLlama fees endpoint | Fees and revenue are different columns. Do not merge them | | **cap / TVL** and **cap / annualised fees** | Compute, never quote a remembered median | These two ratios are the whole table | | Age | `pairCreatedAt`, or first Transfer | A 30-day-old project and a 2-year-old one are not peers on multiples | | Holders and slope | Full reconciled Transfer sweep | GoPlus `holder_count` goes stale within hours | | Real quote-side depth | `balanceOf(quoteToken, pool)`. For Uniswap v4, sum the quote side across every pool | Reported liquidity is not exit depth | | **Value accrual to the token** | Read the contract, then price it in dollars | "9.21% of supply burned" cost one operator 0.15 ETH. A percentage is not a yield | | Security posture | Audits, `eth_getCode` selector scan, proxy check, owner powers | GoPlus returns `{}` for new tokens. Scan the bytecode instead | | Float and lock structure | Locker balances, team wallets, vesting | A stated lock with no verifiable date is UNRESOLVED, not confirmed | | Chain | | Ring 2 peers on cheap chains still set the ceiling | Then state, in one line each: **where the candidate sits in each column relative to the peer band**, and **which single column it is most extreme on**. That column is the thesis or the disqualifier. --- ## Step 3b: THE PRODUCT VERDICT. Five questions, answered in five lines, every screen. BLOCKING. A comp table says what it is priced like. It does not say whether the thing is worth building, whether anyone else is building it, or whether the project can hold the ground it took. Answer all five explicitly. A missing answer blocks delivery. ### First, split the stack into RENTED and OWNED This is the method that produces all five answers at once, and it is mechanical. 1. Open the product's own health, status or config endpoint (`/health`, `/status`, `/api`, `/v1`) and read which upstreams it names. 2. Probe every named upstream directly. Is it public? Does it need a key? Does it cost anything? 3. Write one row per layer, marked **RENTED** or **OWNED**, with the receipt. **Whatever is left in the OWNED column is the entire company.** Everything else is a wrapper over somebody else's free endpoint, and a wrapper is worth what the wrapping is worth, not what the wrapped thing is worth. Receipt, RAILX 13 Sep 2026: its own `/api/v0/health` named `robinhoodAssets`, `robinhoodPrices`, `uniswapTradingApi` and `zeroExSwapApi`. Probing them found `api.robinhood.com/rhj/assets` returning **194 assets with checksummed contract addresses and corporate-action multipliers, HTTP 200, no key, no auth, 60 req/s, free**. The product's own headline pitch was "find the real contract among lookalikes" — already solved upstream, for free, by the issuer. What was genuinely OWNED was the glue: ordered approvals, full sequential simulation, explainable policy verdicts and an eight-tool MCP server. That is a real product and a much smaller one than the marketing implied. ### Then answer, in this order **1. What do they actually do?** One sentence, from the OWNED row only. If the OWNED row is empty, say so; that is the finding. **2. Does the thing they do have potential? Run THE DEMAND TEST. Adoption numbers are NOT the answer.** **Derive it before measuring it.** Adoption at time t is `latent demand x awareness(t) x trust(t) / friction`. At launch, awareness is near zero and trust is zero, because the first thing anyone thinks about a new project is "will this still be here next month, or is he going to exit". **So adoption at t=0 is near zero regardless of how badly the world wants the product, which means a download count, a user count or a TVL figure on day one measures nothing and must never be used as the potential answer.** Latent demand has to be estimated directly, and it can be, because all eight tests below are observable at t=0. **8a. Is the job already being done, by anyone, with something worse?** The strongest signal there is. Count it on chain: how many distinct contracts, routers, bots or front-ends already perform this job today. **If the answer is zero, there is no demand, only a theory, and the project is betting on creating a behaviour rather than serving one.** If the answer is large, the pain exists and the only question left is who captures it. **8b. Name the customer, then COUNT them. Never quote a TAM.** Produce an enumerable list of named entities that could plausibly write the cheque, from the chain's own fee leaderboard (`api.llama.fi/overview/fees/{chain}?dataType=dailyRevenue`), its protocol list, and the router set measured in 8a. A named list of nine is worth more than a $50bn market size. **8c. The substitution test.** What does that named customer do INSTEAD today, and how bad is it, priced in hours of engineering? **If the alternative is a couple of hundred lines against a free public API, this is a vitamin.** A painkiller replaces something that currently costs money, users, or downtime. **8d. THE BUILD-VERSUS-BUY TEST. This is the one that kills most developer-tool plays and it is almost always skipped.** Walk the enumerated list from 8b and ask of each: is this the kind of entity that builds its own? Three types always build: **multichain incumbents** (they already solved it on nine other chains), **anything whose core product IS the thing being sold** (an aggregator will not rent routing), and **anything at real scale** (the cost of a dependency exceeds the cost of the code). **If every named customer already owns what the project sells, the addressable set is empty even though the market looks enormous.** Say that in those words. **8e. Who is already ASKING, and separate builder signal from trader noise.** Builder signal: a technical question, "does it support X", a bug report, a feature request with a use case, someone sharing the docs in a developer context, a repo that imports the package. Trader noise: "burn ser", "chad dev", "wen", "LFG", price talk, collab DMs from marketing accounts. **Ten builder questions outrank ten thousand trader replies. Count them separately and report both numbers.** **8f. The counterfactual.** If this project disappeared tonight, **who complains, by name?** If the honest answer is nobody, there is no product-market fit yet, however good the code is. This is not a criticism, it is the stage. **8g. The wedge.** Is there ONE specific customer with ONE specific painful job where the incumbent does not already win? A platform for everyone is a platform for nobody. **Name the wedge, or say plainly that there isn't one.** A new customer category that nobody has built rails for yet (today: AI agents) is the highest-value wedge available, because it is the only place where "the incumbent already built it" is false. **8h. THE SURVIVAL GATE, which is what actually throttles early adoption.** A serious integrator does not evaluate features first, it evaluates whether the dependency will exist in six months. Measure exactly what they would: **is the client open source (so the code survives the founder) while the API is a single point of failure (so the service does not)?** Commit and release cadence. Is the founder doxxed or anon. Is there a second person, a company, or anyone who could keep it running. Is there a published incident or status history. **An anon founder with a closed hosted API is a dependency risk a professional team will refuse regardless of quality, and that alone caps adoption for months no matter how good the product is.** Say so when it applies, and note that this is the gate the founder can actually move. **8i. SEPARATE THE TWO TRUST QUESTIONS, because they have different answers and only one of them gates adoption.** - **"Will he rug the token?"** — fully solvable on chain, today, cheaply. A discretionary buyback run from an EOA is a promise; the same buyback routed into an **ownerless contract that anyone can trigger** is code. Same for a founder bag: a poll followed by a manual transfer is a promise, whereas sending it to a burn address, a timelocked vault with a public unlock, or a merkle distributor is settled the moment the transaction lands. **Check whether the chain already ships this as a product before saying it is hard** — on Robinhood Chain, PonsVault V2 (staking, stake-and-burn, RWA dividend templates, "anyone can press run") and Sinjoh's fee router and trustless merkle airdrop distributor both do exactly this and are live. - **"Will the service still exist in six months?"** — NOT solvable on chain, because an off-chain API is off-chain compute. Only three things move it: **open-sourcing the server so it can be self-hosted** (an open client with a closed server leaves the dependency intact), **attested execution in a TEE** so integrators verify the running code rather than trust it, and **putting the one piece of state that matters on chain as an immutable or timelocked registry** so integrators read the chain instead of the operator's server. **This is the question that actually gates real customers, and the one founders almost never answer.** **So when scoring the survival gate, name the specific deployment that would remove the founder from the trust equation, and say which of the two questions it answers.** A founder who has made the money trustless but not the service has fixed the half that matters least. Note also that a real name and a company still outrank all of it for an enterprise buyer, because their risk is contractual rather than technical. ### Then give the PMF verdict as ONE of these four labels, never a number - **NO DEMAND** — nobody is doing this job with anything, the project is creating a behaviour. - **DEMAND EXISTS, ALREADY CAPTURED** — the job is being done at scale, but every named customer builds it themselves. The commonest and most flattering trap: the market is real and the addressable slice is empty. - **DEMAND EXISTS, UNSERVED** — the job is being done badly by people who would switch. The only genuinely good answer at this stage. - **PMF PROVEN** — somebody has already switched, and can be named. **Then, and only then, run the chain-growth scenario** (chain volume 5x and 10x, share flat and rising, at the stated take rate) and state the number honestly: a large number multiplied by a share of zero is still zero, and saying so is the point. **Never let the scenario stand in for the demand test.** **3. Are they competing with anyone?** Three places, all three checked: - **Same chain**, from the chain-filtered DefiLlama protocol list, not from a ticker search. - **Off chain**, the multichain incumbents in the same job, with their market caps. - **Upstream**, and this is the one that gets missed: **could the provider they depend on simply ship this feature?** When the dependency is also the issuer, the regulator, the chain or the exchange, that is the realistic competitive event, not a rival launch. **4. Is it easy to copy?** Answer with a rebuild estimate in days or weeks, not an adjective. Ask: are any upstreams gated, paid, licensed, staked or capital-intensive? Is there proprietary data, a permitted contract, an exclusive integration? If every input is free and public, say **"a competent developer rebuilds this in N days"** and name N. Then name the one part that is genuinely hard, because there usually is one and it is usually the unglamorous part. **5. Do they have a moat, and is it priced?** Only these count, and each must be evidenced: - **Integration lock-in** — someone has already shipped on it and switching costs real work. Needs a named integrator. - **Liquidity or network effects** — depth, holders or counterparties that compound. - **Distribution or default position** — being the tool an agent, wallet or front-end reaches for first. - **Regulatory, licensed or permitted status** — the only truly hard one. - **Data nobody else has.** Being first is not a moat, being the only one on a small chain is not a moat, and good code is not a moat. **Then separate the product's moat from the TOKEN's moat**: if the fee link is a sentence on a website rather than a take rate readable on chain, the toll booth is a plan and the token has no moat at all, however good the product is. Say that in those words. **Close the block with one line: what is actually being bought here.** Usually it is one of: a protocol with contractual cash flows, a land grab on a slot, or an operator. Naming which one changes how the position is sized and what kills it. --- ## Step 4: Go deeper, dimension by dimension. This is where the analysis actually happens. ### 4a. Technology and features Verified from contracts and docs, never from marketing. Produce an explicit two-column list: **genuinely better** and **genuinely worse**, each item with a receipt. Ask, and answer for the candidate and for each Ring 1 and Ring 2 peer: - Core mechanism (AMM, CLOB, RFQ, bonding curve, vault, hook) - Collateral or numeraire asset, and why that choice - Who can create, and who can settle or resolve - Oracle: what it is, whether it is on chain, whether there is a bond or dispute window - Fee structure and split - Liquidity model and capital efficiency - What it does that no peer does - What every peer does that it cannot **The governing rule: a design choice is only "better" if it survives the constraint it was built under.** PFWA's bonding curve gives worse pricing than a CLOB and is still the correct choice, because Robinhood Chain has no prediction-market makers and an orderbook there would never fill. Say both halves. **The corresponding trap: a sophisticated mechanism nobody uses is worse than a crude one people use.** Twofold's dual-yield JIT liquidity is more advanced than Delta's position builder and had $13,000 of adoption against Delta's $1.51M. ### 4b. The founders - **Doxxed or anon, and verified how.** "Followed by an Ethereum Foundation member" is a follower-graph claim, not a doxx. - **Build history before this project.** Search the founder's handle back a year. A trail of shipped things is the strongest non-financial signal available. - **Ship cadence during the screen window.** Count deployed contracts and dated announcements, not tweets. - **Are they buying or selling their own token?** On chain, not from claims. A router-routed inbound to the dev wallet is a buy; a plain EOA transfer is not. Receipt: PFWA's founder bought 7,223,602 tokens through a router while the treasury only ever distributed. - **Team allocation: size, location, lock, and verifiable unlock date.** An unverifiable date is UNRESOLVED. - **Behaviour under stress.** How they answered the last bug, delay or accusation. - **Peer comparison:** is the Ring 1 and Ring 2 field anon, VC-backed, or corporate? An anon solo dev against a VC-backed field is a different risk than against an anon field. ### 4c. On-chain numbers Measure, do not quote: - **TVL directly.** Enumerate the protocol's own contracts and sum balances. Receipt: PFWA's TVL came from `getOptionTokenAddresses` across all 92 markets, giving 0.147183 ETH, $361.78, against a $733,907 cap. - **Protocol revenue as cumulative inflow**, via `txlistinternal`, checking outbound legs. A balance understates by whatever was spent and hides whatever was swept. - **Burns and buybacks priced in dollars, and sourced.** Market-bought with ETH is a buyback. Burning treasury inventory is not, and the tell is that the treasury's ETH balance did not fall. - **Holder count and slope**, from a reconciled sweep. Rising holders plus rising price is the only combination that produces a run. Flat holders with falling volume is a base; falling holders with falling volume is the end. - **Cohort overhang**: who bought when, how much they still hold, and its dollar value against the real bid. - **Contract powers** by selector scan when GoPlus is empty. ### 4d. X visibility and sentiment, as a COMPARISON Not a description of the candidate. **Run the same queries against every Ring 1 peer and tabulate.** Use twitterapi.io per `research-sources`. Per project, pull the 30-day series and compute: | Metric | Why | |---|---| | **Posts per day, and the slope** | Attention leading price by days is a positive. Price leading attention is distribution | | **Unique authors** | 100 posts from 8 accounts is not 100 posts | | **Share of posts from the project's own account** | 25% self-generated means the attention is manufactured. PFWA's own account was 10 of 100 ticker posts | | **Largest amplifier, by followers** | One 53k account carrying a name means the bid leaves when they rotate | | **Tier-one coverage, checked by name** | `(TICKER OR handle OR 0xCA) from:account` for blknoiz06, theunipcs, pingucharts, CrashiusClay69, 0xkioto, _0xghost_, metaversejoji, dontbuytops. Zero after direct tagging is the clearest ceiling signal there is | | **Mentions per $1M of market cap, across the peer set** | The comparison that actually matters. More mentions at a lower cap than peers means under-priced attention. Fewer mentions at a higher cap is a crowded trade | | **Non-English coverage** | Chinese, Korean and Turkish CT move Robinhood Chain names and never appear in an English ticker search | **Sentiment is read, not scored.** Never quote a sentiment number; LunarCrush held 77 to 86 through an entire 60% drawdown. Instead classify every post into: `product claim` · `price claim` · `competitor attack` · `founder or team content` · `phishing` · `bot spam` · `genuine user report` Then report the **mix**, and how it differs from peers. A field that is 60% price claims and 20% bot spam is a different object from one that is 50% product claims and user reports. Always scan for the two campaign patterns: **phishing** ("claim portal", "holder portal", "check eligibility" with the correct contract address) and **bot spam** (near-identical broken-English posts every 20 minutes, zero likes). **Bot spam and paid promotion DO reach the output**, because they say who is actually bidding. **The drainer and phishing campaign does NOT** (Ben, 6 Sep 2026): the template runs on every ticker on the chain, so it carries zero information and never separates one token from another. Log it in the `/areas/` file only if the template is genuinely novel or impersonates the project's own account. **Separately, always run the impostor-contract check and put it at the TOP of the output when it fires.** Search the ticker as well as the contract address, and pull every distinct contract address that comes back. For each, read `pairCreatedAt`, the deployer, and whether the mint went to a launchpad curve or straight to an EOA. Cross-check against the project's own bio and website. Receipt, RAILX 13 Sep 2026: a self-minted copy deployed 7 minutes after the real Pons launch was trading at **6.1x the market cap and 7.1x the liquidity of the genuine token**, and a ticker search on DexScreener sorted by liquidity returns the fake first. ### 4f. THE OPERATOR READ. Is the founder street smart? BLOCKING, every screen. 4b establishes whether the founder is real and whether they are selling. This is different: **can they actually run a launch?** On a micro cap the technology is copyable and the token usually has no contractual claim on anything, so the operator is the asset. Grade it, do not describe it. The timeline is the evidence. Pull the project account and the founder's personal account (`x.com/` and `/with_replies` through the Mac Chrome bridge when the twitterapi.io index gap returns 0 for `from:`, which it does for accounts under about a week old). **Measure latency against the community post being answered, not against the clock.** **Launch sequencing, worth more than everything below it** - Did the product exist BEFORE the token? Site, docs, repo, package with a publish date earlier than `pairCreatedAt` is the single strongest founder signal available on a day-one screen. - Was the launch venue the right one for the product, and is the contract the standard template for it? - Was there a pinned post with the contract address, and does the profile bio carry it? **A bio CA is the only thing that settles an impostor-contract question.** **Reactivity, timed** - Response latency to real questions: minutes, hours, or never. - Does he answer the AWKWARD question, or only the flattering one? Quoting a critic and answering plainly is worth more than ten replies to fans. - Does he ship what the community asks for, and how fast does the commitment arrive? - Behaviour under attack: calm and specific beats defensive, and beats promising what cannot be delivered. **Does what he says make sense** - Do his claims survive the chain? **Check his own numbers before repeating them, in his favour and against.** A founder who understates his own buyback is telling you something; so is one who overstates it. - Does he post receipts (transaction hashes, dashboards, endpoints) or adjectives? - Does he understand his own product well enough to explain it in one sentence a trader can repeat? If the community cannot restate the pitch, it cannot spread. **Pump economics: is he making the right moves at the right time** - **Is there a buyback or burn, and is it a PROGRAM or a gesture?** Price every leg in dollars and plot the cadence. A steady clip every N minutes is a program; one large burn at launch is a gesture. **Separate a pre-launch supply cut from an open-market buyback — the timestamp against `pairCreatedAt` settles it, and conflating the two overstates the loop.** - **What is he doing with the discretionary bag, and does the market know?** An undecided founder allocation is the largest single overhang on most day-one tokens. Putting it to a public vote, locking it, or burning it are all better than silence. - Is he holding attention across the dip, or did the posting stop when the price did? Map his post times against the price series. - Is he buying paid promotion, and is he honest that it is paid? Dexscreener boosts, "dex paid", call-channel quote tweets, and a farm of tiny accounts posting the same line are all purchasable and all detectable. - **What he does NOT do counts as much.** No price targets, no "next 100x", no market-cap goals, no quote-tweeting paid callers, and no tokens sold into the pool. Each absence is a point in his favour, and the presence of any one of them is a point against. - Is he defending the ticker? **An unaddressed impostor contract trading above the real one is the clearest operator failure there is**, and it is the one most founders miss. **Grade it A to F in one line, then name the specific thing a better operator would already have fixed.** Always set the grade against the size of the room: flawless behaviour in front of 171 followers is a different fact from flawless behaviour in front of 50,000, and the output must say which. --- ### 4e. Further dimensions, use the ones that apply - **Regulatory exposure.** Sharp for prediction markets, RWA and anything touching tokenised equities. Check the parent company's own filings via SEC EDGAR full-text where relevant. - **Chain dependency.** If this chain stalls, does the project survive? Could it ship unchanged elsewhere, and would anyone care if it did? - **Competitive moat.** What stops the Ring 1 peer with 700x the TVL from adding this feature next week? Usually nothing. Say so. - **Distribution.** Who brings the users: the chain, a launchpad, a KOL, an integration, or nobody. - **Lifecycle stage.** Pre-product, product-live-no-usage, usage-growing, mature. Peers at a different stage are not multiple comps. - **Incentives.** Merkl campaigns with end dates tell you which TVL is rented and when the rent stops. --- ## Step 5: Output, the benchmark block Delivered before the frames, in this shape: 1. **Category, one line.** What it is, and the return bucket it sits in. 2. **Peer set, three rings**, named with contracts or chains. 3. **The comparison table.** 4. **The one column it is most extreme on**, stated in a sentence. 5. **THE RENTED / OWNED STACK**, one row per layer, then the five product questions: what they do; **the DEMAND TEST with its four-label PMF verdict, the enumerated named customer list, the build-versus-buy result, the builder-signal count stated separately from trader noise, the counterfactual, the wedge and the survival gate** (never a day-one adoption number as the potential answer); competitors; ease of copy with a rebuild estimate in days; moat, product moat and token moat stated separately. Close with what is actually being bought. 6. **THE OPERATOR READ**, graded A to F, with the timed reactivity evidence, the buyback cadence priced in dollars, what he is doing with the discretionary bag, and the one thing a better operator would already have fixed. Grade set against the size of his audience. 7. **Technology: better / worse**, two short lists with receipts. 8. **Founders: one paragraph** against the peer field. 9. **X comparison table** across Ring 1, plus the sentiment mix, plus the impostor-contract check. 10. **Is the category tokenised, and who is the same-chain competitor without a token.** Then hand to `three-frame-valuation`, which now has a real peer set for the anchor, a real product floor from Ring 3, and a real ceiling from Ring 2. --- ## Verification before handing off **Gates 1 to 6 BLOCK delivery. If any answer is no, the screen is not finished and must not be delivered.** 1. Is there a **RENTED / OWNED stack table**, built by reading the product's own health or config endpoint and then probing every upstream it named? 2. Are all **five product questions** answered: what they do, potential with a customer count and a chain-growth scenario, competitors in all three places including the upstream provider shipping it themselves, ease of copy **with a rebuild estimate in days or weeks**, and moat **with the product moat and the token moat stated separately**? 3. Is the **operator graded A to F**, from his actual timeline, with response latency measured against the posts he was answering? 4. Is every **buyback and burn priced in dollars, plotted as a cadence, and split between pre-launch supply cuts and open-market buys by timestamp against `pairCreatedAt`**? 5. Is it stated **what he is doing with any discretionary founder bag**, and whether the market has been told? 6. Was the **impostor-contract check** run by searching the ticker as well as the contract address, with every distinct address returned resolved against the project's own bio and website? 7. Is there a **PMF verdict carrying one of the four labels** (no demand / demand already captured / demand unserved / PMF proven), and is it stated that a day-one adoption number is not evidence either way? 8. Was **the job already being done counted on chain**, and the **customer list ENUMERATED BY NAME** rather than given as a market size? 9. Was the **build-versus-buy test** run against every named customer, and is the **survival gate** (open-source client vs closed API, cadence, doxx, bus factor) stated as the thing actually throttling early adoption? Then the rest: - Was the category assigned from the product, and does it survive being read back against the contract? - Was a promoter's comp tested rather than adopted? - Are there at least 8 peers, spanning all three rings? - **Was "is this category tokenised at all" answered explicitly?** - **Was the same-chain competitor without a token found and named?** - Does every table cell have a figure or an explicit "not tracked"? - Were cap/TVL and cap/fees computed for every peer, not recalled? - Was the X comparison run against peers, not just the candidate, and is the sentiment reported as a mix rather than a score? - Were the founders checked on chain for buying or selling, rather than by their claims? - Is the single most extreme column named, and is it the thesis or the disqualifier?