Come configurare un nodo Ethereum (guida 2026)

Un nodo Ethereum ti dà accesso diretto alla rete: il tuo endpoint JSON-RPC personale, senza rate limit, senza terze parti che leggono le tue query. Questa guida ti porta da un server Ubuntu vuoto a un nodo sincronizzato con comandi pronti da copiare e incollare — Geth come client di esecuzione, Lighthouse come client di consenso, entrambi gestiti da systemd. Copre anche ciò che la maggior parte dei tutorial omette: l’hardware nel 2026, la durata della sincronizzazione, il costo mensile e quando conviene di più un’API.

Cos’è un nodo Ethereum?

Un nodo Ethereum è un computer che esegue software client Ethereum, memorizza una copia della blockchain, verifica ogni blocco in entrata rispetto alle regole del protocollo, ed espone un’interfaccia JSON-RPC che wallet e applicazioni usano per leggere la chain e inviare transazioni.

Dal Merge di settembre 2022, “il client” è in realtà due programmi che devono girare fianco a fianco. Il client di esecuzione (Geth, Nethermind, Besu, Erigon o Reth) mantiene lo state, esegue le transazioni e risponde alle chiamate JSON-RPC. Il client di consenso (Lighthouse, Prysm, Teku, Nimbus o Lodestar) si occupa del proof of stake: segue la beacon chain e comunica al client di esecuzione quale blocco è la testa attuale. I due comunicano tramite una porta locale autenticata (8551) e si identificano a vicenda con un segreto JWT condiviso. Uno senza l’altro non è un nodo funzionante. Questo dettaglio inganna la maggior parte degli operatori alle prime armi.

Esistono tre profili di storage. Un nodo completo mantiene lo state recente e fa il pruning dei dati vecchi; Geth richiede circa 1,2–1,4 TB a metà 2026. Un nodo archive mantiene ogni state storico — ben oltre 10 TB sul layout classico di Geth basato su hash, o circa 2–3 TB su client costruiti apposta come Erigon e Reth. Un nodo light scarica solo gli header; sembra attraente, ma quasi nessun peer serve i client light su mainnet, quindi non è un percorso di accesso praticabile.

Requisiti per un nodo Ethereum

I numeri qui sotto descrivono un nodo completo nel 2026. Un nodo archive è un progetto a sé, e un validatore non aggiunge hardware extra a un solido nodo completo.

Due righe meritano una spiegazione.

Lo storage deve essere NVMe. La sincronizzazione scrive piccoli blocchi casuali ad alta velocità. Gli SSD SATA restano regolarmente bloccati per giorni nella fase di state heal di Geth, e i volumi cloud con IOPS predefiniti spesso non finiscono mai. Un disco NVMe TLC con cache DRAM è la scelta sicura. Sulla capacità: il database di Geth si aggira intorno a 1,2 TB e Lighthouse aggiunge circa 200–250 GB, quindi 2 TB funzionano oggi ma lasciano poco margine — 4 TB ti comprano anni.

Anche il traffico si accumula. Un nodo muove nell’ordine di 1 TB al mese. Le connessioni domestiche lo gestiscono bene; i piani VPS con limiti di traffico stretti no.

Linux, macOS e Windows funzionano tutti. Ogni comando qui sotto presuppone Ubuntu 24.04, uno standard server comune.

Modi per gestire un nodo

Non devi assemblare tutto a mano. Box plug-and-play come DappNode e Avado sono macchine preconfigurate con dashboard: comprare, collegare, seguire la procedura guidata. Anche le schede ARM funzionano — Ethereum on ARM pubblica immagini pronte per schede della classe Raspberry Pi 5 con storage NVMe, economiche da gestire ma più lente da sincronizzare. I launcher automatizzano il percorso manuale: eth-docker (basato su Docker, richiede conoscenze da terminale), Stereum (installa client su un server remoto via SSH con GUI), NiceNode (scegli un client, avvia in pochi click) e Sedge (una procedura guidata CLI di Nethermind che genera una configurazione Docker).

Cloud o locale? Un VPS va bene per lo sviluppo. Se la resistenza alla censura fa parte della tua motivazione, gestisci il nodo su hardware di tua proprietà — un nodo dentro una grande regione cloud eredita la giurisdizione e i termini di servizio di quel provider.

Il resto di questa guida tratta il setup manuale. È ciò che insegna di più, e tutto ciò che impari si trasferisce ai launcher.

Passo dopo passo: Geth + Lighthouse su Ubuntu

1. Preparare il server

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

Apri le porte peer-to-peer e nient’altro:

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

