Logo
Nuevos usuarios de RPC: 35% de descuento el primer mesVer oferta
RPC Assistant

¿Cuándo se lanzó la mainnet de peaq y qué significa para tu desarrollo en 2025?

Resumen

La mainnet de peaq se lanzó en 2024, pasando la Layer 1 enfocada en DePIN de experimentos en testnet a una red de producción donde máquinas, vehículos y dispositivos IoT pueden registrar identidades y liquidar valor on-chain. Si estás construyendo sobre peaq ahora, la fecha de lanzamiento importa menos que la pregunta operativa que plantea: qué endpoint RPC y configuración de nodo mantendrán tu aplicación DePIN receptiva a medida que crece el tráfico de dispositivos.

Esta página cubre la línea de tiempo del lanzamiento, la relación con la testnet Agung, la configuración de la cadena que necesitas para conectarte y cómo decidir entre un endpoint RPC público y una infraestructura de nodo dedicada para cargas de trabajo en producción.

Qué cambió realmente el lanzamiento de la mainnet de peaq para los desarrolladores

La mainnet de peaq se lanzó en 2024, que es la respuesta corta que la mayoría busca. La respuesta larga es más útil si estás desplegando una aplicación DePIN: el lanzamiento llevó a peaq de un entorno exclusivo de testnet a una Layer 1 de producción donde las identidades de dispositivos, los pagos entre máquinas y las primitivas DePIN se ejecutan contra estado real.

Antes de la mainnet, la mayor parte del desarrollo en peaq ocurría en la testnet Agung. Agung sigue siendo útil para pruebas de contratos, experimentos con fondos de faucet y pipelines de CI, pero no es donde vive el tráfico de producción. Una vez lanzada la mainnet, la pregunta práctica para los equipos cambió de "¿puedo desplegar esto?" a "¿puede mi capa RPC seguir el ritmo del volumen de solicitudes a escala de dispositivos?".

Las cargas de trabajo DePIN son diferentes del tráfico típico de DeFi. Una flota de sensores, vehículos o robots puede emitir muchas lecturas y escrituras pequeñas de forma continua en lugar de ráfagas de transacciones grandes. Ese patrón ejerce una presión constante sobre tu endpoint, y es la razón principal por la que los desarrolladores de peaq deberían pensar en la infraestructura de nodos desde el principio y no después de su primer pico de tráfico.

Recomendación rápida: ¿endpoint público o nodo dedicado?

Usa esto como filtro inicial antes de leer el resto de la página.

Tu situaciónPunto de partida sensatoPor qué
Prototipado, hackathon o pruebas tempranas de contratosEndpoint RPC públicoRápido de configurar, sin infraestructura que gestionar, adecuado para bajo volumen de solicitudes
Trabajo en testnet en AgungEndpoint de testnet más faucetMantiene los experimentos aislados del estado de la mainnet
Aplicación DePIN en producción con tráfico constante de dispositivosNodo dedicado o un plan de proveedor dimensionado para tu carga de trabajoCapacidad predecible y menos sorpresas por recursos compartidos
Indexación, analítica o lecturas históricas intensivasNodo con capacidad de archivoLos nodos completos estándar pueden no retener el historial que necesitas
Monedero, panel o bot con muchas lecturas concurrentesProveedor con términos claros de tasa y concurrenciaNecesitas saber qué ocurre en tu pico, no solo en tu promedio

Si aún estás decidiendo, comienza con un endpoint público, mide tu mezcla real de solicitudes y luego pasa a infraestructura dedicada cuando tu tráfico sea lo suficientemente predecible para dimensionarlo. OnFinality ofrece tanto acceso a RPC API como nodos dedicados, para que puedas empezar pequeño y escalar la misma red sin cambiar el código de tu aplicación.

La línea de tiempo de la mainnet de peaq en contexto

El lanzamiento no ocurrió de forma aislada. Fue el final de un proceso de varias etapas que la mayoría de los equipos DePIN siguió de cerca.

  • Fase de testnet (Agung). Agung sirvió como campo de pruebas público para los módulos DePIN de peaq, las herramientas estilo parachain y el trabajo temprano de identidad de máquinas. Los equipos lo usaron para validar contratos e integraciones antes de que existiera la mainnet.
  • Lanzamiento de la mainnet (2024). La mainnet de peaq se abrió para despliegue en producción, dando a los proyectos DePIN una red activa para el registro de dispositivos, pagos máquina a máquina y economías de máquinas tokenizadas.
  • 2025 y más allá. El enfoque de la mayoría de los equipos se ha movido a escalar: más dispositivos, actualizaciones de estado más frecuentes y patrones de lectura más exigentes. Aquí es donde las elecciones de RPC y nodos empiezan a importar más que la propia fecha de lanzamiento.

Si estás leyendo esto en 2025 y te preguntas si peaq está "listo", el enfoque más útil es que la red está activa y la carga operativa se ha desplazado a tus elecciones de infraestructura.

Configuración de la cadena para conectarse a peaq

