Recomendaciones para agentes
Usa getTransactionsForAddress en lugar de una consulta en dos pasos
getTransactionsForAddress combina la búsqueda de firmas y la obtención de transacciones en una sola llamada con filtrado del lado del servidor. Admite rangos de tiempo/slots, filtrado de cuentas de tokens y paginación.
Usa sendSmartTransaction para envíos estándar
Simula automáticamente, estima las unidades de cómputo, obtiene las comisiones de prioridad y confirma. No crees manualmente instrucciones de ComputeBudget; el SDK las agrega de forma automática.
Usa Helius Sender para lograr una latencia ultrabaja
Para transacciones sensibles al tiempo (arbitraje, sniping y liquidaciones), usasendTransactionWithSender. Enruta las transacciones a través de la infraestructura multirregional de Helius y Jito.
Usa getAssetBatch para varios activos
Cuando obtengas más de un activo, agrúpalos en lotes. No llames a getAsset dentro de un bucle.
Usa webhooks o WebSockets en lugar de sondeos
No sondeesgetTransactionsForAddress dentro de un bucle. Usa webhooks para notificaciones entre servidores o WebSockets para transmitir datos en tiempo real del lado del cliente.
Paginación
El SDK usa distintas estrategias de paginación según el método.Basada en tokens/cursores (métodos RPC V2)
Basada en páginas (API de DAS)
Filtro tokenAccounts
Al consultar getTransactionsForAddress, el filtro tokenAccounts controla si se incluye la actividad de las cuentas de tokens:
changedSinceSlot: obtención incremental de cuentas
changedSinceSlot devuelve únicamente las cuentas modificadas después de un slot determinado. Resulta útil para flujos de trabajo de sincronización o indexación. Es compatible con getProgramAccountsV2, getTokenAccountsByOwnerV2, getAccountInfo, getMultipleAccounts, getProgramAccounts e getTokenAccountsByOwner.
Errores comunes
-
transactionDetails: "full"no es el valor predeterminado: de forma predeterminada,getTransactionsForAddresssolo devuelve firmas. ConfiguratransactionDetails: "full"para obtener los datos completos de las transacciones. -
No agregues instrucciones de ComputeBudget con
sendSmartTransaction: el SDK las agrega automáticamente. Si agregas tus propias instrucciones, se duplicarán y la transacción fallará. -
Las comisiones de prioridad se expresan en microlamports por unidad de cómputo: no en lamports. Los valores de
getPriorityFeeEstimateya están en la unidad correcta paraSetComputeUnitPrice. -
La paginación de DAS comienza en 1:
page: 1es la primera página, nopage: 0. -
blockTimeusa segundos Unix, no milisegundos: usaMath.floor(Date.now() / 1000)cuando filtres porblockTime. -
getAssetoculta los tokens fungibles de forma predeterminada: pasaoptions: { showFungible: true }para incluirlos. -
Los flujos de WebSocket necesitan limpieza: usa siempre una señal de AbortController y llama a
helius.ws.close()cuando termines para evitar fugas de conexiones. -
Configura
maxSupportedTransactionVersion: 1al obtener transacciones. De lo contrario,getTransaction,getBlockegetTransactionsForAddresscontransactionDetails: "full"fallan con el error-32015en las transacciones v1. En las transacciones v1, la comisión de prioridad esmessage.transactionConfig.priorityFee, un total expresado en lamports; no hay instrucciones de ComputeBudget que analizar. Consulta Compatibilidad con transacciones v1.
Manejo de errores y reintentos
El SDK lanza objetos nativosError con el código de estado HTTP integrado en la cadena del mensaje (por ejemplo, "API error (429): ..."). El objeto de error no tiene una propiedad .status, por lo que debes analizar el mensaje para detectar el estado.