Hard fork BNB Chain Jenner l’8 dicembre 2026: Payment Lane, CAS20 e chi deve aggiornare

Il prossimo hard fork di BNB Chain, chiamato Jenner, entra in funzione sulla mainnet di BNB Smart Chain (BSC) martedì 8 dicembre 2026 alle 02:30:00 UTC. La data arriva dalla versione 1.8.2 del client bsc, pubblicata su GitHub il 3 novembre, che aggancia il passaggio al timestamp Unix 1796697000. L’aggiornamento è obbligatorio per chi gestisce un nodo. I possessori di BNB e dei token della rete non devono fare nulla.

Jenner introduce una corsia riservata ai pagamenti, uno standard nativo per i token conformi e un modo per gli smart contract di leggere l’ora del blocco in millisecondi. La velocità dei blocchi resta quella di oggi.

Data dell’hard fork di BNB Chain e orari locali

A Roma e a Parigi il fork scatta alle 03:30 (CET), a Lagos alle 03:30 (WAT), a Johannesburg alle 04:30 e a Nairobi alle 05:30 (EAT). A Londra e ad Accra sono le 02:30. BNB Chain ha indicato un orario e non un’altezza di blocco, quindi il numero esatto del blocco si saprà solo quando la rete raggiungerà quel timestamp.

La prova generale è già alle spalle. Jenner è andato in funzione su Chapel, la testnet di BSC, il 29 ottobre 2026 alle 02:30 UTC con il client v1.8.1, secondo la pagina ufficiale delle release, l’annuncio nella documentazione e le note del client Reth. Il post sul blog di BNB Chain del 22 ottobre indicava invece il 28 ottobre; qui seguiamo i registri delle release. Quel post rinviava la data della mainnet a un annuncio successivo, che la v1.8.2 ha poi fornito.

Cosa cambia con Jenner: Payment Lane, CAS20 e orario in millisecondi

Il fork è specificato nella BEP-718 e attiva tre proposte. Nel repository delle BEP, il 7 novembre tutte e tre risultavano ancora in stato Draft, benché il codice del client che le esegue sia già stato rilasciato.

La BEP-703, la Payment Lane, riserva ai pagamenti il 5% del gas di ogni blocco come impostazione predefinita. La governance può alzare la quota, ma mai oltre il 10%, un tetto scritto nel protocollo. Rientrano due tipi di transazione: i trasferimenti semplici di BNB, di importo diverso da zero, verso un account ordinario (cioè senza codice di contratto), e le transazioni inviate a contratti presenti in un elenco di pagamento tenuto dalla governance. Quell’elenco parte vuoto. La BEP dice che l’intenzione è cominciare con USDT e USDC, ma ogni contratto richiede comunque l’approvazione della governance: il primo giorno i trasferimenti di stablecoin non hanno quindi spazio riservato.

I pagamenti possono superare il 5% quando c’è posto. Non vale l’inverso: il gas che la corsia lascia inutilizzato resta fermo e non passa ad altre transazioni. Inoltre la corsia tutela i pagamenti come categoria, non il singolo pagamento.

La BEP-702 crea CAS20, un Compliant Asset Standard integrato nel protocollo per le stablecoin e per gli asset reali tokenizzati. Un token CAS20 non è un contratto distribuito ma un precompile con stato eseguito dal nodo, che mantiene l’interfaccia BEP-20 già nota ai wallet. Gli emittenti dispongono di ruoli distinti per coniare, bruciare, sospendere e sequestrare, più allow list e block list conservate in un registro di policy condiviso. Il blog di BNB Chain precisa che questi controlli, da soli, non rendono un token conforme sul piano legale.

Jenner porta solo la capacità tecnica. Per creare token e scrivere nel registro di policy serve un interruttore separato, azionato da un amministratore nominato dalla governance; il blog definisce questo passaggio «in arrivo» (coming soon) senza indicare una data.

La BEP-706 aggiunge un precompile all’indirizzo 0x70 che restituisce l’ora del blocco corrente in millisecondi, al costo di 20 gas. block.timestamp resta in secondi, quindi i contratti esistenti si comportano come prima; solo quelli che chiamano il nuovo indirizzo vedono l’orologio più fine. La BEP pensa a quotazioni con scadenza sotto il secondo, chiusure di aste e controlli sulla freschezza dei prezzi degli oracoli.

La release 1.8.2 contiene anche le modifiche della BEP-675 per i builder MEV, già comparse nella v1.8.1: offerte di blocco inviate via gRPC in formato binario, rifiuto delle offerte con state root vuoto e blocchi dei builder che sopravvivono al riavvio del nodo. Sono modifiche del client, non regole dell’hard fork, quindi valgono appena un nodo esegue la nuova versione. La documentazione elenca un flag, --mev.grpc.disable, per spegnere il servizio gRPC, che di default ascolta sulla porta 8552.