Le porte 8545 (JSON-RPC) e 8551 (engine API) restano chiuse verso l’esterno; entrambe si legano a localhost nelle unit qui sotto.

2. Installare Geth

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

3. Installare Lighthouse

Lighthouse viene distribuito come binario statico. Questo snippet recupera sempre l’ultima 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 il download: ogni pagina di release elenca checksum SHA-256 e una firma PGP; esegui sha256sum e confronta, oppure importa la chiave di Sigma Prime e usa gpg --verify. I binari scambiati sono un vettore di attacco reale, e il controllo richiede un minuto.

4. Creare il segreto JWT

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

Entrambi i client leggono questo file. Se vedono segreti diversi, si rifiutano di comunicare tra loro (vedi risoluzione dei problemi).

5. Unit systemd per 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 è importante: Geth scrive lo state su disco allo spegnimento, e ucciderlo troppo presto è il modo classico per corrompere il database.

6. Unit systemd per 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

L’URL di checkpoint sync permette a Lighthouse di partire da uno state finalizzato recente invece di rigiocare la beacon chain dal genesis: secondi invece di giorni. Ti fidi di quell’endpoint per il tuo punto di partenza; verifica lo state root rispetto a una seconda fonte come beaconstate.info se questo ti preoccupa.

7. Avviare e osservare

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

Geth registra prima download di header, poi un flusso infinito di righe “Imported new chain segment”; Lighthouse riporta slot sincronizzati entro pochi minuti. Verificare il progresso della sincronizzazione:

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 sincronizzato. Durante la sincronizzazione, ottieni invece un oggetto di progresso.

Quanto dura la sincronizzazione?

Ethereum non ha snapshot ufficiali di database da scaricare, e non ne ha bisogno — i percorsi veloci sono integrati nei client.

Lighthouse con checkpoint sync raggiunge la testa della chain in meno di un minuto e recupera i blocchi storici in background. Geth in modalità snap sync (predefinita) scarica circa 800 GB–1 TB dalla rete e poi ricostruisce localmente lo state trie. Sull’hardware consigliato, prevedi uno o due giorni; su hardware minimo con un disco mediocre, da tre a cinque. La fase finale è lo “state heal”, e se dura giorni senza terminare, il tuo disco è troppo lento — vedi risoluzione dei problemi.

Dopo la sincronizzazione iniziale, le cose si calmano. Dalla versione 1.13, Geth fa il pruning dello state al volo (state storage basato sui path), quindi il database non cresce più senza limiti come avvertivano le guide più datate. Geth 1.16 e successivi possono anche eliminare la storia pre-Merge (--history.chain postmerge), il che libera qualche centinaio di GB se lo spazio si fa stretto.

Modalità di sincronizzazione: snap, full e archive

Il flag --syncmode nell’unit di Geth decide quanta parte della chain verifichi tu stesso e quanto storage paghi per farlo. Esistono tre modalità, e quella giusta segue dalle domande a cui il nodo deve rispondere.

Snap sync è la modalità predefinita e quella usata da questa guida. Geth scarica lo state attuale direttamente dai peer, verifica gli header dei blocchi fino al genesis, e poi ripara lo state trie. Risultato: un nodo completo operativo in uno o due giorni e un database di circa 1,2–1,4 TB a metà 2026, che cresce da lì.

Il full sync (--syncmode full) riesegue ogni transazione dal 2015 invece di scaricare lo state. Il risultato finale su disco è lo stesso database sottoposto a pruning, ma la sincronizzazione dura settimane anche su hardware potente. Lo si sceglie per un motivo: ci si rifiuta di fidarsi del download dello state e si vuole ricalcolare l’intera storia sulla propria macchina. È una posizione di ricerca, non una necessità operativa.

La modalità archive si colloca su un altro asse: --gcmode archive sopra un full sync mantiene ogni state intermedio invece di eseguirne il pruning. Solo un nodo archive risponde a “quale era questo saldo al blocco 15.000.000” o esegue trace profondi senza ricalcolo, di cui hanno bisogno indexer, strumenti fiscali e piattaforme di analytics. Sul layout classico di Geth basato su hash, questo costa ben oltre 10 TB. Erigon e Reth memorizzano la storia in modo diverso e collocano i nodi archive nell’intervallo di 2–3 TB a metà 2026, quindi quasi ogni nuovo deployment archive parte con uno dei due; la modalità archive più recente di Geth basata sui path gioca nella stessa classe di dimensione ma ha meno esperienza in produzione.

