Hi @AxiomaticAardvark and arbitrators,
We’ve reproduced it and agree with the finding.
**What we confirmed**
- The receipts match the report. We fetched the three disputed transactions from four Polygon RPC providers, using both `eth_getTransactionReceipt` and range `eth_getLogs` (the call graph-node uses). All four return `Approval` log indexes 89, 51 and 205 at blocks 58,152,153, 58,152,171 and 57,293,422, not the 87, 38 and 185 in our response.
- Each of our wrong indexes is the real log index of a different log in the same block, belonging to transactions 24, 11 and 47 of those blocks.
- graph-node copies `logIndex` from the RPC response into the entity id unchanged, so our store kept whatever the provider returned. The deployment’s initial sync ran from block 56,387,750 to chain head on 2025-11-17. The two ids we got right (blocks 84.0M and 91.9M) were indexed later, at chain head.
- All staked.cloud indexers query the same graph-node store, which is why `0xdc53e62d…`, `0x090f7382…`, `0xa6ff993e…` and `0x9af3fc81…` returned identical responses. Because the entity ids feed into the PoI, our PoI on this deployment is wrong too.
**Likely cause**
Both RPC providers we used for matic during that sync were backed by Polygon Erigon at the time. The pattern, where one log is given the index of another log in the same block, matches the [Erigon 3 receipt-file bug](invariantsEthGetLogs found `eth_getLogs: at blockNum=3525000 duplicated log_index 0` · Issue #15838 · erigontech/erigon · GitHub) that was fixed in Erigon PR 15918. Per Erigon issue 18656, affected nodes kept the bad files through upgrades until a full resync. Both providers now run Bor and return the correct values. We no longer have graph-node logs from November 2025, so we can’t tell which provider served the bad responses.
**What we’ve done**
- On November 5, between 21:23 and 21:35 UTC, we closed all eight staked.cloud allocations on this deployment with a zero PoI and zero public PoI, and collected no indexing rewards. Unlike our ftnGO closes, these went out as intended: the `POIPresented` events show `0x0` for all eight. None remain open.
- Following the guidance on the ftnGO thread, we’ll keep the current store intact until the Arbitrators rule, then resync from the start block. Before allocating again, we’ll check the resynced ids against chain receipts and compare our public PoI at a shared epoch block with other indexers, including levergrt.eth.
- This is the second dispute traced to bad RPC data during an original sync, so we’re also comparing public PoIs with other indexers at a recent epoch block for our other matic deployments synced in the same period.
**Questions**
1. Is there any additional information you’d like from us?
Thanks,
Staked Team
PS Any indexer that synced matic deployments from Erigon-backed RPCs in 2025 may want to spot-check entities keyed on `logIndex`. graph-cli’s default templates build ids that way, and nothing in graph-node flags a wrong index.
Note this response was generated with some AI help 