Ejemplo de RPC de Base: Configuración de Endpoint, Llamadas curl y Depuración

La mayoría de los desarrolladores que buscan un ejemplo de RPC de Base quieren una cosa: un endpoint que funcione y una solicitud que puedan pegar en una terminal ahora mismo. Esta página te da eso, y luego explica la configuración y los modos de fallo que encontrarás una vez que el ejemplo pase a una aplicación real.

Base es una Layer 2 de OP Stack que se asienta en Ethereum, por lo que habla JSON-RPC estándar de EVM. Eso significa que cualquier herramienta de Ethereum funciona con ella, y los ejemplos a continuación deberían resultarte familiares si has usado RPC de Ethereum antes. Las diferencias que importan son el chain ID, el explorador y cómo manejas testnet versus mainnet.

Elige el endpoint de Base correcto antes de copiar nada

Base tiene dos redes a las que te conectarás durante el desarrollo, y confundirlas es la causa más común de la confusión "mi saldo es cero". Usa esta tabla para elegir.

Ambos endpoints anteriores son URLs RPC públicas de OnFinality y aceptan HTTP JSON-RPC. Si necesitas rendimiento constante, suscripciones WebSocket, datos de archivo o llamadas de trace, un endpoint público compartido no es la elección correcta a largo plazo. Compara precios de RPC y nodos dedicados cuando pases del prototipado, y consulta la página de red Base para los transportes compatibles actuales.

Una regla rápida: si se supone que una transacción cuesta dinero real o toca los fondos de un usuario, estás en mainnet (8453). Si estás iterando en la lógica de un contrato, casi con certeza estás en Sepolia (84532).

Configuración de la cadena Base para billeteras y frameworks

Las billeteras y la mayoría de los frameworks necesitan los mismos cuatro valores. Agrega Base manualmente en MetaMask, Rabby o cualquier billetera EVM con:

• Nombre de red: Base
• URL RPC: https://base.api.onfinality.io/public
• Chain ID: 8453
• Símbolo de moneda: ETH
• Explorador de bloques: https://basescan.org

Para Base Sepolia, cambia el nombre a Base Sepolia, la URL RPC a https://base-sepolia.api.onfinality.io/public, el chain ID a 84532 y el explorador a https://sepolia.basescan.org.

Si estás integrando esto en un frontend, define la cadena una vez y reutilízala. Una definición de cadena de viem se ve así:

import { defineChain } from "viem";

export const base = defineChain({
  id: 8453,
  name: "Base",
  nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
  rpcUrls: {
    default: { http: ["https://base.api.onfinality.io/public"] },
  },
  blockExplorers: {
    default: { name: "BaseScan", url: "https://basescan.org" },
  },
});

Mantén el chain ID y la URL RPC en un solo objeto de configuración en lugar de dispersar cadenas por los componentes. Cuando luego cambies a un endpoint privado o dedicado, cambias una línea en lugar de buscar por todo el código.

Un ejemplo mínimo de curl que puedes ejecutar ahora

La verificación más rápida es una sola llamada JSON-RPC sobre HTTP. Esto le pide a Base el último número de bloque:

curl -s https://base.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_blockNumber",
    "params": [],
    "id": 1
  }'

La respuesta es una cadena hexadecimal, no un número decimal:

{ "jsonrpc": "2.0", "id": 1, "result": "0x13a2f1c" }

Conviértelo con parseInt(result, 16). Si el número sube entre llamadas, tu endpoint está activo y sincronizado. Si devuelve un objeto de error, salta a la sección de depuración a continuación.

Dos llamadas más que vale la pena guardar en tus notas. eth_chainId confirma que estás hablando con la red que crees:

curl -s https://base.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

Debería devolver 0x2105, que es 8453 en hexadecimal. Y eth_getBalance verifica una dirección:

curl -s https://base.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","latest"],"id":1}'

Reemplaza la dirección cero con una real. El resultado está en wei, así que divide por 1e18 para ETH.

Leer la respuesta sin adivinar

Una respuesta JSON-RPC siempre tiene una de dos formas. O tiene un campo result, o tiene un objeto error con un code y un message. No hay un tercer caso, y no hay un código de estado HTTP que te cuente toda la historia, porque muchos errores de RPC aún devuelven HTTP 200.

Por eso "devolvió 200 pero mi aplicación falló" es tan común. Tu cliente debe verificar el campo error, no solo el estado HTTP. La mayoría de las bibliotecas maduras como viem y ethers hacen esto por ti, pero las llamadas fetch hechas a mano a menudo no.

Cuando obtengas un error, lee primero el code:

• -32601 significa que el método no existe o no está habilitado en ese endpoint.
• -32602 significa que tus parámetros están mal formados, a menudo falta el prefijo 0x o hay un número incorrecto de argumentos.
• -32000 es un error genérico del lado del servidor y a menudo apunta a una solicitud que el nodo no pudo servir, como un rango demasiado grande.
• Un 429 o un mensaje sobre límites de tasa significa que estás enviando demasiadas solicitudes para el nivel de endpoint en el que estás.

