Deployer funding and holder clusters API

Identify the Base token deployer, walk early inbound funding hops, and report holder concentration clusters. Unknown funding origin is identified=false with origin_label=unknown — not a neutral skip.

The Deployer funding and holder clusters operation is part of the Base Token Security API on BRAINIAC.software. Identify the Base token deployer, walk early inbound funding hops, and report holder concentration clusters. Unknown funding origin is identified=false with origin_label=unknown — not a neutral skip. It is exposed as POST /api/v1/token-security/deployer-funding-trace and priced at $0.10 USDC on Base. Payment uses the x402 exact scheme: an unpaid call returns HTTP 402 with payment requirements; after paying the exact USDC amount, retry the same request with a payment-signature header and Idempotency-Key. No account and no API key are required. Data sources for this product: Base public JSON-RPC (mainnet.base.org), unauthenticated. Contract runtime bytecode and public eth_call / eth_getStorageAt reads. DEX Screener public token endpoint (api.dexscreener.com), unauthenticated. Honeypot.is simulation for sell-simulation. Blockscout Base API for deployer funding and holders. DeFiLlama coins API for the second price in price-two-source. Limitations: Only Base mainnet (chain id 8453) is assessed. A missing signal is not evidence that a token is safe. Bytecode selector matches can be coincidental and do not prove a function is callable. DEX Screener figures are feed reports, not pool balances read by this API. sell-simulation, deployer-funding-trace, and price-two-source use tri-state pass|fail|not_checked; not_checked is never treated as pass. sell-simulation uses Honeypot.is sizing; amountUsd is caller intent and may not match the simulated trade size. Deployer funding labels are conservative; unlabeled origins stay origin_label=unknown with identified=false. LP locks and wallet-specific blacklist status are not measured on the bytecode-only checks. No risk score is calculated. HTTP 200 with status=partial means some checks completed, some unavailable. status=complete means no missing checks. status=failed means critical error or all checks unavailable (e.g. full RPC outage). missing_items lists unavailable checks with machine-readable reason: timeout, upstream_down, rate_limited, or not_supported. HTTP 200 with status complete, partial, or failed is charged at the full listed price. There is no partial discount. Retrying missing checks requires a new full paid call. HTTP 4xx/5xx are not charged. Idempotency after errors: payment-signature attached ≠ charged. A 402 without payment-signature does not store the key; 402/503 after payment-signature was attached release it; pre-reserve schema 400 does not store it. Responses after payment-signature was attached are stored and replay on same key+body; different body returns 409. Stored 4xx/5xx replays are not a second charge. After a 4xx prefer a new key once the body is fixed; after a 5xx reuse the same key only to retrieve the stored error. Settlement signal: settled 2xx include a payment-response header; 4xx/5xx do not and are not charged. missing_items.reason retry guidance: timeout and rate_limited — one retry after a delay with a new Idempotency-Key; upstream_down — retry only after the upstream recovers; not_supported — never retry that check. Caller invariant: a response with any missing_items entry is never status=complete; a check listed in missing_items should not also appear as a completed finding of the same check. Caller invariant for sources[]: sources[] is provenance only (source, url, retrievedAt). Entries are not keyed by check id and do not carry success or error. A check in missing_items does not remove its upstream from sources[]; unavailability is expressed only in missing_items (and unavailable findings), never by omitting the source or adding an error field on the source entry. When Base RPC is fully unavailable, status=failed with missing_items containing rpc_unavailable (reason: upstream_down). When DEX Screener is fully unavailable for liquidity/manipulation checks, status=partial if contract checks passed, status=failed if only DEX checks were requested. Partial results are not cached for anonymous replay. Reusing the same Idempotency-Key for the same operation and body returns the stored response (including status=partial) without re-running checks; a new key runs a fresh call. Use retrievedAt and sources[].retrievedAt to see when sources were fetched for that response. Successful coverage responses include result_id and received_at. GET /api/v1/results/{result_id} returns the original stored response without re-running checks (free; expires after 24 hours; listed in OpenAPI and /api/v1/catalog). Send Prior-Result-Id on a later paid call to set replaces_result_id on the new result. Outputs are compliance prechecks, drafts, or data lookups for human review. They are not official determinations, legal advice, identity confirmation, or certified filings. Related operations in this group include Token risk verdict, Honeypot risk check, Ownership risk check, Liquidity risk assessment. Open the group documentation for the full request schema, field notes, and response examples before integrating.