Concepts

Bitcoin metaprotocols

Metaprotocols are standards built on top of Bitcoin that add new functionality without modifying the base protocol. They encode data within Bitcoin transactions that can be interpreted to represent assets, ownership, or other information.

How metaprotocols work

Bitcoin transactions contain space for arbitrary data through:

• OP_RETURN outputs - Up to 80 bytes of data
• Witness data - Segregated witness fields
• Inscription envelopes - Ordinals protocol format

The Bitcoin Indexer parses these data fields to extract metaprotocol information:

Bitcoin Transaction → Parser → Structured Data → API

Supported metaprotocols

Ordinals Digital artifacts inscribed on individual satoshis:

• Inscriptions (images, text, code)
• Unique satoshi tracking
• Collection support

Runes Fungible token protocol optimized for efficiency:

• UTXO-based balances
• Efficient state transitions
• No off-chain data

BRC-20 Token standard using JSON inscriptions:

• Deploy, mint, transfer operations
• Balance tracking
• Marketplace integration

Indexing architecture

The Bitcoin Indexer uses a multi-stage pipeline to process blockchain data:

Processing stages

1. 1Block ingestion - Receives blocks via ZeroMQ from Bitcoin Core
2. 2Reorg detection - Compares block hashes to detect chain reorganizations
3. 3Parallel parsing - Processes metaprotocols concurrently
4. 4State management - Updates balances and ownership
5. 5API serving - Provides REST endpoints for queries

Reorg handling

Bitcoin reorganizations occur when the network switches to a longer valid chain, invalidating previously confirmed blocks.

Automatic reorg handling

The indexer maintains internal state to handle reorgs seamlessly:

{
  "block_height": 820000,
  "block_hash": "00000000000000000002ee82e2e0e648d90536e32d214a4917cbec0bbd3e3e91",
  "indexed_at": "2023-12-15T10:30:00Z",
  "metaprotocol_states": {
    "ordinals": { "inscriptions": 45234123 },
    "runes": { "etched": 15234 },
    "brc20": { "tokens": 8923 }
  }
}

When a reorg is detected:

1. 1Rollback to the common ancestor block
2. 2Mark affected data as pending
3. 3Re-process blocks on the new chain
4. 4Update API responses atomically

Performance optimization

The indexer uses several techniques for optimal performance:

Parallel processing

Each metaprotocol parser runs in its own thread:

• Independent parsing pipelines
• Shared block data access
• Concurrent database writes

Archive bootstrapping

Instead of indexing from genesis:

1. 1Download pre-indexed archives from Hiro
2. 2Verify archive integrity
3. 3Resume indexing from archive height
4. 4Reduces sync time from weeks to hours

Database optimization

PostgreSQL configuration for high throughput:

• Bulk inserts with COPY
• Partial indexes on hot paths
• Table partitioning by block height
• Async commit for non-critical data

API design patterns

REST endpoints follow consistent patterns across metaprotocols:

Resource endpoints

GET /ordinals/v1/inscriptions/{id}
GET /runes/v1/runes/{name}  
GET /brc-20/v1/tokens/{ticker}

List endpoints with pagination

GET /ordinals/v1/inscriptions?limit=20&offset=0
GET /runes/v1/activity?limit=50&offset=100

Address-specific queries

GET /ordinals/v1/inscriptions?address={address}
GET /runes/v1/balances/{address}

Next steps