Cómo configurar un nodo Ethereum (guía 2026)

Un nodo Ethereum te da acceso directo a la red: tu propio endpoint JSON-RPC, sin rate limits, sin terceros leyendo tus consultas. Esta guía te lleva desde un servidor Ubuntu vacío hasta un nodo sincronizado con comandos listos para copiar y pegar — Geth como cliente de ejecución, Lighthouse como cliente de consenso, ambos gestionados por systemd. También cubre lo que la mayoría de tutoriales omiten: hardware en 2026, duración de la sincronización, coste mensual y cuándo te conviene más una API.

¿Qué es un nodo Ethereum?

Un nodo Ethereum es un ordenador que ejecuta software cliente de Ethereum, almacena una copia de la blockchain, comprueba cada bloque entrante contra las reglas del protocolo, y expone una interfaz JSON-RPC que wallets y aplicaciones usan para leer la cadena y enviar transacciones.

Desde el Merge de septiembre de 2022, “el cliente” es en realidad dos programas que deben ejecutarse en paralelo. El cliente de ejecución (Geth, Nethermind, Besu, Erigon o Reth) mantiene el state, ejecuta transacciones y responde a las llamadas JSON-RPC. El cliente de consenso (Lighthouse, Prysm, Teku, Nimbus o Lodestar) se encarga del proof of stake: sigue la beacon chain e indica al cliente de ejecución cuál es el bloque actual. Ambos se comunican a través de un puerto local autenticado (8551) y se identifican mutuamente con un secreto JWT compartido. Uno sin el otro no es un nodo funcional. Este detalle atrapa a la mayoría de operadores primerizos.

Existen tres perfiles de almacenamiento. Un nodo completo mantiene el state reciente y poda los datos antiguos; Geth necesita alrededor de 1,2–1,4 TB a mediados de 2026. Un nodo archive mantiene todo el state histórico — muy por encima de 10 TB en el layout clásico de Geth basado en hash, o aproximadamente 2–3 TB en clientes construidos para ello como Erigon y Reth. Un nodo ligero solo descarga headers; suena atractivo, pero casi ningún peer sirve a clientes ligeros en mainnet, así que no es una vía de acceso práctica.

Requisitos de un nodo Ethereum

Las cifras siguientes describen un nodo completo en 2026. Un nodo archive es un proyecto aparte, y un validador no añade hardware adicional a un buen nodo completo.

Dos filas merecen explicación.

El almacenamiento debe ser NVMe. La sincronización escribe pequeños fragmentos aleatorios a alta velocidad. Los SSD SATA se quedan regularmente atascados días enteros en la fase de state heal de Geth, y los volúmenes en la nube con IOPS por defecto a menudo nunca terminan. Un disco NVMe TLC con caché DRAM es la elección segura. Sobre capacidad: la base de datos de Geth ronda 1,2 TB y Lighthouse añade unos 200–250 GB, así que 2 TB funcionan hoy pero dejan poco margen — 4 TB te compran años.

El tráfico también se acumula. Un nodo mueve del orden de 1 TB al mes. Las conexiones domésticas lo gestionan bien; los planes VPS con límites de tráfico ajustados, no.

Linux, macOS y Windows funcionan todos. Cada comando de abajo asume Ubuntu 24.04, un estándar de servidor común.

Formas de ejecutar un nodo

No tienes que montarlo todo a mano. Cajas plug-and-play como DappNode y Avado son máquinas preconfiguradas con panel: comprar, conectar, seguir el asistente. Las placas ARM también funcionan — Ethereum on ARM publica imágenes listas para placas de la clase Raspberry Pi 5 con almacenamiento NVMe, baratas de ejecutar pero más lentas de sincronizar. Los launchers automatizan la vía manual: eth-docker (basado en Docker, requiere conocimientos de terminal), Stereum (instala clientes en un servidor remoto vía SSH con GUI), NiceNode (elige un cliente, arranca en pocos clics) y Sedge (un asistente CLI de Nethermind que genera una configuración Docker).

¿Nube o local? Un VPS está bien para desarrollo. Si la resistencia a la censura forma parte de tu motivación, ejecuta el nodo en hardware propio — un nodo dentro de una gran región cloud hereda la jurisdicción y los términos de servicio de ese proveedor.

