Whobought and Cielo: token-discovery checks
21 September 2026 · Bounded live tests · Findings as of 09:55 UTC
Prioritise Cielo for an RH research pilot, with our native transaction tape as the reference. Defer Whobought for RH: its Robinhood interface is not live. Whobought is usable for Solana discovery, provided we verify changes in wallet holdings. Neither service has passed a complete-coverage or trading-performance evaluation.
What passed—and what did not
| Check | Whobought | Cielo |
|---|---|---|
| Read access | Public REST responses and live WebSocket events worked | User-supplied key worked; stored privately with owner-only permissions |
| Robinhood | HOOD button disabled and marked “soon”; RH backend queries returned no swaps | Authenticated live chain discovery includes robinhood |
| Transaction evidence | All 12 selected Solana transactions existed, succeeded, and included the attributed wallet as a signer | Four of six selected RH transactions were eventually returned with the expected token: three swaps and one transfer |
| Main limitation | Three sampled route legs did not change the displayed token’s net wallet balance | Two sampled busy wallets were rejected; a curve sell appeared only as a transfer |
| Identity and metadata | Platform labels are useful leads, not independently proven ownership | One token-balance response had the correct balance but the wrong name and symbol |
The samples are small and deliberately inspect different cases. These counts are not estimates of overall accuracy or profitability.
Whobought: useful for Solana, not currently our RH feed
I inspected the running public app and its deployed chain-selector code. Both show SOL enabled and HOOD/BNB disabled. The backend accepts the identifier RH, but the requested 60-minute and 1,440-minute Fomo windows returned empty results. An accepted chain identifier alone does not establish populated coverage.
The public Solana feed includes source labels, handles, wallet addresses, token addresses, side, timestamp, USD amount, transaction hash and an event ID. A lookup for the Fomo handle used in our earlier capture sample returned a Solana wallet mapping. That fills a potential data gap, but the mapping is a provider assertion: the blockchain can verify the transaction and wallet, not that a named social account owns the wallet. Solana mappings must not be carried over to RH addresses.
Transaction check
I froze a 100-row feed response, then selected the first three distinct transaction hashes for each source/side combination: Fomo buys, Fomo sells, Pump.fun buys and Pump.fun sells. All 12 were checked against finalized public Solana RPC results.
- 12/12: successful transactions, matching signatures, attributed wallet among signers, and provider timestamps matching block timestamps.
- 9/12: the displayed token’s net balance moved in the indicated direction.
- 3/12: the displayed token’s net balance was unchanged while another token’s balance changed. These were route-leg cases, not evidence of acquiring or disposing of a net position in the displayed token.
- The six Fomo-labelled cases all passed the net-direction check. The three route-leg cases were in the Pump.fun subset. This is too small a sample to generalise either result.
Two transactions needed support for transaction version 1; they were re-read and retained in the original sample. No failed cases were replaced. USD valuations, full historical inventory and social-account ownership were not independently validated. Solana transaction RPC reference.
Freshness and recovery
Five reads about 12 seconds apart all returned HTTP 200 and 500 records, with 761 distinct events across the reads. Despite requesting ten minutes, each capped response reached back only 95–102 seconds. The observed response exposed no pagination cursor. A collector outage longer than that observed window could lose data unless a separate historical route is established. An empty or overlapping response is not a completeness certificate.
The normal browser session also received 40 distinct swap events over 11.7 seconds. Receipt time minus provider event time had a 0.75-second median and approximately 1.08-second 95th percentile. This is a tiny sample with second-resolution provider timestamps, not a latency guarantee. Automatic reconnect and outage backfill were not certified.
In one profile’s receipt data, all 24 non-null bundlerPercent values exceeded 100. The units are not established, so those values must not be interpreted as ordinary percentages or fed into ranking. The service’s trust/P&L summaries remain unvalidated. Public app endpoints worked, but I did not establish a supported third-party API contract, retention guarantee or rate allowance.
Cielo: RH works, with coverage and interpretation gaps
Authenticated /api/v1/chains confirmed robinhood, and live feed requests worked. The account’s unfiltered feed was empty; explicit wallet queries returned data. Our collector must define its wallet universe rather than assume the default feed covers the entire chain. Feed reference, live-chain discovery reference.
I selected three distinct curve-token cases from a frozen native-tape snapshot, including buys and sells, and three distinct pool-token cases from recent inserted pool records. All six transaction hashes, block times and successful receipts were independently checked by RH RPC. Tests used bounded wallet/time queries; no account tracking lists were changed.
| Case | Native activity | Final observed result |
|---|---|---|
| 1 | Curve buy | Exact transaction and token returned as a swap after rechecking |
| 2 | Curve sell | Exact transaction and token returned only as a transfer |
| 3 | Routed curve sell | Router query rejected; querying the transaction sender eventually returned the swap |
| 4 | Pool trade | Sender rejected with “unable to track wallet with high tx number” |
| 5 | Pool trade | Exact transaction and token returned as a Uniswap V4 swap |
| 6 | Pool trade | Sender rejected with the same high-activity-wallet error |
Initial responses included HTTP 202, empty HTTP 200 results, and HTTP 400 rejections. Subsequent wider-window and original-window queries recovered the curve records. A successful empty response cannot establish absence of activity, especially during initial wallet indexing. Recheck delay, ingestion lag and possible caching were not separately measured.
“Returned” here means matching transaction hash and token address, including contract_address for a transfer. It does not establish complete economic decoding. In particular, the curve transfer alone does not capture the native proceeds or establish that a sell occurred; our native curve event supplies that meaning. A collector restricted to txTypes=swap would miss this tested exit.
Confirmed metadata error
A Robinhood token-balance call returned the correct balance of approximately 19,244.288779 tokens, but named the contract Global Dollar / USDG. Direct calls to that same contract returned Snowline / SNOW, 18 decimals, and the matching raw balance. The address in both responses was the same. This is a confirmed metadata mismatch, not evidence that the balance amount was wrong.
The balance call succeeded even though the endpoint’s documented chain list does not include RH. Live capability and documentation differ; endpoint support needs testing individually. Token-balance documentation.
How we should use the findings
- Cielo supplies additional RH observations. Join them to the native curve/pool tape using chain, transaction hash and token address. Retain event indices and individual legs; do not deduplicate an entire multi-leg transaction into one trade.
- Fetch transfers as well as swaps. Classify a transfer as a buy or sell only when transaction evidence establishes that meaning. Query the actual trader where a router address is rejected; preserve failures for busy trader addresses.
- Verify identity and position changes. Maintain source/handle/wallet mappings with provenance and an observation time. Distinguish same-person wallets, independent traders and unknown relationships. A route leg is not conviction.
- Keep collection gaps visible. Preserve first receipt time, original payload, retry state, pagination coverage and late observations. Never backdate an alert to the provider timestamp for a performance test.
- Use Whobought only for the Solana research branch today. Require positive verified net accumulation before counting a buy as wallet support; leave questionable percentage and trust scores out.
The next production decision should follow a bounded forward comparison against native events: report recovered events, misses, classifications, busy-wallet failures and receipt delays separately for curve and pool activity. This investigation does not justify a large position because two wallets overlap.
Cost and scope
Cielo currently documents 3 credits for a wallet-filtered feed request, 5 for a general feed request, and 3 for a token-balance request; live chain discovery is documented as zero credits. This investigation made 14 wallet-feed requests, one general-feed request and one balance request: 50 credits at listed successful-request rates, before any differing treatment of pending/errors. Actual billing was not retrieved. Feed pricing, balance pricing.
For scale, one wallet polled each minute costs 4,320 credits/day at that rate; 50 separately polled wallets cost 216,000/day. A single list feed polled each minute starts at 7,200/day before extra pages. These are arithmetic scenarios, not a recommended polling schedule. The documented 100-row page limit must be considered. Cielo also documents paid-plan WebSocket access, but its live stream and account entitlement were not tested here. WebSocket reference.
This was a bounded, read-only evaluation. No ongoing collector was deployed. Source snapshots and reproducible probe scripts are retained privately; this published report contains aggregate findings only. The credential is excluded from all report files.
Download the aggregate measurements · Download this report as Markdown