Ruta de depuración: del síntoma a la solución

Cuando algo se rompe, trabaja con esta tabla en lugar de cambiar el código al azar.

El caso de eth_getLogs merece una nota. Los endpoints públicos a menudo limitan el rango de bloques que puedes consultar en una sola llamada. Si estás indexando eventos, pagina a través del historial en ventanas más pequeñas en lugar de pedir millones de bloques a la vez. Esto es un problema de forma de solicitud, no un problema de red, y es una de las razones más frecuentes por las que un indexador de Base parece "dejar de funcionar".

Cuando el ejemplo público no es suficiente

Un endpoint público es perfecto para el ejemplo anterior y para desarrollo ligero. No está diseñado para tráfico de producción con carga en ráfagas, suscripciones WebSocket o consultas pesadas de archivo. Señales de que lo has superado:

• Ves respuestas 429 intermitentes durante el uso pico.
• Necesitas eth_subscribe sobre WebSocket para eventos en tiempo real.
• Necesitas estado histórico o datos de trace que los endpoints compartidos no exponen.
• Quieres capacidad predecible en lugar de compartir mejor esfuerzo.

En ese punto, la decisión es entre una API RPC gestionada y un nodo dedicado. OnFinality ofrece ambas: un servicio de API RPC gestionado para equipos que quieren un endpoint sin ejecutar infraestructura, y nodos dedicados para cargas de trabajo que necesitan capacidad aislada. Si estás evaluando proveedores en general, la guía de selección de proveedores repasa los criterios. Para Base específicamente, comienza desde la página de red Base y la página de Base Sepolia, luego revisa precios y la lista completa de redes compatibles.

Probar en Base Sepolia sin perder tiempo

Sepolia es donde ocurrirá la mayor parte de tu ejecución de ejemplos, así que configúralo correctamente una vez. El chain ID es 84532, el explorador es sepolia.basescan.org y el endpoint es https://base-sepolia.api.onfinality.io/public. Necesitarás ETH de prueba para desplegar contratos o enviar transacciones; obtenlo de un faucet de Base Sepolia, luego confirma que llegó con eth_getBalance antes de depurar cualquier otra cosa.

Una trampa común: un contrato desplegado en Sepolia tiene una dirección diferente que el mismo contrato en mainnet. Nunca copies una dirección entre los dos. Mantén variables de entorno separadas para cada red y cárgalas por chain ID para que una dirección de testnet nunca pueda filtrarse a una transacción de mainnet.

Puntos clave

• Base mainnet usa chain ID 8453; Base Sepolia usa 84532. Confirma con eth_chainId antes de depurar cualquier otra cosa.
• Los endpoints públicos de OnFinality son https://base.api.onfinality.io/public y https://base-sepolia.api.onfinality.io/public.
• Los errores JSON-RPC pueden llegar con un estado HTTP 200, así que siempre verifica el cuerpo de la respuesta en busca de un campo error.
• Los límites de rango de bloques de eth_getLogs y las respuestas 429 son las dos razones más comunes por las que un ejemplo que funciona se rompe bajo carga.
• Pasa a un endpoint privado o dedicado cuando necesites suscripciones WebSocket, datos de archivo o trace, o capacidad predecible.

Preguntas frecuentes

¿Cuál es la URL RPC de Base? Para mainnet, el endpoint público de OnFinality es https://base.api.onfinality.io/public. Para testnet, usa https://base-sepolia.api.onfinality.io/public. Las aplicaciones en producción normalmente usan un endpoint privado o dedicado en su lugar.

¿Cuál es el chain ID de Base? Base mainnet es 8453 (hex 0x2105). Base Sepolia es 84532.

¿Por qué mi llamada RPC de Base devuelve un error con HTTP 200? JSON-RPC reporta errores a nivel de aplicación dentro del cuerpo de la respuesta, no a través del estado HTTP. Verifica el objeto error y su campo code.

¿Puedo usar WebSocket con Base? El soporte de WebSocket depende del nivel del endpoint. Los endpoints HTTP públicos son para llamadas básicas; consulta la página de red Base para los transportes compatibles y considera un nodo dedicado para suscripciones.

¿Necesito un nodo de archivo para Base? Solo si consultas estado histórico o rangos amplios de logs. Las consultas estándar de bloques recientes funcionan en un endpoint normal. El acceso a archivo y trace suele ser una característica de nodo dedicado.

¿Cómo evito los límites de tasa en RPC de Base? Agrupa y cachea cuando sea posible, evita bucles de sondeo ajustados y pasa a un endpoint privado o dedicado cuando tu volumen de solicitudes crezca. Consulta precios de RPC para los niveles.