Per un backend di pagamenti, lo snap sync risponde a tutto: saldi attuali, nuovi blocchi, ricevute di transazione. L’archive serve per il giorno in cui devi ricostruire il passato.

Scelta del client e diversità

Geth più Lighthouse è una scelta predefinita solida, e proprio la sua popolarità è il problema. Il modello di sicurezza di Ethereum presuppone che nessun client controlli troppo della rete: un bug di consenso in un client con più di due terzi dei validatori potrebbe finalizzare una chain rotta, l’unico fallimento che il protocollo non può annullare in modo pulito. Anche una quota di un terzo è scomoda, perché il fallimento di quel solo client fermerebbe la finalità.

Dove si trova la rete a metà 2026: Geth guida ancora il livello di esecuzione con una quota che le misurazioni collocano tra un terzo e circa il 40%, Nethermind segue tra il venti e il trenta per cento, Besu e Reth si mantengono su cifre basse a due cifre, Erigon qualche punto percentuale. Sul lato consenso, Lighthouse è cresciuto oltre la linea di comfort di un terzo secondo la maggior parte dei conteggi, Prysm segue al secondo posto, poi Teku e Nimbus. La rete diventa più sicura ogni volta che un operatore sceglie un client di minoranza, e l’operatore rinuncia a poco — tutti i client di esecuzione parlano lo stesso JSON-RPC, tutti i client di consenso la stessa beacon API.

La fine del 2025 ha reso l’argomento concreto. Poco dopo l’upgrade Fusaka, un bug in un client di consenso ampiamente usato ha costretto a patch di emergenza, mentre i nodi sugli altri client continuavano a validare senza interruzioni. Gli operatori su combinazioni di minoranza hanno letto di quell’incidente invece di doverlo gestire.

Per un primo nodo, la combinazione di questa guida va bene. Per un secondo nodo, o qualsiasi uso professionale, scegli una combinazione di minoranza come Nethermind con Teku o Reth con Nimbus. Il setup sopra si trasferisce quasi uno a uno — ogni combinazione richiede lo stesso segreto JWT e lo stesso cablaggio engine API; cambiano solo i binari, i flag e le directory dei dati.

Quanto costa gestire un nodo Ethereum

Nessun prezzo esatto qui; cambiano ogni mese e variano per paese. Al suo posto, il calcolo per farlo da soli.

Hardware proprio: un mini-PC nella classe dei requisiti (8 core, 32 GB RAM, 2–4 TB NVMe) è un acquisto una tantum nell’ordine di poche centinaia di euro. Il consumo energetico si aggira intorno ai 30–60 W. Il calcolo: 0,03–0,06 kW × 720 h ≈ 20–45 kWh al mese; moltiplica per la tua tariffa elettrica. A 0,30 €/kWh sono 6–13 € al mese in aggiunta alla connessione internet che già paghi.

Server in affitto: i piani VPS con onesti 2 TB di NVMe sono rari, quindi in pratica finisci su un server dedicato entry-level. Questo ti colloca nella fascia bassa delle centinaia di euro al mese — un ordine di grandezza, non un preventivo. Le istanze cloud con IOPS provisionate costano notevolmente di più rispetto al box dedicato equivalente.

Il tuo tempo: il primo setup richiede un pomeriggio con questa guida; in seguito, aggiornamenti dei client e un’occhiata occasionale ai log, conta un’ora al mese. Se fatturi il tuo tempo, anche questa voce appartiene al totale.

Monitoraggio e controlli di salute

Tre domande coprono la salute del nodo: il processo è in esecuzione, è sincronizzato, ha peer. systemd risponde alla prima con systemctl is-active geth lighthouse. Le altre due hanno endpoint su entrambi i livelli:

# 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

L’API REST di Lighthouse ascolta sulla porta 5052 grazie al flag --http già presente nell’unit. L’endpoint /eth/v1/node/health codifica lo state di sincronizzazione nel codice di stato HTTP, il che lo rende una sonda naturale per script e load balancer; /eth/v1/node/syncing restituisce la distanza in slot se vuoi il numero. Un cron job che esegue questi controlli più df -h /var/lib/geth, inviando un’email in caso di anomalie, è un monitoraggio completo per un nodo personale.

Per le dashboard, aggiungi --metrics a Geth (endpoint Prometheus sulla porta 6060) e --metrics a Lighthouse (porta 5054), mantieni entrambi su localhost, e importa le dashboard Grafana che entrambi i progetti pubblicano. Qualunque cosa tu costruisca, imposta due alert prima di tutti gli altri: utilizzo del disco sopra l’85% e altezza del blocco ferma per dieci minuti. Questi due catturano quasi ogni fallimento reale prima che lo notino i tuoi utenti.

