--- name: token-screens description: The long-form detail of Ben's token due-diligence method — his ten DD questions, the demand test, the impostor-contract check, and the mandatory screen blocks. Read whenever screening a token or project; /preferences.md carries only the short rules. sources: [cowork] aliases: [dd-questions, demand-test, impostor-check, screen-method] --- ## His ten DD questions, in order (13 Sep 2026) This is what the Run DD button on his runner board generates. It replaced the old six-point lowcap screen on that button. - [stated] (0a) PICK THE LENS FIRST and say which: MEME (the name, the lore and whether the joke travels ARE the product) or TECH (whether it works and anyone needs it is the product). Never grade a meme on its GitHub, never forgive a tech project for having a nice story; if both, say which half carries it. On a meme, questions 4, 5 and 6 get one line each and the effort goes to 0b, 7, 8 and 10. - [stated] (0b) NAME AND LORE, often the whole thesis on a meme: look the name up rather than guessing, say what it means and where it comes from, whether they got the reference RIGHT or half wrong, whether it connects to this chain or this moment, whether it is legible without a paragraph of explanation, whether the same reference has been used before and died, and then whether people would actually LIKE it. His worked example: 宋江 (Song Jiang), the outlaw leader from Water Margin, is the Chinese Robin Hood, on Robinhood Chain, an exact fit and the reason that coin has a reason to exist. On a meme the MOAT is the reference itself: who owns it, can a second coin take the same name and story, is this the one people point at. - [stated] (1) Is the deployer suspicious: funding source, prior launches and whether they died, self-snipe or bundle, still holding or sold. - [stated] (2) What does the project actually do, in one or two plain sentences. - [stated] (3) Does it do what it says: site and X claims against the contracts and the chain, name every mismatch. - [stated] (4) Is it live: actually open the website and the product, say what was clicked and what happened, distinguish a working product from a landing page with a buy button. - [stated] (5) Product market fit: real users and real usage on chain, not holders; is the job already being done elsewhere; who complains if it vanishes tonight. - [stated] (6) GitHub: does one exist, real code or a template, last commit, commit count, how many people, one anon or a team; say plainly if there is none. - [stated] (7) Is the dev reactive AND does he ship, two halves, shipping matters more. (a) reply latency, and whether he answers hard questions or only easy ones. (b) SHIPPING VELOCITY: a dated list of what has actually shipped since launch from his posts, the site, the contracts and any GitHub, with the gap in hours or days between releases, then the label: ships fast off community feedback (name the request and the release that answered it), or has his own roadmap and is hitting it on time (name the milestone and the date), or nothing shipped since launch and it is all posting. His rule: iterating quickly and pushing new features fast IS part of being reactive, and a dev who replies to everyone but ships nothing is NOT reactive. - [stated] (8) Does he understand PUMP ECONOMICS: when holders raise burning, buybacks, fee sharing or supply cuts, does he engage, and is he ACTUALLY DOING IT, priced in dollars with dates, real buybacks separated from pre-launch supply cuts. - [stated] (9) Moat: product moat and token moat stated separately, plus a rebuild estimate in days. - [stated] (10) Differentiation: name competitors on chain and off it, say in one line what makes it unique or say nothing does. - [stated] Close with one verdict word (buy / hold / avoid), one sentence why, and the single thing that would change the verdict. ## The demand test (13 Sep 2026) - [stated] NEVER USE A DAY-ONE ADOPTION NUMBER AS THE "DOES IT HAVE POTENTIAL" ANSWER. Mechanism: adoption = latent demand x awareness x trust / friction, and at t=0 awareness is near zero and trust is zero (the first thing anyone thinks is "will this still be here next month, or is he going to exit"), so adoption is near zero regardless of demand. - [stated] Estimate latent demand directly, with eight tests all observable at t=0: (a) is the job already being done by anyone with something worse, counted on chain; (b) NAME and COUNT the customers from the chain's own fee leaderboard, never a TAM; (c) substitution test, what do they do instead and how many engineering hours is it; (d) BUILD-VERSUS-BUY against every named customer, the test that kills most dev-tool plays, because multichain incumbents, anything whose core product IS the thing being sold, and anything at scale all build their own; (e) builder signal counted SEPARATELY from trader noise, one technical question outranks ten thousand "burn ser"; (f) the counterfactual, who complains by name if it vanished tonight; (g) the wedge, one customer with one painful job where the incumbent has not already won; (h) THE SURVIVAL GATE, which is what actually throttles early adoption: an anon founder with a closed hosted API is a dependency a professional team refuses regardless of quality. - [stated] Verdict is ONE of four labels, never a number: NO DEMAND / DEMAND EXISTS ALREADY CAPTURED / DEMAND EXISTS UNSERVED / PMF PROVEN. The chain-growth scenario runs last and never substitutes for the test. ## Five product questions and the operator grade (13 Sep 2026) - [stated] Split the stack into RENTED and OWNED by reading the product's own health/config endpoint and probing every upstream it names; whatever is left in OWNED is the entire company. - [stated] Answer: what they do; potential (via the demand test); competitors on chain, off chain, AND whether the upstream provider could simply ship it; ease of copy AS A REBUILD ESTIMATE IN DAYS, never an adjective; moat, with the product moat and the TOKEN moat stated separately. - [stated] Grade the founder A to F from his live timeline: response latency measured against the posts he was answering, whether his claims survive the chain, buyback/burn cadence priced in dollars and split from pre-launch supply cuts by timestamp, what he is doing with his discretionary bag, and what he is NOT doing (no price targets, no paid-caller quote tweets, no selling). Always set the grade against the size of his audience. ## Mandatory blocks on every screen - [stated] CHAIN CONTEXT BLOCK: host chain TVL with 30/60 day change, DEX volume 24h/7d/30d with change, chain fees, protocol count, and the token's own fee base as a share of chain volume. - [stated] SLOT OWNERSHIP scored in two parts, attention rank AND structural rank on the metric the product actually runs on, because reporting only the first is how a thesis gets oversold. A slot a project has genuinely taken is a real advantage that must be priced in, not waved away. - [stated] TOLL BOOTH TEST: a first-mover premium is priced only when the token sits between the flow and the counterparty; name the take rate, read it from the contract, and run a chain-growth scenario (chain 5x and 10x, share flat and rising) before crediting it. - [stated] A screen without a benchmark comp table against named same-sector projects with caps and MC/TVL is incomplete, every time. ## The impostor-contract check (13 Sep 2026) - [stated] RUN IT ON EVERY SCREEN and put it at the TOP of the output when it fires. Search the ticker as well as the CA, resolve every distinct address returned against the project's own X bio and website, and read each one's pairCreatedAt, deployer, and whether the mint went to a launchpad curve or straight to an EOA. - [stated] Receipt: RAILX 13 Sep 2026, a self-minted copy at 0x8680a02bb54fe135279b16842D8E90a9ba81e0f0 deployed 7 minutes after the real Pons launch traded at 6.1x the market cap and 7.1x the liquidity of the genuine 0xfEAd46F7baBd84b7f450aaEEcE081deF6e973c28, so a DexScreener ticker search sorted by liquidity returns the fake first.