> ## Documentation Index
> Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Cómo indexar datos de Solana

> Aprende a crear y rellenar índices de Solana con datos históricos, y a mantenerlos actualizados.

## Descripción general

La blockchain de Solana almacena datos en un registro secuencial de solo anexado. Esto es excelente para la integridad de los datos y el rendimiento de las transacciones, pero tiene un costo considerable: hace que consultar [datos históricos](/docs/es/rpc/historical-data) sea muy ineficiente y excesivamente lento.

Las operaciones complejas suelen requerir filtrar, agregar o combinar datos de varias fuentes. En estos casos, hacer consultas directas a Solana no es práctico para la mayoría de las aplicaciones reales.

Para resolverlo, la mayoría de las empresas crean índices privados de los datos históricos de Solana.

Esta guía cubre el ciclo de vida completo: rellenar datos históricos con [`getTransactionsForAddress`](/docs/es/rpc/gettransactionsforaddress) y otros métodos RPC de archivo, elegir una base de datos y mantener actualizado el índice mediante transmisión en tiempo real.

## Cuándo usar esto

Crea un índice cuando:

* Tu producto necesita consultas rápidas y filtradas para las que las llamadas RPC directas son demasiado lentas (por ejemplo, las cuentas de tokens y los saldos de una billetera, o el historial completo de un par de trading)
* Necesitas filtrar, agregar o combinar datos on-chain, o combinarlos con datos off-chain (precios de CEX, KYC, etiquetas)
* Calculas elementos como PnL, análisis de titulares o historiales de ventas de NFT que requieren datos preprocesados y consultables
* Atiendes a muchos usuarios y no puedes permitirte la latencia por solicitud al consultar la cadena