Manutenzione e aggiornamenti

Gli aggiornamenti dei client non sono opzionali. Gli hard fork richiedono nuovo software, e un nodo su una versione vecchia smette semplicemente di seguire la chain al blocco del fork. Iscriviti ai feed delle release di Geth e Lighthouse su GitHub e al blog della Ethereum Foundation — la rete attualmente rilascia circa un aggiornamento maggiore all’anno, con release dei client nel mezzo.

La procedura resta breve. Geth dal PPA si aggiorna con sudo apt upgrade e sudo systemctl restart geth; conferma con geth version. Lighthouse è un singolo binario: ripeti il download dal passo 3, sostituisci /usr/local/bin/lighthouse, riavvia l’unit. Leggi le note di rilascio prima di riavviare — i flag vengono occasionalmente rinominati, e un flag rinominato in un’unit systemd significa un servizio che si rifiuta di avviarsi alle 2 di notte.

Pianifica anche la crescita del disco. Un nodo completo Geth aggiunge nell’ordine di 10–15 GB a settimana a metà 2026; Lighthouse cresce più lentamente. Su un disco da 2 TB questo è un conto alla rovescia che puoi resettare — la scadenza della storia pre-Merge libera qualche centinaio di GB (vedi risoluzione dei problemi), e un snap sync fresco ricostruisce un database completamente compattato in uno o due giorni. Con 4 TB, la crescita è una questione annuale invece che trimestrale. Il nodo non deve essere online ogni secondo, ma più a lungo resta offline, più tempo gli servirà per recuperare.

Un nodo completo non è un validatore

I 32 ETH di cui tutti hanno sentito parlare appartengono allo staking, non alla gestione del nodo. Il nodo di questa guida non ha bisogno di alcun ETH — valida i blocchi nel senso di controllarli, il che costa hardware, non stake.

Un validatore è un terzo programma accanto ai due client: detiene le chiavi di firma, produce attestation e blocchi, e guadagna ricompense per questo, con un indirizzo fee recipient configurato per l’entrata. I 32 ETH sono una garanzia che il protocollo può confiscare in caso di comportamento scorretto dimostrabile. Anche l’asticella operativa si sposta — un nodo RPC che trascorre un weekend offline si aggiorna semplicemente lunedì, mentre un validatore offline subisce piccole penalità a ogni epoch.

Con meno di 32 ETH, lo staking in pool è il punto di ingresso: Rocket Pool e protocolli simili permettono a operatori permissionless di gestire validatori con un bond più piccolo, e alcune configurazioni di pool girano esattamente sul nodo costruito sopra. Un semplice nodo completo non guadagna nulla. Lo gestisci per indipendenza e privacy, per lo sviluppo, o come base su cui un validatore si appoggerà in seguito.

Sicurezza: la disposizione delle porte è la policy

L’intero modello di sicurezza di questo setup è visibile nelle regole del firewall del passo 1. Le porte 30303 e 9000/9001 sono aperte perché il peer-to-peer ha bisogno di sconosciuti; 8545 e 8551 si legano a 127.0.0.1 perché nulla al di fuori della macchina ha motivo di essere lì. Il segreto JWT autentica l’engine API sulla 8551, ma trattalo come un secondo livello, non come un motivo per esporre la porta.

Una 8545 aperta è l’errore peggiore, perché JSON-RPC non ha alcuna autenticazione. Gli scanner trovano rapidamente le porte RPC Ethereum esposte, e il danno va oltre lo sfruttamento gratuito: con i namespace sbagliati abilitati, gli estranei ottengono internals di debug e contenuti del mempool che non dovrebbero mai vedere. Mantieni --http.api sui quattro namespace dell’unit; admin, debug e personal restano disattivati su qualsiasi macchina la cui porta RPC potrebbe mai essere raggiungibile.

Quando altre macchine hanno legittimamente bisogno dell’RPC, crea un tunnel invece di esporre: WireGuard o un tunnel SSH per te stesso, nginx o Caddy con TLS e una allowlist di IP per un piccolo team. I client girano già come utenti di sistema senza login dal passo 1, quindi un processo client compromesso non eredita alcun account shell. Aggiungi unattended-upgrades per le patch del sistema operativo, e la parte noiosa della sicurezza del server si gestisce da sola.

Risoluzione dei problemi

Lighthouse non riesce a raggiungere Geth (“Unable to connect to execution endpoint”)

O Geth è down (systemctl status geth), oppure i segreti JWT differiscono. Conferma che entrambe le unit puntino allo stesso percorso jwt.hex. In caso di dubbio, rigenera il segreto una volta e riavvia entrambi i servizi.

