# BountySignal Trench Gate — a falsifiable pre-trade evidence gate for Robinhood Chain

## Executive result

I built and tested a working CLI that watches Robinhood Chain's newest pools, joins five public evidence surfaces, and returns `STOP`, `WAIT`, or `PAPER_TEST`. It never emits a buy signal. Its purpose is to prevent a retail trader from confusing freshness, paid visibility, volume, or a green chart with evidence of executable risk-adjusted opportunity.

The first live five-pool scan on 2026-08-17 returned **zero PAPER_TEST candidates**:

| Candidate | Verdict | Deepest indexed liquidity | Main reason |
|---|---|---:|---|
| POLAR | WAIT | not yet indexed by DEX Screener | no independently indexed pair |
| Charlie | WAIT | $20,990 | below the $25k execution floor |
| TERM | WAIT | not yet indexed by DEX Screener | no independently indexed pair |
| 牛来 | WAIT | $28,880 | largest visible EOA held 44.80% |
| FLY-100 | WAIT | $2,233 | below the $25k execution floor |

That is a useful result: the tool refused all five rather than manufacturing a ranking.

Public artifacts:

- Live product home: https://bountysignal-radar-v2.minhtuan36zzz97948.chatgpt.site
- This complete report is the submitted public artifact.
- Runnable Node 22+ source: https://paste.rs/SeiUc.mjs

Run locally:

```bash
node robinhood-trench-gate.mjs scan --limit=8
node robinhood-trench-gate.mjs 0x020bfC650A365f8BB26819deAAbF3E21291018b4
```

No wallet, private key, API key, trade execution, custody, or paid service is used.

## 1. Research before product selection

### Robinhood Chain constraints

