---
name: dd-process
description: "Ben's DD process: the ten-question due diligence he runs on a coin, delivered in four passes under time pressure. Use whenever he says run DD, DD this, run the DD process, or pastes a coin and asks for DD."
---

# The DD process

Ben's named command. "Run DD on this", "DD this coin", "run the DD process" all mean
exactly what is written below, every time, in this order, in this format. It is the same
process the Run DD button on his runners board generates.

**This is NOT "deep dive."** Deep dive is the slow full chain (research-sources, benchmarking,
three-frame-valuation, gem-hunter) and a bare contract address pasted with no other words still
means deep dive. DD is the fast ten-question read he uses to decide whether to enter a coin that
is minutes to hours old. If he says DD, run DD.

---

# STEP ZERO: RUN THE SNIPE-CLUSTER GATE. NO VERDICT PRINTS BEFORE IT RETURNS CLEAN.

This runs BEFORE pass 0, before the ten questions, before anything. It is not a factor to be
weighed against positives. It is a gate.

**Receipt, 13 Sep 2026, DUO / duo.rich on Robinhood Chain `0x601C29752e68Bfff7113751c7d6b6655494D07ae`.**
A buy verdict was delivered at t+45min. The token rugged **3 minutes later**: 37 wallets exited
in a **3.4-second** block window (62096782 to 62096815), pool ETH 7.91 to 1.09, mcap $177,964 to
$3,379. The screen had a clean contract (no mint, no owner, no pause), confirmed on-chain
buybacks, a live product, real docs and a dev shipping every ten minutes. **Every one of those
findings was true and none of them mattered.** The cohort data was in hand and was discarded.

Save this as `snipe_cluster.py` and run it. Do not hand-roll it.

```python
#!/usr/bin/env python3
"""snipe_cluster.py <token_ca> [rpc]
Measures the LAUNCH COHORT by tokens ACQUIRED in the first N seconds after the mint,
NOT by current balance -- a cluster that has already dumped shows a zero balance and is
invisible to any balance-based holder scan. That miss cost the DUO call.
"""
import sys,json,subprocess,time
from collections import defaultdict
UA="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 Chrome/128.0 Safari/537.36"
RPC=sys.argv[2] if len(sys.argv)>2 else "https://rpc.mainnet.chain.robinhood.com"
def rpc(m,p,t=90):
    d=json.dumps({"jsonrpc":"2.0","id":1,"method":m,"params":p})
    return json.loads(subprocess.run(["curl","-s","--max-time",str(t),"-A",UA,"-H","content-type: application/json","-X","POST",RPC,"--data",d],capture_output=True,text=True).stdout)
CA=sys.argv[1].lower(); WINDOW_S=15
T="0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"
ZERO="0x"+"0"*40; a=lambda t:"0x"+t[-40:]
head=int(rpc("eth_blockNumber",[])["result"],16)
logs=[];cur=head-60000
while cur<=head:
    e=min(cur+10000,head)
    logs+=rpc("eth_getLogs",[{"address":CA,"topics":[T],"fromBlock":hex(cur),"toBlock":hex(e)}]).get("result",[]); cur=e+1
logs.sort(key=lambda l:(int(l["blockNumber"],16),int(l["logIndex"],16)))
mint=[l for l in logs if a(l["topics"][1])==ZERO]
b0=int((mint or logs)[0]["blockNumber"],16)
t1=int(rpc("eth_getBlockByNumber",[hex(b0),False])["result"]["timestamp"],16)
t2=int(rpc("eth_getBlockByNumber",[hex(b0+10000),False])["result"]["timestamp"],16)
bt=(t2-t1)/10000
SUP=sum(int(l["data"],16) for l in mint) or int(rpc("eth_call",[{"to":CA,"data":"0x18160ddd"},"latest"])["result"],16)
cutoff=b0+int(WINDOW_S/bt)
acq=defaultdict(int); ever=defaultdict(int); sold=defaultdict(int)
for l in logs:
    f,to,v,b=a(l["topics"][1]),a(l["topics"][2]),int(l["data"],16),int(l["blockNumber"],16)
    ever[to]+=v; sold[f]+=v
    if b<=cutoff: acq[to]+=v
cands=sorted([(k,v) for k,v in acq.items() if v>0 and k!=ZERO and not k.endswith("dead")],key=lambda x:-x[1])[:45]
rows=[]
for k,v in cands:
    c=rpc("eth_getCode",[k,"latest"],20).get("result","0x"); time.sleep(0.15)
    if len(c)>4: continue                      # drop pools/routers/wrappers
    rows.append((k,v/SUP*100,(ever[k]-sold[k])/SUP*100))
print(f"token {CA}  mint block {b0}  blocktime {bt:.4f}s  window {WINDOW_S}s (<= block {cutoff})")
print(f"{'wallet (EOA)':<44}{'% bought in window':>20}{'% held now':>13}")
for k,p,h in rows[:30]: print(f"{k:<44}{p:>19.2f}%{h:>12.2f}%")
tot=sum(r[1] for r in rows)
band=[r for r in rows if 1.0<=r[1]<=3.0]
gone=[r for r in rows if r[2]<0.05]
print(f"\nEOAs buying inside {WINDOW_S}s: {len(rows)}  = {tot:.1f}% of supply")
print(f"  of those in an even 1-3% band: {len(band)} wallets, {sum(r[1] for r in band):.1f}%")
print(f"  of those now fully exited:     {len(gone)} wallets")
v = "CLUSTER DETECTED" if (len(rows)>=8 and tot>=20) else "clean"
print(f"\n>>> {v} <<<")
```