El resto de esta guía trata la configuración manual. Es lo que más te enseña, y todo lo que aprendas se traslada a los launchers.

Paso a paso: Geth + Lighthouse en Ubuntu

1. Preparar el servidor

sudo apt update && sudo apt upgrade -y
sudo useradd --no-create-home --shell /usr/sbin/nologin geth
sudo useradd --no-create-home --shell /usr/sbin/nologin lighthouse
sudo mkdir -p /var/lib/geth /var/lib/lighthouse
sudo chown geth:geth /var/lib/geth
sudo chown lighthouse:lighthouse /var/lib/lighthouse

Abre los puertos peer-to-peer y nada más:

sudo ufw allow 30303 comment 'geth p2p'
sudo ufw allow 9000 comment 'lighthouse p2p'
sudo ufw allow 9001/udp comment 'lighthouse quic'

Los puertos 8545 (JSON-RPC) y 8551 (engine API) permanecen cerrados hacia el exterior; ambos se vinculan a localhost en las units de abajo.

2. Instalar Geth

sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt update
sudo apt install -y ethereum
geth version

3. Instalar Lighthouse

Lighthouse se distribuye como binario estático. Este snippet siempre obtiene la última release:

LH=$(curl -s https://api.github.com/repos/sigp/lighthouse/releases/latest | grep -m1 '"tag_name"' | cut -d '"' -f 4)
curl -LO "https://github.com/sigp/lighthouse/releases/download/${LH}/lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
tar xzf "lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
sudo mv lighthouse /usr/local/bin/
lighthouse --version

Verifica la descarga: cada página de release lista sumas de comprobación SHA-256 y una firma PGP; ejecuta sha256sum y compara, o importa la clave de Sigma Prime y usa gpg --verify. Los binarios sustituidos son un vector de ataque real, y la comprobación tarda un minuto.

4. Crear el secreto JWT

sudo mkdir -p /var/lib/jwt
openssl rand -hex 32 | sudo tee /var/lib/jwt/jwt.hex > /dev/null

Ambos clientes leen este archivo. Si ven secretos distintos, se niegan a comunicarse entre sí (ver solución de problemas).

5. Unit systemd para Geth

Crea /etc/systemd/system/geth.service:

[Unit]
Description=Geth execution client (mainnet)
After=network-online.target
Wants=network-online.target

[Service]
User=geth
Group=geth
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
ExecStart=/usr/bin/geth \
  --mainnet \
  --syncmode snap \
  --datadir /var/lib/geth \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3,txpool \
  --authrpc.addr 127.0.0.1 --authrpc.port 8551 \
  --authrpc.vhosts localhost \
  --authrpc.jwtsecret /var/lib/jwt/jwt.hex

[Install]
WantedBy=multi-user.target

TimeoutStopSec=600 importa: Geth escribe el state a disco al apagarse, y matarlo demasiado pronto es la forma clásica de corromper la base de datos.

6. Unit systemd para Lighthouse

Crea /etc/systemd/system/lighthouse.service:

[Unit]
Description=Lighthouse consensus client (mainnet)
After=network-online.target geth.service
Wants=network-online.target

[Service]
User=lighthouse
Group=lighthouse
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse bn \
  --network mainnet \
  --datadir /var/lib/lighthouse \
  --execution-endpoint http://127.0.0.1:8551 \
  --execution-jwt /var/lib/jwt/jwt.hex \
  --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \
  --http

[Install]
WantedBy=multi-user.target

La URL de checkpoint sync permite a Lighthouse arrancar desde un state finalizado reciente en lugar de reproducir la beacon chain desde el génesis: segundos en vez de días. Confías en ese endpoint para tu punto de partida; comprueba el state root frente a una segunda fuente como beaconstate.info si eso te preocupa.

7. Iniciar y observar

sudo systemctl daemon-reload
sudo systemctl enable --now geth lighthouse
journalctl -fu geth

Geth primero registra descargas de headers, luego un flujo interminable de líneas “Imported new chain segment”; Lighthouse informa de slots sincronizados en minutos. Comprobar el progreso de la sincronización:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://127.0.0.1:8545

{"result":false} significa completamente sincronizado. Mientras sincroniza, obtienes en su lugar un objeto de progreso.

¿Cuánto tarda la sincronización?

Ethereum no tiene snapshots oficiales de base de datos para descargar, y no los necesita — las rutas rápidas están integradas en los clientes.

Lighthouse con checkpoint sync alcanza la cabeza de la cadena en menos de un minuto y rellena los bloques históricos en segundo plano. Geth en modo snap sync (el predeterminado) descarga entre 800 GB y 1 TB de la red y luego reconstruye el state trie localmente. En el hardware recomendado, cuenta con uno a dos días; en hardware mínimo con un disco mediocre, de tres a cinco. El tramo final es la fase de “state heal”, y si se ejecuta durante días sin terminar, tu disco es demasiado lento — ver solución de problemas.

Tras la sincronización inicial, las cosas se calman. Desde la versión 1.13, Geth poda el state sobre la marcha (state storage basado en rutas), así que la base de datos ya no crece sin límite como advertían las guías antiguas. Geth 1.16 y posteriores también pueden eliminar el historial pre-Merge (--history.chain postmerge), lo que libera unos cientos de GB si el espacio aprieta.

Modos de sincronización: snap, full y archive

El flag --syncmode en la unit de Geth decide cuánto de la cadena verificas tú mismo y cuánto disco pagas por ello. Existen tres modos, y el correcto se deriva de las preguntas que el nodo debe responder.

Snap sync es el predeterminado y lo que usa esta guía. Geth descarga el state actual directamente de los peers, verifica los headers de bloque hasta el génesis, y luego repara el state trie. Resultado: un nodo completo operativo en uno o dos días y una base de datos de aproximadamente 1,2–1,4 TB a mediados de 2026, que crece a partir de ahí.

Full sync (--syncmode full) reejecuta cada transacción desde 2015 en lugar de descargar el state. El resultado final en disco es la misma base de datos podada, pero la sincronización se ejecuta durante semanas incluso en hardware potente. Se elige por una razón: te niegas a confiar en la descarga del state y quieres recalcular todo el historial en tu propia máquina. Es una postura de investigación, no una necesidad operativa.

El modo archive se sitúa en otro eje: --gcmode archive sobre un full sync mantiene cada state intermedio en lugar de podarlo. Solo un nodo archive responde a “cuál era este saldo en el bloque 15.000.000” o ejecuta trazas profundas sin recalcular, algo que necesitan indexadores, herramientas fiscales y plataformas de analítica. En el layout clásico de Geth basado en hash, eso cuesta muy por encima de 10 TB. Erigon y Reth almacenan el historial de forma diferente y sitúan los nodos archive en el rango de 2–3 TB a mediados de 2026, así que casi cualquier nuevo despliegue archive empieza con uno de los dos; el modo archive más reciente de Geth basado en rutas juega en la misma categoría de tamaño pero tiene menos recorrido en producción.

Para un backend de pagos, el snap sync responde a todo: saldos actuales, nuevos bloques, recibos de transacción. El archive es para el día en que necesites reconstruir el pasado.

Elección de cliente y diversidad

Geth más Lighthouse es una elección predeterminada sólida, y su popularidad es precisamente la trampa. El modelo de seguridad de Ethereum asume que ningún cliente controla demasiado de la red: un bug de consenso en un cliente con más de dos tercios de los validadores podría finalizar una cadena rota, el único fallo que el protocolo no puede deshacer limpiamente. Incluso una cuota de un tercio resulta incómoda, porque el fallo de ese único cliente detendría la finalidad.

Dónde está la red a mediados de 2026: Geth sigue liderando la capa de ejecución con una cuota que las mediciones sitúan entre un tercio y aproximadamente el 40 %, Nethermind le sigue en los veinte-treinta por ciento, Besu y Reth se mantienen en cifras bajas de dos dígitos, Erigon unos pocos puntos porcentuales. En el lado del consenso, Lighthouse ha crecido más allá de la línea de confort de un tercio según la mayoría de los recuentos, Prysm sigue en segundo lugar, luego Teku y Nimbus. La red se vuelve más segura cada vez que un operador elige un cliente minoritario, y el operador apenas renuncia a nada — todos los clientes de ejecución hablan el mismo JSON-RPC, todos los clientes de consenso la misma beacon API.

Finales de 2025 hizo el argumento concreto. Poco después de la actualización Fusaka, un bug en un cliente de consenso ampliamente usado forzó parches de emergencia, mientras los nodos en los demás clientes seguían validando sin interrupción. Los operadores en combinaciones minoritarias leyeron sobre ese incidente en lugar de tener que gestionarlo.

Para un primer nodo, la combinación de esta guía es adecuada. Para un segundo nodo, o cualquier uso profesional, elige una combinación minoritaria como Nethermind con Teku o Reth con Nimbus. La configuración de arriba se traslada casi uno a uno — cada combinación necesita el mismo secreto JWT y el mismo cableado de engine API; solo cambian los binarios, los flags y los directorios de datos.

Cuánto cuesta operar un nodo Ethereum

Sin precios exactos aquí; cambian cada mes y varían por país. En su lugar, el cálculo para hacerlo tú mismo.

Hardware propio: un mini-PC en la clase de requisitos (8 núcleos, 32 GB de RAM, 2–4 TB NVMe) es una compra única en el orden de unos pocos cientos de euros. El consumo eléctrico ronda los 30–60 W. El cálculo: 0,03–0,06 kW × 720 h ≈ 20–45 kWh al mes; multiplica por tu tarifa eléctrica. A 0,30 €/kWh eso son 6–13 € al mes además de la conexión a internet que ya pagas.

Servidor alquilado: los planes VPS con unos honestos 2 TB de NVMe son raros, así que en la práctica acabas en un servidor dedicado de nivel de entrada. Eso te sitúa en el rango bajo de las centenas de euros al mes — un orden de magnitud, no una cotización. Las instancias cloud con IOPS aprovisionadas cuestan notablemente más que la caja dedicada equivalente.

Tu tiempo: la primera configuración es una tarde con esta guía; después, actualizaciones de clientes y una mirada ocasional a los logs, cuenta una hora al mes. Si facturas tu tiempo, esa línea también pertenece al total.

Monitorización y comprobaciones de salud

Tres preguntas cubren la salud del nodo: ¿está el proceso en marcha?, ¿está sincronizado?, ¿tiene peers? systemd responde a la primera con systemctl is-active geth lighthouse. Las otras dos tienen endpoints en ambas capas:

# execution: peer count as hex; eth_syncing from step 7 covers sync state
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

# consensus: HTTP 200 = synced, 206 = still syncing
curl -s -o /dev/null -w '%{http_code}\n' \
  http://127.0.0.1:5052/eth/v1/node/health

La API REST de Lighthouse escucha en el puerto 5052 gracias al flag --http ya incluido en la unit. El endpoint /eth/v1/node/health codifica el estado de sincronización en el código de estado HTTP, lo que lo convierte en una sonda natural para scripts y balanceadores de carga; /eth/v1/node/syncing devuelve la distancia en slots si quieres el número. Un cron job que ejecute estas comprobaciones más df -h /var/lib/geth, avisando por correo ante anomalías, es una monitorización completa para un nodo personal.

Para dashboards, añade --metrics a Geth (endpoint de Prometheus en el puerto 6060) y --metrics a Lighthouse (puerto 5054), mantén ambos en localhost, e importa los dashboards de Grafana que ambos proyectos publican. Sea lo que sea que construyas, define dos alertas por encima de todas las demás: uso de disco por encima del 85 % y altura de bloque estancada durante diez minutos. Esas dos capturan casi cualquier fallo real antes de que lo noten tus usuarios.

Mantenimiento y actualizaciones

Las actualizaciones de clientes no son opcionales. Los hard forks requieren software nuevo, y un nodo en una versión antigua simplemente deja de seguir la cadena en el bloque del fork. Suscríbete a los feeds de releases de Geth y Lighthouse en GitHub y al blog de la Ethereum Foundation — la red actualmente lanza alrededor de una actualización mayor al año, con releases de clientes entre medias.

El procedimiento se mantiene breve. Geth desde el PPA se actualiza con sudo apt upgrade y sudo systemctl restart geth; confirma con geth version. Lighthouse es un binario único: repite la descarga del paso 3, reemplaza /usr/local/bin/lighthouse, reinicia la unit. Lee las notas de la release antes de reiniciar — los flags a veces cambian de nombre, y un flag renombrado en una unit systemd significa un servicio que se niega a arrancar a las 2 de la madrugada.

Presupuesta también el crecimiento del disco. Un nodo completo de Geth añade del orden de 10–15 GB por semana a mediados de 2026; Lighthouse crece más despacio. En un disco de 2 TB eso es una cuenta atrás que puedes reiniciar — la expiración del historial pre-Merge libera unos cientos de GB (ver solución de problemas), y un snap sync fresco reconstruye una base de datos totalmente compactada en uno o dos días. Con 4 TB, el crecimiento es un asunto anual en lugar de trimestral. El nodo no necesita estar en línea cada segundo, pero cuanto más tiempo esté fuera de línea, más tardará en ponerse al día.

Un nodo completo no es un validador

Los 32 ETH de los que todo el mundo ha oído hablar pertenecen al staking, no a la operación del nodo. El nodo de esta guía no necesita nada de ETH — valida bloques en el sentido de comprobarlos, lo cual cuesta hardware, no stake.

Un validador es un tercer programa junto a los dos clientes: mantiene claves de firma, produce attestations y bloques, y gana recompensas por ello, con una dirección de fee recipient configurada para los ingresos. Los 32 ETH son la garantía que el protocolo puede confiscar por mala conducta demostrable. El listón operativo también cambia — un nodo RPC que pasa un fin de semana fuera de línea simplemente se pone al día el lunes, mientras que un validador fuera de línea sufre pequeñas penalizaciones cada epoch.

Con menos de 32 ETH, el staking mancomunado es la entrada: Rocket Pool y protocolos similares permiten a operadores sin permiso ejecutar validadores con un bono más pequeño, y algunas configuraciones de pool se ejecutan exactamente sobre el nodo construido arriba. Un nodo completo normal no gana nada. Lo ejecutas por independencia y privacidad, para desarrollo, o como la base sobre la que se apoyará un validador más adelante.

Seguridad: la disposición de puertos es la política

Todo el modelo de seguridad de esta configuración es visible en las reglas de firewall del paso 1. Los puertos 30303 y 9000/9001 están abiertos porque el peer-to-peer necesita desconocidos; 8545 y 8551 se vinculan a 127.0.0.1 porque nada fuera de la máquina tiene nada que hacer ahí. El secreto JWT autentica la engine API en el 8551, pero trátalo como una segunda capa, no como una razón para exponer el puerto.

Un 8545 abierto es el error más grave, porque JSON-RPC no tiene ninguna autenticación. Los escáneres encuentran rápido los puertos RPC de Ethereum expuestos, y el daño va más allá del aprovechamiento gratuito: con los namespaces equivocados activados, extraños obtienen internals de depuración y contenido del mempool que nunca deberían ver. Mantén --http.api en los cuatro namespaces de la unit; admin, debug y personal deben quedar desactivados en cualquier máquina cuyo puerto RPC pudiera llegar a ser alcanzable.

Cuando otras máquinas necesitan legítimamente la RPC, haz un túnel en lugar de exponer: WireGuard o un túnel SSH para ti mismo, nginx o Caddy con TLS y una allowlist de IP para un equipo pequeño. Los clientes ya se ejecutan como usuarios de sistema sin login desde el paso 1, así que un proceso cliente comprometido no hereda ninguna cuenta de shell. Añade unattended-upgrades para los parches del sistema operativo, y la parte aburrida de la seguridad del servidor se cuida sola.

Solución de problemas

Lighthouse no puede alcanzar Geth (“Unable to connect to execution endpoint”)

O bien Geth está caído (systemctl status geth), o los secretos JWT difieren. Confirma que ambas units apuntan a la misma ruta jwt.hex. En caso de duda, regenera el secreto una vez y reinicia ambos servicios.

Geth se queda colgado en “State heal in progress” durante días

La fase de state heal persigue la cabeza de la cadena, y un disco con un rendimiento débil de escritura aleatoria nunca la alcanza. Haz un benchmark con fio; quieres decenas de miles de IOPS de 4k. Los SSD SATA y los volúmenes cloud por defecto son los culpables habituales. La solución es almacenamiento NVMe real — ningún flag rescata un disco lento.

El número de peers se queda en cero

El puerto 30303 (TCP y UDP) está bloqueado o no redirigido por tu NAT. Comprueba también el reloj del sistema: timedatectl debería mostrar sincronización NTP activa, porque un reloj desviado rompe los handshakes de peers en el lado de consenso.

El disco se llena

Encuentra primero el crecimiento: du -h --max-depth=2 /var/lib/geth. Un datadir creado antes de Geth 1.13 todavía usa el layout antiguo basado en hash; la solución limpia es un resync desde cero, tras el cual el state permanece podado automáticamente. Activar la expiración del historial pre-Merge libera unos cientos de GB más, y el ancient store puede trasladarse a un HDD barato con --datadir.ancient.

Geth informa de corrupción de base de datos tras un fallo

Un corte de luz, un kill -9 o un OOM kill en mitad de una escritura deja líneas de log sobre corrupción o datos faltantes en el siguiente arranque. A veces un reinicio lo cura; si el log se repite en bucle, deja de reparar y resincroniza en su lugar — aparta el datadir, empieza de cero, y el snap sync reconstruye todo en uno o dos días, normalmente más rápido que cualquier intento de reparación. La prevención ya está en la unit: TimeoutStopSec=600 le da a Geth tiempo para flushear, y un systemctl stop limpio es la única forma en que el proceso debería terminar alguna vez.

El OOM killer termina Geth

journalctl -k | grep -i oom confirma la sospecha. El --cache de Geth está en 4096 MB por defecto en mainnet, y el uso real supera ese ajuste durante la sincronización; añade Lighthouse y el sistema operativo, y una máquina de 16 GB se queda sin memoria. Configura --cache 2048 en máquinas pequeñas y mantén un archivo swap como colchón — lento es mejor que muerto, porque un Geth matado no flushea nada e invita al caso de corrupción de arriba.

¿Ejecutar tu propio nodo o usar una API?

Una comparación honesta, ya que Chaingateway vende la alternativa.

El nodo gana cuando necesitas JSON-RPC bruto, intensivo y sostenido: consultas archive, tracing, monitorización del mempool, o privacidad y resistencia a la censura máximas. Un nodo es un coste fijo con solicitudes ilimitadas — en la cifra baja de cientos de euros al mes de la sección de costes, supera a cualquier oferta de RPC medida por uso una vez que tu volumen es suficientemente alto. También es la mejor forma de entender cómo funciona realmente Ethereum.

La API gana cuando el nodo sería solo un medio para un fin, lo cual para la mayoría de negocios significa pagos. Un nodo sincronizado te da eth_sendRawTransaction y logs de eventos. No te da direcciones de depósito por cliente, notificaciones cuando llega un pago ERC-20, gestión de claves ni lógica de reintento. Eso es software de aplicación que tendrías que construir y operar encima, y normalmente cuesta más horas que el propio nodo.

La API de Ethereum de Chaingateway es exactamente esa capa que falta: crear e importar direcciones (POST /api/v2/ethereum/addresses/import), enviar tokens ERC-20 (POST /api/v2/ethereum/transactions/erc20), y recibir webhooks firmados con HMAC para los depósitos entrantes — las entregas fallidas aterrizan en una lista consultable (GET /api/v2/ethereum/webhooks/notifications/failed) y pueden reenviarse mediante el endpoint de reintento. El punto de equilibrio es aritmética: coste del servidor más tus horas de construcción y operación frente a un plan en /es/pricing/. Para flujos de pago, el lado API de esa desigualdad se mantiene más pequeño hasta bien pasada la escala de aficionado; para consumo de RPC bruto, el lado del nodo gana pronto. Empieza con el quickstart y la guía de webhooks — la prueba de 7 días sin KYC basta para probar un flujo de depósito de principio a fin (regístrate aquí).

¿Ejecutas también otras chains? Consulta las guías para BNB Smart Chain y TRON.