Skip to main content
Prácticas recomendadas y patrones para agentes que usan el SDK de Rust de Helius. Para ver la instalación y los primeros pasos, consulta la descripción general.

Recomendaciones para agentes

Usa get_transactions_for_address en lugar de una búsqueda de dos pasos

get_transactions_for_address combina la búsqueda de firmas y la obtención de transacciones en una sola llamada con filtrado del lado del servidor.

Usa send_smart_transaction para envíos estándar

Simula automáticamente, estima las unidades de cómputo, obtiene las tarifas de prioridad y confirma. No crees manualmente instrucciones ComputeBudget; el SDK las agrega automáticamente.

Usa Helius Sender para una latencia ultrabaja

Para transacciones sensibles al tiempo (arbitraje, sniping y liquidaciones), usa send_smart_transaction_with_sender. Enruta a través de la infraestructura multirregional de Helius y Jito.

Usa get_asset_batch para varios activos

Cuando obtengas más de un activo, agrúpalos en un lote. No llames a get_asset dentro de un bucle.

Usa webhooks en lugar de sondeo

No consultes get_transactions_for_address dentro de un bucle. Usa webhooks para las notificaciones entre servidores.

Paginación

Basada en tokens/cursores (métodos RPC V2)

Basada en páginas (API de DAS)

Filtro token_accounts

Al consultar get_transactions_for_address, el filtro token_accounts controla si se incluye la actividad de las cuentas de tokens:

changed_since_slot: obtención incremental de cuentas

changed_since_slot devuelve solo las cuentas modificadas después de un slot determinado. Es útil para flujos de trabajo de sincronización o indexación. Es compatible con get_program_accounts_v2, get_token_accounts_by_owner_v2, get_account_info, get_multiple_accounts, get_program_accounts y get_token_accounts_by_owner.

Errores comunes

  1. transaction_details: Some(TransactionDetails::Full) no es el valor predeterminado: de forma predeterminada, get_transactions_for_address solo devuelve firmas. Configura TransactionDetails::Full para obtener los datos completos de las transacciones.
  2. No agregues instrucciones ComputeBudget con send_smart_transaction: el SDK las agrega automáticamente. Si agregas tus propias instrucciones, se produce un error HeliusError::InvalidInput.
  3. Las tarifas de prioridad se expresan en microlamports por unidad de cómputo: no en lamports. Los valores de get_priority_fee_estimate ya están en la unidad correcta.
  4. La paginación de DAS comienza en 1: page: 1 es la primera página, no page: 0.
  5. async_connection() requiere new_async o HeliusBuilder: llamar a helius.async_connection() en un cliente creado con Helius::new() devuelve Err(HeliusError::ClientNotInitialized).
  6. get_asset devuelve Option<Asset>: una respuesta correcta aún puede ser None si el activo no existe. Maneja Option de forma explícita.
  7. Las propinas de Sender son obligatorias: send_smart_transaction_with_sender determina y agrega automáticamente las propinas. El mínimo es de 0.0002 SOL (modo dual) o 0.000005 SOL (solo SWQOS).
  8. Indicadores de características de TLS: el crate usa native-tls de forma predeterminada. Usa features = ["rustls"] (e default-features = false) para TLS implementado completamente en Rust cuando OpenSSL no esté disponible.
  9. Establece la versión máxima de transacción compatible en 1 al obtener transacciones. De lo contrario, get_transaction, get_block e get_transactions_for_address con TransactionDetails::Full fallan con el error -32015 en las transacciones v1. En las transacciones v1, la tarifa de prioridad es el transactionConfig.priorityFee del mensaje, un total expresado en lamports; no hay instrucciones ComputeBudget que examinar. Consulta Compatibilidad con transacciones v1.

Manejo de errores y reintentos

El SDK proporciona variantes de error con tipo mediante la enumeración HeliusError, por lo que puedes compararlas directamente:

Estrategia de reintentos

Reintenta cuando se produzcan RateLimitExceeded e InternalError con espera exponencial: