Block explorer integration.

01 electrs, Esplora and the explorer

A gccd node holds the chain, but its JSON-RPC is not the right tool for “show me every transaction that touched this address” — that is an indexer’s job. In the GCC stack the indexer is electrs: it reads blocks from gccd, builds address and history indexes, and exposes two things on top:

• an Electrum protocol endpoint (TCP), which the wallet talks to; and
• an Esplora-compatible REST API (HTTP), which the explorer and any integrator talks to.

The public explorer at explorer.getcrypto.co.in is the Esplora frontend pointed at this REST API. The split is worth holding in your head: the wallet uses the Electrum path, the explorer (and your integration code) uses the REST path. They read the same index from the same electrs; they are just two different protocols over it.

Because GCC is a Litecoin/Bitcoin-format chain, electrs indexes it byte-for-byte the way it would index Litecoin, and the Esplora REST shape is identical to the public Esplora/mempool.space API you may already know. Everything below is that standard surface — with GCC’s gcc1… addresses and 60-second blocks.

02 The REST endpoints you will use

The REST API is served under a base URL. For the public chain that is https://explorer.getcrypto.co.in/api; for your own stack it is wherever you front electrs (commonly http://127.0.0.1:3002 behind nginx). The endpoints an integrator reaches for:

Chain tip. Height as plain text, hash as plain text:

A block by hash. /block/:hash returns the decoded header and block-level metadata:

A transaction by txid. /tx/:txid returns the decoded transaction with its inputs, outputs and confirmation status:

value and fee are in the smallest unit (1 GCC = 100,000,000 base units), so 250000000 is 2.5 GCC.

Fee estimates. /fee-estimates returns a map of confirmation target (in blocks) to fee rate in sat/vB:

On a quiet testnet these sit at the floor; the shape is what matters for wiring a wallet’s fee selector.

03 Address queries and the HRP

Address endpoints are how you turn a gcc1… address into a balance and a history. /address/:addr gives the aggregate, /address/:addr/txs gives the transaction list:

The current confirmed balance is funded_txo_sum − spent_txo_sum in base units — here 5000000000 − 250000000 = 4750000000, i.e. 47.5 GCC.

04 Point your own explorer at your electrs

When you run your own copy of the stack, you stand up the same three layers and wire them in order: gccd → electrs → explorer.

1. Run electrs against your node. Point it at the node’s RPC (loopback) and P2P/cookie as your build expects, and give it the chain’s network so it indexes with the right magic and address HRP. It exposes the Electrum TCP port (the wallet’s path) and the Esplora REST/HTTP port (the explorer’s path).
2. Front the REST port behind nginx so the explorer fetches over HTTP(S). In the reference stack the Esplora REST sits on an internal port and nginx serves it under /api on the explorer host.
3. Configure the explorer with two values: the REST base URL (your /api) and the Electrum endpoint it should hand to wallets. Set the chain’s network/HRP so it renders gcc1… addresses and the correct ticker.

The single most common bring-up mistake is a mismatched network between electrs and the node: if electrs is told “litecoin mainnet” but the node is your GCC fork, it will index with the wrong magic and HRP and the explorer will show nothing useful. Match electrs’s chain configuration to the node it indexes, and the address/REST examples above will resolve against your own data.