Chi deve intervenire prima dell’8 dicembre

La release indica i destinatari: operatori di nodi mainnet, builder MEV e operatori di sentry. Il lavoro si divide per ruolo.

• I validatori e gli altri operatori di nodi sostituiscono il binario con bsc v1.8.2 (basato su geth) oppure con BSC-Reth v0.1.4 e riavviano prima delle 02:30 UTC dell’8 dicembre. Chi è ancora fermo alla v1.7.x o alla v1.8.0-alpha deve leggere prima le note della v1.8.0-alpha e della v1.8.1, perché alcuni campi di configurazione sono stati rimossi.
• I builder MEV devono lasciare spazio al gas che la Payment Lane riserva quando riempiono i blocchi e verificare i propri strumenti di offerta rispetto all’interfaccia gRPC.
• Gli sviluppatori di app che simulano chiamate su BSC-Reth devono controllare la modifica RPC descritta più sotto e provare il precompile in millisecondi se i loro contratti lo useranno.
• I team che si occupano di pagamenti devono verificare quali trasferimenti contano come pagamenti: i semplici trasferimenti di BNB sì, i trasferimenti di token solo dopo che il loro contratto è stato votato e inserito nell’elenco.
• Chi detiene BNB o altri token non deve fare nulla. Nessuna fonte ufficiale chiede di spostare, scambiare o «aggiornare» i token, e un messaggio che lo chieda va considerato con ogni probabilità una truffa.

Al 7 novembre non abbiamo trovato alcun avviso di exchange su Jenner, quindi non si sa ancora se qualche piattaforma sospenderà depositi o prelievi su BSC attorno al fork.

Il client Reth: v0.1.4 per il fork, poi un hotfix

BSC-Reth, il client in Rust, ha una propria linea di rilascio. La versione 0.1.3, uscita il 16 ottobre, portava Jenner su Chapel. La versione 0.1.4, pubblicata il 3 novembre insieme a bsc v1.8.2, fissa il timestamp della mainnet ed è indicata come obbligatoria per gli operatori mainnet.

Ne è seguita una seconda build. La v0.1.4-hotfix è uscita alle 02:53 UTC del 6 novembre con la correzione a monte di Reth per un calcolo errato dello state root in certe condizioni del trie. Non richiede alcuna migrazione del database né un hard fork, e BNB Chain raccomanda di installarla il prima possibile su mainnet e testnet. L’articolo di Crypto Briefing del 6 novembre tratta le due build come un’unica release; le pagine di GitHub le tengono separate. Il nostro articolo sul bug di Reth che poteva dare ai nodi uno state root sbagliato racconta quella correzione a Base, BNB Chain e Tempo.

Una modifica RPC di Reth, introdotta con la v0.1.3, vale appena un nodo si aggiorna, prima del fork: in eth_call, eth_estimateGas, debug_traceCall e eth_simulateV1, un blockOverrides.prevRandao fornito deve codificare il resto in millisecondi (da 0 a 999) come esadecimale a 32 byte. Se si sovrascrive solo il campo del tempo, quel resto torna a zero.

Da Lorentz a Jenner: gli hard fork di BSC e i tempi di blocco

Tra aprile 2025 e gennaio 2026 tre fork hanno ridotto il tempo di blocco di BSC da 3 secondi a 0,45 secondi. Con più di due blocchi al secondo, un orologio che conta i secondi interi non distingue più i blocchi vicini: è il vuoto che la BEP-706 colma.

Jenner non ha legami con la Layer 1 separata con blocchi da 200 ms che BNB Chain sta costruendo per il 2027, ancora in devnet privata.

Perché conta per chi legge dall’Italia e dall’Africa

La Payment Lane riguarda i piccoli trasferimenti, dove le commissioni gas e la congestione pesano di più. Un semplice trasferimento di BNB tra due wallet rientra nella corsia dal momento del fork. I trasferimenti di stablecoin, che molti lettori in Europa e in Africa usano per i pagamenti, non ne traggono vantaggio finché la governance non inserisce i loro contratti nell’elenco.

CAS20 dà agli emittenti strumenti on-chain per congelare, sequestrare o limitare i token. Nessun emittente, in Europa o altrove, ha annunciato un token CAS20.

Cosa non si sa ancora

BNB Chain non ha detto quando sarà attivata la creazione di token CAS20, chi ricoprirà il ruolo di amministratore né quando USDT, USDC o altri contratti entreranno nell’elenco della Payment Lane. Le pagine ufficiali su Jenner non riportano modifiche per opBNB. Da seguire: un avviso degli exchange, le proposte di governance sull’elenco della corsia e il blocco di attivazione dell’8 dicembre.