Gweindex

GIWA-Native infrastructure · GASOK application

Every generic indexer trusts a block
the moment it sees one.
On GIWA, that's already wrong.

Flashblocks give GIWA ~200ms preconfirmations inside every ~1s block — and the transaction set behind a block hash can still change before it's final. Gweindex is the indexing layer built to expect that, instead of being surprised by it.

See the measured gap Check the live indexer
Balance mismatches, naive indexer
100/100
Balance mismatches, Gweindex
0/100
Query speed, filtered log lookup
~15×faster

The problem

A wrong answer that looks completely normal

The Graph, Ponder, Envio — every general-purpose indexer we looked at assumes a block is final the instant it's observed. GIWA's own docs say plainly that this doesn't hold: "even for the same block, the hash may change if the set of preconfirmed transactions changes." No generic indexing stack accounts for that.

The failure mode isn't a crash. It's a balance, a log, a fill status that's confidently wrong for exactly as long as it takes a preconfirmation to revise — with nothing in the response telling you so.

We measured it, not just noticed it

Same feed, two indexers, one honest table

Naive indexerGweindex
Balance mismatches100 / 1000 / 100
Log query mismatches500 / 5000 / 500
Query latency139µs9µs (~15×)

Naive here means the default behavior of every generic indexing tool against a feed shaped like GIWA's real Flashblocks cadence — wrong on every single answer it gives, with zero indication anything is off.

The fix

One idea, applied uniformly

A Flashblocks revision is structurally a depth-1 reorg. Track exactly what each revision contributed, undo it cleanly when superseded, replay the canonical version — the same mechanism handles a 200ms preconfirmation flip and a multi-block chain reorg with an identical code path.

  • Revision-tagged writes

    Every write is tagged with its revision and rolled back cleanly when superseded — nothing is ever overwritten blind.

  • Compressed bitset log index

    Roaring-style address/topic indexing for eth_getLogs-shaped queries — measured 17× less memory than a naive bitset at scale.

  • LSM-backed durable storage

    Pebble, not a B-tree — sustained high-write ingestion is exactly the workload LSM engines were built for.

  • Merkle Mountain Range over sealed data

    Sealing is gated behind finalized, never latest — the MMR is append-only and can't un-see a leaf a later reorg reaches back into.

  • Reorg vs. catch-up classification

    A genuine chain reorganization is counted separately from a pending-tier view simply not being final yet — two different events, two different signals.

Validated against the real chain

Run continuously, live against GIWA Sepolia

Two indexing strategies, side by side, against real testnet traffic — not a simulated feed.

Log lines observed
72,800+
Blocks sealed into the MMR
126
Panics / fatal errors
0
Memory vs. naive bitset
17× less

Found and fixed a real O(n²) growth bug mid-validation — a 500k-log indexing pass went from ~9s to ~150ms. The 17× memory gap kept widening the longer the run went, not a one-time benchmark number.

Live right now

Not a screenshot — an endpoint

The indexer below is polling GIWA Sepolia as you read this. It's the same code path described above, not a staged demo.

Checking live status…

Where we actually are

What we won't overclaim

  • Reorg repair is scoped to unfinalized blocks by design — MMR-sealed data is intentionally out of scope for automatic repair. The alternative is silent corruption, which is worse.
  • Public testnet RPC is genuinely rate-limited — a meaningful share of pending polls failed over our extended live run. Production needs dedicated or self-hosted node access.
  • The MMR root today is computed and published by the indexer itself. Anchoring it on-chain, independent of the indexer operator, is the next trust-minimization step.

Ask

  • Dedicated or self-hosted GIWA RPC access — our own measurements show the public endpoint isn't viable for sustained production use.
  • Introductions to early GIWA Wallet / dApp teams who'd be real first consumers of a Flashblocks-aware log API.