Robinhood Chain is a permissionless EVM-compatible Arbitrum L2. The official connection page identifies mainnet chain ID **4663**, ETH gas, a public Blockscout explorer, and public RPC/sequencer endpoints; it also warns that public RPC is rate-limited and not intended for production throughput. The official ecosystem page lists Uniswap as a public DEX and Rialto as an aggregator/PropAMM. Sources: [Robinhood Chain overview](https://docs.robinhood.com/chain/), [connection details](https://docs.robinhood.com/chain/connecting/), and [bridge routes](https://docs.robinhood.com/chain/bridging/).

This matters for product choice:

1. The chain is live and observable, so a working read-only MVP is possible now.
2. The ecosystem is young enough that historical labels and stable routing coverage cannot be assumed.
3. EVM compatibility makes contract-security and holder-distribution evidence portable.
4. First-come, first-served sequencing reduces gas-auction assumptions but does not remove latency, slippage, MEV, fake volume, concentration, or contract risk.

### Existing workflow and market map

| Job | Current product/workaround | What it does well | Gap relevant to Robinhood Chain |
|---|---|---|---|
| Discover fresh pools | GeckoTerminal new-pools feed | Network-specific new pools and near-real-time pool fields | Freshness is discovery, not safety or edge; the public API is beta, cached and rate-limited |
| Inspect price/liquidity/activity | DEX Screener | Pair liquidity, 24h transactions, volume, age and links | Paid boosts can increase trending visibility, so visibility is explicitly not an independent quality signal |
| Inspect contract risk | GoPlus Token Security API | EVM flags, creator/holder data, honeypot and DEX fields; chain 4663 is supported | Coverage is a safety input, not a return forecast; missing/unknown fields must fail closed |
| Verify canonical chain state | Robinhood Chain Blockscout | Contract verification, reputation, holders, creation transaction and token metadata | Raw concentration is misleading when pools/bridges/contracts are not separated from EOAs |
| Execute a manual decision | Bots + tabs + spreadsheet | Flexible for expert operators | Evidence becomes fragmented, stale and easy to cherry-pick under FOMO |

Primary product/API sources: [GeckoTerminal API](https://api.geckoterminal.com/docs/index.html), [DEX Screener API](https://docs.dexscreener.com/api/reference), [DEX Screener boosts](https://docs.dexscreener.com/boosting), [GoPlus Token Security API](https://docs.gopluslabs.io/reference/token-security-api), and [Robinhood Chain Blockscout API](https://robinhoodchain.blockscout.com/api-docs).

### Recurring user failures

Trader discussions repeatedly describe the same fragmented workflow and failure modes: discovery from trending/new-pair surfaces, then ad hoc contract/distribution checks, with losses from rugs, clustered supply, fake volume, and fees. Examples include a detailed report of dusted holders and wash trading used to influence trending metrics ([CryptoMarkets discussion](https://www.reddit.com/r/CryptoMarkets/comments/1he5w7p/)), a concrete case where one operator distributed supply across multiple wallets to evade simple rug checks ([Solana discussion](https://www.reddit.com/r/solana/comments/1bxoq8c/)), and users explicitly asking how low-value trades avoid being destroyed by fees ([trenching discussion](https://www.reddit.com/r/solana/comments/1iopsdu/)). These are anecdotes, not causal estimates; I use them only to identify jobs and failure modes.

Research supports taking the manipulation problem seriously. *Trade or Trick?* characterizes scam tokens and colluding addresses on Uniswap ([paper](https://arxiv.org/abs/2109.00229)); *Token Spammers, Rug Pulls, and SniperBots* analyzes token spam, rugs and sniper participation across Ethereum/BSC ([paper](https://arxiv.org/abs/2206.08202)). Neither paper proves that this MVP generates alpha on Robinhood Chain.

## 2. Selected opportunity

The underserved job is not “show me the next token.” Existing tools already maximize discovery and attention. The better first product is a **fail-closed evidence gate** placed between discovery and research allocation:

```text
new pool → independent pair index → contract/security checks → ownership classification
         → execution stress → STOP / WAIT / PAPER_TEST → forward observation only
```

Why this is more useful than another score:

- It treats absence of evidence as `WAIT`, not as a neutral zero.
- It separates EOAs from contracts, pool addresses and burn addresses before applying concentration thresholds.
- It treats paid boosts as a caution, never a positive feature.
- It makes dollar order size visible through an execution-stress estimate.
- It preserves the underlying reasons instead of hiding them behind a 0–100 score.
- It refuses to claim expected return before an out-of-sample evaluation exists.

## 3. Working MVP

### Data joined

For each token address the CLI fetches, in parallel:

1. Blockscout token metadata;
2. Blockscout address/verification/reputation data;
3. Blockscout top holders;
4. DEX Screener Robinhood pairs;
5. GoPlus chain-4663 token-security data.

The scan command first consumes GeckoTerminal's Robinhood `new_pools` feed, extracts distinct base-token addresses, then runs the gate sequentially to respect public services.

### Decision policy

`STOP` is triggered by a hard safety observation such as a GoPlus honeypot/cannot-sell/hidden-owner/take-back-ownership/blacklist flag, a Blockscout scam reputation, or visible buy activity with no sells.

`WAIT` is triggered by incomplete or execution-poor evidence: unverified source, no independent pair, deepest visible liquidity below $25,000, fewer than 20 sells in 24 hours, largest visible EOA above 20%, missing open-source status, or no DEX coverage.

`PAPER_TEST` means only that none of those current gates failed. It is deliberately not called `GO` or `BUY`.

Thresholds are version-0 operational hypotheses, not optimized parameters. They are intentionally explicit so they can be falsified and changed only on training data, not after seeing holdout performance.

### Execution stress

For order sizes of $100, $500 and $1,000, the report displays a constant-product approximation:

```text
one-way impact ≈ order / (2 × visible USD liquidity + order)
round trip ≈ 2 × (impact + assumed 0.30% pool fee)
```

The output clearly states that this excludes concentrated-liquidity ticks, routing, gas, MEV, latency and token transfer tax. It is a rejection-oriented stress test, not a quote.

### Verification performed

- Four deterministic unit tests pass: eligible evidence never becomes a buy verdict; honeypot becomes `STOP`; weak liquidity/unverified source becomes `WAIT`; pool and contract balances do not inflate EOA concentration.
- A live single-token run joined all five sources and generated a complete Markdown decision record.
- A live five-new-pool run completed and rejected all five from paper-test eligibility for observable reasons.
- The implementation accepts only a valid 20-byte EVM address and uses 15-second request timeouts.

## 4. Validation design

### Operational definition

An **early token** is a token whose deepest independently visible DEX pair was created no more than 72 hours before the observation timestamp. Discovery timestamp and every raw response hash should be frozen so later data cannot leak backward.

### Forward paper test (required before any performance claim)

On a fixed cadence, record every distinct new pool and the complete feature snapshot. Do not retrospectively add missed winners. For each candidate, record executable mid/route estimates at observation plus horizons of 15m, 1h, 6h, 24h and 72h. Mark failed/no-route exits as losses rather than dropping them.

Net return must include:

- entry and exit pool fees;
- gas at the contemporaneous chain state;
- size-dependent slippage using an executable route or simulation;
- latency from discovery to observable decision;
- failed transactions and unsellable positions;
- bridge costs only if the baseline assumes capital is off-chain.

### Baselines

1. Uniform random selection from the same new-pool cohort and timestamp.
2. Liquidity-weighted selection from that cohort.
3. Highest 24h volume/liquidity selection.
4. DEX Screener visibility/boost heuristic.
5. “Trade every new pool” with the same order size and latency.

The gate should be evaluated first as a **loss-avoidance classifier**, not as a price predictor. Report coverage, false-negative rate for catastrophic outcomes, false-positive rate, median and mean net return, volatility, maximum drawdown, hit rate, sample size, and bootstrap confidence intervals. Pre-register the training window, freeze thresholds, then evaluate a later holdout window. Wallet/entity clustering should be built only on past information.

### Success and stop conditions

MVP success requires both:

1. materially lower catastrophic-loss/failed-exit rate than all discovery baselines; and
2. higher net risk-adjusted paper returns after costs on a frozen holdout, with enough observations for uncertainty to be informative.

If it only reduces coverage without improving net risk-adjusted outcomes, the concept fails. The next-best research direction would be execution feasibility and sell-route simulation for Robinhood Chain, not a more elaborate token score.

## 5. Known limitations and non-claims

- Public APIs may lag, omit pools, change schema, or rate-limit.
- Related wallets can evade a simple EOA concentration check; entity resolution is future work.
- A verified contract can still be malicious or economically unsafe.
- Security-provider flags are inputs, not guarantees.
- Volume and holder count can be manipulated.
- The current MVP does not simulate an actual swap or inspect concentrated-liquidity tick depth.
- No historical or forward result yet establishes positive expected return.
- The product provides intelligence only: it does not trade, snipe, custody, leverage, copy-trade or create tokens.

## Conclusion

The evidence does not justify an “alpha score” today. It does justify a working, reproducible gate that removes obviously weak or under-evidenced candidates before a trader spends attention or capital. The most honest first release is therefore the one shipped here: fresh-pool discovery, cross-source evidence, transparent rejection reasons, order-size stress, and a falsifiable forward-test plan.