Context
Envio is deprecating XDC support on HyperSync. Their XDC indexer is already stuck at block 105,265,600 (~400K blocks behind the actual chain). Before the endpoint goes offline entirely, we need to extract full historical data for ALL production XDC contracts while HyperSync is still available.
This also serves as a stress test for the hardened v5 pipeline (PR #51) -- large-scale backfill across many contracts will exercise the rate-limiting handling, retry logic, and block-aligned chunking under real load.
Plan
- Add all production XDC contracts to the pipeline config (addresses from
GoodProtocol/releases/deployment.json)
- Create BigQuery tables for each new contract (DDL)
- Run historical backfill via HyperSync (up to block 105,265,600 -- everything available)
- Build RPC adapter to replace HyperSync going forward (separate issue)
Contracts to backfill (production-xdc)
Already indexed:
New (need backfill):
Lower priority (may skip if low event volume):
Why now
- HyperSync backfills millions of blocks in seconds (vs hours via RPC)
- XDC endpoint could go offline any day
- Once backfilled, RPC handles the gap fill and daily operations (no vendor dependency)
Follow-up
- Build RPC adapter to replace HyperSync for all chains (separate issue)
- Extend to Celo production contracts (same pattern, HyperSync still works there)
Relates to #40
Context
Envio is deprecating XDC support on HyperSync. Their XDC indexer is already stuck at block 105,265,600 (~400K blocks behind the actual chain). Before the endpoint goes offline entirely, we need to extract full historical data for ALL production XDC contracts while HyperSync is still available.
This also serves as a stress test for the hardened v5 pipeline (PR #51) -- large-scale backfill across many contracts will exercise the rate-limiting handling, retry logic, and block-aligned chunking under real load.
Plan
GoodProtocol/releases/deployment.json)Contracts to backfill (production-xdc)
Already indexed:
0x22867567E2D80f2049200E25C6F31CB6Ec2F0faf) -- 2.7M rows0x6bd698566632bf2e81e2278f1656CB24aAF06D2e) -- 9.2K rowsNew (need backfill):
0xEC2136843a983885AebF2feB3931F73A8eBEe50c) -- transfers, mints, burns0x27a4a02C9ed591E1a86e2e5D05870292c34622C9) -- verification events0x7344Da1Be296f03fbb8082aDaC5696058B5a9bd9) -- faucet claims0xa3247276DbCC76Dd7705273f766eB3E8a5ecF4a5) -- cross-chain bridges0x94A3240f484A04F5e3d524f528d02694c109463b) -- reserve operations0x88de45906D4F5a57315c133620cfa484cB297541) -- exchange/swaps0x2fFBB49055d487DdBBb0C052Cd7c2a02A7971e41) -- exchange liquidity0x5557E9dEF86ad6564462741a7A3f3679C1223f5d) -- UBI expansion0x75a8bE0C2dEaDEd8Fc9ECEB5F01ad0B979b7AD03) -- DAO governance0x21eaC3fE218307BeE0463F77EBcA3b50F452C0Ce) -- DAO treasury0xB8A0d4b97327a0B6dD0705dC290AE26aA38a7d2b) -- UBI distributionLower priority (may skip if low event volume):
0x1e5154Bf5e31FF56051bbd45958b879Fb7a290FE)0xe8861A20452Db53dF685F1d9e6B7017de3DB0E46)Why now
Follow-up
Relates to #40