Transaction Indexing Guide

How Indexing Works

brale.network uses a multi-source reconciliation model. Each transaction can be observed from multiple sources (transfer type RPCs, webhooks, the Brale API) and merged into a single canonical record with a confidence score.

Three ways transactions enter the index

1. Live ingest — Alchemy Custom Webhooks push ERC-20 Transfer events on Base, Polygon, Celo, and Ethereum to our Cloudflare Worker as soon as each block is indexed; Solana (Helius) is polled every 15 minutes pending Helius webhook cutover.
2. Historical backfill — Bulk scripts page through the full transaction history for each contract/mint and ingest everything. Checkpointed so restarts resume safely.
3. On-demand fetch — Visit any transaction URL with a hash. If we don't have it yet, the page fetches it live from the transfer type RPC, ingests it through the reconciler, and renders it immediately.

All three paths go through the same reconciler, which deduplicates on a fingerprint of chain_id:tx_hash:log_index and merges observations by priority.

Transaction URL Structure

Transactions can be loaded using two URL formats:

Full context URL (preferred)

• transferType — the transfer type slug (e.g. base, solana)
• valueType — the value type symbol, lowercase (e.g. sbc, cfusd)
• hash — the on-chain transaction hash or signature

The full context URL narrows the database lookup and renders transfer type / value type context in the page header. Use this format when linking from applications.

Hash-only URL (fallback)

Works for any transaction hash. The explorer will look it up across all transfer types and value types. If the transaction isn't in the database yet, it will attempt on-demand fetching — detecting the transfer type from the hash format (0x-prefixed = EVM, base58 = Solana).

Currently Indexed Pairs

These are the transfer type + value type pairs actively being indexed, along with their on-chain contract addresses and current transaction counts.

Live Transaction Examples

Click any link below to see a real indexed transaction for each pair. These are the most recent transactions in the database.

On-Demand Transaction Fetching

You can link to any transaction hash for a tracked value type — even one that hasn't been backfilled yet. The explorer will:

1. Check the local database for the transaction
2. If not found, detect the transfer type from the hash format
3. Fetch the transaction from the transfer type RPC (Alchemy for Base, Helius for Solana)
4. Parse and ingest it through the reconciler
5. Render the page with live data

This means you can paste any transaction hash from BaseScan or Solscan into the URL and it will work — as long as it involves a tracked value type contract.

Try it: paste a hash from an external explorer

Tracked Contract Addresses

These are the token contracts and mint addresses that brale.network indexes. Transactions involving other contracts are not tracked.

Linking From Your Application

To link to a transaction from your app, wallet, or dashboard, construct the URL as:

Valid transferType values: base, solana, canton, polygon, celo, ethereum
Valid valueType values: usdc, sbc, cfusd, usdglo, hsusd, createx, mxne, rusd

Agent-Friendly Data (Content Negotiation)

Every public page on brale.network supports Accept: text/markdown content negotiation. When an AI agent, LLM, or automated tool sends a request with this header, the same canonical URL returns a structured markdown document instead of HTML.

This means agents can read brale.network data without scraping HTML or parsing the DOM — they get clean, well-structured markdown with the same data the HTML page shows.

How It Works

1. Send a request to any brale.network page URL
2. Include the header Accept: text/markdown
3. Receive a markdown response with Content-Type: text/markdown; charset=utf-8
4. The response includes an x-markdown-tokens header estimating token count

Supported Pages

Examples

Response Headers

The Vary: Accept header ensures caches serve the correct version. The x-markdown-tokens header provides an approximate token count (characters / 4) so agents can estimate context window usage before reading the body.