Geth rimane bloccato su “State heal in progress” per giorni

La fase di state heal insegue la testa della chain, e un disco con prestazioni deboli in scrittura casuale non la raggiunge mai. Fai un benchmark con fio; vuoi decine di migliaia di IOPS a 4k. Gli SSD SATA e i volumi cloud predefiniti sono i soliti colpevoli. La soluzione è storage NVMe vero — nessun flag salva un disco lento.

Il numero di peer resta a zero

La porta 30303 (TCP e UDP) è bloccata o non inoltrata dal tuo NAT. Controlla anche l’orologio di sistema: timedatectl dovrebbe mostrare una sincronizzazione NTP attiva, perché un orologio sfasato rompe gli handshake tra peer sul lato consenso.

Il disco si riempie

Trova prima la crescita: du -h --max-depth=2 /var/lib/geth. Un datadir creato prima di Geth 1.13 usa ancora il vecchio layout basato su hash; la soluzione pulita è un resync da zero, dopo il quale lo state resta sottoposto a pruning automaticamente. Attivare la scadenza della storia pre-Merge libera qualche centinaio di GB in più, e l’ancient store può essere spostato su un HDD economico tramite --datadir.ancient.

Geth segnala corruzione del database dopo un crash

Un’interruzione di corrente, un kill -9 o un OOM kill a metà scrittura lascia righe di log su corruzione o dati mancanti al riavvio successivo. A volte un riavvio risolve; se il log si ripete in loop, smetti di riparare e resincronizza invece — sposta il datadir da parte, riparti da zero, e lo snap sync ricostruisce tutto in uno o due giorni, di solito più velocemente di qualsiasi tentativo di riparazione. La prevenzione è già nell’unit: TimeoutStopSec=600 dà a Geth il tempo di fare il flush, e uno systemctl stop pulito è l’unico modo in cui il processo dovrebbe mai terminare.

L’OOM killer termina Geth

journalctl -k | grep -i oom conferma il sospetto. Il --cache di Geth è impostato di default a 4096 MB su mainnet, e l’uso reale supera quell’impostazione durante la sincronizzazione; aggiungi Lighthouse e il sistema operativo, e una macchina da 16 GB finisce la memoria. Imposta --cache 2048 sulle macchine piccole e mantieni un file di swap come cuscinetto — lento batte ucciso, perché un Geth ucciso non fa il flush di nulla e invita al caso di corruzione sopra.

Gestire un proprio nodo — o usare un’API?

Un confronto onesto, dato che Chaingateway vende l’alternativa.

Il nodo vince quando hai bisogno di JSON-RPC grezzo, pesante e sostenuto: query archive, tracing, monitoraggio del mempool, o massima privacy e resistenza alla censura. Un nodo è un costo fisso con richieste illimitate — alla cifra bassa di qualche centinaio di euro al mese della sezione costi, batte qualsiasi offerta RPC a consumo una volta che il tuo volume è abbastanza alto. È anche il modo migliore per capire come funziona davvero Ethereum.

L’API vince quando il nodo sarebbe solo un mezzo per un fine, il che per la maggior parte delle aziende significa pagamenti. Un nodo sincronizzato ti dà eth_sendRawTransaction e i log degli eventi. Non ti dà indirizzi di deposito per cliente, notifiche quando arriva un pagamento ERC-20, gestione delle chiavi o logica di retry. Questo è software applicativo che dovresti costruire e gestire sopra, e di solito costa più ore del nodo stesso.

L’API Ethereum di Chaingateway è esattamente questo livello mancante: creare e importare indirizzi (POST /api/v2/ethereum/addresses/import), inviare token ERC-20 (POST /api/v2/ethereum/transactions/erc20), e ricevere webhook firmati HMAC per i depositi in entrata — le consegne fallite finiscono in una lista interrogabile (GET /api/v2/ethereum/webhooks/notifications/failed) e possono essere reinviate tramite l’endpoint di retry. Il punto di pareggio è aritmetica: costo del server più le tue ore di costruzione e gestione contro un piano su /it/pricing/. Per i flussi di pagamento, il lato API di questa disuguaglianza resta più piccolo ben oltre la scala hobbistica; per il consumo RPC grezzo, il lato nodo vince presto. Inizia con il quickstart e la guida ai webhook — la prova di 7 giorni senza KYC basta per testare un flusso di deposito end-to-end (registrati qui).

Gestisci anche altre chain? Guarda le guide per BNB Smart Chain e TRON.