**THE GATE. 8 or more EOAs buying inside 15 seconds of the mint, together holding 20% or more of
supply, is a coordinated snipe cluster. Verdict is AVOID. Print it and stop.** No clean contract,
no buyback, no burn, no live product, no reactive dev and no shipping velocity may overturn it.
On DUO the gate prints `EOAs buying inside 15s: 37 = 93.6% of supply -> CLUSTER DETECTED`.

Four rules that come out of that failure, all of them cheap:

1. **Never discard a launch-cohort read because its largest entries are contracts.** The DUO
   screen printed "Recipients within 3s of deploy: 82", saw 285M / 204M / 126M at the top, called
   it routing noise and threw the whole cohort away. The contracts at the top ARE the pool. The
   cluster is underneath them. Drop contracts with `eth_getCode`, then count the EOAs.
2. **Measure the cohort by tokens ACQUIRED in the window, never by current balance.** A cluster
   that has already sold holds zero and a balance-based scan calls it clean.
3. **Run `eth_getTransactionCount` on the whole cohort, not just the deployer.** DUO's band wallets
   ran nonce 30 to 93: seasoned bot wallets, not fresh buyers. Only the deployer's nonce was checked.
4. **Check whether the deployer is IN his own cohort.** On DUO he was row 15, buying 3.00% of his
   own token inside 15 seconds of the mint, and he sold it in the same 3.4-second window as the farm.

**Detection without action is not a pass.** The DUO screen named the even 1.2-2.5% wallet band AND
named "the band starts unloading together" as its own falsifier, then outweighed it with the
positives. A coordinated launch cohort is a gate, not a factor to trade off.

---

# THE BUYBACK TEST: did he burn what he BOUGHT, or the free allocation?

Apply to every buyback and burn claim, every time. Price both legs in dollars with timestamps.

- **Burn the tokens he BOUGHT** means real value accrual, count it.
- **Burn the FREE launch allocation while holding the bought bag** means marketing spend dressed
  as value accrual, and it is a rug tell, not a positive.

DUO receipt: the deployer received 30M free at the mint, burned 25M of it (2.50% of supply,
two txs), and kept the 16.8M he bought with 1.1 ETH (~$2,750). **The bought tokens are exactly
what he dumped.** The split was written down in the screen and the conclusion was not drawn.

---

## Standing conditions

- **He is trading this live. Speed beats completeness.** A late complete answer is worth less
  than an early partial one. The gate above is the one thing never skipped for speed: one script,
  about twenty seconds.
- **Sizing is $100 to $500, a lottery ticket.** Never raise exit depth, position sizing, risk
  management, liquidity being thin, or disclaimers. Never downrank a coin for being small.
- Plain words, like he is five. Short bullets. No jargon. No preamble.
- Never truncate a contract address. Full 42 characters, everywhere.
- Ignore the claim-portal drainer and the Pons-spotlight bot farm. They run on every Robinhood
  Chain ticker and separate nothing.

## First, pick the lens

Say in one line which one, then judge it as that.

- **MEME** the name, the lore and whether the joke travels ARE the product.
- **TECH** whether the thing works and anyone needs it is the product.

Do not grade a meme on its GitHub. Do not forgive a tech project because it has a nice story.
If it is both, say which half is carrying it. On a meme, questions 4, 5 and 6 get one line each
and the effort goes to 0, 7, 8 and 10.

## Four passes, print each the moment it is done

