Un monedero deja de actualizarse, una aplicación se queda cargando y, en algún punto detrás, aparece un mensaje de límite de solicitudes excedido. No hay nada mal en tus claves, en tu saldo ni en la cadena. Un operador ha decidido que hiciste más preguntas en una ventana dada de las que permite tu plan, y rechaza todo lo que llega por encima de esa línea.
Qué informa realmente un error de límite
Un nodo RPC es una máquina que responde preguntas sobre la cadena en nombre de monederos y aplicaciones que no ejecutan el suyo. Quien opera esa máquina decide también cuántas preguntas puede hacer cada llamante, y hace valer la decisión rechazando todo lo que llega por encima del techo.
El RFC 6585 le da a ese rechazo un código de estado propio. Indica que el código 429 señala que el usuario ha enviado demasiadas solicitudes en un tiempo dado, y la propia sección llama a esa condición limitación de tasa; añade que las representaciones de la respuesta SHOULD incluir detalles que expliquen la condición y MAY incluir una cabecera Retry-After que indique cuánto esperar antes de una nueva solicitud.
De ahí se siguen dos cosas, y ambas se pasan por alto frente a una pantalla rota. El rechazo es sobre el llamante y no sobre la llamada, de modo que la solicitud idéntica habría funcionado un momento antes. Y el techo es la política de un operador, no una propiedad de la red, así que un segundo endpoint con otra política responde la misma solicitud sin queja.
El rechazo llega en más de un sobre
No toda llamada limitada vuelve como estado HTTP. JSON-RPC 2.0 lleva los errores dentro del cuerpo de la respuesta, y su especificación reserva los códigos del -32000 al -32099 para errores de servidor definidos por la implementación, que es donde puede alojarse el mensaje de limitación de un proveedor. La capa HTTP informa entonces de un éxito corriente.
| Dónde aterriza el rechazo | Qué aspecto tiene | Por qué se pasa por alto |
|---|---|---|
| Estado HTTP | Una respuesta 429, a veces con cabecera Retry-After | Invisible para un cliente que solo comprueba si la conexión funcionó |
| Cuerpo JSON-RPC | Un objeto error con un código de servidor definido por la implementación | El estado HTTP es un éxito, así que una comprobación de estado lo deja pasar |
| Redacción del cliente | Un saldo obsoleto, un indicador de carga o un fallo de red genérico | El texto está escrito para una persona y no nombra la capa que rechazó |
El diagnóstico empieza, por tanto, decidiendo cuál de los tres estás viendo. Un monedero que solo dice que no pudo conectar no prueba que no hubiera rechazo: prueba que el monedero no lo mostró.
Los límites no siempre se cuentan en solicitudes
Un techo expresado en llamadas por segundo es solo una de las formas que adopta un límite. Cuando un operador pondera las llamadas en vez de contarlas, un método pesado toma más del mismo presupuesto que uno ligero, y el presupuesto se vacía más rápido de lo que sugiere el número de llamadas.
Por eso «unas pocas llamadas» y «has excedido el límite» pueden describir con precisión el mismo minuto. Una consulta de registros sobre un rango amplio de bloques es una llamada por conteo y una retirada grande por peso. Leer la propia descripción del operador sobre qué cuenta su presupuesto lo resuelve antes que experimentar contra él.
De dónde sale realmente el volumen de solicitudes
El volumen se acumula, no se elige. Sale de bucles que nadie considera bucles: una pantalla que relee un saldo por temporizador, un componente que vuelve a pedir datos en cada renderizado, un vigilante en segundo plano que pregunta si una transacción ya entró.
La aritmética es implacable porque el intervalo es pequeño y la sesión larga. Una pantalla que refresca un saldo una vez por segundo produce por sí sola 43.200 llamadas en una sesión de doce horas, antes de contar cualquier acción del usuario. Frente a un plan que permite 100.000 llamadas al día, una sola pestaña abierta ya se ha llevado una parte grande de la jornada.
Los reintentos son la segunda fuente y multiplican la primera. Un cliente que responde a cada rechazo enviando de nuevo convierte un techo excedido en un flujo de ellos, y lo hace justo en el momento en que el operador menos quiere atenderlo.
Reintentar sin empeorar el rechazo
Reenviar con el mismo intervalo que causó el rechazo reproduce el rechazo. La corrección consiste en esperar más tras cada fallo en lugar de lo mismo, de modo que el intervalo crezca mientras el techo sigue donde está, y en detenerse tras un número acotado de intentos en lugar de continuar indefinidamente.
Añade azar a esa espera. Los clientes rechazados en el mismo instante que retroceden con la misma regla vuelven también en el mismo instante, así que la recuperación llega como otra ráfaga. Un desplazamiento aleatorio reparte la espera y rompe esa sincronía, y no cuesta nada.
Cuando hay una cabecera Retry-After, sustituye a la conjetura. El operador ya ha dicho cuánto esperar, y respetar ese valor es más rápido que un calendario inventado por ti y menos probable que se te compute en contra.
Recortar el número de solicitudes en vez de subir el techo
El agrupamiento es la primera reducción, y pertenece al protocolo y no a un proveedor concreto. JSON-RPC 2.0 establece que para enviar varios objetos Request a la vez el cliente MAY enviar un array lleno de objetos Request, y que el servidor debería responder con un array que contenga los objetos Response correspondientes tras procesar todos los objetos Request del lote. Plegar diez llamadas en un array convierte aquella sesión de 43.200 llamadas en 4.320 solicitudes.
El almacenamiento en caché es la segunda. Los valores que no pueden cambiar entre bloques no necesitan releerse entre bloques: los decimales de un token, la dirección de un contrato, el recibo de una transacción ya liquidada. Todo lo definitivo se puede guardar indefinidamente, y releerlo es gasto puro.
Las suscripciones son la tercera, cuando el endpoint las ofrece. El sondeo pregunta una y otra vez si algo ha cambiado; una suscripción pregunta una vez y recibe aviso cuando la respuesta cambia. Ambas llevan la misma información y cuestan cantidades de presupuesto muy distintas.
| Qué observas | Dónde está de verdad el techo | Qué lo cambia |
|---|---|---|
| Rechazos con uso ligero | Un presupuesto ponderado gastado por métodos pesados | Estrechar los rangos de bloques y dividir la consulta |
| Los rechazos se multiplican tras el primero | Los reintentos chocan contra el mismo techo | Retroceder con una espera creciente y aleatorizada |
| Rechazos desde una sola pestaña inactiva | Un bucle de sondeo con temporizador | Agrupar, cachear o suscribirse en vez de sondear |
| Rechazos solo en una red | Una política ligada a ese endpoint | Añadir un segundo endpoint para esa red |
Cuándo un reintento no es el movimiento seguro
Las lecturas y las escrituras no se repiten igual. Pedir un saldo dos veces cuesta una llamada extra y nada más. Enviar dos veces una transacción firmada es otro evento, y un rechazo en el endpoint no te dice de qué lado de esa frontera se detuvo la transacción.
Antes de reenviar, averigua si el primer intento llegó al mempool. Una transacción que la red ya sostiene y una transacción nueva que expresa la misma intención no son intercambiables, y tratarlas como una sola es el camino a una difusión duplicada. En Solana la referencia de frescura hace explícito el momento: un envío retrasado por un retroceso largo puede toparse con un blockhash vencido y necesitar reconstrucción en vez de reenvío.
La misma cautela vale para lo que tu cliente crea después. Un monedero cuyas lecturas están siendo rechazadas compara su propio recuento de transacciones enviadas contra una vista que no pudo refrescar, y esa es una de las rutas al mensaje nonce demasiado alto. El contador no se equivoca; falta la imagen contra la que se comparó.
Cambiar de endpoint repara una causa, no las demás
Si el techo es del operador, pasar a otro operador te sitúa bajo un techo distinto, y cambiar de endpoint es la reparación habitual para ese caso. Verifica el chain ID de la nueva entrada antes de enrutar nada por ella, y conserva la entrada que ya funcionaba. Lo que un cambio no alcanza es todo lo que la cadena ya registró: una transacción que se ejecutó y fue deshecha queda revertida, y cualquier endpoint honesto informa ese recibo igual.
Si el volumen es tuyo, el cambio compra tiempo y nada más. El mismo bucle de sondeo alcanza el techo del siguiente operador con el mismo calendario, y rotar entre endpoints para estar bajo varios techos a la vez esconde el bucle en lugar de arreglarlo.
Un tercer caso merece separarse de ambos. Un endpoint dedicado con tu propia clave no es simplemente una asignación mayor; también te aísla de otros llamantes que compartían uno público, de modo que un rechazo recibido después es de verdad tuyo y tuya la explicación.
En resumen
Un error de límite es una afirmación sobre cuánto pediste, no sobre si tenías derecho a pedir. Nombra un presupuesto, una ventana y un operador, y una respuesta útil empieza por identificar cuál de los tres está atando.
Lee el rechazo donde aterriza, respeta Retry-After cuando se ofrece y retrocede con una espera creciente y aleatorizada en lugar de reenviar con el calendario viejo. Después reduce el volumen en vez de perseguir un techo mayor: agrupa lo que puede viajar junto, cachea lo que no cambia y suscríbete en vez de sondear. Una asignación del doble de tamaño, consumida por el mismo bucle, se agota la misma tarde. Para seguir aprendiendo los fundamentos, sigue leyendo Bitbase Academy.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Cómo cambiar de endpoint RPC de forma segura
- Comisión máxima de transacción superada: qué significa ese aviso de la billetera
- ¿Qué es un código QR de cripto?
- Frase semilla y frase de contraseña: la diferencia y por qué importa
- ¿Qué es la firmeza en blockchain?
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en septiembre de 2026; consulta la información oficial más reciente.
Fuentes
[1] M. Nottingham y R. Fielding, Additional HTTP Status Codes, RFC 6585, IETF, abril de 2012 rfc-editor.org
[2] JSON-RPC 2.0 Specification, grupo de trabajo JSON-RPC, actualizado el 4 de enero de 2013 jsonrpc.org
