Indexer & GraphQL API

Overview

A custom indexer is available for integration, providing GraphQL access to indexed on-chain data from Solana RWA programs. The indexer continuously monitors and indexes transactions from all Solana RWA programs, making historical and real-time data easily accessible through a unified GraphQL API.

Key Features

• Multi-Program Indexing: Indexes all Solana RWA programs
• Token-2022 Activity: Indexes Token-2022 mint and burn instructions for registered tokens
• GraphQL API: Unified GraphQL endpoint with interactive GraphiQL IDE
• Chronological Ordering: All queries return data in chronological order optimized for cap table building

Authentication

The GraphQL endpoint uses API key authentication via the X-API-Key header. The key is available upon request.

Using the API Key

Include the API key in all GraphQL requests using the X-API-Key header:

curl -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "{ __typename }"}' \
  https://solana-rwa-indexer.upside.gg/graphql

Endpoints

Production

• GraphQL Endpoint: https://solana-rwa-indexer.upside.gg/graphql
• GraphiQL IDE: https://solana-rwa-indexer.upside.gg/graphiql
• Health Check: https://solana-rwa-indexer.upside.gg/health (no authentication required)

Staging

• GraphQL Endpoint: https://solana-rwa-indexer-staging.upside.gg/graphql
• GraphiQL IDE: https://solana-rwa-indexer-staging.upside.gg/graphiql
• Health Check: https://solana-rwa-indexer-staging.upside.gg/health (no authentication required)

Example Request

# Production
curl -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "{ __typename }"}' \
  https://solana-rwa-indexer.upside.gg/graphql

# Staging
curl -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "{ __typename }"}' \
  https://solana-rwa-indexer-staging.upside.gg/graphql

GraphQL Schema for Cap Table Activity

The indexer provides a unified tokenActivity query that combines all token movements (mints, burns, and transfers) in a single sorted list, designed for cap table building.

TokenActivity Query

query TokenActivity($mint: String!, $limit: Int!, $offset: Int!, $order: SortOrder) {
  tokenActivity(mint: $mint, limit: $limit, offset: $offset, order: $order) {
    activityType          # "mint", "burn", or "transfer"
    signature
    instructionIndex
    slot
    slotTimestamp
    stackHeight
    amount
    mint
    createdAt

    # Authority fields (check activityType to know which are populated)
    destinationAuthority  # For mints and transfers
    targetAuthority       # For burns
    sourceAuthority       # For transfers
  }
}

Query Parameters

Parameter	Type	Required	Description
mint	String!	Yes	Token mint address to query
limit	Int	No	Maximum number of results (default: 100)
offset	Int	No	Number of results to skip (default: 0)
order	SortOrder	No	Sort order: ASC (oldest first, default) or DESC (newest first)

TokenActivity Response Fields

Field	Type	Description
activityType	String	Type of activity: "mint", "burn", or "transfer"
signature	String	Transaction signature (part of unique event ID)
instructionIndex	Int	Index of instruction within transaction (part of unique event ID)
slot	String	Solana slot number
slotTimestamp	Int	Unix timestamp of the slot
stackHeight	Int	Call stack height (1 = outer, >=2 = inner/CPI) (part of unique event ID)
amount	String	Token amount (as decimal string)
mint	String	Token mint address
createdAt	String	Timestamp when record was indexed
destinationAuthority	String?	Destination authority (populated for mints and transfers)
targetAuthority	String?	Target authority (populated for burns)
sourceAuthority	String?	Source authority (populated for transfers)

note

The unique identifier for each event is a composite key constructed from signature, stackHeight, and instructionIndex. Use this combination to uniquely identify and deduplicate events.

SortOrder Enum

enum SortOrder {
  ASC   # Ascending order (oldest first) - default
  DESC  # Descending order (newest first)
}

Example Queries

Cap Table Activity Query

Get all token movements for a specific mint in chronological order:

query CapTableActivity {
  tokenActivity(
    mint: "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"
    limit: 1000
    offset: 0
    order: ASC  # Optional: ASC (default) or DESC
  ) {
    activityType
    signature
    instructionIndex
    slot
    slotTimestamp
    stackHeight
    amount
    mint
    createdAt

    # Authority fields (check activityType to know which are populated)
    destinationAuthority  # For mints and transfers
    targetAuthority       # For burns
    sourceAuthority       # For transfers
  }
}

Using for Cap Table Building

1. Query returns all activities in chronological order (oldest first by default, use order: DESC for newest first)
2. Unique Event Identification: Each event should be uniquely identified using a composite key constructed from signature, stackHeight, and instructionIndex. This ensures proper deduplication when processing events across multiple queries or pagination.
3. Check activityType to determine how to process each event:
   • "mint": Add amount to destinationAuthority balance
   • "burn": Subtract amount from targetAuthority balance
   • "transfer": Move amount from sourceAuthority to destinationAuthority
4. Process sequentially to build current state

Pagination Example

For large datasets, use pagination:

query CapTableActivityPaginated {
  tokenActivity(
    mint: "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"
    limit: 100
    offset: 0
    order: ASC
  ) {
    activityType
    signature
    slot
    amount
    destinationAuthority
    targetAuthority
    sourceAuthority
  }
}

Fetch subsequent pages by incrementing offset:

• Page 1: offset: 0, limit: 100
• Page 2: offset: 100, limit: 100
• Page 3: offset: 200, limit: 100

Data Ordering

All parsed instruction queries are ordered by slot ASC, stack_height ASC, instruction_index ASC:

• Chronological order from oldest to newest (ascending slot)
• Outer instructions before inner ones (ascending stack_height)
• Sequential order within a transaction (ascending instruction_index)

This ordering is optimized for cap table building and state reconstruction, where you need to process events in the exact order they occurred on-chain.