voidfeed.ai
4 Base listings. By the latest purchase of each: 2 delivered · 1 failed on the seller's side · 0 on vet402's side · 1 awaiting on-chain verification · 0 not yet bought. Latest purchase: 2026-09-28 00:01 UTC.
1.Your listings
| Listing | Latest purchase | Result | Whose side |
|---|---|---|---|
| voidfeed.ai/v1/content/fact-feed/latestGET | 2026-09-28 00:01 UTC | awaiting on-chain verification | — |
What we saw: The seller returned a settlement receipt, and vet402 has not confirmed that transaction on-chain yet. Until it is confirmed or refuted, this purchase is neither delivered nor failed.Recorded: settle_claimed · HTTP 200 · tx 0xddc58ea0…5d92In export.csv?days=2: the row with attempted_at 2026-09-28T00:01:50Z and resource_key voidfeed.ai/v1/content/fact-feed/latest.Earlier: 2026-09-21 18:02 UTC delivered · 2026-09-13 00:02 UTC vet402's wallet was out of USDC (vet402's side) · 2026-09-04 12:09 UTC delivered | |||
| voidfeed.ai/v1/tools/extract/graphGET | 2026-09-27 18:02 UTC | delivered | — |
What we saw: Paid; vet402 confirmed the transfer on-chain and the paid request answered HTTP 200.Recorded: settled · HTTP 200 · tx 0x2758e9df…51a5In export.csv?days=2: the row with attempted_at 2026-09-27T18:02:11Z and resource_key voidfeed.ai/v1/tools/extract/graph.Earlier: 2026-09-17 18:01 UTC delivered · 2026-09-11 06:01 UTC delivered | |||
| voidfeed.ai/v1/market/priceGET | 2026-09-23 12:01 UTC | Took the payment, then refused the input | seller's side |
What we saw: The payment settled on-chain, and then the paid request got 400, 404, 415 or 422: the route took the payment before it checked the input, so the buyer paid for a refused request. When the seller declared a body, or a required query, that vet402 was not yet sending, the row is on vet402's side instead.What to fix: Check the input before you settle, so an invalid request is refused without taking the payment; and declare the input in the listing with example values that work as written. (a server change)Before 2026-09-27 23:27 UTC, vet402 did not add query parameters to paid requests on Base; this listing declares optional ones.Recorded: settled · HTTP 400 · tx 0x89b117db…b9e7 · held as settled_4xxIn export.csv?days=6: the row with attempted_at 2026-09-23T12:01:26Z and resource_key voidfeed.ai/v1/market/price. | |||
| voidfeed.ai/v1/content/extract/dataset/latestGET | 2026-09-22 06:01 UTC | delivered | — |
What we saw: Paid; vet402 confirmed the transfer on-chain and the paid request answered HTTP 200.The latest purchase delivered. An earlier purchase listed below did not.Recorded: settled · HTTP 200 · tx 0x116c926a…3a88In export.csv?days=7: the row with attempted_at 2026-09-22T06:01:58Z and resource_key voidfeed.ai/v1/content/extract/dataset/latest.Earlier: 2026-09-15 18:00 UTC vet402's wallet was out of USDC (vet402's side) · 2026-09-09 12:08 UTC delivered · 2026-09-02 19:00 UTC delivered | |||
2.How to read this
Each listing shows its latest purchase on Base and up to four earlier ones. Whose side says where the failure came from: the seller's answer or listing, or vet402 itself. A row held (held_reason in the export) is not counted against the seller in the delivered numbers, because vet402 cannot rule out that its request was the problem. The transaction link opens the settlement on Basescan. Listings removed from the Bazaar, and listings whose catalog network is not Base, are not on this page. The fix-first page groups the same results across sellers (methodology).
3.Think a row is wrong?
Open the listing's record (the link in the first column) and use “Dispute this record” there. Say which purchase and what you saw instead. The row is not deleted on dispute; a correction is published with the same weight.