Los metadatos exactos de la cadena, como el chain ID, la moneda nativa y las URL del explorador, siempre deben confirmarse en la página de red de peaq antes de codificar nada, porque estos valores pueden actualizarse. El patrón a continuación muestra cómo se estructura una configuración típica de red estilo EVM; trátalo como una plantilla y completa los valores actuales desde la página de red.

{
  "chainName": "peaq",
  "rpcUrls": ["<tu endpoint de peaq en OnFinality>"],
  "nativeCurrency": {
    "name": "peaq",
    "symbol": "PEAQ",
    "decimals": 18
  },
  "blockExplorerUrls": ["<URL del explorador desde la página de red de peaq>"]
}

Para un monedero o un selector de red de dapp, los mismos valores van en la llamada wallet_addEthereumChain. Mantén el endpoint en una variable de entorno en lugar de confirmarlo, y usa un valor separado para testnet para que una compilación mal configurada no pueda escribir accidentalmente en la mainnet.

// Ejemplo: agregar peaq a un monedero EVM
await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0x...", // confirma el chain ID actual en la página de red de peaq
    chainName: "peaq",
    nativeCurrency: { name: "peaq", symbol: "PEAQ", decimals: 18 },
    rpcUrls: [process.env.PEAQ_RPC_URL],
    blockExplorerUrls: ["<URL del explorador>"]
  }]
});

Verificar tu endpoint antes de desplegar

Una fecha de lanzamiento no te dice si tu endpoint está saludable hoy. Ejecuta algunas comprobaciones básicas contra tu URL RPC elegida antes de dirigir tráfico de producción hacia ella.

# Confirmar que la cadena es accesible y verificar el chain ID reportado
curl -s -X POST "$PEAQ_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

# Verificar el último bloque para confirmar que el nodo está sincronizado
curl -s -X POST "$PEAQ_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Si eth_chainId devuelve un valor que no coincide con el chain ID actual de la mainnet de peaq, casi con certeza estás apuntando a una testnet o a una configuración obsoleta. Si eth_blockNumber va notablemente por detrás de un explorador público, el nodo puede estar sincronizándose o degradado. Vale la pena detectar ambos en staging en lugar de en producción.

Qué le hace el tráfico DePIN a un endpoint compartido

La mayoría de los consejos de solución de problemas de RPC asumen tráfico en ráfagas: un usuario abre un monedero, envía una transacción y se va. Las aplicaciones DePIN a menudo se comportan de manera diferente.

  • Lecturas continuas. Los paneles de dispositivos y las vistas de telemetría pueden consultar saldos, estado de dispositivos o eventos a intervalos fijos en muchos dispositivos.
  • Muchas escrituras pequeñas. Los pagos máquina a máquina y las actualizaciones de identidad pueden producir un alto número de transacciones pequeñas en lugar de unas pocas grandes.
  • Conexiones de larga duración. Si usas suscripciones WebSocket para eventos de dispositivos, la estabilidad de la conexión importa tanto como el rendimiento bruto.
  • Consultas históricas. Las auditorías, los cálculos de recompensas y la analítica pueden necesitar estado de bloques muy anteriores.

Un endpoint público compartido puede manejar versiones tempranas de todo esto. La fricción suele aparecer cuando el número de dispositivos crece y tu patrón de solicitudes se vuelve lo suficientemente predecible como para que ya no puedas tratarlo como "solo algo de tráfico". Ese es el punto en el que vale la pena evaluar capacidad dedicada, términos de tasa más claros y soporte de archivo o trace.

Elegir un proveedor de RPC para una aplicación peaq en producción

Cuando comparas proveedores para una carga de trabajo DePIN, la fecha de lanzamiento es irrelevante y los términos operativos lo son todo. Usa los criterios a continuación como una matriz de evaluación en lugar de una lista de características.

Área de evaluaciónQué preguntarPor qué importa para las aplicaciones DePIN en peaq
Ajuste a la carga de trabajo¿Puede el proveedor dimensionar la capacidad para tráfico constante de dispositivos, no solo ráfagas?Las lecturas continuas y las escrituras pequeñas son la norma, no la excepción
Cobertura de métodos¿Están disponibles los métodos de archivo, trace y suscripción si los necesitas?Las recompensas, la analítica y la lógica de dispositivos basada en eventos a menudo dependen de ellos
Soporte de transporte¿Admite HTTP y WebSocket donde tu aplicación necesita ambos?Los paneles y bots con frecuencia mezclan solicitud/respuesta y suscripciones
Failover¿Puedes configurar un endpoint secundario sin cambiar el código de la aplicación?Un único endpoint es un único punto de fallo para flotas de dispositivos
Observabilidad¿Puedes ver el volumen de solicitudes, errores y latencia por método?No puedes dimensionar una infraestructura que no puedes medir
Ruta de migración¿Puedes pasar de capacidad compartida a dedicada en la misma red?Evita una reescritura cuando crece el tráfico

OnFinality proporciona RPC de peaq a través de su servicio API y ofrece opciones de nodo dedicado cuando necesitas una capacidad más predecible. Puedes revisar los precios de RPC y la lista completa de redes RPC compatibles para ver cómo encaja peaq junto a las otras cadenas que ejecutas. Para un marco más amplio, la guía de selección de proveedor de RPC recorre los mismos criterios con más profundidad.