Never hold finished work back waiting for the rest. The order is by how REVERSIBLE an answer
is, not by how fast it is: a look-up can never be overturned by more work, so it is safe to
show at once; a judgement can flip, so it waits.

**PASS 0, KILL SCREEN, target 30 seconds.** In parallel, only these four:

- **the snipe-cluster gate above** (run the script, read the verdict line)
- impostor contract: search the TICKER as well as the address; if a different contract owns the
  name, say which is real and which he is looking at
- the deployer: has this wallet launched before, did those die
- the socials: real accounts, or scraped and pointing at someone else

If any is disqualifying, print **AVOID** with the one receipt and **STOP**. Do not do the rest.
That verdict is final because nothing later reverses it.

**PASS 1, SETTLED FACTS, target 2 minutes.** Questions 0, 1, 2, 3, 4, 6, all fanned out IN
PARALLEL, never one after another. Print as one block.

**PASS 2, COUNTS.** Holder trend, buy versus sell, the dated shipping list (7b), buybacks and
burns in dollars (8) with the bought-versus-free split. Print each with its number so he can
watch it settle.

**PASS 3, JUDGEMENT, only now.** Questions 5, 9, 10, and the verdict.

Label every line: `[SETTLED]` a look-up that will not change, `[COUNTING]` a number still
moving with its value so far, `[CALL]` a judgement, pass 3 only. Never give buy / hold / avoid
before pass 3, the kill screen aside. If anything later contradicts a line already printed,
open with **CORRECTION**, name the exact line, and say which number misled you. Never quietly update.

## The ten questions

Each one carries its receipt.

**0. NAME AND LORE.** On a meme this is often the entire thesis. Look the name up, do not guess.
What does it mean and where does it come from? Did they get the reference RIGHT or half wrong?
Does it connect to this chain or this moment? (Worked example: 宋江, Song Jiang, the outlaw
leader from Water Margin, is the Chinese Robin Hood, and the coin is on Robinhood Chain. Exact
fit, and the reason that coin has a reason to exist.) Is it legible, meaning would someone
seeing the ticker get it without a paragraph of explanation? Has the same reference been used
before and did that one die? Then: would people actually LIKE this, and why.

**1. DEPLOYER.** Suspicious or not. Where the wallet was funded from, what else it has launched
and whether those died, whether it sniped or bundled its own launch, whether it still holds.
**`eth_getTransactionCount` settles "has this wallet launched before" in one call when Blockscout
is walled: a low nonce cannot hide a launch history. Then check whether the deployer appears in
the snipe-cluster output. Sniping his own launch is disqualifying on its own.**

**2. WHAT IS IT.** What the project actually does, in one or two plain sentences, as if he knows
nothing about it.

**3. DOES IT DO WHAT IT SAYS.** Claims on the site and on X against what the contracts and the
chain show. Name every mismatch. **A dev contradicting his own stack in public (DUO: "two Uniswap
V2 pools" at 16:15 against "first launchpad to use Uniswap hooks" at 16:07, while the chain shows
V4) is a real finding: either he did not build it or he does not understand it.**

**4. IS IT LIVE.** Actually open the website and the product. Does it load, does it work, can you
use it, or is it a landing page with a buy button? Say what you clicked and what happened.
**On any swap, trade or quote UI, type an amount into the one box that matters and read the
number back. A beautiful multi-page app is not a working product.**

**5. WILL PEOPLE USE IT.** This is hour one, so do NOT answer with day-one usage numbers. Nobody
knows it exists: no audience, no trust, no visibility, so adoption is near zero whatever the
demand is. That is expected and it is the whole point of being this early. Answer the real
question: will people use this, do people need this, does it make sense, is there product market
fit. Work it from what is observable now: is the job being done today by someone with something
worse, name and count who would actually pay, what do they do instead and how much work is it,
could the buyers just build it themselves, is any real builder (not a trader) asking technical
questions, who complains by name if it vanishes tonight. First flickers of usage are a bonus,
never the answer. Verdict is one of: NO DEMAND / DEMAND ALREADY CAPTURED / DEMAND EXISTS
UNSERVED / PMF PROVEN.

**6. GITHUB.** Is there one? Real code or a template, last commit, commit count, how many people,
one anon or a team. If there is none, say so plainly. **The GitHub API is blocked from the cloud
container. If it could not be checked, say UNKNOWN, never "no GitHub".**

