docs: add Pons API page for Robinhood Chain (BIT-15195) - #243
Merged
Conversation
Documents the Pons V2 bonding-curve launchpad (PonsV2LaunchFactory 0x7ed598bc… and PonsV2LaunchAndBuy 0xe33e9e47…) on Robinhood Chain. Bitquery has no ABI for any Pons V2 contract, and TokenLaunched indexes token, curve and deployer — so the event payload alone never identifies the launched token. The page works around that two ways, both verified live: Call.Output on the launch selectors returns (token, curve), and the Topics filter matches an indexed address to reconstruct a token's full lifecycle from undecoded events. Covers the launch feed and metadata (Call.Input carries name, symbol, IPFS logo, description and socials), bonding-curve trades, the snipe tax decay, graduation, the hooked Uniswap v4 pool, post-graduation Trading/DEXPoolEvents/DEXPoolSlippages queries, and holders. All 63 event topic0 values were computed from the verified contract source and confirmed against live logs. Every GraphQL block in the page was executed against streaming.bitquery.io; the three subscriptions were verified over WebSocket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Drop full contract addresses from three h3 headings; they made the right-hand TOC unreadable. Addresses moved to an "Emitter:" line and the headings pinned to stable explicit ids. - Curve trade fee is read from the launch config (curveFeeBps), not a protocol constant. Verified in PonsV2LaunchFactory source; every sampled launch uses config 0, but the page no longer states 100 bps as if it were fixed. Verified while auditing: graduate() and createGraduatedPool() carry no access modifier, so "permissionless" is accurate; and a Pons V1 launch transaction does emit PoolCreated plus Initialize/Mint on a Uniswap V3 WETH pool, confirming the V1 caution box. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The page previously claimed SignatureHash filters, Topics filters and
"the entire Calls cube" were realtime-only, and pointed users at the
launch-mint transfer as the only route to history. Retesting showed
that was wrong on two counts.
What actually forces realtime is `Log.Signature.SignatureHash` and
`Call.Signature.SignatureHash` — and it forces it whether you FILTER on
the field or merely SELECT it, which is the easy trap. The earlier
finding was a false attribution: the failing query happened to select
SignatureHash while filtering on Topics.
Verified working on realtime + archive + combined:
- Topics: {includes: [{Hash: …}]}, including topic0, with multiple
hashes combined as AND
- Call.Input / Call.Output, including Input: {startsWith: [...]},
which accepts a list of selectors
So the whole page — the Calls launch feed included — is archive-capable.
Changes:
- New Datasets section: omitting `dataset` silently gives you realtime,
which is the usual cause of "my query returns nothing older than a few
days". Includes the per-construct realtime/archive/combined matrix and
links to the canonical dataset docs.
- All 10 topic0 and selector filters switched to the archive-capable
forms, and SignatureHash removed from every selection set.
- Launch-mint transfer section reframed: a second, independent route to
the same list (and the convenient one for metadata), not the only way
to reach history.
All 20 GraphQL blocks re-executed on realtime; the 7 converted ones also
verified on archive and combined. Build + check-links clean; 48 in-page
anchors resolve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bitquery has since added ABIs for all 13 pools.trade events this page documented as raw, including the entire Crowd Launch (CCA) auction. Re-measured against the live API on 11 Aug 2026. - Event reference: all 15 rows now decoded; topic0 column retained - New "Reading decoded arguments": tuple components flatten into one row each, carrying the tuple's type name and distinguished only by Index (UERC20Metadata, PoolKey, MigratorParameters) - Flag the TokenCreated name collision: the entry contract and the factory emit different signatures under the same name, so Name alone matches both - Token metadata: description / external link / image now read straight from Arguments, replacing the client-side ABI-decoding instructions - Crowd Launch bids and clearing price rewritten onto decoded arguments - Dataset note: SignatureHash remains realtime-only (re-confirmed), and archive coverage of these events is still thin Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Full adversarial re-read of the page against the live API. Four real defects, all measured rather than reasoned: 1. The flagship launch feed double-counted. It matched d6a0eef5 (launchTokenFor) alongside f85f8e41 (launchAndBuy) while the caution directly below it warned against exactly that. Measured 200 rows / 143 transactions = 1.4x inflation. Dropped d6a0eef5; now 1.000x. 2. "Swap the factory address for the curve address and the same filter returns that token's history" was false. Curve events index the recipient/account, not the token, so that query returns zero rows. Replaced with a caution explaining where the trick does and does not apply. 3. The graduated-pool query scoped by Transaction.To on the factory, which silently drops graduations triggered by keeper contracts — graduation is permissionless. Measured 33 of 34 over three days. Rescoped onto the `hooks` argument, which returns all 34 and is the semantically correct discriminator. Also archive-capable. 4. The launch-mint section still described the Calls feed as "source of truth within the realtime window" and itself as the "archive-reachable approximation" — stale after the archive rewrite, since both now run on archive. Also: note that Input.startsWith takes a list and the 0x prefix is optional; drop a "100 bps baseline" phrase that contradicted the config-derived fee note; add a tip to check whether Bitquery has since decoded Pons (the sibling pools.trade page just gained ABIs — re-checked, Pons is still fully undecoded). All 20 GraphQL blocks re-executed; build and check-links clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds
docs/blockchain/robinhood/pons-api.mddocumenting the Pons V2 bonding-curve launchpad on Robinhood Chain, per BIT-15195.Covers
PonsV2LaunchFactory(0x7ed598bc…) andPonsV2LaunchAndBuy(0xe33e9e47…): the launch feed and metadata, bonding-curve trades, snipe tax, graduation, the hooked Uniswap v4 pool, post-graduationTrading/DEXPoolEvents/DEXPoolSlippagesqueries, and holders.The problem the page solves
Bitquery has no ABI for any Pons V2 contract, so
Log.Signature.NameandArgumentsare empty on every Pons event. Worse,TokenLaunchedindexes token, curve and deployer — the payload alone never identifies the launched token, and Bitquery does not expose topics as an output field.Two workarounds, both verified live, and both applicable to any undecoded EVM contract:
Call.Output/Call.Inputon theCallscube. The launch selectors return(token, curve[, tokensOut]), andCall.Inputcarries the full metadata struct — name, symbol, IPFS logo, description, and socials. This is the best launch feed available and stays the best even if the ABI is added later, because the metadata only ever exists in calldata.Topics: {includes: [{Hash: …}]}, which filters on any log topic including an indexed address padded to 32 bytes. Reconstructs a token's whole lifecycle from undecoded events.Neither appears in the existing Robinhood pages.
Verification
Transfer(address,address,uint256)), then confirmed against live logs. Events that exist in the ABI but rarely fire are marked (rare) rather than presented as usable feeds.streaming.bitquery.io— 0 failures. The 3 subscriptions were verified over WebSocket with real messages arriving.npm run buildpasses withonBrokenLinks: "throw";check-linksreports 547 pages / 0 errors; all 47 in-page anchors resolve in the rendered DOM.Two things worth a reviewer's attention
A caveat inherited from the pools.trade page is false here. That page warns of ~1.9× duplicate trade legs. Pons v4 pools measured 1.0× over 300 rows, so this page says so explicitly and points at the difference rather than copying the warning. Three other inherited caveats were re-tested and did hold.
Pons V1 is out of ticket scope but still live.
PonsLaunchFactory(0xa5aab3f0…) is a separate protocol — no bonding curve, a Uniswap V3 WETH pool at launch, different event signatures — and it is still deploying tokens at roughly 5,000 events/day. The page documents V2 only, with a caution box carrying V1's address and topic0s, because a "Pons launches" feed built from V2 alone silently misses it. Say the word if you'd rather V1 got its own page.Per review decisions: no Bitquery IDE saved-query links (they can't be created or verified from a CLI session), and structural constants only — no dated launch/volume counts, since the realtime window is ~4 days and those numbers would go stale fast.
🤖 Generated with Claude Code