---
title: "Get a Robinhood Chain token verdict, holders, tax, sell check"
method: GET
path: "/v1/rhc/curve/{address}"
tags: ["paid"]
---

# Get a Robinhood Chain token verdict, holders, tax, sell check

`GET /v1/rhc/curve/{address}`

## Request

- Base URL: `https://api.loopholetape.com`
- URL: `https://api.loopholetape.com/v1/rhc/curve/{address}`
- Auth: none required

Use when you hold or are about to trade one pons v2 token on Robinhood Chain and need a verdict by a fixed public rule, its holders, creator tax, deployer record, ring screen and an exact sell check; to find launches use GET /v1/rhc/launches/recent. Not for Solana mints. The verdict (avoid / caution / no_flags_observed, the fixed public rule LABELS rhc_verdict at /v1/labels, with basis, reason and up to three reasons carrying their evidence and measured base rate): avoid while a charged buy pays >= 618 bps of snipe tax or when the 3 s holder structure matched the ring rule; caution on a creator tax >= 500 bps, a top holder >= 50%, a deployer with >= 3 earlier launches and no graduation, a curve at <= 50% of its peak price 30 min after launch without graduating, a missing or pending 3 s snapshot, or a completed or graduated curve. deployer_record: the deployer's earlier launches on our tape, how many graduated or matched the ring rule at 3 s, the median peak and terminal multiples. sell_check: buy and sell tax in bps, the exact quote for selling 1% of supply and a 0.01 ETH round trip in bps from the recorded reserves (graduated tokens: the pool's taxes, no quote). Full structure card for ONE pons v2 curve on Robinhood Chain, addressed by curve or token address (0x…): launch facts (block, deployer, pair token, graduation threshold), raised / progress / price multiple vs launch (exact curve reserves, ETH-paired curves), the launch's trade fee and creator tax in bps (fees block; the creator tax is charged on every buy and sell and is invisible to three-word event parsers), snipe-tax activity, holder ledger concentration (top-1 / top-5 / HHI / deployer share), same-block direct-buy cluster share and wallets, max direct buys in one 100 ms block, terminal-vs-direct route mix with terminal holdings share, flow (buys / sells / unique buyers / new buyers in the last 2 and 6 s / last trade age / volumes), lifecycle (completed / graduated blocks and delays, refunds), the trade_cost block (for a 0.01 and a 0.05 ETH clip at the curve's reserves now, exact with fee and creator tax on both legs and own impact: fill price vs marginal, the immediate round trip, and the price rise from now needed to break even), and the ring block: the same-block direct-buy cluster screen (unique_buyers >= 8 and same-block direct-buy cluster share >= 0.5) our own capture measured at 14.5% of launches, 47% dumped, median 0.37x terminal; matching timing is not proof of coordination, and on pons v2 such a cluster is often the team's own opening bundle, exempt from the snipe tax at launch. coverage=full for curves launched inside our event window (last ~2 h, trades observed from block 0); thin = launch facts + lifecycle only, with a reason. Always 200 for a valid address.

## Path parameters

- `address` string, required

## Response `200`

Paid response (header PAYMENT-RESPONSE carries the settlement)

- Envelope
  - `ok` boolean, required
  - `schema_version` '2.0', required
  - `generated_at` string, date-time, required
  - `t` number, required: unix seconds at generation
  - `coverage` 'full' | 'thin', required: the mint is inside our live window (created while our captur / thin = the mint is not in the live window (older than ~2 h of silen
  - `data` object, required
  - `meta` object, required
    - `source` string
    - `version` string
    - `feed_lag_s` number, nullable: seconds between the newest event in our tape and now (the age of the newest event we ingested; it does not say whether the capture runs behind the chain, see chain_lag_s)
    - `is_stale` boolean: the ingest age (feed_lag_s) exceeds the route's freshness limit (5 s for compact risk checks, 30 s otherwise); a paid or keyed pump.fun request is also refused above 5 s of estimated chain lag when the gate enforces (see chain_lag_s, tape_behind), which this flag does not show
    - `chain_lag_s` number, nullable: estimated seconds the newest slot in our pump.fun tape is behind the Solana RPC's processed tip (slots_behind x the measured slot time, to 0.1 s); null when the tip is unknown; absent on Robinhood Chain answers
    - `slots_behind` integer, nullable: estimated slots between the newest slot in our pump.fun tape and the Solana RPC's processed tip (a tip read every 30 s, carried forward by the wall time since at the slot rate our own reads measure); 0 when the tape is at or ahead of the estimate; null when the tip is unknown
    - `tape_behind` boolean, nullable: true when the estimated chain_lag_s is above 5 s, false within 5 s, null when there is no tip to compare; on pump.fun answers only
    - `last_slot` integer, nullable
    - `price_usd` number, nullable
    - `next` object: related resources worth calling next (paths relative to base_url)
    - `disclaimer` string

## Other responses

- `402`: Payment required (x402 v2): header PAYMENT-REQUIRED = base64 of the body
- `404`: not found or invalid: address is not 0x-prefixed 40-hex pons v2 curve OR token address on Robinhood Chain ({ok:false, error, hint})
- `422`: Validation Error

---

[API](https://skmtc.dev/loopholetape/apis/loophole-tape.md) · [All operations](https://skmtc.dev/loopholetape/apis/loophole-tape/llms.txt) · [OpenAPI document](https://skmtc.dev/loopholetape/apis/loophole-tape/revisions/eea099d70151?raw)