**7. IS THE DEV REACTIVE, AND DOES HE SHIP.** Two halves, both needed.
(a) Talking: reply latency, and whether he answers the hard questions or only the easy ones.
(b) Shipping, which matters more: 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), has his own roadmap and is hitting it on time (name the milestone and date),
or nothing shipped since launch and it is all posting. **A dev who replies to everyone but ships
nothing is NOT reactive.** **Counterweight, from DUO: a dev shipping every ten minutes and
answering hostile questions is also exactly what a competent operator running a farm looks like.
It never outranks the gate.**

**Aged-handle tell:** read the project account's `createdAt` against `followers` and
`statusesCount`. A 15-year-old blue-verified account with double-digit followers and a wiped
history is a purchased handle, and distribution is zero regardless of the check mark. DUO
receipt: @LaunchOnDuo, created 2011-08-21, 18 followers, 20 posts, following 1.

**8. DOES HE UNDERSTAND PUMP ECONOMICS.** When holders raise burning, buybacks, fee sharing or
supply cuts: does he engage, does he take it seriously, and is he ACTUALLY DOING IT? Price every
buyback and burn in dollars with dates, separate real buybacks from pre-launch supply cuts, and
**apply the buyback test above: bought-and-burned, or free-allocation-burned-while-holding-the-
bought-bag.** If he is doing none of it, say that.

**9. MOAT.** Product moat and token moat stated separately, plus a rebuild estimate in days. 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.

**10. DIFFERENTIATION.** Name the competitors, on this chain and off it. Meaningfully different,
or the same thing with a new name? One line on what makes it unique, or say nothing does.

## Close

One plain verdict word: **buy / hold / avoid**. One sentence why. The single thing that would
change the verdict.

**PRE-DELIVERY GATE, numbered, blocks the answer:**

1. Did `snipe_cluster.py` run, and did it return `clean`? If it returned CLUSTER DETECTED the
   verdict is AVOID and nothing else is negotiable.
2. Is the deployer absent from the cluster list?
3. If a buyback is being credited, were the burned tokens BOUGHT rather than free allocation?
4. Is every contract address printed at full 42 characters?
5. Is every source that failed named in the output rather than silently dropped?

## Data to gather first

When the coin is on Robinhood Chain and only an address is given, pull these before answering,
so the numbers are in hand:

- DexScreener `https://api.dexscreener.com/latest/dex/tokens/{addr}` for price, market cap,
  liquidity, volume, `pairCreatedAt`, and `txns` on the 5m and 1h.
- GMGN `https://openapi.gmgn.ai/v1/token/info?chain=robinhood&address={addr}` (header `X-APIKEY`)
  for `link.twitter_username`, website, telegram, github, `launchpad`, `dev`, `holder_count`,
  `image_dup_count`, `migration_market_cap` and the `stat.*` concentration figures. **The route
  is `/v1/token/info`; `/v1/market/token_info` is a 404.** `twitter_username` is often empty even
  when the project has an account, so fall back to the website domain and telegram name rather
  than inventing a handle.
- X search by ticker AND by contract address, bull and bear, per the x-claim-audit method.
- GeckoTerminal minute candles for ATH and distance from it:
  `/api/v2/networks/robinhood/pools/{pool}/ohlcv/minute?aggregate=1&limit=120`.

If a source fails, say what you tried. Never assert a source has no data without opening it.

### Robinhood Chain transport notes, all verified 13 Sep 2026

- **Blockscout is Cloudflare-walled on both v1 and v2 most sessions.** When it is, rebuild the
  holder table from `eth_getLogs` Transfer events instead. It works fine on a young token and is
  the preferred route, not a fallback.
- **GoPlus does not support this chain at all:** `{"code":2022,"message":"The main chain is not
  supported"}`. Read token powers from runtime bytecode instead: `mint(address,uint256)` 40c10f19,
  `pause()` 8456cb59, `owner()` 8da5cb5b, `transferOwnership(address)` f2fde38b,
  `blacklist(address)` f9f92be4, `setFee(uint256)` 69fe0e2d, `setMaxWallet(uint256)` 5d0044ca.
- **Block time is about 0.102 s**, so 30,000 blocks is roughly 51 minutes. Size log scans accordingly.
- **Python `urllib` fails against the Robinhood RPC through the agent proxy; shelling out to `curl`
  with a browser User-Agent works.** The RPC 403s without a browser UA.
- **An inbound token leg FROM the v4 PoolManager `0x8366a39cc670b4001a1121b8f6a443a643e40951` is
  ambiguous** (buy, LP pull or fee claim). Open the tx and read `value` plus `to`: non-zero ETH
  into the Universal Router `0x8876789976decbfcbbbe364623c63652db8c0904` (selector `0x3593564c`)
  settles it as a market buy in one call.