{
  "v": 1,
  "requestId": "b1123516-1005-4377-ba6a-850832e92727",
  "chainId": 1,
  "window": {
    "toBlock": 26026607,
    "fromBlock": 26019451,
    "toBlockHash": "0x8a84f5aa1d5976b1d454cfe7b479740ae9b7e7015bfd4635b124cb47767cdec2"
  },
  "answerType": "uint256",
  "answer": "6456273333333333",
  "figure": "193688200000000000",
  "definitions": {
    "window": "blocks 26019451 to 26026607 inclusive at both ends, on the chain whose block 26026607 hashes to the pinned 0x8a84f5aa...7cdec2; nothing outside those blocks was counted.",
    "sale": "one OrderFulfilled log emitted by Seaport 1.5 (0x00000000000000adc04c56bf30ac9d3c0aaf14dc) or Seaport 1.6 (0x0000000000000068f116a894984e2db1123eb395) whose offer and consideration arrays together hold exactly one NFT item, that item being itemType 2 (ERC-721) with token 0x34c4eba1966b502dfcf0868b6f271d85cc8a2312. An event carrying any second NFT item (itemType 2, 3, 4 or 5) is a bundle and was dropped.",
    "price": "listing fill (the single offer item is the NFT): the sum of every consideration amount, fees and royalties included, and only when every consideration item is native ETH (itemType 0) or WETH 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (itemType 1). Bid fill (the single offer item is ETH or WETH): the offer amount, which is the gross the buyer paid before Seaport routes fees out of it.",
    "denomination": "wei. Native ETH and WETH are counted one for one, as the request's price definition does; no other token is money here and no fill paid in one qualified.",
    "average": "arithmetic mean over the qualifying sales: the integer sum of their prices divided by their count, truncated toward zero (floor, the values being non-negative). 193688200000000000 / 30 = 6456273333333333 wei, remainder 10.",
    "unit-of-count": "one OrderFulfilled log is one sale. Two fills in one transaction are two sales; a transaction that sweeps eight tokens counted eight times.",
    "figure": "the numerator: total ETH+WETH paid over the 30 qualifying sales, in wei. The answer is that divided by 30.",
    "excluded": "ERC-1155 fills, bundles, marketplaces other than Seaport, Seaport fills paid in any token that is not ETH or WETH, and mints or plain transfers that emit no OrderFulfilled. In this window nothing was dropped for those reasons except non-Seaport movement."
  },
  "recipe": {
    "kind": "panel",
    "source": "https://rpc.flashbots.net/fast (eth_getLogs for Transfer on 0x34c4eba1966b502dfcf0868b6f271d85cc8a2312 over blocks 26019451-26026607, then eth_getTransactionReceipt for the Seaport OrderFulfilled logs in those transactions; identical totals from https://ethereum-rpc.publicnode.com and https://rpc.mevblocker.io/fast)"
  },
  "notes": "Answer: 6456273333333333 wei (~0.0064563 ETH), the mean of 30 qualifying Seaport sales totalling 193688200000000000 wei (~0.19369 ETH).\n\nWhy the recipe is `panel`: the brief sets \"evidence\": \"panel\", and the catalogue admits only { kind: panel, source } for such a brief. No chain recipe in the catalogue fits this question anyway - OrderFulfilled carries its offer and consideration arrays in the data, so log-sum cannot reach the price, and the NFT contract is not an indexed topic, so it cannot be filtered on either. The source names the endpoint and the exact two RPC methods, which is what makes the figure re-derivable.\n\nHow it was computed, from public RPC data alone:\n1. Confirmed eth_chainId == 1 and that block 26026607 hashes to the pinned 0x8a84f5aa1d5976b1d454cfe7b479740ae9b7e7015bfd4635b124cb47767cdec2, on four independent operators (flashbots, publicnode, mevblocker, drpc) before reading anything.\n2. eth_getLogs { address: 0x34c4eba1966b502dfcf0868b6f271d85cc8a2312, topics: [Transfer] }, blocks 26019451-26026607: 114 logs, all four-topic (ERC-721), in 64 blocks, across 92 transactions. Confirmed with the delivered scan script: `node .imd/reads/skills/oracle-assess/scripts/scan.mjs --rpc https://rpc.mevblocker.io/fast --from 26019451 --to 26026607 --pin 0x8a84f5aa... --address 0x34c4eba1966b502dfcf0868b6f271d85cc8a2312 --event \"Transfer(address,address,uint256)\" --chunk 4000` -> logs 114, pinned true.\n3. Every Seaport sale of an ERC-721 necessarily emits that Transfer, so those 92 transactions are a superset of the window's sales. Pulled their receipts and kept the OrderFulfilled logs (topic0 0x9d9af8e38d66c62e2c12f0225249fd9d721c54b83f48d9352c97c6cacdcb6f31) emitted by Seaport 1.5 or 1.6: 30 logs. This reads exactly the pinned blocks and is the same set a whole-window OrderFulfilled scan of both Seaport contracts would yield for this collection, at a fraction of the calls - a full-window Seaport scan is tens of thousands of logs.\n4. Decoded each with the Seaport ABI (orderHash, recipient, SpentItem[] offer, ReceivedItem[] consideration) and applied the definitions above. All 30 qualified: one ERC-721 of the collection, no second NFT, money on the other side. 28 were bid fills (collection-offer sweeps, WETH, priced at the offer amount) and 2 were listing fills (priced at the summed consideration, 7994100000000000 wei each, fees included).\n5. Sum 193688200000000000 wei over 30 sales; floor(193688200000000000 / 30) = 6456273333333333.\n\nCross-check: the whole run was repeated against a second operator (https://ethereum-rpc.publicnode.com) and returned the same 114 transfers, 92 transactions, 30 sales, same sum and same mean. No log range was refused or truncated; the scan halves a refused range and retries, and none was needed.\n\nOpen choices, stated because a panel can split on them: the bid-fill price is the buyer's gross offer amount (fees come out of it inside Seaport, so adding the consideration there would double-count); a sweep of N tokens is N sales, not one; ETH and WETH are one denomination; and the window is inclusive at both ends. The guard min=1 holds: 6456273333333333 >= 1."
}