Puntos de control de migración: de testnet a mainnet

Si construiste en Agung antes de la mainnet y ahora estás pasando a producción, trabaja a través de estos puntos de control en orden.

  1. Separa tus entornos. Usa endpoints y variables de entorno distintos para Agung y la mainnet de peaq. Nunca dejes que una compilación de prueba herede una URL de mainnet.
  2. Vuelve a verificar la configuración de la cadena. El chain ID, la URL del explorador y los metadatos de la moneda deben volver a comprobarse en la página de red de peaq en lugar de copiarse de una configuración antigua de testnet.
  3. Vuelve a desplegar y verificar los contratos. Las direcciones no se trasladan entre redes. Confirma el despliegue y la inicialización en la mainnet.
  4. Vuelve a probar tus rutas de lectura. Los paneles, indexadores y bots que funcionaban en testnet pueden encontrar diferentes límites de tasa o historial en la mainnet.
  5. Agrega un endpoint de failover. Configura una URL RPC secundaria y prueba que tu aplicación se degrade correctamente si la primaria no está disponible.
  6. Instrumenta antes de escalar. Agrega monitoreo básico para el recuento de solicitudes, la tasa de errores y la latencia para que puedas dimensionar la capacidad con datos.

Errores comunes después del lanzamiento

Algunos errores aparecen repetidamente una vez que los equipos pasan a la mainnet.

  • Codificar un endpoint público. Los endpoints públicos están bien para desarrollo, pero no deberían ser la única URL en una configuración de producción.
  • Asumir que el historial de testnet existe en la mainnet. El estado y los registros de Agung no existen en la mainnet de peaq; cualquier lógica histórica debe reconstruirse a partir de datos de la mainnet.
  • Ignorar la reconexión de WebSocket. Las suscripciones de larga duración necesitan lógica de reconexión y resuscripción, o tu panel de dispositivos dejará de actualizarse silenciosamente.
  • Dimensionar para el promedio, no para el pico. Las flotas de dispositivos a menudo tienen ventanas de reporte sincronizadas. Dimensiona para el pico, no para la media.
  • Omitir la planificación de archivo. Si necesitas estado antiguo para recompensas o auditorías, confirma el soporte de archivo antes de comprometerte con un proveedor.

Puntos clave

  • La mainnet de peaq se lanzó en 2024, poniendo fin a la fase exclusiva de testnet y abriendo la red para despliegues DePIN en producción.
  • Agung sigue siendo útil para pruebas, pero la mainnet es donde pertenece el tráfico de dispositivos en producción.
  • La fecha de lanzamiento es un punto de partida; la decisión operativa que importa ahora es tu configuración de RPC y nodos.
  • Los endpoints públicos sirven para prototipar; el tráfico constante de DePIN normalmente justifica capacidad dedicada y términos de tasa más claros.
  • Verifica la configuración de la cadena en la página de red de peaq y mantén los endpoints de testnet y mainnet estrictamente separados.
  • OnFinality ofrece RPC de peaq a través de su servicio API y nodos dedicados, con detalles sobre precios de RPC y redes compatibles.

Preguntas frecuentes

¿Cuándo se lanzó la mainnet de peaq?

La mainnet de peaq se lanzó en 2024. Si necesitas la fecha exacta para una integración o auditoría específica, confírmala en los canales oficiales de peaq, ya que esta página se centra en lo que el lanzamiento significa para los desarrolladores en lugar de servir como un anuncio oficial.

¿Está disponible la mainnet de peaq en 2025?

Sí. La red está activa en 2025, y la mayoría de los equipos que construyen sobre peaq hoy se centran en escalar el tráfico de dispositivos en lugar de esperar el lanzamiento.

¿Cuál es la diferencia entre la mainnet de peaq y Agung?

Agung es la testnet de peaq, utilizada para desarrollo y pruebas con cuentas financiadas por faucet. La mainnet es la red de producción donde viven el valor real y las identidades de dispositivos reales. Tienen configuraciones de cadena separadas y estado separado.

¿Puedo usar un endpoint RPC público para una aplicación peaq en producción?

Puedes empezar allí, pero las cargas de trabajo DePIN en producción con tráfico constante de dispositivos normalmente se benefician de capacidad dedicada y términos más claros de tasa y concurrencia. Mide primero tu patrón de solicitudes y luego dimensiona en consecuencia.

¿OnFinality es compatible con peaq?

Sí. OnFinality proporciona acceso RPC a peaq a través de su servicio API y ofrece opciones de nodo dedicado. Consulta la página de red de peaq y los precios de RPC para obtener detalles actuales.

¿Qué debo verificar primero al conectarme a la mainnet de peaq?

Confirma el chain ID actual y el endpoint en la página de red de peaq, ejecuta una comprobación de eth_chainId y eth_blockNumber, y asegúrate de que tus configuraciones de testnet y mainnet no puedan confundirse.

Base de conocimiento RPC

Detalles RPC relacionados

Nunca te preocupes por la infraestructura nuevamente

OnFinality elimina la carga pesada de DevOps para que puedas construir de forma más inteligente y rápida.

Comenzar