Il 9 giugno 2026, Second — il laboratorio Bitcoin fondato da ex executive di Blockstream — ha portato in produzione Bark, la propria implementazione del protocollo Ark, direttamente sulla mainnet di Bitcoin. È un momento atteso da anni nella comunità degli sviluppatori: Ark promette di offrire pagamenti veloci e a basso costo in self-custody, senza la complessità dei canali della Lightning Network.
In termini semplici: con Bark puoi ricevere e spendere bitcoin istantaneamente, con fee ridotte, senza aprire canali, senza pre-allocare liquidità, e mantenendo sempre la custodia delle tue chiavi.
Il lancio include il Bark SDK in Rust con binding per sette linguaggi, il demone Barkd per ambienti server, quattro wallet già operativi su mainnet (Noah, Arke, Satsigner, Bark Wallet per Umbrel) e un plugin per BTCPay Server.
Second ha raccolto 5,1 milioni di dollari da un investitore privato e opera con un team di undici persone, tra cui il CEO Steven Roose, il CTO Erik De Smedt e il CMO Neil Woodfine — tutti provenienti da Blockstream.
Fin qui, le notizie che circolano. Ma c’è molto di più da capire.
🔬 ANALISI
Come funziona davvero Ark: i vUTXO
Il cuore tecnico è il concetto di Virtual UTXO (vUTXO). Per capirlo, partiamo da cosa è un UTXO: nel protocollo Bitcoin ogni pagamento crea un “pezzo di bitcoin” non ancora speso, associato a una chiave pubblica.
Chi controlla quella chiave può spenderlo. Semplice, trasparente, on-chain.
Un vUTXO è la versione off-chain di questa struttura. Tecnicamente è una transazione pre-firmata che garantisce la creazione di un vero UTXO on-chain nel momento in cui viene trasmessa in rete, ma che nel frattempo vive fuori dalla blockchain. Tutti i vUTXO di tutti gli utenti vengono annidati in un albero di transazioni pre-firmate — chiamato “batch” — la cui radice è un singolo UTXO condiviso on-chain, bloccato da una firma multi-party che include tutti i partecipanti e il server coordinatore (l’ASP, Ark Service Provider).
Ogni foglia dell’albero corrisponde ai fondi di un singolo utente. Per “uscire” da Ark, l’utente trasmette il proprio ramo dell’albero — solo il suo, non quello degli altri — realizzando il proprio UTXO on-chain. È un’uscita unilaterale (unilateral exit), possibile in qualsiasi momento, e questa è la vera garanzia di self-custody.
Il trade-off che nessuno ti dice: pagamenti veloci vs. trustlessness
Bark offre due modalità di pagamento con garanzie molto diverse:
Pagamenti in-round (trustless): avvengono durante le finestre di coordinamento periodiche dell’ASP. Ogni partecipante firma l’albero insieme agli altri, e il pagamento acquisisce la stessa garanzia di sicurezza di Lightning — nessuna fiducia richiesta verso l’operatore. Il rovescio è che bisogna attendere il prossimo round, che avviene ogni settimana o due.
Pagamenti out-of-round (con fiducia parziale): avvengono immediatamente, in modo “insanamente veloce” come li ha descritti Marty Bent nella prima demo mainnet. Ma per ottenerli, il destinatario deve accettare un rischio: deve fidarsi che il mittente e l’ASP non colludano per fare un double-spend. Per pagamenti piccoli tra persone che si conoscono — un caffè, una mancia, un rimborso tra amici — è un trade-off del tutto accettabile. Per pagamenti grandi verso sconosciuti, aspettare il round in-round è la scelta saggia.
Il problema reale è come questa distinzione verrà comunicata agli utenti nelle interfacce wallet. Un utente inesperto che riceve un pagamento out-of-round di valore elevato e lo considera definitivo potrebbe essere truffato. È una questione aperta di UX che Second e gli sviluppatori wallet devono risolvere.
Il requisito di liveness: il “vUTXO che scade”
Un altro aspetto cruciale assente nelle notizie mainstream: i vUTXO scadono. Ogni vUTXO ha una data di scadenza, e il proprietario deve interagire con il server ASP almeno una volta ogni mese o due per “rinnovarlo” (il cosiddetto refresh). Se l’utente non partecipa a un round entro la scadenza, l’ASP ha il diritto di reclamare i fondi sottostanti.
Questo non è un bug ma una conseguenza della struttura crittografica del protocollo: i fondi condivisi on-chain devono essere “sbloccati” periodicamente per evitare che restino bloccati per sempre. L’uscita unilaterale on-chain rimane sempre possibile — ma solo se l’utente è stato attivo nei tempi previsti.
In pratica: Bark non è adatto a chi vuole dimenticarsi del wallet per anni. È un protocollo pensato per chi usa bitcoin con una certa regolarità. Chi vuole conservare sats a lungo termine senza preoccupazioni farà meglio a tenerli on-chain o su hardware wallet in cold storage.
Il rischio sistemico nascosto: la exit congestion
Immagina che molti utenti perdano fiducia nell’ASP di Second nello stesso momento — o che Second stessa smetta di operare — e decidano tutti di uscire unilateralmente on-chain. Ogni uscita richiede di trasmettere l’intero ramo dell’albero di transazioni pre-firmate. Con centinaia di migliaia di utenti, questo scenari creerebbe una congestione on-chain catastrofica, con fee che esplodono e lunghi tempi di attesa per le conferme.
Tecniche di controllo della congestione basate sui covenant — in particolare gli alberi CTV-based mutuati dalla ricerca sul protocollo Ark — potrebbero mitigare drasticamente questo rischio. Ma finché l’opcode OP_CTV non viene attivato come soft fork su Bitcoin, il rischio sistemico di exit congestion rimane un limite strutturale reale. È il prezzo del “covenantless Ark”: funziona oggi, ma la sua resilienza sistemica in scenari di stress è inferiore a quella che avrebbe con CTV.
Il protocollo oggi: MuSig2 al posto dei covenant
L’Ark originale proposto da Burak nel 2023 richiedeva OP_CTV (BIP 119) per funzionare. L’idea era usare i covenant — restrizioni crittografiche su come un UTXO può essere speso in futuro — per costruire l’albero di vUTXO in modo deterministico e sicuro, senza richiedere firme interattive.
Second ha scelto di non aspettare. Bark funziona su Bitcoin così com’è oggi, usando MuSig2 — un schema di aggregazione di firme basato su Schnorr e Taproot — per coordinare interattivamente le firme di tutti i partecipanti durante ogni round. È più laborioso per l’ASP e richiede la presenza degli utenti, ma non richiede alcuna modifica al protocollo base di Bitcoin.
Il futuro: CTV e CSFS potrebbero trasformare Bark
Steven Roose non si è limitato al lancio commerciale: ha pubblicato un paper tecnico dettagliato — hArk & Erk — che descrive come l’attivazione di OP_CTV e OP_CSFS (OP_CHECKSIGFROMSTACK) potrebbe evolvere radicalmente Ark.
Con CTV, il round di firma interattiva potrebbe essere eliminato: l’albero dei vUTXO verrebbe costruito tramite covenant deterministici, rendendo i round più veloci, meno costosi, e non richiedendo la presenza simultanea degli utenti. Con CSFS in aggiunta, diventerebbe possibile che l’ASP rinnovi i vUTXO senza la presenza dell’utente, delegando il monitoraggio a watchtower di terze parti. Un utente potrebbe, in sostanza, impostare una watchtower di fiducia e dimenticarsi del requisito di liveness.
Nessuno di questi miglioramenti richiede cambiamenti all’architettura core di Bark: sono upgrade incrementali verso un protocollo progressivamente meno interattivo e più robusto. Il tutto dipende, ovviamente, dall’accensione politicamente complicatissima di un soft fork su Bitcoin.
L’interoperabilità con Lightning: complementarità, non competizione
Bark e Lightning non sono concorrenti: sono sistemi con trade-off quasi opposti che si completano. Lightning eccelle nei micropagamenti frequenti tra due parti con canali aperti; Ark eccelle nell’onboarding di nuovi utenti, nella ricezione senza liquidità pre-allocata e nei pagamenti verso destinatari occasionali.
La complementarità diventa concreta nell’interoperabilità atomica: i vUTXO possono essere scambiati in modo atomico con transazioni che entrano o escono dalla Lightning Network — usando atomic swap on-protocol. Il plugin BTCPay Server sviluppato da Second ne è la dimostrazione pratica: i merchant ricevono pagamenti Lightning in self-custody senza aprire canali o gestire liquidità, perché Bark fa da “cuscinetto” tra l’utente e Lightning.
I mass payout: il caso d’uso enterprise ignorato
Un use case è quello dei mass payout. Con Ark è possibile, per un datore di lavoro o una piattaforma, elaborare pagamenti simultanei verso migliaia di destinatari con finalità quasi istantanea e fee condivise tra i partecipanti. Immaginate uno stipendio in bitcoin a fine mese per un’azienda con cento dipendenti: oggi on-chain costerebbe decine o centinaia di dollari in fee; con Ark sarebbe una singola operazione coordinata. Questo apre scenari B2B che il framing “wallet per utenti comuni” nasconde del tutto.
Chi c’è dietro: il peso del background Blockstream
Il CEO Steven Roose ha lavorato per anni su Liquid Network e ha scritto parte delle specifiche di Elements; il CTO Erik De Smedt è co-autore di sistemi critici nell’infrastruttura Bitcoin; Neil Woodfine come CMO ha contribuito alla comunicazione tecnica di alcuni dei prodotti più avanzati dell’ecosistema. Non è una startup generica: è un team che ha già consegnato infrastruttura Bitcoin di produzione.
💬 OPINIONE
Bark è probabilmente il layer-2 Bitcoin più tecnicamente rigoroso lanciato su mainnet negli ultimi anni. Second ha fatto una scelta coraggiosa e filosoficamente coerente: non aspettare CTV, non usare sidechain con modelli di fiducia ibridi, non cedere alla tentazione di asset bridge. Ha costruito su Bitcoin puro, oggi, con i meccanismi crittografici disponibili, accettando i limiti che ne derivano e documentandoli onestamente.
Questa onestà sui trade-off è rara, e va apprezzata. Il problema del requisito di liveness, il rischio di exit congestion, la fiducia parziale nei pagamenti out-of-round: sono tutti limiti reali che Second ha descritto pubblicamente nel suo paper tecnico invece di nasconderli nel marketing.
La domanda più importante non è tecnica, però. È politica e di adozione: Bark può diventare un argomento nel dibattito su CTV? Se un’implementazione reale, su mainnet, con utenti reali, dimostrasse che CTV ridurrebbe significativamente i rischi sistemici di exit congestion e migliorerebbe l’UX, potrebbe finalmente spostare il dibattito su quel soft fork da “proposta teorica interessante” a “upgrade con benefici dimostrabili e urgenti”. La storia di Bitcoin insegna che i soft fork partono sempre da un bisogno concreto dimostrato dall’uso reale.
C’è infine un aspetto forse sottovalutato nel dibattito mainstream: Bark non è solo un prodotto, è una scommessa sull’ecosistema degli sviluppatori. Il Bark SDK in sette linguaggi, Barkd con API REST, quattro app al lancio — Second non sta puntando su un singolo wallet flagship. Sta costruendo l’infrastruttura perché altri costruiscano wallet, integrazioni, servizi. Se questa scommessa funziona, l’adozione di Ark non dipenderà da Second: dipenderà da decine di sviluppatori indipendenti che troveranno nel Bark SDK il modo più semplice per dare ai loro utenti pagamenti Bitcoin in self-custody. È esattamente la stessa strategia che ha reso Lightning ciò che è oggi.
Riferimenti e approfondimenti
- Bark su mainnet — annuncio ufficiale Second
- Ark Protocol — documentazione ufficiale
- Bitcoin Magazine: Bitcoin Layer 2 — Ark
- Bitcoin Magazine: Second’s Bark — ex Blockstream developers
- Steven Roose — hArk & Erk: Evolving Ark with CTV and CSFS
- Dev.to — Bark & Ark: A Deep Dive
- Bitcoin Optech — Ark Protocol
- Glossario Bitcoin Italia Network
