testo integrale
358\19 R.G REPUBBLICA ITALIANA IN NOME DEL POPOLO ITALIANO LA CORTE DI APPELLO DI FIRENZE prima sezione civile ### composta: - dott. ### - dott. ### - dott. ssa ### rel. ha pronunciato la seguente ### causa n.358 iscritta in grado di appello al ruolo generale della ### dell'anno 2019 Promossa da ### s.r.l. (già ### s.r.l.) in persona del legale rappresentante p.t. ### rappresentato e difeso dall'avv. ### del foro di ### come da mandato in atti ### presso il Tribunale di Firenze, in persona del sostituto dott. ### di ### s.r.l. in persona dei curatori dott. ### e ### rappresentato e difeso dall'avv. ### del foro di ### come da mandato in atti ###### tutti rappresentati e difesi, dagli avv.ti ##### del ### di ### e dall'avv. ### del foro di ### come da mandato in atti ### l'intervento del P.G.
E di ### GmbH in persona del legale rappresentante ### rappresentata e difesa dagli avv.ti ### e ### del foro di ### come da procura notarile in atti ### in decisione all'udienza del 27.9.2019 sulle seguenti ### Per il reclamante: “### la ### d'### di ### respinta ogni contraria difesa, così giudicare: nel merito accogliere il presente reclamo e per l'effetto revocare il fallimento di ### s.r.l., dichiarato con sentenza n. 18/2019 del 19.12.2018/21.01.2019 dal Tribunale di Firenze…. Con vittoria di spese, diritti, onorari, spese generali oltre IVA e CPA come per legge. In via istruttoria: disporsi l'acquisizione del fascicolo d'ufficio della procedura pre-fallimentare recante il 178/205/2018 di R.G. Disporre se del caso una nuova ### e comunque in denegata ipotesi disporre una integrazione della relazione od in via subordinata chiamare il CTU a chiarimenti sugli aspetti indicati in narrativa ed in particolare sui quesiti di cui alle note difensive dell' ### (doc. 14) e sui riflessi che il comunicato ### del ### del 05.11.2019 (doc. 11) ha sulle conclusioni della relazione.” ### s.r.l.: “Piaccia all'###ma ### d'### di ### respingere il reclamo. Con vittoria di spese e onorari.” ###.M.: “Chiede che la ### di ### di ### voglia rigettare il reclamo presentato contro la dichiarazione di fallimento di ### s.r.l. pronunciata con la sentenza 18\19” Per i creditori reclamati ###### “### l'###ma ### di ### di ### per tutti i motivi di cui in atti, respinta ogni contraria domanda, eccezione e deduzione avversaria, anche istruttoria: - rigettare il reclamo proposto da ### s.r.l., in quanto inammissibile e/o infondato in fatto e in diritto per le ragioni esposte in narrativa e, per l'effetto, confermare la sentenza n. 18/2019 del Tribunale di ### resa il 19 dicembre 2018 e pubblicata il 21 gennaio 2019 con la quale è stato dichiarato il fallimento; in via istruttoria: - rigettare la richiesta di rinnovazione/integrazione della consulenza tecnica e di chiarimenti al consulente tecnico, in quanto richieste inammissibili e irrilevanti ai fini dell'odierna decisione; in ogni caso: - condannare ### a rifondere ai sig.ri ##### e ### le somme da costoro versate nel giudizio prefallimentare #### R.G. 178+205/2018 (anche per conto della stessa BG ### per la remunerazione del consulente tecnico d'ufficio, pari a complessivi ### 5.200; - condannare il la ### al pagamento in favore dei sig.ri ##### e ### di spese, diritti e onorari del presente giudizio, incluso il procedimento per la dichiarazione di fallimento, oltre spese generali, c.p.a. e IVA, come per legge.” ### GmbH: “### alla ### respingere il reclamo con vittoria di spese e di onorari” FATTO E DIRITTO ### di ### con sentenza n.18 del 21.1.2019, ad istanza di ### creditore procedente, e del ### presso il ### di ### ha dichiarato il fallimento di ### s.r.l. avente ad oggetto la gestione del software e relativo sito internet della piattaforma exchange on line denominata www. ###com che, tra i vari servizi offerti, permette l'acquisto, lo scambio e il deposito di diverse tipologie di criptovalute, tra cui la criptovaluta denominata ### a fronte del pagamento di una commissione.
Il fallimento veniva dichiarato in ragione della sussistenza di tutti i presupposti di cui agli artt. 1 comma 2, 5 e 15 ultimo comma della ### fallimentare alla luce dei fatti verificatisi e rappresentati sia dal creditore ricorrente sia dal P.M. a seguito del blocco della piattaforma finanziaria disposto il ### e poi il ### dal suo gestore, con impossibilità per i depositari delle criptovalute di prelevare i propri depositi, blocco giustificato dalla sparizione dalla piattaforma di circa 17 milioni di ### - pari a circa 120 milioni di euro - appartenenti agli utenti dell'exchange. ### è una società subentrata nella gestione della piattaforma finanziaria ### alla impresa individuale ### di ### assumendo appunto all'origine la denominazione originaria di ### s.r.l: la domanda di fallimento ha interessato pertanto anche il ### quale imprenditore individuale dal momento che i fatti che hanno determinato l'ammanco dichiarato dal ### nella sua denuncia si sono verificati quando la piattaforma era gestita dall'impresa individuale, avendo operato sotto la gestione della nuova società per un arco limitatissimo di tempo, prima che il ### fallimentare di ### ne disponesse in via cautelare il blocco in data ###, disponendo altresì il sequestro conservativo dell'intero patrimonio aziendale.
Dunque l'istanza di fallimento che riguarda la ### nasce dal fatto che la stessa, essendo subentrata nella gestione dell'impresa e quindi in tutti i contratti in essere ex art.2558 c.c. si è accollata interamente i debiti nascenti dalla precedente gestione e dunque è debitrice verso i singoli investitori della piattaforma, alla restituzione della criptomoneta ivi depositata in virtù della solidarietà passiva quale effetto naturale della cessione di azienda prevista dall'art. 2560 c.c..
Di conseguenza tutte le argomentazioni che questa ### utilizzerà sono derivate da quelle che hanno interessato analogo procedimento di reclamo avverso la dichiarazione di fallimento della ### di ### Andando perciò a ripercorrere i fatti che hanno portato al fallimento della prima azienda cessata e cancellatasi dal registro delle imprese immediatamente dopo l'avvenuta trasferimento, si premette come antefatto necessario che il ### in veste ormai di legale rappresentante della BG ### ha denunciato la sparizione della ### valuta in ### e ha rappresentato che l'ammanco dei ### coinvolgeva l'80% della ### valuta appartenente agli utenti e ha dichiarato l'impossibilità per la società alla restituzione cui era tenuta in base a quanto previsto nelle condizioni generali di contratto, che prevedevano, in caso di blocco o chiusura del conto da parte del gestore, il diritto degli utenti alla restituzione di tutte le criptovalute accreditate con conversione in ### al di fuori della piattaforma ### aveva proposto perciò agli utenti un piano di rientro e offerto loro, al posto dei ### sottratti (nella misura dell'80% ciascuno) uno strumento finanziario creato ad hoc dalla ### denominato ### shares.
Per il creditore ricorrente ### la perdita per quanto riguarda la ### valuta era di oltre 3,5 milioni di euro.
Il ricorso per fallimento proposto dal P.M. si fondava dunque sui successivi esiti della indagine penale in corso avviatasi a seguito della denuncia presentata dal medesimo ### indagine che, sin dai primi sviluppi, aveva comunque consentito di appurare che questi, nei giorni immediatamente precedenti la denuncia, aveva trasferito su altra piattaforma finanziaria denominata “###”, attraverso nove operazioni conseguenziali, bitcoin per un controvalore di € 1,7 milioni, valuta che, a seguito del tracciamento dei versamenti, proveniva da indirizzi riconducibili a quelli utilizzati dai clienti di ### La difesa di ### nel corso dell'udienza prefallimentare, ricalca quello di ### ovvero che: l'attività principale connessa alla piattaforma a cui gli utenti potevano accedere tramite la creazione di uno specifico account è proprio la fornitura di servizi finalizzati al trading ovvero allo scambio di valute virtuali, mentre le attività di deposito erano del tutto residuali e strumentali al solo fine di permettere gli scambi; che non sussisteva perciò responsabilità del gestore in forza delle norme applicabili al deposito perché non vi era alcuna remunerazione collegata al deposito ma erano applicate solo commissioni sui prelievi e gli scambi di criptovalute; che l'ammanco di 17 milioni di ### era dipeso da una duplicazione di operazioni di prelievo effettuati dagli utenti della piattaforma contabilizzati una sola volta per effetto della vulnerabilità del software ### e non poteva ricondursi in alcun modo al gestore della piattaforma ### e dunque né al ### né alla ### s.r.l. e che quindi il relativo controvalore sottratto non poteva costituire in alcun modo un debito delle due imprese.
La difesa della fallenda si incentrava su tale punto nevralgico: 1)non esisteva, secondo i ### of Use di contratto, alcun obbligo di custodia delle valute in capo al gestore, ma, anzi, sussisterebbe una esplicita previsione della assunzione dei rischi connessi all'utilizzo della piattaforma in capo agli utenti, con la conseguenza che gli effetti non direttamente riferibili alla condotta del gestore e connessi ai servizi non potrebbero che gravare sugli utilizzatori; 2) anche a voler ritenere sussistente un contratto di deposito, nel caso specifico vi sarebbe un furto, suscettibile di integrare un evento imprevisto, non imputabile al depositario che ne determina la liberazione dall'obbligo di restituzione ai sensi del 1780 c.c.; 3) che infine le proposte di soluzioni amichevoli effettuate al fine di evitare controversie legali non potevano considerarsi come riconoscimento di debito in quanto è da escludere, in forza di quanto argomentato, un diritto alla restituzione delle somme o al risarcimento del danno da parte degli utenti della piattaforma.
Nella fase prefallimentare sono intervenuti ##### in qualità di utenti della ### i quali avevano registrato analoghi ammanchi sulla propria ### valuta e che hanno aderito alla richiesta di fallimento. ### ha dichiarato il fallimento sul presupposto della natura commerciale dell'attività svolta dall'impresa ### della sussistenza dei limiti dimensionali di fallibilità di cui all'art. 1 comma 2 L.F. senz'altro quanto ai debiti avendo gli stessi ampiamente superato la soglia di € 500,00 e al patrimonio netto,- Quanto poi alla responsabilità di ### per gli ammanchi di criptovaluta, fatto da cui discende l'esistenza del suo indebitamento e quindi, per conseguenza immediata, l'insolvenza dell'imprenditore commerciale, presupposto imprescindibile di fallibilità, il ### dopo aver esperito consulenza tecnica, ha affermato la responsabilità del gestore per gli ammanchi registrati sulla piattaforma ### e per effetto dell'ingente indebitamento, pari alla cifra dell'ammanco registrato - superiore senz'altro alla soglia dell'indebitamento globale di cui all'art. 1 comma 2 l. c) L.F. - ha ritenuto lo stato di insolvenza di cui all'art. 5 L.F.
La responsabilità del gestore verso gli utenti per il verificarsi degli ammanchi veniva sostenuta dal ### con una doppia motivazione, sia che si consideri il rapporto tra gli utenti e il gestore della piattaforma finanziaria come un contratto misto di trading e deposito irregolare ex art. 1782 c.c., sia che lo si consideri come un contratto misto di trading e deposito regolare.
Accertato attraverso la CTU che l'ammanco dei 17 milioni di ### era senz'altro dipeso dai c.d. prelievi multipli (ovvero più prelievi di pari importo eseguiti da un medesimo conto intestato a ### senza che potesse invocarsi l' “idempotenza” (inefficacia del secondo ordine o comando di prelievo per valuta identica impartito a breve distanza dal primo perché gli ordini, seppur identici, erano partiti come ordini diversi e così comunicati al ### e con contabilizzazione solo del primo per la piattaforma, nonostante vi fosse fuoriuscita di valuta per tutti e due gli ordini identici e consecutivi, rilevava il consulente, all'esito delle operazioni, che non era la rete ### che disponeva uscite in maniera multipla, ma l'exchange ### che richiedeva più volte al nodo di far uscire dei fondi che in realtà erano già usciti alla prima richiesta senza tenerne traccia nel database dell' exchange.
Mentre il ### era sotto la responsabilità di un team, appunto il team che aveva elaborato la ### valuta, la piattaforma exchange ### era, all'epoca dei fatti, sotto la diretta gestione di ### e quindi era il software ### che aveva generato il problema e l'ammanco in quanto ogni prelievo multiplo è nato come richiesta multipla da parte di ### e il nodo ### ha eseguito le richieste pervenute non avendo visione sulla reale contabilità dell'exchange. Dunque gli ammanchi si erano verificati perché gli utenti che si sono appropriati dei ### avevano scoperto che, richiedendo un prelievo in determinati momenti, vi erano buone probabilità di ottenere due prelievi identici, di cui uno contabilizzato ed ufficiale ed uno ulteriore, effettuato una seconda volta, che non veniva contabilizzato dall'exchange mentre era regolarmente iscritto all'interno della blockchain del nodo ### affiancato all'exchange: di conseguenza vi è stata una fuoriuscita di criptovaluta ### dalla piattaforma senza che le transazioni venissero registrate nel data-base delle exchange. Ravvisava perciò il ### una responsabilità del ### che evidentemente accortosi dei primi ammanchi registrati sulla exchange dal luglio del 2017 come risultante da una chat intrattenuta proprio con il ### (ammanchi che, come accertato ex post ammontavano già a quella data a € 2,5 ml, mentre per altri 7,5 ml. si sono avuti nell'ottobre 2017) non avrebbe adottato misure idonee ad evitare la perdita dei beni, e ciò perchè questi, nel luglio 2017, si era di fatto limitato a collocare in “black list” taluni utenti sospetti a cui potevano essere ricollegati i suddetti episodi di doppie richieste di prelievo simultanee; mentre in data ### aveva operato con una migrazione a mano, effettuata con 9 transazioni, il trasferimento dell'importo di 13 milioni di ### dall'indirizzo Bitgrail ### al ### 2, destinato, il primo, a diventare un cold wallet ovvero una piattaforma di mero stazionamento della cripto valuta, e il secondo destinato ad essere il nuovo hot wallet ovvero la piattaforma operativa, e ciò proprio al fine di mettere al riparo dalle transazioni una parte della criptovaluta ivi depositata.
Da ciò argomentando il ### qualificato in via principale il rapporto come un deposito irregolare, alla luce del fatto che tutti gli utenti della piattaforma vedevano confluire le proprie valute virtuali in un unico ed indifferenziato deposito, convogliate sull'indirizzo principale di ### senza alcuna indicazione di elementi distintivi circa la appartenenza ai singoli utenti, ha riconosciuto, in via primaria l'obbligazione restitutoria del ### e quindi di ### fondata sull' art. 1782 c.c., per l'esplicita previsione ivi contenuta per il depositario di mantenere sempre a disposizione dei depositanti la quantità integrale delle valute e quindi con il conseguente riconoscimento di debiti di questi per 120 milioni di euro. Ad analogo risultato di affermazione della esistenza di un gravoso indebitamento dell'impresa il ### addiveniva qualificando il rapporto tra il gestore della piattaforma e gli utenti come contratto di deposito regolare, dal momento che, non solo la perdita di valuta virtuale era dipesa da fatto a questi imputabile, come era stato accertato dalle risultanze della CTU sopra evidenziate, ma era altresì mancata l'immediata denuncia ai depositanti dei fatti illeciti per i quali aveva perduto la detenzione dei beni depositati, tenuto conto che il ### era a conoscenza delle perdite sin dal luglio del 2017.
A chiusura del quadro, il ### riteneva comunque la responsabilità e l'esistenza di un credito risarcitorio nei confronti di tutti gli utilizzatori della piattaforma considerando l'atipicità del contratto, in ragione dei principi generali del codice civile per la violazione del dovere di diligenza nell'adempimento dell'obbligazione.
Considerata perciò l'ingente sproporzione tra l'indebitamento conseguente alla gestione dell'impresa e le disponibilità dell'impresa quali risultanti dall'esecuzione del sequestro, ha ritenuto sussistente lo stato di insolvenza derivante dalla impossibilità di restituire le risorse investite nella piattaforma finanziaria e\o comunque di garantire l'adempimento dell'ingente debito risarcitorio. ********************
Avverso questa decisione ha proposto reclamo ### s.r.l. che ha contestato innanzitutto in diritto le conclusioni a cui è pervenuto il ### premettendo che: a) i ### non rappresentano “monete” in senso legale; b) la piattaforma non è una “banca”; c) le attività della piattaforma non sono in alcun modo riconducibili ad uno schema analogo al deposito bancario, non avendo con questo alcun elemento in comune, ma semmai è ravvisabile lo schema del rapporto di mandato; d) gli ammanchi sono dipesi da falle nel software sviluppato dal ### che portavano al continuo “crash” del nodo; e) non era peraltro compito o onere della ### quello di procedere alla continua verifica dei quantitativi depositati, tenendo anche conto dell'elevatissimo numero di indirizzi cui i ### erano riferibili (con circa 50.000 utenti). Ciò porta ad escludere la fallibilità della ### per carenza dei presupposti, primo fra tutti lo stato di insolvenza, non potendosi configurare alcuna obbligazione restitutoria fondata sull'art. 1782 c.c. e quindi sul presupposto della esistenza di un rapporto di deposito irregolare, né una responsabilità risarcitoria fondata sull'art. 1780 c.c., non costituendo la sparizione dei ### un fatto imputabile al gestore, bensì un fatto attribuibile alla condotta illecita di terzi, peraltro denunciato prontamente dopo la sua scoperta.
In fatto la reclamante ha contestato la valutazione del ### perché fondata su una Ctu oltre che erronea e incompleta, anche completamente nulla, in quanto espletata in violazione del principio del contraddittorio: tale violazione si sarebbe sostanziata sia a) nella unilaterale ed illegittima acquisizione di una chat di gruppo intercorsa tra il ### altri gestori di piattaforme finanziarie e la ### chat denominata “Telegram” da cui il ### si era cancellato senza considerare che questa, in quanto documento telematico doveva essere acquisita secondo i principi previsti nel campo informatico al fine di assicurarne l'integrità e la genuinità; b) in secondo luogo perché la versione definitiva della Ctu divergeva in numerosi punti dalla Ctu depositata e posta al vaglio delle parti al fine di sollecitare le osservazioni dei consulenti, risultando oltre che integrata delle risposte ai periti di parte, anche arricchita di fatti nuovi non espressi nella bozza, tale da stravolgerne integralmente il contenuto.
In fatto ancora sollecitava una integrale rinnovazione della ### in subordine una sua integrazione anche alla luce di un fatto nuovo successivo alla intervenuta dichiarazione di fallimento. E' accaduto infatti che in data 5 febbraio 2019 è stato dichiarato per la prima volta a mezzo comunicato stampa su “Medium” dal ### l'esistenza di un bug software del “Nodo” (il software di funzionamento della criptomoneta) che, nelle versioni precedenti alla versione 17.1, poteva comportare la duplicazione delle transazioni di invio. Si legge nel comunicato che “abbiamo ricevuto le prime segnalazioni multiple di utenti che hanno ricevuto depositi imprevisti di ### nei loro conti ### Il problema era localizzato su un piccolo numero di nodi che non erano stati aggiornati alla versione 17.1(…) problema in cui le transazioni potrebbero essere ripetute in rari casi.” (doc. 11 allegato al reclamo). Tale comunicato, nella prospettazione del reclamante, fornirebbe ai fatti di causa un inquadramento diverso che non può che andare a modificare gli esiti della CTU facendone cadere l'intero impianto ricostruttivo e ribaltandone le conclusioni in relazione alle modalità per cui sono avvenuti i doppi prelievi ed alla corretta implementazione del software ### confermando quindi la tesi che i prelievi illegittimi sono avvenuti a causa di problematiche esclusivamente riconducibili al software ### sviluppato dal ### che portavano al continuo crash del nodo. ### richiesto ex novo al Ctu è quello di effettuare un test di funzionamento sul software ### (in particolare relativamente alle versioni pregresse che giravano sui server ### per accertare appunto che la causa dei doppi prelievi erano da imputarsi solo al mancato funzionamento di tale software nei momenti di crash.
Premessi questi fatti in linea generale, i motivi di reclamo contenuti nelle oltre 75 pagine si possono così schematizzare: a) Nullità della ctu per violazione del principio del contraddittorio per la discrasia tra la bozza depositata e sottoposta alla valutazione dei ctp e quella definitiva depositata il ###; b) Nullità della Ctu per l'illegittima acquisizione della chat del gruppo ### tale documento non era stato depositato, neppure parzialmente, da nessuna delle parti e, il ### dopo averlo acquisito unilateralmente, lo avrebbe inviato ai consulenti - senza peraltro indicare la fonte di provenienzasolo con la prima bozza della relazione. Inoltre il Ctu ha travisato del tutto il contenuto di quella chat dai cui poi il ### avrebbe tratto delle conclusioni errate nel senso di attribuire al ### sin dal luglio del 2017 la conoscenza dei fatti distrattivi della ### valuta, circostanza di assoluta gravità che ha poi determinato l'affermazione di responsabilità in capo al ### ex art. 1780 c) Erroneità della consulenza per le conclusioni cui è pervenuta in punto di affermazione della responsabilità del gestore, all'epoca appunto il ### mentre invece doveva considerarsi provata, e comunque oggetto di approfondimento l'assunto della responsabilità del ### quanto al verificarsi dei doppi prelievi, dovuti, nella prospettazione della reclamante, non a negligenza quanto all'approntamento della sicurezza del software dell'exchange, ma quanto piuttosto dai numerosi e consueti e frequenti “crash” del ### La prova di quanto affermato si evincerebbe appunto dal recente comunicato emesso in data 5 febbraio 2019 con cui il ### ha ammesso il verificarsi di un “bug software” (letteralmente “baco”) del nodo registratesi sulla diversa piattaforma ### che ha portato ad una duplicazione delle transazioni di invio. d) Erroneità della sentenza per non aver correttamente considerato che, alla stregua delle stesse valutazioni del ### nessun rimprovero poteva essere mosso al precedente gestore, sotto il profilo della diligenza, per essere ### una piattaforma finanziaria assolutamente blindata sotto il profilo della sicurezza perimetrale, poiché è stato accertato che non sono state rubate le chiavi di accesso e che i furti erano attribuibili non ad intrusioni esterne, ma a fatti illeciti commessi durante la vita operativa dell'exchange da alcuni utenti che in esso si erano registrati. E tali fatti illeciti erano stati possibili solo perché taluni utenti avevano compreso che ripetendo l'operazione di prelievo in determinati momenti in cui il ### andava in crash, questo erogava per due volte la somma richiesta, registrandola nella blockchain del ### senza che però potesse configurarsi una fallacità della piattaforma per averla memorizzata una sola volta nel proprio data -base. Infatti, i ### “persi” da ### non sono stati rubati violando la piattaforma stessa o entrando in possesso delle chiavi private che ### custodiva, bensì sono stati esclusivamente prelevati sfruttando la vulnerabilità del nodo ### che era sotto l'esclusivo controllo del team di ### e su cui ### non aveva possibilità di intervenire. e) Erroneità della sentenza per aver rilevato la sussistenza di un contratto di deposito irregolare tra gli utenti e il gestore della piattaforma, inquadrabile nel deposito bancario, in base al fatto che tutte le ### valute migravano dal portafoglio individuale di ciascun utente per confluire in un portafoglio unico e centralizzato della piattaforma operativa di ### così integrando il presupposto della confusione della valuta, tipico del deposito irregolare, omettendo però di considerare che - per quanto accertato dallo stesso Ctu - mai la valuta degli utenti era stata utilizzata dal gestore non avendone questi mai acquisito la proprietà. ### in diritto in cui sarebbe incorso il ### è perciò ravvisato nel fatto che, per affermare la sussistenza di un deposito irregolare, non è sufficiente sostenere che vi sia confusione tra le varie valute ma ulteriore elemento qualificante è dato dall'effettivo utilizzo del bene fungibile da parte del depositario con l'obbligo di restituzione della medesima quantità ### ai singoli depositanti, mentre è pacifico che la piattaforma non riutilizzava il danaro depositato. Anche l'aspetto della confusione della valuta era del tutto discutibile perché l'assemblaggio della valuta in un unico database non escludeva che la proprietà delle monete rimanesse in capo ai singoli utenti che ne avevano traccia nel proprio database interno o personale. ### (e prima la ### non aveva contrattualmente alcuna facoltà di servirsi delle valute virtuali scambiate sulla piattaforma: non essendo prevista una facoltà di ritenzione e ritardo nella restituzione delle valute, vi era obbligo immediato di restituzione a semplice richiesta, evidentemente incompatibile con la facoltà di utilizzo. Pare dunque evidente che la proprietà delle criptovalute depositate era e rimaneva in capo al depositante, il quale ovviamente aveva piena autonomia in ogni decisione di prelevare, acquistare o scambiare le criptovalute. f) Erroneità delle argomentazioni del Ctu circa la fallacità del #### utilizzato da ### per registrare l'avvenuta transazione e quindi la doppia transazione sul data base dell'exchange. Rilevava il reclamante che questo profilo, assume estremo rilievo ai fini della dimostrazione della insussistenza di responsabilità in capo al ### circa la mancata contabilizzazione dei prelievi sulla exchange. Non essendo stata prevista in modo nativo la funzionalità di firma offline, ### aveva sviluppato un sistema di controlli a cascata per poter gestire al meglio la procedura di prelievo delle criptovalute ed assicurarne la corretta esecuzione. Uno di questi controlli si basava sul ### che consiste sostanzialmente in un ulteriore “Nodo” gestito dagli sviluppatori affiancato and una interfaccia web (indirizzo https://raiblocks.net) che va ad interrogare la blockchain presente per dare le informazioni richieste (saldi, transazioni, etc.). Fino alla intervenuta scoperta del furto, era sempre stato comunicato dal ### alla comunità ### che il ### era estremamente affidabile e riportava sempre ed istantaneamente tutte le transazioni. Nella stessa conversazione intrattenuta tra il ### ed il ### in occasione della scoperta del furto il ### aveva assicurato la perfetta funzionalità del block explorer (che era ed è sotto il completo ed esclusivo controllo degli sviluppatori) che visualizzava ed apponeva le date corrette nel giro di pochi secondi dall'avvenuta transazione. Soltanto a seguito della comunicazione data dal ### all'indomani dei furti il ### smentendo completamente le proprie affermazioni sull'affidabilità del ### inseriva in esso un apposito “disclaimer” per avvertire gli utenti che le date riportate non erano da considerarsi affidabili (vedi ### di parte - pag. 6, doc. 35).Quanto sopra perciò, nella difesa di BG ### rappresenta un aspetto di estrema importanza perché dimostrerebbe come ### sia stato il primo ad accorgersi di una fallacità del funzionamento dei “nodi” ### e del ### g) ### della sentenza per aver sostenuto, sulla scorta di quanto affermato dal ### la possibilità per gli utilizzatori dell'exchange di effettuare i prelievi con firma “offline” o fuori dal nodo”: al contrario tale possibilità non era dimostrata, perciò il ### non aveva alternative se non implementare controlli a cascata, che servivano proprio al controllo della corrispondenza delle transazioni, procedura che egli aveva diligentemente sviluppato e implementato. Come accertato dal CTU “### conosceva benissimo la necessità di firma fuori dal nodo delle transazioni per i ### al punto che (come confermato durante l'incontro peritale del 13 novembre 2018) correttamente la implementava e utilizzava nel suo #### infatti aveva correttamente impostato il codice dell'exchange ### per generare e firmare fuori dal nodo le transazioni ### proprio perchè sapeva - come sa chiunque si occupi di criptomonete - che era la modalità corretta di procedere” (pag. 55, doc. 3). Obiettava il reclamante che sebbene ### progettista dell'exchange, fosse a conoscenza delle modalità corrette di procedere con la di firma fuori dal nodo, non le aveva implementate sul nodo ### semplicemente perché la funzione non era prevista nativamente e una implementazione esterna non sarebbe stata tecnicamente percorribile. Sulla possibilità di firma fuori dal nodo pertanto il CTU avrebbe compiuto una affermazione meramente teorica, senza effettuare una verifica concreta con un codice funzionante e testato nelle condizioni di utilizzo dell'exchange. La conclusione a cui è pervenuto il ### secondo cui sarebbe stato onere del ### implementare la sicurezza del software quanto alla contabilizzazione delle operazioni sulla exchange, pur potendo operare firme fuori dal nodo, anche a costo di maggiori spese, non poteva essere perciò condivisibile perché non era testata la possibilità di fare transazioni siffatte ai tempi degli avvenuti ammanchi attesa la impossibilità pratica di poter generare le transazioni fuori dal nodo, e in conseguenza l'unico strumento di verifica, per accertarsi della corrispondenza delle transazioni, non poteva che essere il block explorer ### di fatto utilizzato, la cui fallacità non era imputabile al gestore della piattaforma ma al ### h) ### della sentenza per avere il ### fatto applicazione della regola di cui all'art. 1780 cc. previa qualificazione, in via subordinata, del rapporto oggetto di giudizio sub specie di deposito regolare, e quindi affermato la responsabilità del depositario anche per il fatto illecito di terzi perché questi non aveva tempestivamente denunciato la perdita della detenzione dei beni, pur essendone consapevole sin dal luglio del 2017. In realtà, osserva il reclamante, si tratta di un vero e proprio travisamento del CTU circa le espressioni utilizzate e estrapolate dalla chat di ### perché da essa può ricavarsi esclusivamente che a luglio 2017 egli si era accorto che taluni utenti avevano cercato di “spammare “(in gergo tecnico “disturbare”) il sistema inviando richieste di prelievo multiple, senza che emergesse in qualche modo da quella chat che questi fosse consapevole, sin dal luglio 2017, degli ammanchi. La circostanza rivestiva un enorme rilievo dal momento che addossa al ### non solo un comportamento negligente, ma ai limiti della condotta dolosa oltre al discredito generalizzato che ne sarebbe derivato. i) ### della sentenza per aver affermato la sussistenza dei presupposti di fallibilità della ### e primo tra tutti lo stato di insolvenza, perché non è ravvisabile alcun obbligo restitutorio o risarcitorio in capo al gestore della piattaforma ed in ogni caso l'accertamento di un obbligo siffatto avrebbe dovuto essere oggetto di accertamento di un giudizio ordinario a cognizione piena e non attraverso un accertamento incidentale come appunto avvenuto nel processo fallimentare. Nel caso specifico poi, l'assenza nelle condizioni di contratto sottoscritto dagli utenti con la piattaforma (### of use) di specifici obblighi di custodia in capo al gestore e, al contrario, la previsione dei rischi connessi all'utilizzo della piattaforma in capo agli utenti, lascerebbero intendere che le conseguenze di eventi non direttamente riferibili alla condotta di ### e connessi ai servizi che essa si è limitata a garantire non possono che gravare sugli utilizzatori. Alla luce di ciò il contratto più che di deposito in senso giuridico doveva essere correttamente inquadrato in un rapporto di mandato corredato da un deposito regolare ex art. 1766 Si è costituita la curatela che ha contestato il gravame in tutti i punti di censura e ha prodotto una nota del consulente tecnico d'ufficio ### a chiarimento del fatto nuovo circa il comunicato della ### datato 5 febbraio 2019 in merito alla problematica delle duplicazioni dei depositi registrati sulla diversa piattaforma ### nonché sulle modalità di acquisizione della chat ### infine circa le proprie considerazioni espresse in merito alle affermazioni del ### sulla chat medesima ( doc 3 curatela).
Si è costituito anche il ### che ha chiesto il rigetto del gravame per la piena condivisione delle valutazioni espresse in punto di fatto in diritto la parte del ### Si sono altresì costituiti i creditori #### e ### i quali hanno contestato motivi di censura associandosi alla richiesta di rigetto del gravame.
E' intervenuto anche il creditore ### che ha chiesto il rigetto del reclamo ###udienza del 27.9.2019 la causa è stata trattenuta in decisione previo deposito di memorie a difese già concesse alla precedente udienza del 17.5.2019. *****************************
Ravvisa innanzitutto la ### la completezza di tutti i dati informativi necessari per poter addivenire alla decisione senza necessità, in considerazione delle note del Ctu depositate dalla ### di effettuare una riconvocazione del perito per i chiarimenti richiesti, né tantomeno di effettuare un rinnovo della Ctu nella insussistenza dei presupposti di cui all'art.196 c.p.c. ### degli elementi fattuali e le osservazioni tecniche in atti, filtrate attraverso le contrastanti opinioni dei periti di pare e ricondotte ad unità nella consulenza tecnica del dott. ### portano questa ### unitamente alle osservazioni in diritto che si esporranno, a disattendere il gravame per infondatezza delle doglianze su cui si poggia.
Seguendo un ordine logico nella trattazione dei profili di gravame, rileva innanzitutto la ### che l'accertamento operato dal tribunale di ### quanto alla sussistenza di un obbligo restitutorio\risarcitorio del ### e quindi anche della ### obbligata in solido, per gli ammanchi di cripto valuta ### registrati sulla propria ### rientra perfettamente nella struttura e nella logica della cognizione fallimentare di cui all'art. 15 comma 6 e 7 L.F: si tratta, come noto, di un accertamento, che seppur incidentale, è a cognizione piena e a contraddittorio pieno perché il ### è facoltizzato ad espletare ogni specie di accertamento istruttorio funzionale all'accertamento del credito, così come di fatto è avvenuto nel caso di specie, attraverso l'espletamento della ### Proprio la CTU riveste rilevanza cruciale circa la comprensione del funzionamento della piattaforma, per la descrizione delle modalità in cui si sono verificati i doppi prelievi e quindi per l'accertamento della relativa responsabilità quanto alla tenuta della sicurezza esterna ed interna della piattaforma. Destituito di fondamento è perciò la censura sollevata al capo i) secondo cui un siffatto accertamento avrebbe dovuto svolgersi nell'ambito di un giudizio di cognizione ordinario autonomo e distinto, dal momento che nulla si sarebbe potuto aggiungere all'accertamento, non sussistendo alcun minus della cognizione svoltasi in fase fallimentare (cfr in tal senso ### 6 ordinanza n. 5001 del 14.3.2016) rispetto al giudizio ordinario di cognizione, e la natura sostanzialmente “aperta” del presente gravame, neppure soggetto, a rigore, ai limiti della formulazione dei motivi di appello ex art. 342 c.p.c. per l'efficacia devolutiva piena che gli è riconosciuta, garantisce il doppio giudizio a tutela del fallito (così Cass. Sez. I sent. n. 6306 del 19.3.2014).
Sempre seguendo un ordine logico, i motivi di reclamo di cui ai capi a) e b) che fanno leva sulla nullità della Ctu per violazione del contraddittorio sono palesemente infondati: la discrasia tra la bozza originaria e la bozza definitiva della Ctu in nulla limita o intacca il diritto di difesa di parte reclamante in quanto si tratta solo di una diversa e comunque possibile modalità di risposta che il CTU adotta alle considerazioni dei periti di parte dopo l'invio ad essi della prima relazione o bozza. In secondo luogo, le considerazioni del tutto nuove in essa contenute neppure possono considerarsi vietate perché sottratte alla logica del contraddittorio, dal momento che nuove considerazioni tecniche del perito possono rendersi necessarie proprio alla luce di quanto hanno contestato e considerato i tecnici di parte, ovvero anche solo provocate da osservazioni di parte. Ciò che rileva in realtà ai fini della salvaguardia del principio del contraddittorio è che il giudice abbia contezza di tutte le osservazioni dei periti di parte e delle controdeduzioni del perito, indipendentemente dal fatto che queste siano apposte a chiusura della Ctu o siano incorporate nel testo della consulenza.
Neppure è fondato il rilievo di nullità della CTU per la dedotta illegittima modalità di acquisizione unilaterale della chat ### in realtà il perito poteva acquisire il documento in forza dei poteri ufficiosi conferitigli dal codice ed il documento è stato sottoposto al vaglio dialettico delle parti prima che le stesse potessero sollevare le loro deduzioni: inoltre nel caso specifico il ### non ha disconosciuto la chat a cui egli aveva partecipato fino al gennaio del 2018 e nello stesso tempo non ne ha contestato la genuinità; ha solo suggerito, come gli era possibile nella logica della dialettica instaurata, la propria versione e interpretazione dell'espressione utilizzata oggetto di analisi da parte del ctu “some users try to spam….” Il motivo di reclamo che fa leva sull'erroneo inquadramento giuridico da parte del ### del rapporto contrattuale oggetto di giudizio nell'ambito del contratto di deposito irregolare di cui al motivo sub e) - valutazione da cui dipende l'obbligo restitutorio affermato dal primo giudice della rispettiva quantità di ### valuta depositata da ciascun utente sulla piattaforma ### - è infondato e deve essere respinto. La principale osservazione svolta in proposito dalla reclamante è nel senso che il gestore della piattaforma, pur facendo confluire tutta la criptomoneta depositata in un unico contenitore, con confusione dei beni, in realtà non era facoltizzato all'utilizzo della stessa: dal che discenderebbe l'impossibilità di ravvisare il contratto tipico di deposito irregolare che si fonda anche e soprattutto sull'utilizzo dei beni.
In punto di diritto l'osservazione è però del tutto priva di pregio perché il contratto di deposito irregolare è una figura del tutto sui generis che assume una diversa valenza a seconda della causa in concreto che si vuole conferire al contratto, divenendo un contratto di credito o un contratto reale di deposito.
Innanzitutto, il depositario acquista la proprietà del danaro o dei beni fungibili a lui consegnati solo se ha la facoltà di servirsene: in caso contrario la proprietà resta al depositante, ma resta sempre fermo l'obbligo di restituzione del depositario. Se è prevista la facoltà di servirsi dei beni l'interesse prevalente delle parti non è più il deposito ma l'elargizione di un credito ed è per questo che non può più essere considerato quale contratto di custodia, ma va collocato tra i contratti di credito, nei quali una parte trasferisce all'altra la proprietà di certe cose con il diritto di ottenere la restituzione di altrettante, applicandosi così, per espressa previsione dell'art. 1782 c.c. la disciplina del mutuo, figura da cui però si differenzia solo perché nel mutuo la disponibilità di servirsi delle cose da parte del mutuatario è lo scopo contrattuale, mentre nel deposito irregolare è lo scopo secondario essendo preminente l'interesse al deposito da parte del depositante.
Il deposito irregolare senza facoltà di utilizzo del bene ha una preponderante causa nell'interesse delle parti alla custodia dei beni fungibili, con obbligo comunque di restituzione delle medesime quantità degli stessi.
Si è anche affermato in giurisprudenza che la facoltà di servirsi del danaro o dei beni fungibili depositati costituisce un elemento naturale della fattispecie di cui all'art. 1742, per escludere la quale è necessaria un'apposita pattuizione derogatoria. ### tipizzante del contratto dunque non è tanto centrato sulla possibilità di utilizzo del bene e sull'acquisto della proprietà dei beni fungibili - che può anche essere escluso - ma quanto sulla consegna al depositario di beni mobili di natura fungibile che radica il correlativo obbligo di restituzione del tantundem eius generis per effetto della confusione dei beni derivanti dalla loro natura fungibile.
Nel caso di cui ci si occupa dunque, il fatto che ### pur centralizzando tutte le valute in un unico portafoglio, non abbia utilizzato i beni dei singoli utenti è del tutto irrilevante: non solo l'uso dei beni non era espressamente escluso dal contratto ma - ed è questo l'argomento più calzante - anche a voler ipotizzare che la facoltà di servirsi dei beni fosse stata esclusa, non si poteva ritenere variata la caratteristica del contratto che era un contratto di deposito irregolare per la fungibilità intrinseca della criptovaluta, con interesse prevalente per il depositante alla custodia dei beni funzionali al trading e la cosa è resa ancor più evidente dal fatto che nelle condizioni di contratto è previsto che in caso di fuoriuscita del singolo utente dall'exchange, l'obbligo di restituzione concerneva non la eadem res posseduta da ciascuno in criptovaluta, ma il controvalore in bitcoin di tutte le valute virtuali depositate.
Non può negarsi però che il principale contratto stipulato tra il gestore dell'exchange e i singoli users sia un contratto di mandato all'acquisto o allo scambio di criptovaluta, ove il trading è appunto la causa o funzione preponderante del contratto; del pari innegabile è però che strumentale ad esso, in rapporto di accessorietà necessaria, è anche il contratto di deposito, che rappresenta il presupposto di partenza per gli utenti per scambiare criptovaluta. Tale contratto non può che assumere, in ragione di quanto innanzi detto, le caratteristiche di un deposito irregolare per la natura stessa dei beni che dai wallets personali degli utenti confluivano sulla piattaforma finanziaria in un unico portafoglio centralizzato, per consentire al mandatario di dare attuazione alle operazioni di vendita, prelievo e scambio che venivano impartiti dagli utenti dai propri accounts personali.
Che le criptovalute siano beni fungibili è insito sia nella loro definizione di “valute virtuali” (corrispondenti cioè alla digitalizzazione di un valore) sia nel fatto che esse rappresentano mezzi di pagamento al pari del danaro pur non essendo emessi da un'autorità pubblica o da una banca privata.
Dunque, le criptovalute non costituiscano danaro, ma hanno del danaro la medesima funzione e le medesime caratteristiche di fungibilità.
Rileva altresì la ### che nel caso di specie è invocabile la figura del collegamento negoziale dove la causa atipica del contratto è appunto una causa mista in cui la preponderanza dell'interesse alle negoziazioni da parte dell'utente è inscindibile dal presupposto che occorra operare attraverso una piattaforma finanziaria che richiede un preventivo deposito della criptovaluta. Tutto questo per sostenere che la tesi della reclamante circa la prevalenza del contratto gestorio o di mandato sul contratto di custodia, e della correlativa normativa non è percorribile, ma le due discipline si intrecciano e si interfacciano tra loro.
La lettura delle clausole contrattuali (### of use) non consente affatto di escludere l'applicabilità della normativa relativa al deposito, perché l'assunzione dei rischi da parte dei singoli utilizzatori della piattaforma quanto alle operazioni di trading non esonera comunque il gestore all'approntamento di tutti i presidi tecnici necessari affinchè il sistema informatico della exchange sia sicuro, sia sotto il profilo della sicurezza perimetrale - nel senso che il sistema deve essere blindato da attacchi di utenti in esso non registrati - sia sotto il profilo della sicurezza interna ovvero dunque della trasparenza e della rilevabilità e tracciabilità delle operazioni di trading a tutela della conservazione del patrimonio depositato in criptovaluta dagli utenti medesimi.
Pertanto eventuali errori di funzionamento dell'exchange connessi al trading - a cui il deposito irregolare di criptovaluta è funzionalmente collegato - non possono che ripercuotersi sul contratto collegato, nel senso che diventa, sotto il profilo dell'obbligo restitutorio, irrilevante il fatto che la perdita dei beni depositati sia avvenuta per fatto illecito di terzi, quando risulti dimostrato che comunque i fatti illeciti sono stati resi possibili a causa di negligenza e imperizia del mandatario, gestore dell'exchange, nell'approntare strumenti per la sua tenuta e conservazione.
Andando perciò ad affrontare i motivi nevralgici del gravame (punti c, d, f e g) che fanno leva sulla completa assenza di responsabilità del gestore in merito alla sparizione della ### valuta dall'exchange e quindi alle cause che tale evento hanno determinato, responsabilità affermata dal ### a causa delle conclusioni cui è pervenuto il dott. ### rileva la ### che questi si rivelano del tutto fallaci perché sostanzialmente inidonei a contrastare in fatto le risultanze chiare e definitive in merito al difetto di diligenza e perizia del ### in qualità di progettista e gestore dell'exchange ### a cui è giunto l'ausiliario del giudice pur nella estrema complessità della vicenda.
Nella sostanza, il dott. ### premesso di aver accertato che il problema dei doppi prelievi era una falla della exchange ### e non del nodo ### dal momento che era ### che generava due ordini identici ma distinti che venivano perciò evasi dal nodo ### con una duplice contabilizzazione registrandoli nella propria blockchain del sistema (mentre gli ordini venivano registrati una sola volta nel data base dell'exchange) ha mosso due rimproveri al ### originario gestore di ### a) il non aver munito la piattaforma di un sistema di contabilizzazione interna delle transazioni in uscita da ### rafforzato e perfettamente sincronico con il nodo ### essendosi affidato al programma ### che, seppur elaborato dal ### non era calibrato per svolgere al meglio questa funzione e ciò egli avrebbe potuto fare perché era consentita la possibilità di firma offline, cioè al di fuori del nodo ### con la possibilità perciò di tracciare correttamente l'ordine in uscita e la relativa esecuzione dello stesso; in secondo luogo per non essersi attivato prontamente, bloccando la piattaforma e inibendo l'ulteriore trading, una volta che aveva già avuto sentori di richieste di prelievo anomale perché consecutive e di pari importo, al punto da condividere questo problema con il ### già nel luglio del 2017 quando si è verificato il più elevato numero di prelievi multipli (sebbene poi il picco si sarebbe raggiunto, per quantità della valuta sottratta, solo nell'ottobre 2017); in ogni caso per non aver fatto verifiche contabili periodiche che avrebbero consentito di rilevare la suddetta asincronia di dati registrati nella blockchain del nodo ### e nel database dell'exchange, verifica che seppur avrebbe sospeso l'operatività della piattaforma e il frenetico trading che in esso si svolgeva, avrebbe in ogni caso consentito l'immediata enucleazione degli ammanchi.
Andando con ordine, e quindi affrontando il motivo sub c) la reclamante contesta l'affermazione di partenza che sia stato ### a generare due ordini multipli differenti che venivano evasi dal ### in quanto appunto percepiti come ordini distinti e consentiti dalla piattaforma la quale le inviava senza registrare il primo ordine di prelievo (quando invece, per un corretto funzionamento del sistema, era la piattaforma che avrebbe dovuto bloccare il secondo ordine e non farlo partire se non prima aver ricevuto risposta e quindi contabilizzato il primo prelievo andato a buon fine). ### e così ### sostengono che era il sistema ### che in determinati momenti andava in crash e quindi percepiva il doppio ordine di prelievo come ordine differente, e quindi non identico e perciò non operava l'effetto dell'idempotenza (ndr. principio in forza del quale il secondo ordine identico viene percepito come inefficace e il sistema evade solo il primo): la prova di quanto affermato si evincerebbe da un fatto nuovo e sopravvenuto verificatosi nel febbraio 2019 che ha coinvolto la diversa piattaforma finanziaria ### ha chiesto perciò la convocazione a chiarimenti del ### Su questo punto la ### fallimentare ha richiesto spiegazioni al perito e ha depositato in allegato alla comparsa di costituzione una nota a chiarimenti del CTU (doc.3). Quanto allo specifico problema che ha interessato appunto la piattaforma ### il dott. ### ha così risposto: “l'incidente menzionato è in realtà avvenuto a causa di una particolare funzionalità del software ### chiamata “epoch blocks”, introdotta nella versione 15.0 del codice pubblicata il 14 luglio 2018. Non è stata coinvolta la rete ### o il protocollo, bensì uno specifico nodo - quello dell'exchange ### - che non aveva aggiornato il codice all'ultima versione. Il 21 gennaio 2019 infatti era già stata pubblicata una versione del codice, la 17.1, che rimediava proprio a questo bug identificato il 14 gennaio 2019. Questo significa che questo fenomeno non avrebbe potuto accadere prima del 14 luglio 2018, perchè il codice stesso che ne ha permesso il verificarsi non esisteva ed è esistito solamente tra le versioni 15.0 e 17.0, versioni che l'exchange ### non ha mai utilizzato perché gli ammanchi e la chiusura si sono verificate in un periodo precedente.” Pur senza riportare per intero la spiegazione del problema fornita dal consulente - che è a questo punto irrilevante ai fini della questione che qui interessa perché il problema è dipeso appunto da un aggiornamento successivo al sistema ### non utilizzato da ### - rileva la ### che anzi il comportamento di ### è dimostrativo di una particolare diligenza nella tenuta nei controlli della propria piattaforma in quanto il gestore di ### ha immediatamente bloccato le transazioni.
Il fatto nuovo non è dunque né decisivo e né pertinente, e inutile sarebbe la convocazione del ### Escluso questo aspetto, il reclamo sul punto della addebitabilità dei doppi prelievi al nodo anziché all'exchange ### nulla di nuovo aggiunge alla dialettica sviluppatasi in primo grado.
Deve però la ### osservare che un aspetto assolutamente trascurato dalla reclamante è che, vertendosi in materia di obbligazione restitutoria da contratto, e quindi di responsabilità contrattuale, la prova che l'inadempimento dell'obbligazione è dipesa da fatto non imputabile al debitore gravava secondo il parametro dell'art.1218 interamente sul gestore dell'exchange (quindi la prova che i furti si siano verificati per un malfunzionamento del ### anziché del programma della piattaforma ###. La pretesa poi di un test concreto da parte del CTU sulla modalità di prelievo e di funzionamento della piattaforma è assolutamente infondata in quanto il ### ha dichiarato di non aver mantenuto copia della precedente versione del software utilizzato quando si sono verificati gli ammanchi: di conseguenza l'assenza del codice sorgente della piattaforma ### dell'epoca impedisce di poter simulare l'accaduto. ###, come è noto, si era espresso nel senso che ciò che ha permesso a taluni utenti di prelevare una così grande quantità di cripto moneta ### è stata la sommatoria di doppie richieste inviate da ### al ### che hanno causato doppi prelievi a fronte di un'unica contabilizzazione. In sostanza il software dell'### non era in grado, per sua errata progettazione, di verificare e gestire l'esito delle richieste di prelievo da parte degli utenti, che venivano girate direttamente al nodo inviando (quando non rilevava effettiva fuoriuscite dei fondi) più volte richieste di pari importo e generando così prelievi multipli. Il problema pertanto veniva correttamente ravvisato dal Ctu in un problema di processo, cioè di comunicazione tra la piattaforma e il #### di ### non è stato perciò causato da carenza della sicurezza perimetrale ma è stato causato da una caratteristica che si potrebbe definire “vulnerabilità di sviluppo nel protocollo di gestione dei prelievi implementata dall'exchange ### che non teneva conto dei limiti intrinseci delle operazioni asincrone e non idempotenti”; e cioè da un problema nel processo di gestione delle cripto monete in particolare delle modalità con le quali ### impartiva ordini di prelievo di cripto monete nano per conto dei propri utenti al nodo nano, perché la piattaforma non predisponeva nel giusto modo le richieste ed effettuava controlli scorretti, talvolta generando una seconda richiesta di prelievo.
In maniera ancora più esplicativa la dinamica del problema è stata ben chiarita a pag. 67 in questi termini: “la ragione per la quale la rete ### ha potuto eseguire le transazioni ### richieste in modo multiplo, ossia quelle non autorizzate oltre la prima effettivamente autorizzata, deriva dunque dal fatto che l'### conservava tutta la cripto valuta ### in un unico portafoglio con un saldo sufficiente a soddisfare qualsiasi richiesta di prelievo. Inoltre, la cosa più importante, l'hash, cioè la firma - una sorta di codice CRO come nei bonifici - di ognuna delle singole transazioni componenti le transazioni multiple era diversa nonostante ### richiedesse al nodo un prelievo più volte convinto che si trattasse sempre dello stesso prelievo. Ed in effetti, agli occhi del nodo le transazioni sono state elaborate come transazioni diverse mentre per ### le transazioni di prelievo effettivamente uscite erano singole con unico valore hash e unica entry nel database “withdraws” che teneva traccia di ogni singola richiesta di prelievo ufficiale andata poi a buon fine o meno.” Che si trattasse di un problema dell'exchange e non del ### si desumerebbe poi dal fatto che il CTU ha garantito, che il protocollo ### prevede sin dalla sua origine la possibilità di evitare prelievi multipli generando la richiesta di prelievo per chi gestisce un unico conto per più soggetti: come emerso nel corso della CTU per far ciò occorre costruire la transazione e tra i parametri da impostare vi è il bilancio del conto e l'hash dell'ultima transazione. Per cui anche se arrivassero due richieste di prelievo identiche solo la prima avrebbe effetto cioè la transazione sarebbe idempotente, perché il ### le avrebbe scartate evitando il problema che si è verificato.
Alla critica mossa dal consulente dott. ### circa il rilievo che la problematica evidenziata si verificava per colpa del ### e dei suoi frequenti crash, che non riconosceva che si trattava di un'unica richiesta di prelievo, il consulente aveva già risposto nel senso che non è dimostrato che le uscite multiple si siano sempre verificate in costanza dei crash del nodo e che comunque la circostanza dedotta dal ### non è verificabile.
E' invece verificato è accertato che il ### applicava il principio dell'idempotenza, ragion per cui ogni uscita multipla è nata come richiesta multipla da parte di ### e il ### l'ha eseguita non avendo visione sulla reale contabilità dell'exchange.
Il problema pertanto si sposta a questo punto sulla fallacità delle contabilizzazioni delle date dei prelievi, oggetto di censura di cui al punto f).
Il reclamo si sostanzia, in estrema sintesi sul fatto che non sarebbe imputabile al gestore dell'exchange la fallacità del servizio esterno ### utilizzato per tracciare i prelievi all'interno dell'exchange, sostenendo che il team ### che lo aveva sviluppato ne aveva da sempre garantito l'affidabilità: il punto di critica è tuttavia debole perché il Ctu ha chiarito che tale strumento non nasceva per l'uso fattone da ### pertanto ogni controllo fatto attraverso esso non poteva considerarsi attendibile dal momento che si trattava di un servizio esterno che poteva essere disallineato in determinati momenti dal ### che eseguiva le richieste di prelievo. ### infatti rileva come poiché il prelievo di nano non veniva gestito al di fuori dal nodo ma all'interno di esso era necessario implementare procedure di controllo e di comunicazione diverse non affidate a un sistema di controllo esterno che poteva non essere allineato e sincronizzato al ### cosa questa che avrebbe implicato maggiori risorse, anche di sviluppo, ma avrebbe di sicuro impedito la doppia spesa rendendo idempotenti le transazioni. Il ctu ha in sostanza affermato che per la sua stessa operatività che era al di fuori sia dell'exchange che del ### il ### non poteva assicurare la perfetta corrispondenza tra le transazioni eseguite e quelle memorizzate nel data base dell'exchange. La doglianza pertanto non produce alcuna critica alle affermazioni del ### perché è stata sostenuta a monte l'inadeguatezza di questo sistema di verifica, per cui è corretto sostenere che era il gestore della piattaforma, che accettato il rischio di avvalersi di un ulteriore ### esterno, avrebbe poi dovuto occuparsi della verifica periodica, della corrispondenza delle transazioni contabilizzate a quelle effettivamente eseguite dal ### Quanto all'ulteriore censura mossa al capo g) sempre connessa alle cause che hanno generato il prelievo multiplo, la reclamante ha sostenuto che non era possibile implementare processi di verifica quanto alla correttezza delle date delle transazioni diversi da quelli di fatto utilizzati, perché il sistema ### non consentiva di firmare e quindi generare transazioni fuori dal ### prima del 16.12.2017, cioè sviluppando un codice autonomo che tracciava la richiesta all'interno del sistema ### e di cui poteva aversi memoria nel data-base dell'exchange e che avrebbe di sicuro impedito la possibilità di generare una duplice richiesta. Su questo punto però il CTU è stato ulteriormente chiaro specificando che invece è sempre stato possibile eseguire firme fuori dal nodo con procedure note già da giugno 2017 e pubblicate su diversi manuali on line da parte della comunità ### Da tali scritti emergerebbe come l'utilizzo del nodo come centro contabile era previsto, come in generale avviene anche per le altre cripto monete, solamente per gli utenti singoli con il loro wallet privato e cioè per attività di scambio non intense. Le piattaforme di exchange, invece, sono sempre state invitate a gestire in modo autonomo le transazioni proprio perché conferire tutta la fiducia al nodo implica un alto rischio e non soltanto per le eventuali doppie transazioni. La firma al di fuori dal ### cioè garantisce all'exchange maggiore sicurezza perché consente di identificare completamente l'ordine di prelievo per lo sviluppo di un autonomo codice e il ### di ciò era consapevole e usava tale procedura per i bitcoin: ove tale procedura fosse stata utilizzata anche per la ### valuta non sarebbe stato perciò necessario utilizzare il block explorer per le verifiche della corrispondenza delle transazioni. La reclamante, sulla scorta di quanto affermato da ### si limita a sostenere che tale procedura non era stata implementata perché non possibile e tanto sarebbe confermato dalla circostanza che solo il 12 febbraio 2018, dopo gli ammanchi subiti da ### il ### aveva avviato la richiesta di sviluppo di una modifica alla funzione “Send” con l'integrazione della possibilità di impostare un codice identificativo Id univoco, destinato proprio a garantire interamente al nodo l'idempotenza. A questo rilievo il CTU ha ribattuto già dall'inizio che questa modifica in realtà equivale ad una semplificazione della procedura ma non esclude che già da prima non fosse possibile generale e firmare blocchi offline.
Il rilievo critico perciò del reclamante che l'utilizzo della firma off line era preclusa perché altrimenti egli l'avrebbe adottata, così come aveva fatto per i ### non rappresenta un vero motivo di critica all'operato del ### il quale si è limitato semplicemente a prendere atto che questi, pur potendo adottare un sistema più sicuro ha preferito utilizzare il nodo come centro contabile delegando all' ### poi il compito di sincronizzare i prelievi.
Alla luce di quanto esposto, del tutto superfluo è la doglianza espressa al punto d) circa la sicurezza perimetrale esterna della piattaforma perché né il CTU né il ### hanno mai avanzato alcun rimprovero di diligenza al gestore su tale aspetto, una volta chiarito che la problematica dei doppi prelievi nulla ha a che vedere con la sicurezza esterna, essendo accertato che l'ammanco è derivato da un difetto di programmazione dell'exchange intrinseca e che quindi si tratta di un problema di processo interno che ha consentito di sviluppare le richieste multiple e la loro non corretta contabilizzazione.
I rimproveri perciò che il Consulente muove al gestore della piattaforma si fondano su aspetti diversi, appunto quelli esaminati, a cui il ### - deus ex machina del programma - avrebbe peraltro potuto porre rimedio in prevenzione - non appena avuto sentore o contezza delle richieste di prelievo identiche o multiple sin dal luglio 2017 - attraverso le condotte indicate a pag. 72 e ss. della Ctu. Tra le condotte indicate, quella più semplice tra tutte, era quella di operare un confronto tra le transazioni in uscita dal nodo e quelle indicate nella tabella dei prelievi dell'exchange: confronto questo che poteva essere eseguito anche a piattaforma attiva perché avrebbe riguardato poche decine di transazioni al giorno di verifica e avrebbe permesso di identificare anche una sola transazione anomala o non autorizzata.
Preme a questo punto affrontare l'ulteriore profilo di censura di cui al capo h) in cui la società reclamante contesta decisamente l'affermazione del ### mutuata dalla Ctu -di cui chiede la chiamata a chiarimenti - circa la maturata consapevolezza della esistenza dei cospicui ammanchi sin dal luglio del 2017.
Su questo punto il Ctu ha dedotto ulteriormente - fugando ogni equivoca interpretazione delle proprie affermazioni - con la nota depositata in allegato 3 dalla ### Esattamente il perito ha chiarito di non aver mai affermato che il ### avesse avuto consapevolezza dei prelievi multipli e quindi degli ammanchi - peraltro ingenti, di 2,5 ml di ### - sin dal luglio 2017, ma di aver solo affermato che dalla chat acquisita emerge che egli si era reso conto che molti utenti avevano inviato richieste multiple cercando di “spammare” il sistema operativo. Testualmente il Ctu scrive: “Lo scrivente ribadisce che il fatto che dalla chat emerge che il ### avesse identificato a luglio 2019 l'attacco in corso e comprese le modalità tecniche di esecuzione non significa che ne avesse anche compreso le conseguenze: non sono state infatti trovate dallo scrivente prove che il ### avesse realizzato già a luglio 2019 come a seguito di tale assedio fossero stati sottratti oltre due milioni di ### …. E' certamente rilevante però - da qui l'importanza della chat - che a fronte di un tale attacco e del riconoscimento della modalità di esecuzione così massiccia (ricordiamo che il numero dei doppi prelievi databili a luglio è di gran lunga maggiore di quelli avvenuti in tutto il resto dell'anno) e peculiare (versamenti e prelievi continui della stessa cifra in modo veloce e ravvicinato) la risposta sia stata chiudere alcuni account senza verificare in alcun modo i danni subiti…” Rileva la ### perciò che effettivamente vi è stato un fraintendimento del ### su questo aspetto, tuttavia però l'errore commesso non determina alcuna conseguenza sotto il profilo della decisione assunta in questa sede perché il profilo di censura che attiene alla qualificazione del contratto di deposito come deposito regolare e alla responsabilità del ### per la mancata tempestiva denuncia degli ammanchi resta in realtà superato dalla qualificazione conferita da questa ### al contratto di deposito come deposito irregolare.
Ma in ogni caso, anche a voler aderire alla qualificazione subordinata di deposito regolare, l'errore in fatto in cui è incorso il ### perde di concreto rilievo perché, per quanto innanzi ampiamente argomentato, la responsabilità principale del ### si fonderebbe non sulla tardiva denuncia ma sul fatto di non aver reso la piattaforma immune dalle sparizioni di criptovaluta effettuate al suo interno da operatori esperti; nonché per non aver approntato tempestive cautele - pur avendo avuto univoche avvisaglie di tentativi anomali di doppie richieste di prelievi dall'interno del sistema - per scongiurarle, in sostanza per non aver reso la piattaforma ### immune dalle degenerazioni operative che hanno portato all'enorme ammanco registrato.
Il fatto che i prelievi duplici si siano verificati per fatti illeciti di terzi non esonera il ### da responsabilità per essere stato, in qualità di gestore, anche il custode della piattaforma e dei fondi ivi depositati e per essere stata accertata la fallacità del sistema di prelievo, per come è stato chiarito dalla laboriosa perizia in atti, e per non essersi tempestivamente adoperato in prevenzione dei successivi ammanchi che si sono verificati anche successivamente in ottobre 2017, una volta accertata la sua consapevolezza che vi erano tentativi di forzatura del sistema che avrebbero comunque imposto, secondo prudenza e diligenza, di accertarne il fine e gli effetti.
Le verifiche contabili di fatto non sono mai state seguite prima del gennaio 2018 quando l'ammanco era ormai iperbolico, e, anche a voler ragionare come la reclamante, secondo cui le verifiche per essere effettuate avrebbero imposto il blocco della piattaforma con grave danno per le transazioni in corso, o comunque, perché i dati sarebbero stati approssimativi, non regge alla prova della diligenza in un contratto caratterizzato dalla responsabilità ex recepto. Senz'altro è rilevabile che la scelta del ### di non indagare ulteriormente bloccando la piattaforma è stata volontaria, e forse anche motivata dal fatto che, proprio nel momento in cui di fatto si sono verificati gli ammanchi, la cripto valuta ### stava raggiungendo l'apice del suo valore (se si considera che il valore iniziale nell'aprile 2017 era di 0,01$ per arrivare nel dicembre 2017 a 36 $) quindi con un incremento di valore esponenziale che si rifletteva anche sui profitti incassati dalla piattaforma nelle operazioni di trading, come ha appunto dimostrato la ### in sede attraverso la nota prodotta dalla ### Assorbito e superato resta l'ultimo profilo di reclamo sub i) relativo ai presupposti di fallibilità dell'impresa per l'affermata insussistenza dei requisiti dimensionali. Il motivo rappresenta una duplicazione delle doglianze già mosse quanto all'esclusione dell'indebitamento globale quantificato in 120 milioni di euro. Rileva la ### che alla luce di quanto sopra argomentato il credito nel suddetto ammontare sussiste, è scaduto e tale aspetto surclassa anche la verifica degli altri profili, seppur la soglia quantitativa per l'assoggettabilità a fallimento di cui all'art. 1 comma 2 sarebbe integrata anche quanto al patrimonio netto.
Le spese seguono la soccombenza e si liquidano come da dispositivo, tenuto conto dello scaglione tariffario previsto per le cause di valore indeterminabile (così Cass. Sez. Unite n.16300 del 24.7.2007) che per la natura del procedimento deve considerarsi di complessità alta, anche se deve opportunamente operarsi una riduzione in considerazione del fatto che identica difesa è stata espletata nel connesso procedimento n. 358\19.
Ricorrono invece giusti motivi per compensare le spese tra il reclamante e l'intervenuta ### tenuto conto che tale creditore è intervenuto solo nella fase conclusionale e la memoria di costituzione è meramente adesiva alle difese ampiamente spiegate dagli altri contraddittori reclamati. ### dà atto altresì della ricorrenza dei presupposti di cui all'art 13 comma 1 quater D.P.R. 115\02 per il raddoppio del contributo unificato. P.Q.M. ### di ### definitivamente pronunciando, sul reclamo proposto da ### in qualità di esercente l'impresa individuale ### avverso la sentenza dichiarativa di fallimento del ### di ### n.17 del 21.1.2019, ogni diversa domanda ed eccezione disattesa: i Rigetta il reclamo e per l'effetto conferma la sentenza impugnata. i Condanna parte reclamante alla rifusione delle spese nei confronti della curatela e dei creditori, spese che si liquidano in € 6.000,00 per la ### e in € 7.000,00 per i creditori (costituiti con unica comparsa), oltre rimborso forfettario e accessori di legge. i Compensa le spese tra la reclamante e ### i Si dà atto della ricorrenza dei presupposti di cui all'art 13 comma 1 quater D.P.R. 115\02 per il raddoppio del contributo unificato. i Manda alla ### per le notificazioni e per gli altri adempimenti di cui all'art. 18, comma 13 ### deciso in ### nella camera di consiglio del 28.2.2020 ### estensore ### dr.ssa ### dr. ###
causa n. 358/2019 R.G. - Giudice/firmatari: Loprete Annamaria, Carnemolla Maria Guglielma, Sgambati Giovanni
v5.31
