{
  "v": 1,
  "requestId": "06afe64f-1059-442c-a0d3-dc3c6d0a810b",
  "chainId": 4663,
  "window": {
    "fromBlock": 68224388,
    "toBlock": 68438428,
    "toBlockHash": "0xa490f1949b375dc071eeafd98504e76ac44460d3db87225ee7ef7b40757351ba"
  },
  "answerType": "address[]",
  "answer": [
    "0xba2f1ed4ceb2169d538d1e614d847e83c5a55913",
    "0x7ddbd3952d9fd58cc7d344ad0931d08db072114a",
    "0x7a6a053eccf1446a2633e05aa6d40d09381997ec",
    "0xd750615e5900f2aa09083e95c0dbb4958b173800",
    "0x8366a39cc670b4001a1121b8f6a443a643e40951"
  ],
  "figure": "862063547781759636731",
  "definitions": {
    "recipient": "The `to` argument (topic 2) of each ERC-20 Transfer(address indexed from, address indexed to, uint256 value) log emitted by the token contract. No recipient is excluded: contracts rank alongside EOAs, mints (from = 0x0000000000000000000000000000000000000000) count toward their recipient, and 0x0 itself would rank as a recipient of burns if its total placed it (it did not reach the top 5).",
    "token": "Only logs whose emitting contract is 0xc9a981fee1f9dec688bb123ccdecc63d0debfc4e are counted. Confirmed on chain at the closing block: symbol GLD, name \"SPDR Gold Trust • Robinhood Token\", decimals 18.",
    "denomination": "Raw token base units (integer wei-scale, 18 decimals), summed as uint256 with no scaling and no price conversion. `figure` is the leader's total in those base units; 862063547781759636731 base units = 862.063547781759636731 GLD.",
    "amount": "The unindexed `value` data word (data:0) of each Transfer log, read as an unsigned uint256. No de-duplication of round trips and no netting of outgoing transfers: this is gross received value, not net flow.",
    "window": "Both endpoints inclusive, blocks 68224388..68438428. The opening block's timestamp is 1789936008 and the closing block's is 1789957608, so the pinned range is exactly the 21600 seconds (6 hours) the question asks for. The window was taken from the brief and not widened.",
    "ordering": "Descending by summed received value; ties broken by ascending hexadecimal address. The top five totals are all distinct, so no tie-break was exercised. Addresses are lowercase 0x + 40 hex.",
    "log_selection": "Only logs with topic0 = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef (keccak256 of \"Transfer(address,address,uint256)\") and at least three topics. Logs marked `removed` are dropped; a (blockNumber, logIndex) pair seen twice is counted once."
  },
  "recipe": {
    "kind": "log-rank",
    "address": "0xc9a981fee1f9dec688bb123ccdecc63d0debfc4e",
    "event": "event Transfer(address indexed from, address indexed to, uint256 value)",
    "sumArg": "value",
    "abs": false,
    "groupBy": "to",
    "topN": 5
  },
  "notes": "Computed with the delivered scan script over exactly the pinned blocks, one complete scan from one operator:\n\n  node .imd/reads/skills/oracle-assess/scripts/scan.mjs --rpc https://rpc.ordofi.network --from 68224388 --to 68438428 --pin 0xa490f1949b375dc071eeafd98504e76ac44460d3db87225ee7ef7b40757351ba --address 0xc9a981fee1f9dec688bb123ccdecc63d0debfc4e --event \"Transfer(address,address,uint256)\" --rank topic:2 --by data:0 --top 10 --chunk 20000\n\nResult: pinned true, 16332 Transfer logs across 3565 blocks with logs, 4715 distinct recipients, 43 chunks / 47 RPC calls. The script started at 20000 blocks per eth_getLogs and halved twice on refusal, settling at 5000 blocks per call for the whole range.\n\nTop ten by received value, in base units (the answer is the first five; extra rows included because `head` is 1 and agreement is exact only on the leading positions):\n  1. 0xba2f1ed4ceb2169d538d1e614d847e83c5a55913  862063547781759636731\n  2. 0x7ddbd3952d9fd58cc7d344ad0931d08db072114a  648342696935475017613\n  3. 0x7a6a053eccf1446a2633e05aa6d40d09381997ec  647551284061006669787\n  4. 0xd750615e5900f2aa09083e95c0dbb4958b173800  642093688291405044306\n  5. 0x8366a39cc670b4001a1121b8f6a443a643e40951  602579819556883336585\n  6. 0x51c72848c68a965f66fa7a88855f9f7784502a7f  547437623034393938162\n  7. 0x9f736f87e6293ac1bd9142e257dbfac8b7acf1ae  545114836867651661851\n  8. 0x6aa80dbbed9ae5ab45fbf61f9644fada3b29326e  533225360319174155580\n  9. 0x8237f673a33ee64c25b3ec93c1582d589bfeea38  489497442779089073097\n 10. 0x1a18a8b96eac3f980133a18402d04194f1faa4e7  381335000000000000000\nNo adjacent pair among these is tied, so the ordering is fixed by value alone.\n\nEndpoints used. Scan: https://rpc.ordofi.network (eth_chainId 0x1237 = 4663). Pin cross-checked before the scan on three independent operators, all returning hash 0xa490f1949b375dc071eeafd98504e76ac44460d3db87225ee7ef7b40757351ba and timestamp 1789957608 for block 68438428: https://rpc.ordofi.network, https://robinhood-rpc.publicnode.com, https://rpc.mainnet.chain.robinhood.com. The script itself re-confirmed the pin during the scan (pinned: true). Token metadata (symbol/name/decimals) read by eth_call at the closing block on https://rpc.ordofi.network.\n\nTruncation guard. Public nodes answer an oversized eth_getLogs with a short list more often than with an error, and the densest 5000-block chunk of this window (68374388-68379387) held 3943 logs, so that chunk was re-read as a control: 3943 logs / sum 318685115731994870024 at chunk 5000 on https://rpc-robinhood.blockmachine.io and on https://rpc.mainnet.chain.robinhood.com (one call each, two operators independent of the scan endpoint), and 3943 logs / the same sum at chunk 1000 on the scan endpoint. Identical across operators and across chunk sizes, so no chunk was silently truncated. https://robinhood-rpc.publicnode.com refuses archive eth_getLogs without a personal token and was used only for the pin check. No other full scan was run: the deployer reruns the recipe before anything is signed.\n\nOn the ranking's shape. Position 5, 0x8366a39cc670b4001a1121b8f6a443a643e40951, is the Uniswap v4 PoolManager on this chain; it ranks as a recipient because GLD swapped into a v4 pool is transferred to the manager. The question asks which address received the most GLD by summed Transfer value and sets no exclusion, so contracts, routers and the pool manager are ranked alongside externally owned accounts rather than filtered out. This is gross receipts: an address that received and then forwarded the same tokens is credited with the full received amount.\n\nThe question maps onto the catalogue's log-rank without loss, so the recipe above is the computation itself and not an approximation."
}