Si solo necesitas datos estándar de billeteras o activos, una API administrada puede ser más sencilla que ejecutar tu propio índice. Consulta [Opciones complementarias](#próximos-pasos) a continuación.

## ¿Qué significa indexar datos de Solana?

La indexación es el proceso de consultar datos de la blockchain de Solana y almacenarlos en una base de datos de backend (por ejemplo, PostgreSQL o ClickHouse) que luego puede usarse para atender rápidamente las solicitudes de los clientes sin tener que consultar directamente la blockchain mediante [llamadas RPC de Solana](/docs/es/api-reference/rpc/http-methods).

Un indexador normalmente hace cuatro cosas:

1. **Rellena datos históricos:** usa [métodos RPC de archivo](/docs/es/rpc/guides/overview#datos-históricos-archivo) para consultar todos los datos históricos
2. **Transmite datos nuevos:** procesa bloques nuevos cuando la red los confirma
3. **Analiza y transforma datos:** extrae los datos relevantes de los bloques confirmados (por ejemplo, transacciones, cambios de estado, etc.)
4. **Organiza los datos en una base de datos:** actualiza el índice con los datos nuevos

### ¿Por qué la mayoría de las empresas crean índices de Solana?

Las empresas crean índices de Solana porque su negocio depende de ofrecer acceso rápido y en tiempo real a datos específicos de la blockchain que las llamadas RPC nativas no proporcionan (por ejemplo, el historial de ventas de NFT).

Las empresas también aprovechan los índices personalizados para combinar datos off-chain (por ejemplo, precios de exchanges centralizados, información KYC, etc.) con sus datos on-chain.

#### Ejemplo de una billetera

Por ejemplo, si una billetera de Solana necesita devolver rápidamente las cuentas de tokens y los saldos de un usuario, consultar Solana directamente con [`getTokenAccountsByOwner`](/docs/es/api-reference/rpc/http/gettokenaccountsbyowner) y [`getTokenAccountBalance`](/docs/es/api-reference/rpc/http/gettokenaccountbalance) es demasiado lento y podría hacer que su producto fuera inutilizable. En su lugar, las billeteras suelen mantener sus propios índices de direcciones de clientes, tokens y saldos de cuentas.

#### Ejemplo de trading

De manera similar, una empresa de trading de criptomonedas puede querer registrar toda la actividad de trading que ocurre en un par específico (por ejemplo, [SOL-USDC](https://orbmarkets.io/address/So11111111111111111111111111111111111111112/markets?sort_by=volume24h\&sort_type=desc)) o en un [mercado](https://orbmarkets.io/) específico para hacer backtesting de sus algoritmos de trading.

Consultar directamente la blockchain para obtener estos datos sería demasiado lento para cualquier análisis práctico de trading. En su lugar, los traders cuantitativos pueden optar por crear índices para el mercado SOL-USDC y mantenerlos actualizados con las operaciones más recientes mediante productos de transmisión en tiempo real como [LaserStream](/docs/es/laserstream).

#### Ejemplo de filtrado

Imagina que un usuario quiere filtrar transacciones según criterios específicos en su aplicación frontend (por ejemplo, por tipo de token, cantidad transferida, fecha o dirección de billetera).

Sin un indexador, tu aplicación tendría que examinar millones de transacciones distribuidas entre cientos de miles de bloques y comparar cada una con los criterios del filtro.

Este proceso es demasiado lento para las experiencias de usuario que requieren los productos modernos.

#### Ejemplo de PnL

Para calcular las ganancias y pérdidas (PnL) de un trader, tendrías que:

* Encontrar todas las transacciones asociadas con su billetera en un periodo determinado
* Filtrar las transacciones de swap y etiquetarlas como compras o ventas
* Determinar cuántas comisiones pagó el usuario durante cada swap
* Obtener los datos históricos del precio de cada token en el momento de cada operación
* Agregar el PnL de cada transacción para calcular el PnL total del trader

Calcular todo esto en tiempo real no es práctico y requiere una solución más rápida y escalable.

Con un índice, toda esta información ya está procesada y almacenada en una base de datos consultable. Así, calcular el PnL de un trader se convierte en una sola llamada API que se atiende al instante.

Veamos tres enfoques para rellenar un índice de Solana con datos históricos y mantenerlo actualizado.

## Paso 1: Obtén los datos históricos

El primer paso para crear un índice de Solana es obtener todos los datos históricos que te interesan.

Hay tres formas principales de hacerlo:

1. [**getTransactionsForAddress**](/docs/es/rpc/gettransactionsforaddress) (recomendado)
2. [**getSignaturesForAddress**](/docs/es/rpc/guides/getsignaturesforaddress) y [**getTransaction**](/docs/es/rpc/guides/gettransaction)
3. [**getBlock**](/docs/es/rpc/guides/getblock)

### Método 1: getTransactionsForAddress (recomendado)

El método RPC [`getTransactionsForAddress`](/docs/es/rpc/gettransactionsforaddress) te permite obtener todos los detalles de las transacciones de un segmento arbitrario de datos de la blockchain. Gracias a sus potentes capacidades de filtrado, no perderás tiempo recuperando datos que tu índice no necesita. Además, su función de búsqueda inversa te permite obtener las transacciones en orden cronológico.

#### Pasos para usar este método

* Determina el periodo del que necesitas datos y configura el filtro correspondiente
* Establece `transactionDetails` en `full` para obtener todos los detalles de las transacciones
* Configura el filtro `tokenAccounts` para incluir transacciones de cuentas de tokens asociadas si es necesario
* Pagina los resultados mediante `paginationToken`
* En cada iteración, extrae los datos que necesitas y almacénalos en tu base de datos

#### Ventajas de usar getTransactionsForAddress

Las principales ventajas de usar el [endpoint gTFA](/docs/es/api-reference/rpc/http/gettransactionsforaddress) son la velocidad y la simplicidad. Con filtros basados en slots y tiempo, compatibilidad con cuentas de tokens, búsqueda inversa y paginación, puedes obtener cualquier dato que quieras de cualquier momento del historial de Solana con una sola llamada, sin bucles complejos ni lógica de reintentos. A diferencia de [`getSignaturesForAddress`](/docs/es/rpc/guides/getsignaturesforaddress), también puede incluir transacciones que involucren cuentas de tokens asociadas propiedad de la dirección.

Si tu índice se centra específicamente en el movimiento de tokens y SOL nativo (pagos, libros contables, conciliación de saldos), [`getTransfersByAddress`](/docs/es/rpc/gettransfersbyaddress) devuelve filas de transferencias analizadas y listas para la conciliación en lugar de transacciones completas, lo que puede ahorrarte un paso de análisis.

### Método 2: getSignaturesForAddress y getTransaction

Antes del lanzamiento de gTFA, el enfoque estándar para consultar datos históricos consistía en recorrer recursivamente las firmas con [`getSignaturesForAddress`](/docs/es/rpc/guides/getsignaturesforaddress) (de la más nueva a la más antigua) y luego llamar a [`getTransaction`](/docs/es/rpc/guides/gettransaction) para extraer todos los detalles de las transacciones.

#### Pasos para usar este método

Estos son los pasos básicos para usar este método:

* Llama a `getSignaturesForAddress`
* Almacena la firma de la última transacción recibida de esta llamada
* Para la siguiente llamada a `getSignaturesForAddress`, establece el parámetro `before` en esta firma
* Repite esto en un bucle durante el tiempo que sea necesario
* Por cada firma de transacción recuperada de esta forma, llama a `getTransaction` para obtener todos los detalles de la transacción
* Inserta los datos relevantes en tu base de datos

#### Desventajas de este método

Lamentablemente, para usar este método necesitas:

* Comenzar por la transacción más reciente y avanzar hacia atrás
* Hacer una llamada RPC adicional por cada transacción
* Crear una cola segura para subprocesos que gestione el procesamiento simultáneo
* Crear lógica de reintentos y espera exponencial para evitar la pérdida de datos y las limitaciones de tasa
* No incluye transacciones que involucren cuentas de tokens asociadas propiedad de la dirección

Aunque este método funciona, es más complicado, menos flexible y consume muchos más [créditos](/docs/es/billing/credits). Para obtener el historial completo de una billetera, incluidas las cuentas de tokens, usa [`getTransactionsForAddress`](/docs/es/rpc/gettransactionsforaddress) en su lugar.

### Método 3: Usa getBlock

El método [`getBlock`](/docs/es/rpc/guides/getblock) es más eficaz cuando un porcentaje alto de las transacciones de tus bloques objetivo es relevante para tu análisis, como al indexar las transacciones de [programas de Solana de uso frecuente](/docs/es/orb/explore-programs), entre ellos Aggregator de DFlow, el programa Pump.fun o el programa Token de Solana.

#### Pasos para usar este método

El proceso básico para consultar datos históricos con `getBlock` incluye:

* Decide el intervalo de tiempo que quieres consultar
* Convierte este intervalo en números de slot
* Obtén secuencialmente los bloques correspondientes (hacia adelante o hacia atrás)
* En cada bloque, filtra las transacciones relevantes para tu índice
* Almacena la información relevante en tu índice

Para la mayoría de los casos de uso, este método desperdicia recursos por naturaleza, ya que recuperas todas las transacciones de un bloque cuando normalmente solo una pequeña parte será relevante para tu análisis.

Usa este método solo cuando examines las transacciones de programas de uso frecuente o cuando el filtrado por dirección no pueda capturar los datos que buscas.

## Paso 2: Sincroniza los datos de Solana con tu base de datos

Después de obtener los datos históricos, debes transformarlos y almacenarlos eficientemente en una base de datos.

**Debes adaptar la opción de almacenamiento a tu caso de uso específico**; no existe una solución universal. La base de datos adecuada depende del tamaño de tu conjunto de datos, los requisitos de latencia, los patrones de consulta y la experiencia del equipo.

### Opción 1: Bases de datos SQL

Para la mayoría de los casos de uso, se recomienda almacenar los datos de Solana en bases de datos relacionales como PostgreSQL. SQL es flexible, ampliamente utilizado y fácil de aprender. Las bases de datos relacionales modernas pueden escalar a más de 100 millones de filas y, al mismo tiempo, ofrecer las ventajas del cumplimiento de ACID, combinaciones complejas y potentes índices secundarios.

Usa **SQLite** para crear prototipos, desarrollar de forma local o cuando quieras una base de datos de un solo archivo sin configuración. Es ideal cuando tu conjunto de datos ocupa menos de unos pocos gigabytes.

Usa **PostgreSQL** para aplicaciones de producción que necesiten replicación de datos, acceso simultáneo desde varios clientes o funciones avanzadas como búsqueda de texto completo y operadores JSON.

Para la mayoría de los indexadores de Solana en producción, recomendamos PostgreSQL.

#### Ejemplo de implementación:

Como ejemplo, mostraremos cómo almacenar transferencias de tokens en una base de datos PostgreSQL.

Primero, crea una tabla:

```sql theme={"system"}
CREATE TABLE token_transfers (
    id BIGSERIAL PRIMARY KEY,
    slot BIGINT NOT NULL,
    timestamp TIMESTAMP NOT NULL,
    signature BYTEA NOT NULL UNIQUE,
    token_mint BYTEA NOT NULL,
    source_address BYTEA NOT NULL,
    destination_address BYTEA NOT NULL,
    amount BIGINT NOT NULL,
    decimals SMALLINT NOT NULL,
    program_id BYTEA
);
```

Después, agrega índices a las columnas que se consultan con frecuencia:

```sql theme={"system"}
CREATE INDEX idx_source_address ON token_transfers (source_address);
CREATE INDEX idx_destination_address ON token_transfers (destination_address);
CREATE INDEX idx_token_mint ON token_transfers (token_mint);
```

También puedes crear índices parciales si solo consultas con frecuencia un subconjunto de los datos.

Así puedes crear un índice solo para transferencias de alto valor:

```sql theme={"system"}
CREATE INDEX idx_large_transfers ON token_transfers(amount) WHERE amount > 1000000;
```

Cuando rellenes datos históricos, asegúrate de usar operaciones INSERT masivas y sentencias preparadas para optimizar la velocidad de escritura.

### Opción 2: Bases de datos columnares

Las bases de datos columnares están optimizadas para consultas analíticas, agregaciones y grandes volúmenes de datos de series temporales. Si necesitas indexar varios miles de millones de transacciones, las bases de datos columnares como ClickHouse o Cassandra son tu mejor opción.

Usa **ClickHouse** cuando necesites hacer consultas analíticas en tiempo real sobre grandes conjuntos de datos. Está optimizado para lecturas rápidas, agregaciones y análisis de series temporales.

Usa **Cassandra** cuando necesites un rendimiento de escritura extremadamente alto, un escalado horizontal sencillo y una alta tolerancia a fallos. Esto lo hace ideal para ingerir continuamente volúmenes masivos de datos de Solana.

#### Ejemplo de implementación:

Mostraremos cómo almacenar transferencias de tokens en una base de datos ClickHouse.

Para ello, crea una tabla que use el [motor de tablas MergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/mergetree). Está diseñado para altas tasas de ingesta, por lo que es ideal para la indexación.

Usa este comando:

```sql theme={"system"}
CREATE TABLE token_transfers (
    block_time DateTime,
    slot UInt64,
    signature FixedString(64),
    token_mint FixedString(32),
    source_address FixedString(32),
    destination_address FixedString(32),
    amount UInt64,
    decimals UInt8,
    program_id FixedString(32),
    date Date DEFAULT toDate(block_time)
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(date)
ORDER BY (token_mint, date)
SETTINGS index_granularity = 8192;
```

En esta configuración, `(token_mint, date)` se establece como clave primaria y clave de ordenamiento. ClickHouse ordenará los datos en el disco según tu clave de ordenamiento. Esto es óptimo para consultar una sola [acuñación de token](/docs/es/orb/explore-mint-addresses) y limitar la respuesta por intervalos de fechas.

Este es un ejemplo de consulta:

```sql theme={"system"}
SELECT date, signature, source_address, destination_address, amount
FROM token_transfers
WHERE token_mint = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v'
AND block_time BETWEEN '2025-01-01' AND '2025-01-31'
```

Las firmas y direcciones de las transacciones se almacenan mediante el formato de datos `FixedString(N)`, que almacena exactamente N bytes. ClickHouse comprime los datos automáticamente, lo que reduce los costos de almacenamiento entre 10 y 20 veces y mejora el rendimiento de las consultas.

Para optimizar el rendimiento de las consultas, usa vistas materializadas para calcular previamente las agregaciones comunes.

Por ejemplo, podrías calcular previamente el volumen diario de transferencias de tokens para usarlo en gráficas relacionadas con el volumen dentro de un panel.

### Opción 3: Lagos de datos

Los lagos de datos son ideales para almacenar cantidades masivas de datos sin procesar y procesados de la blockchain con fines de archivo a largo plazo y consultas analíticas.

Una implementación sencilla usa el formato de datos Parquet con Amazon Athena.

**Parquet** es un formato de archivos de datos orientado a columnas y diseñado para almacenar y recuperar datos eficientemente.

**Amazon Athena** es un servicio de consultas interactivas que te permite analizar datos almacenados en Amazon S3 mediante SQL estándar, sin tener que configurar infraestructura ni cargar los datos en una base de datos independiente.

<Warning>
  Solo recomendamos los lagos de datos si necesitas consultar grandes cantidades de datos no estructurados. Para la mayoría de los casos de uso, recomendamos una base de datos SQL (opción 1).
</Warning>

#### Ejemplo de implementación:

Queremos crear un archivo de transferencias de tokens y consultarlas.

Primero, debemos almacenarlas en S3: crea un bucket llamado `solana_index` y particiona los datos de transferencias de tokens por tiempo mediante esta estructura de claves:

```text theme={"system"}
s3://solana_index/token_transfers/YYYY/MM/DD/part-00000.parquet
```

Las transferencias de cada día se almacenan en un archivo Parquet independiente dentro de su carpeta de fecha correspondiente.

A medida que proceses las transferencias de Solana, conviértelas al formato Parquet y escríbelas en el objeto S3 correspondiente.

Después, [crea una tabla](https://docs.aws.amazon.com/athena/latest/ug/step-2-create-a-table.html) en Athena y conéctala al bucket. Esto te permite ejecutar consultas como la siguiente directamente sobre los datos del bucket:

```sql theme={"system"}
SELECT block_time, signature, source_address, destination_address, amount
FROM token_transfers
WHERE token_mint = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v' AND block_time BETWEEN TIMESTAMP '2025-01-01 00:00:00' AND TIMESTAMP '2025-01-31 23:59:59';
```

### Usa frameworks de indexación

Usa [**Carbon**](https://github.com/sevenlabs-hq/carbon) y frameworks similares para evitar escribir código repetitivo y configurar tu indexador en horas en lugar de días.

#### Funciones principales:

* Decodificadores prediseñados para programas populares (programa Token, protocolos DeFi, Metaplex)
* Fuentes de datos configurables (RPC, LaserStream, WebSockets mejorados)
* Compatibilidad integrada tanto con el relleno de datos históricos como con la transmisión en tiempo real
* Salidas hacia varios backends de almacenamiento (Postgres se incluye de forma predeterminada)
* Totalmente personalizable: puedes configurar tus propias fuentes de datos, decodificadores y destinos de datos

## **Paso 3: Mantén actualizado tu índice**

Después de rellenar los datos históricos, necesitas una solución de transmisión en tiempo real para mantener actualizado tu índice con la nueva actividad de la blockchain. De lo contrario, tu índice quedará desactualizado.

### Método 1: LaserStream (recomendado)

Recomendamos [LaserStream gRPC](/docs/es/laserstream/grpc) como opción predeterminada para todos los casos de uso de indexación en producción. Está diseñado específicamente para transmitir datos de manera confiable, con una latencia ultrabaja y tolerancia a fallos.

Algunas ventajas de usar LaserStream son:

* **Reproducción del historial de 24 horas**: si tu indexador se desconecta, LaserStream [reproduce automáticamente](/docs/es/laserstream/historical-replay) todas las transacciones omitidas desde el punto en el que se interrumpió
* **Reconexión automática**: nuestros [SDK de LaserStream](/docs/es/laserstream/clients) (Rust, Go, JS/TS) gestionan automáticamente las interrupciones de red
* **Conmutación por error de nodos**: tu conexión de LaserStream agrega simultáneamente datos de varios nodos para garantizar la máxima disponibilidad

Gracias a su combinación de velocidad y confiabilidad, LaserStream es ideal para aplicaciones en tiempo real como flujos de transacciones en vivo, paneles de trading y actualizaciones instantáneas de saldos.

#### Cómo usar LaserStream para la indexación

Usa el método [`subscribe`](/docs/es/api-reference/laserstream/grpc/subscribe) para suscribirte a eventos de la blockchain.

Estas son algunas prácticas recomendadas:

* **Limita tu filtro tanto como sea posible**: suscríbete únicamente a los datos que realmente necesites indexar para minimizar el consumo de ancho de banda y el procesamiento necesario.
* **Usa el nivel de confirmación `confirmed`**: esto equilibra la latencia y la finalidad. El nivel `processed` puede ser poco confiable, mientras que `finalized` agrega \~13 segundos de latencia
* **Establece `failed: false`**, a menos que necesites específicamente rastrear transacciones fallidas
* **Excluye las transacciones de votación** (`vote: false`), ya que no son relevantes para la indexación

Veamos un ejemplo.

Usa la siguiente suscripción para indexar todas las transferencias de tokens nuevas:

```ts theme={"system"}
{
  transactions: {
    "transfers": {
      vote: false,
      failed: false,
      accountsInclude: [
        '​​TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA',
        'TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb'
      ]
    }
  },
  commitment: CommitmentLevel.CONFIRMED,
  accounts: {},
  slots: {},
  transactionsStatus: {},
  blocks: {},
  blocksMeta: {},
  entry: {},
  accountsDataSlice: []
}
```

### Método 2: Usa LaserStream WebSocket

[LaserStream WebSocket](/docs/es/rpc/websocket), la variante WebSocket de LaserStream que incluye la extensión `transactionSubscribe` específica de Helius, se ejecuta en el mismo backend que LaserStream gRPC y es una alternativa rentable para transmitir datos en tiempo real cuando no necesitas gRPC.

Debes usar LaserStream WebSocket cuando:

* Tu aplicación puede tolerar pérdidas ocasionales de datos
* Las actualizaciones en tiempo real son importantes, pero no son esenciales
* Ya tienes infraestructura para detectar y rellenar los datos faltantes
* Las restricciones presupuestarias son importantes y necesitas minimizar los costos de transmisión
* Estás creando un prototipo o haciendo pruebas antes de adoptar LaserStream

Sin embargo, debes considerar algunas desventajas al elegir WebSockets:

* **Velocidad**: LaserStream WebSocket se ejecuta en el mismo backend que LaserStream gRPC, pero el protocolo WebSocket agrega el entramado JSON y una sobrecarga por mensaje. Para obtener la menor latencia posible con los mismos datos, usa [LaserStream gRPC](/docs/es/laserstream)
* **Confiabilidad**: no hay garantía de reproducción histórica. Si tu WebSocket se desconecta, tendrás que detectar y rellenar manualmente los intervalos faltantes mediante métodos RPC
* **Complejidad**: requiere infraestructura de supervisión adicional para garantizar que los datos estén completos

#### Cómo usar WebSockets para la indexación

Para actualizar un índice que almacena todas las transferencias de tokens, debes suscribirte a [`transactionSubscribe`](/docs/es/rpc/websocket/transaction-subscribe) de esta forma:

```ts theme={"system"}
{
  jsonrpc: '2.0',
  id: 1,
  method: 'transactionSubscribe',
  params: [
    {
      failed: false,
      accountInclude: [
        '​​TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA',
        'TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb'
      ]
    },
    {
      commitment: 'confirmed',
      encoding: 'jsonParsed',
      transactionDetails: 'full',
      maxSupportedTransactionVersion: 1
    }
  ]
}
```

## Comienza

Crear un índice sólido de Solana y rellenarlo con datos históricos requiere resolver tres desafíos principales:

1. Obtener datos históricos de manera eficiente
2. Transformar y almacenar datos para recuperarlos rápidamente
3. Mantener actualizados en tiempo real los datos indexados de Solana

Con nuestro nuevo [sistema de archivo de última generación](https://www.helius.dev/blog/introducing-gettransactionsforaddress), llamadas de archivo como [`getTransactionsForAddress`](/docs/es/rpc/gettransactionsforaddress) y soluciones de transmisión de datos líderes en la industria como LaserStream, crear un índice de Solana es más fácil y práctico que nunca.

## Opciones complementarias

Ejecutar tu propio índice te da control total, pero no siempre es necesario. Para las necesidades comunes, una API administrada de Helius puede sustituir o complementar un índice personalizado:

* **[DAS API](/docs/es/das-api)** — consulta NFT, tokens fungibles y activos comprimidos (metadatos, propiedad, saldos, por propietario, colección o creador) sin tener que indexar tú mismo los datos de los activos.
* **[Wallet API](/docs/es/wallet-api/overview)** — endpoints REST de alto nivel para consultar saldos, historiales, transferencias e identidades de billeteras, con valores en USD y una estructura de respuesta más sencilla.

Muchos equipos usan estas opciones para datos de portafolios, tokens y billeteras, y reservan un índice personalizado para los datos específicos que las API administradas no cubren.

## Próximos pasos

* [Regístrate para obtener una cuenta gratuita de Helius](https://www.helius.dev) y acceder a la API
* Lee la [guía de getTransactionsForAddress](/docs/es/rpc/gettransactionsforaddress) para rellenar datos históricos
* Explora la [descripción general de LaserStream](/docs/es/laserstream) para la transmisión en tiempo real
* Consulta la [descripción general de datos históricos](/docs/es/rpc/historical-data) para conocer todos los métodos de archivo