Tallone d’Achille dell’open source: Nofx e il dramma delle 9.000 stelle, il fiasco del fork e la controversia sull’open source

Titolo originale dell’articolo: «Tallone d’Achille dell’open source: Nofx e il suo percorso di 2 mesi e 9.000 stelle, tra attacchi informatici, scontri interni e polemiche sull’open source»

Autore originale dell’articolo: @wquguru

Contesto dell’articolo

Prima di approfondire questa vicenda, devo chiarire la mia posizione rispetto all’accaduto.

Sono un osservatore e un analista. Durante il periodo di massima popolarità del progetto Nofx, avevo sviluppato il progetto nof0, ispirato a nof1. Nel corso dello sviluppo, ho avuto scambi con i membri principali di Nofx, Tinkle e Zack, soprattutto su implementazioni tecniche e collaborazione open source.

È importante precisare che i miei rapporti con il team Nofx erano esclusivamente di natura tecnica e non comportavano alcuna partnership commerciale. Non ho avuto contatti diretti con il team di ChainOpera AI (COAI). Nel redigere questo articolo, mi impegno a mantenere una posizione obiettiva e imparziale. Tutte le analisi e le valutazioni si basano su informazioni pubblicamente disponibili, tra cui registrazioni GitHub, post sui social media, rapporti di sicurezza e altro.

Cronologia degli eventi:

• Fine 10/2025: viene lanciato il progetto Nofx che, in soli 2 mesi, raggiunge quasi 9.000 stelle su GitHub.

• 11/2025: viene resa nota una vulnerabilità di sicurezza e SlowMist pubblica un avviso di sicurezza (Hackgate).

• 12/2025: scoppia una disputa sulla licenza open source (Open Source Drama), mentre emergono le fratture interne al team (Infighting).

L’intera vicenda si è svolta nell’arco di circa 2 mesi, ma ha messo chiaramente in luce diverse contraddizioni del movimento open source di Web3.

Lo scopo di questo articolo non è schierarsi o incolpare qualcuno, bensì:

• Ricostruire in modo completo questo caso emblematico del movimento open source di Web3
• Esaminare i conflitti profondi tra etica open source e interessi commerciali
• Offrire spunti di riflessione e riferimenti per i futuri sforzi di standardizzazione del settore

Cominciamo ora a districare questa intricata vicenda dall’inizio.

Atto I: l’ascesa fulminea di un progetto di trading AI

Alla fine di 10/2025, su Twitter è apparso un progetto di trading automatizzato basato sull’AI, chiamato Nof1. Nel giro di pochi giorni, diverse varianti open source, tra cui nof0, nofx e altre, hanno raccolto migliaia di stelle su GitHub. Tra queste, Nofx, il cui sviluppo è iniziato alla fine di ottobre, aveva accumulato più di 9.000 stelle a dicembre, diventando uno dei progetti open source più importanti nel settore del trading AI.

Tuttavia, appena due mesi dopo, questo progetto un tempo promettente si è trovato ad affrontare una triplice crisi:

Hackgate: la società di sicurezza blockchain SlowMist ha rivelato una grave vulnerabilità di sicurezza in Nofx, esponendo le chiavi API degli exchange, le chiavi private e gli indirizzi dei crypto wallet di più di 1.000 istanze distribuite in rete. Grandi exchange come Binance e OKX sono intervenuti con urgenza per aiutare gli utenti interessati a sostituire le credenziali.

Crisi dei conflitti interni: Tinkle, membro centrale del progetto, ha accusato pubblicamente il cofondatore Zack di aver partecipato solo per 14 giorni, contribuendo con poche righe di codice, e di aver comunque preteso una quota di proprietà del 50% e 500.000 $. Zack, a sua volta, tramite un legale, ha accusato Tinkle di appropriazione indebita di beni e di dirottamento dei profitti, fornendo documenti di registrazione della partnership che mostrerebbero una quota del 50% per ciascuna delle parti.

Crisi open source: Nofx ha accusato pubblicamente ChainOpera AI (COAI), che ha raccolto 17 mln $, di aver violato la licenza open source AGPL distribuendo un prodotto commerciale basato sul suo codice senza renderlo open source. COAI ha replicato che il 03/11 Nofx era ancora soggetto alla licenza MIT e che era passato alla AGPL solo il 04/11; inoltre, il suo prodotto sarebbe stato sviluppato in Python, risultando completamente diverso dall’implementazione di Nofx in Go.

Come ha fatto un progetto open source sostenuto dalla community a ritrovarsi invischiato in una crisi così complessa in appena due mesi? Quali problemi sistemici della community open source, dei team imprenditoriali e degli ecosistemi di investimento emergono da questa vicenda? Esaminiamo la controversia attraverso cinque domande chiave.

Domanda 1: la licenza open source è stata davvero violata?

MIT contro AGPL: due filosofie open source divergenti

Prima di discutere la disputa sulla licenza tra Nofx e COAI, dobbiamo comprendere le differenze fondamentali tra queste due licenze open source:

La licenza MIT (Massachusetts Institute of Technology License) è una delle licenze open source più permissive. Consente:

• Uso, modifica e distribuzione del codice senza restrizioni
• Uso commerciale senza obbligo di rendere il codice open source
• Unica condizione: conservare l’avviso di copyright originale

La AGPL v3.0 (GNU Affero General Public License) è una delle licenze open source più restrittive. Impone che:

• Qualsiasi progetto che utilizzi questo codice debba essere a sua volta open source
• In particolare, anche quando si offre un servizio via rete (come SaaS), il codice sorgente debba essere reso pubblico
• Le informazioni sul progetto originale siano indicate in modo ben visibile

Passare dalla MIT alla AGPL significa compiere una svolta di 180 gradi, da «estremamente permissiva» a «estremamente restrittiva». È anche il fulcro della controversia attuale.

Modifica della licenza e disputa sulle date

La licenza open source del progetto Nofx è stata modificata da MIT ad AGPL, ma il momento esatto della modifica è diventato oggetto di una controversia centrale. Questa cronologia è cruciale perché determina direttamente quale licenza il team di ChainOpera (COAI) avrebbe dovuto rispettare nel creare un fork del codice.

Confronto delle prove presentate dalle due parti:

• Il team Nofx ha fornito le registrazioni dei commit di GitHub che mostrano quando è stato modificato il file della licenza
• Il team COAI, invece, sostiene che, sulla base delle proprie registrazioni e osservazioni, ci siano dubbi sulla data in cui la modifica della licenza è diventata pubblica

Le accuse di plagio rivolte a ChainOpera

La community Nofx ha scoperto che il codice di ChainOpera (COAI), che ha raccolto 17 mln $ e ha debuttato su Binance Alpha, era molto simile a quello di Nofx.

Le accuse di Nofx:

• COAI avrebbe utilizzato il codice di Nofx senza citarne la fonte e senza rendere pubblico il codice sorgente
• In base alla licenza AGPL in vigore in quel momento, COAI avrebbe dovuto:
Indicare chiaramente la fonte del codice
Rendere pubblico il codice sorgente modificato
Adottare a sua volta la licenza AGPL

La risposta di COAI:

• Sostiene che, quando ha creato il fork del codice, Nofx fosse ancora soggetto alla licenza MIT
• La licenza MIT consente l’uso commerciale senza l’obbligo di rendere il codice open source
• La disputa sulle tempistiche della modifica della licenza influenza la natura dell’intera vicenda

Controversia sulla licenza open source: chi ha ragione?

Questa disputa ha portato alla luce problemi profondamente radicati nell’ecosistema open source di Web3:

Validità della modifica della licenza:

• Disputa sull’effetto retroattivo: una modifica della licenza open source si applica retroattivamente al codice di cui è già stato creato un fork?

• Ambiguità delle date: è difficile accertare il momento esatto della modifica della licenza e ciascuna parte sostiene la propria versione dei fatti

• Integrità delle prove: le registrazioni di GitHub potrebbero essere state alterate; è quindi necessaria una verifica più autorevole da parte di terzi

• Comunicazione della modifica della licenza: fino a che punto è stata comunicata alla community la modifica dalla MIT alla AGPL?

Conflitto di interessi commerciali:

• COAI ha ricevuto ingenti finanziamenti ed è stata quotata su Binance: ha quindi un significativo valore commerciale
• Nofx, in quanto progetto open source, non dispone di un chiaro percorso di commercializzazione

• Conflitto centrale: il delicato equilibrio tra l’etica open source e la tutela degli interessi commerciali

Divergenze di opinione nella community:

• I sostenitori di Nofx affermano che COAI stia sfruttando codice open source a scopo di lucro senza restituire nulla alla community
• I sostenitori di COAI sostengono che la licenza MIT consenta l’uso commerciale e sollevano dubbi sulle tempistiche della modifica della licenza
• Gli osservatori neutrali sottolineano che la disputa sulle tempistiche è cruciale e che, per formulare un giudizio, servono prove più affidabili

Zone grigie legali e tecniche:

• La validità giuridica delle licenze open source nei progetti on-chain resta poco chiara
• La possibilità di manomettere le registrazioni di GitHub ne compromette il valore probatorio
• Il settore Web3 non dispone di un meccanismo maturo per risolvere le controversie open source

Riepilogo: un’accusa controversa

Sulla base delle prove attualmente disponibili, le accuse di Nofx a COAI per violazione della licenza open source sollevano diversi dubbi:

1. Data contestata: le prove di GitHub indicano il passaggio alla AGPL il 04/11

2. Implementazioni tecniche diverse: la presenza degli stessi nomi di interfaccia non implica necessariamente che il codice sia identico

3. Interpretazione ragionevole dei log: la funzionalità di statistiche inserita durante la fase MIT continuerebbe a registrare dati

4. Coinvolgimento nella condotta contestata: non informare gli utenti della presenza di analisi integrate potrebbe violare le leggi sulla privacy

5. Comunicazione affrettata: un’e-mail e un’accusa pubblica sono state inviate a pochi minuti di distanza

Vale la pena notare che la disputa sul momento della modifica della licenza ha un impatto decisivo sulla natura dell’intera vicenda. Se la versione di Nofx è corretta, COAI avrebbe effettivamente violato la licenza AGPL; se invece è corretta la versione di COAI, le sue azioni sarebbero pienamente conformi alla licenza MIT. Per stabilire questo momento servono ancora verifiche più autorevoli da parte di terzi.

Questione 2: bastano 14 giorni per avere diritto al 50% del capitale?

Se la crisi open source riguarda la disputa tra Nofx e soggetti esterni, quella dei conflitti interni è la pubblicizzazione delle tensioni interne al progetto: una battaglia tra i fondatori su «contributo» e «valore».

Cronologia: dall’ingresso allo scontro

28/10/2025: Nofx avvia lo sviluppo

29/10/2025: Zack entra nel progetto (che era stato reso open source solo il giorno prima)

Inizio 11/2025: Zack chiede una quota del 50%, sostenendo di poter coinvolgere Amber Group nella commercializzazione

Inizio 11/2025: Tinkle rifiuta di cedere una quota del 50%, afferma di essere CEO e CTO del team e ritiene insufficiente il contributo di Zack

19/11/2025: l’avvocato di Zack (dalla sede di Hong Kong di JunHe LLP) invia una formale lettera di richiesta per il riacquisto delle quote, «Without Prejudice Save as to Costs», chiedendo 500.000 $ per ricomprare la quota del 50% di Zack

12/2025: il conflitto diventa pubblico e le due parti si accusano reciprocamente sui social media

Considerando la cronologia, è passato meno di un mese dall’ingresso di Zack all’invio della lettera legale: un periodo davvero breve.

Stallo: due versioni dei fatti e due serie di prove completamente diverse

La versione di Tinkle:

Zack ha partecipato al progetto solo per 14 giorni

• Ha contribuito con poche righe di codice («verificabile»)
• È entrato quando il progetto era già open source e il gruppo Telegram aveva migliaia di membri
• Ha usato la promessa di coinvolgere Amber negli investimenti come leva per chiedere una quota consistente
• Dopo il rifiuto della richiesta, ha tenuto in ostaggio l’account Twitter del progetto
• Ha chiesto 500.000 $ tramite una lettera legale, con accuse di estorsione
• Zack era stato stagista presso Amber, ma se n’era andato prima di essere assunto a tempo pieno
• Alla fine non è riuscito a ottenere un investimento da Amber

La replica di Zack:

• Ha fornito i documenti di registrazione della società APEIRON LABS PTE. LTD.
• I documenti mostrano che Tinkle e Zack detengono ciascuno una quota del 50%
• Si tratta di informazioni pubbliche nel sistema di registrazione delle società di Singapore, verificabili da chiunque
• La lettera dell’avvocato è una normale «proposta transattiva senza pregiudizio», conforme alle procedure legali commerciali
• Si tratta di una lettera di richiesta che descrive le condotte di Tinkle: «appropriazione indebita di beni e dirottamento dei profitti»
• 500.000 $ non è una richiesta estorsiva, bensì il riacquisto della legittima quota di Zack a una valutazione scontata
• Domanda di contraccambio: se la società ha valore, non sarebbe ragionevole riacquistare la quota del 50% a una valutazione di 1 mln $? Se invece non ha valore, perché Tinkle definisce la richiesta «estorsione»?

La contraddizione centrale: come si quantifica il contributo?

La sostanza di questa disputa è un dilemma imprenditoriale vecchio quanto il settore: contributo tecnico o segnalazione di risorse, quale dei due vale di più?

Dal punto di vista del contributo al codice, l’argomento di Tinkle può avere un certo fondamento. La cronologia dei commit di GitHub è pubblica e, se Zack ha effettivamente effettuato solo un numero limitato di commit, la community tecnologica può verificarlo facilmente. In un progetto sviluppato nell’arco di 60 giorni, se una persona vi ha partecipato per 14 giorni, la differenza nel contributo in termini di tempo e quantità di codice è effettivamente significativa.

Dal punto di vista della proprietà, però, Zack ha presentato documenti legali. Le informazioni di registrazione di APEIRON LABS PTE. LTD. mostrano che entrambe le parti hanno firmato un accordo per la ripartizione del capitale al 50-50. Questo implica che:

1. Le due parti avevano già stipulato un accordo legale formale

2. L’accordo riconosce a Zack la proprietà del 50%

3. Non si tratta di una promessa verbale, ma di un fatto giuridico registrato presso un ente governativo

La domanda, quindi, è: perché Tinkle ha accettato una simile ripartizione delle quote?

Quanto vale l’asso nella manica di Amber?

La variabile chiave è Amber Group, o più precisamente il suo acceleratore dell’ecosistema, amber.ac

L’asso nella manica di Zack è la sua capacità di coinvolgere Amber nella commercializzazione di Nofx. Secondo Tinkle, Zack era stato in precedenza uno stagista presso Amber (anche se se n’era andato prima di essere assunto a tempo pieno). Nel settore delle criptovalute, ottenere il sostegno e i finanziamenti di un’istituzione di primo piano grazie alle proprie relazioni può avere un valore enorme.

Ma il risultato finale è stato:

1. Amber non ha investito formalmente in Nofx

2. Dichiarazione ufficiale di Amber: nessuna «incubazione, investimento o partnership commerciale» formale con Nofx

3. Amber riconosce di aver avuto «scambi amichevoli», ma questi non hanno portato a una collaborazione formale

Questo lascia spazio a due possibili interpretazioni:

Interpretazione A (a sostegno di Tinkle): Zack ha esagerato le proprie capacità di accesso alle risorse, ha ottenuto una quota in cambio di promesse vuote, non è riuscito a mantenere l’impegno e si è poi rifiutato di cedere la quota, ricorrendo alle minacce tramite una lettera legale.

Interpretazione B (a sostegno di Zack): le due parti avevano effettivamente raggiunto un accordo sulle quote; Zack si è impegnato a coinvolgere Amber, ma alcuni problemi dalla parte di Tinkle (tra cui la possibile «appropriazione indebita di beni e sottrazione di profitti») hanno impedito all’investimento di concretizzarsi. In quanto legittimo azionista, Zack ha il diritto di chiedere di uscire e di ricevere un indennizzo.

Quale interpretazione è più vicina alla verità? Per stabilirlo servono ulteriori documenti interni.

Procedura legale o estorsione?

Tinkle ha condiviso pubblicamente sui social media la lettera dell’avvocato di Zack, definendola «estorsione». È un’accusa grave, perché l’estorsione è un reato penale.

La risposta di Zack, tuttavia, ha messo in luce la professionalità della procedura legale:

«Without Prejudice Save as to Costs» è una procedura legale standard nei sistemi anglosassoni, utilizzata nelle trattative transattive relative a controversie commerciali. Le sue caratteristiche sono:

1. È protetta legalmente e non può essere utilizzata come prova in un procedimento giudiziario (tranne che per le questioni relative alle spese processuali)

2. Mira a incoraggiare le due parti a risolvere amichevolmente la controversia

3. Le proposte transattive non costituiscono estorsione

4. Il documento è una lettera di richiesta che illustra la violazione o l’inadempimento dell’altra parte

La lettera dell’avvocato di Zack chiede 500.000 $, ma tale importo si basa su:

• Il fatto giuridico che Zack detiene il 50% della società
• Una valutazione prudenziale della società pari a 1 mln $
• La richiesta a Tinkle di rilevare la quota di Zack pagando un prezzo di riacquisto

Dal punto di vista legale, si tratta di una strategia di negoziazione transattiva del tutto legittima. Se Tinkle ritiene davvero che sia «estorsione», la cosa giusta da fare sarebbe segnalarlo alle autorità, anziché scriverne su Twitter.

Anche l’«avvertimento finale» di Zack è stato molto deciso: «Se credi davvero che sia estorsione, denuncialo subito alla polizia. Se non hai il coraggio di farlo, smettila di inscenare questa farsa assurda».

L’accusa nascosta: appropriazione indebita di beni e dirottamento dei profitti

Un dettaglio degno di nota in questo scontro pubblico è che Zack ha detto che il corpo principale della lettera di richiesta contiene una descrizione dettagliata delle condotte di Tinkle: «appropriazione indebita dei beni della partnership e cospirazione per ricorrere a mezzi illegali»

Il contenuto integrale della lettera non è stato reso pubblico, ma si tratta di un’accusa molto grave. Se fosse vera, potrebbe riguardare:

1. L’appropriazione di fondi societari a uso personale

2. Scambi personali di vantaggi con istituti di investimento

3. La violazione degli obblighi fiduciari dell’impresa in partnership

Tinkle non ha risposto direttamente a queste accuse, limitandosi a dichiarare che non affronterà più la questione e si concentrerà sullo sviluppo del prodotto.

Questo atteggiamento evasivo suscita in realtà una certa curiosità: che cosa c’era scritto esattamente nella lettera di richiesta?

Conclusione: un dilemma senza soluzione

Le dispute sulle quote all’interno dei team fondatori non sono rare nel mondo delle startup. Il caso Nofx ha attirato l’attenzione perché racchiude le contraddizioni tipiche di questo tipo di controversia:

1. Promesse verbali contro accordi scritti: come si riconosce il contributo in assenza di un accordo scritto sulle quote?

2. Contributo tecnico contro segnalazione di risorse: come si misurano questi due tipi di valore?

3. Responsabilità per aspettative disattese: di chi è la colpa quando la raccolta fondi non va a buon fine?

4. Procedura legale contro giudizio morale: una trattativa transattiva equivale a un’estorsione?

Sulla base delle prove disponibili:

• Zack dispone di documenti legali a sostegno della sua proprietà del 50%
• Tinkle dispone delle registrazioni dei contributi al codice che sostengono il suo ruolo di guida
• Entrambe le parti hanno una propria versione dei fatti, ma manca una catena probatoria completa

La risposta definitiva potrebbe arrivare solo da un tribunale. Questo caso, tuttavia, è un monito per tutti i team di startup:

• Definire le quote fin dall’inizio, per iscritto e con chiarezza
• Stabilire criteri oggettivi per quantificare i contributi (righe di codice, ore di lavoro, valore delle risorse)
• Documentare le decisioni importanti
• In caso di controversie, privilegiare le vie legali anziché gli scontri nell’opinione pubblica

Domanda 3: perché i progetti open source sono diventati un bersaglio per i problemi di sicurezza?

Prima della disputa tra Nofx e COAI sulle licenze e dei conflitti interni sulle quote, una crisi ancora più grave si stava sviluppando silenziosamente: le vulnerabilità di sicurezza.

In 11/2025, la società di sicurezza blockchain SlowMist ha pubblicato un’analisi dettagliata, rivelando gravi vulnerabilità di sicurezza nel progetto Nofx. Non si trattava di un normale «piccolo bug», ma di una falla importante che poteva portare al furto diffuso dei fondi degli utenti.

Cronologia della vulnerabilità: dall’assenza di autenticazione alla chiave predefinita

31/10/2025 - Commit 517d0c: il peccato originale dell’assenza di autenticazione

Questo commit conteneva una falla fatale nel codice di Nofx:

• admin_mode era impostato su true per impostazione predefinita
• Un middleware consentiva a tutte le richieste di passare senza convalida
• L’endpoint /api/exchanges era completamente accessibile

Che cosa significava? Chiunque conoscesse l’indirizzo di un server su cui era distribuito Nofx poteva accedere direttamente all’endpoint /api/exchanges per recuperare:

• api_key: la chiave API dell’utente per l’exchange
• secret_key: la chiave segreta dell’exchange
• hyperliquid_wallet_addr: l’indirizzo del crypto wallet Hyperliquid
• aster_private_key: la chiave privata della piattaforma Aster

Con queste informazioni, un aggressore può:

1. Prendere il controllo completo dell’account dell’utente sull’exchange

2. Effettuare operazioni di wash trading

3. Prelevare direttamente i fondi

4. Manipolare i prezzi di mercato

Si tratta di un’esposizione senza alcuna protezione, un errore fondamentale nella progettazione della sicurezza.

05/11/2025 - Commit be768d9: l’illusione del «rafforzamento»

Forse dopo essersi reso conto dei problemi di sicurezza, con questo commit il team Nofx ha introdotto un meccanismo di autenticazione JWT (JSON Web Token). A prima vista, sembrava un rafforzamento della sicurezza.

Il problema, però, era che:

1. Il valore predefinito di jwt_secret non era stato modificato

2. Se un utente non impostava la variabile d’ambiente, il sistema utilizzava la chiave predefinita codificata direttamente nel codice

3./api/exchanges continuava a restituire tutti i campi sensibili nel formato JSON originale

Questo significa che:

• Gli aggressori possono falsificare un token JWT usando la chiave predefinita
• Una volta ottenuto un token valido, tutte le chiavi restano completamente esposte
• La versione «rafforzata» continua in realtà a essere vulnerabile

È come mettere una serratura alla porta, lasciando però la chiave sotto lo zerbino, a disposizione di chiunque.

13/11/2025 - Branch dev: vulnerabilità ancora presenti

Persino il 13/11, il codice del branch dev presentava ancora diversi problemi:

• L’implementazione di authMiddleware presentava ancora delle falle (api/server.go:1471–1511)
• /api/exchanges continuava a restituire direttamente l’intero ExchangeConfig (api/server.go:1009–1021)
• Il file di configurazione conteneva ancora admin_mode=true e il valore predefinito di jwt_secret codificati direttamente
• Al 31/10, il branch principale (origin/main) utilizzava ancora la versione priva di autenticazione

Non si tratta di una semplice svista, ma di una carenza sistemica di consapevolezza in materia di sicurezza.

Individuazione e risposta: le azioni chiave di SlowMist

Fonte delle informazioni: il ricercatore di sicurezza @Endlessss20 ha fornito a SlowMist le prime informazioni sulle vulnerabilità di sicurezza di Nofx.

Analisi approfondita: il team di sicurezza di SlowMist ha condotto un audit completo del codice di Nofx su GitHub, individuando i due principali problemi di autenticazione menzionati sopra.

Scansione dell’intera rete: cosa ancora più allarmante, SlowMist ha effettuato una scansione dell’intera rete e ha individuato più di 1.000 istanze di Nofx accessibili pubblicamente, molte delle quali utilizzavano configurazioni predefinite o vulnerabili ed esponevano completamente le credenziali degli utenti.

Non si tratta di un rischio teorico per la sicurezza, ma di una minaccia reale e concreta.

Coordinamento urgente: data l’urgenza del rischio, SlowMist ha contattato immediatamente i principali exchange:

• Ha fornito le informazioni ai team di sicurezza di Binance e OKX
• Entrambi gli exchange hanno effettuato verifiche incrociate indipendenti
• Ha rintracciato gli utenti interessati utilizzando le chiavi API ottenute
• Ha avvisato gli utenti e li ha aiutati a ruotare le chiavi
• Ha prevenuto possibili attacchi di wash trading

Aggiornamento: al 17/11/2025, le chiavi esposte degli utenti degli exchange centralizzati (CEX) erano state tutte gestite. Tuttavia, è difficile contattare direttamente alcuni utenti di Aster e Hyperliquid a causa della natura decentralizzata dei loro crypto wallet: devono quindi verificare autonomamente la propria situazione.

Portata dell’impatto: molto più di un problema tecnico

L’impatto di questo incidente di sicurezza va ben oltre l’ambito tecnico:

Vittime dirette:

• 1.000+ utenti che utilizzano Nofx per il trading automatizzato
• Sono coinvolte diverse piattaforme, tra cui Binance, OKX e Hyperliquid
• I dati esposti includono non solo chiavi API, ma anche chiavi private e indirizzi dei crypto wallet

Perdite potenziali:

• Se gli aggressori avessero agito prima dell’intervento degli exchange, i fondi degli utenti avrebbero potuto essere rubati completamente
• I sistemi di trading automatizzato con AI operano ad alta frequenza e con volumi elevati: le perdite avrebbero potuto essere enormi

Erosione della fiducia:

• La community ha perso fiducia nella sicurezza del progetto Nofx
• Sono emersi dubbi sull’intero ecosistema del trading AI open source
• Gli sviluppatori sono diventati più cauti nella scelta dei progetti open source

Domande di fondo: perché un errore così basilare?

La vulnerabilità di sicurezza di Nofx non era una sfida tecnica complessa, ma riguardava le basi della sicurezza informatica:

1. I meccanismi di autenticazione dovrebbero essere attivi per impostazione predefinita, non disattivati

2. Le chiavi predefinite dovrebbero essere generate casualmente, non codificate direttamente

3. I dati sensibili dovrebbero essere crittografati o resi anonimi, non restituiti in chiaro

4. I file di configurazione dovrebbero segnalare esplicitamente i rischi di sicurezza

Qualsiasi sviluppatore esperto dovrebbe conoscere questi principi. Perché, allora, Nofx ha commesso questi errori?

Possibili ragioni:

1. Priorità allo sviluppo rapido: nella frenesia del trading AI, cogliere le opportunità è stato considerato più importante della sicurezza

2. Team inesperto: potrebbe essere mancata l’esperienza necessaria per proteggere i fondi degli utenti

3. Ambiente di test simile a quello di produzione: l’autenticazione era disattivata per semplificare i test e questa configurazione è poi arrivata in produzione

4. Assenza di audit di sicurezza: spesso i progetti open source non vengono sottoposti ad audit di sicurezza professionali

Ma la ragione più fondamentale potrebbe essere: open source ≠ sicuro.

Molti credono che il codice open source sia più sicuro perché «molte persone possono controllarlo e individuare i problemi». La realtà, però, è questa:

• La maggior parte degli utenti si limita a utilizzare il software e non lo revisiona
• Anche quando vengono individuati dei problemi, non tutti hanno le capacità o la volontà di proporre correzioni
• Gli audit di sicurezza richiedono competenze specialistiche e molto tempo
• Le aziende commerciali dispongono di team di sicurezza, mentre i progetti open source spesso no

Limiti della responsabilità: quanta responsabilità dovrebbe avere l’autore di un progetto open source?

Questo solleva una questione controversa: gli autori di software open source dovrebbero essere ritenuti responsabili se gli utenti subiscono perdite a causa di vulnerabilità del software?

Dal punto di vista legale, la maggior parte delle licenze open source (comprese MIT e AGPL) contiene clausole di esclusione della responsabilità: «Il software è fornito così com’è, senza garanzie... L’autore non è responsabile di eventuali danni».

Ma dal punto di vista etico, se si sa che il proprio codice sarà utilizzato per gestire beni reali, non dovrebbe essere adottato uno standard di sicurezza più elevato?

Il caso Nofx è particolare perché:

1. È un sistema di trading automatizzato con AI che coinvolge direttamente i fondi degli utenti

2. Il progetto ha ottenuto 9.000+ stelle e ha un’ampia base di utenti

3. La vulnerabilità non era il risultato di un sofisticato attacco occulto, ma di una svista basilare in materia di sicurezza

4. Il problema è rimasto irrisolto per settimane, durante le quali nuovi utenti hanno continuato a distribuire il sistema

Approfondimento sul settore: i rischi specifici del trading AI

L’incidente di sicurezza di Nofx ha messo in luce i rischi specifici del settore del trading AI:

Il doppio taglio dell’automazione:

• I sistemi di trading AI sono progettati per funzionare automaticamente, 24 ore su 24 e 7 giorni su 7
• Una volta compromessi, gli aggressori possono eseguire rapidamente numerose operazioni
• Gli utenti potrebbero non accorgersi del trasferimento dei propri asset fino a diverse ore dopo

Il conflitto tra open source e sicurezza:

• L’open source favorisce il miglioramento e la revisione da parte della community
• Tuttavia, rende anche più facile per gli aggressori individuare le vulnerabilità
• Spesso le vulnerabilità vengono rese pubbliche prima che siano disponibili le patch di sicurezza

Scarsa educazione degli utenti:

• Molti utenti non comprendono i rischi della distribuzione di sistemi di trading AI
• Utilizzano le configurazioni predefinite senza modificare le chiavi
• Espongono i servizi all’Internet pubblico senza protezioni di sicurezza basilari

L’importanza di SlowMist

In questo incidente, le azioni di SlowMist sono degne di nota:

1. Risposta rapida: ha svolto prontamente un’analisi approfondita dopo aver ricevuto le informazioni

2. Scansione proattiva: non ha atteso le segnalazioni degli utenti e ha individuato autonomamente le istanze interessate

3. Collaborazione nel settore: ha lavorato a stretto contatto con gli exchange anziché agire unilateralmente

4. Divulgazione pubblica: dopo aver gestito l’emergenza, ha pubblicato un rapporto dettagliato per informare la community

5. Posizione chiara: ha sottolineato che non si trattava di una critica, ma di una misura per ridurre i rischi

Questo meccanismo di divulgazione responsabile è un pilastro della sicurezza del settore

Conclusione: l’open source non è una soluzione miracolosa

L’incidente relativo alla vulnerabilità di sicurezza di Nofx ci insegna che:

1. I progetti open source richiedono audit di sicurezza: anche nei progetti in rapida evoluzione non si possono saltare i controlli di sicurezza

2. La sicurezza deve avere la precedenza nelle configurazioni predefinite: la comodità durante lo sviluppo e la facilità con cui si può sferrare un attacco sono spesso due facce della stessa medaglia

3. I fondi degli utenti vanno trattati con particolare attenzione: nei sistemi che coinvolgono denaro, la sicurezza è un requisito imprescindibile

4. La community deve istituire un meccanismo di risposta agli incidenti di sicurezza: le azioni di SlowMist offrono un buon esempio

5. Competenza tecnica ≠ consapevolezza della sicurezza: saper scrivere codice funzionante non significa saper scrivere codice sicuro

Domanda 4: quanto vale davvero il «sostegno» di Amber?

Nella crisi a più livelli di Nofx, c’è un dettaglio facilmente trascurabile che rivela un problema comune nel settore delle criptovalute: la cultura delle sponsorizzazioni

Come è emerso il sostegno: con il backing di @amber_ac_

Prima dell’incidente, visitando la pagina Twitter di Nofx, si poteva leggere questa frase nella biografia: Backed by @amber_ac_

Che cosa significa? Nel settore delle criptovalute,

«backed by» di solito vuol dire:

• aver ricevuto un investimento dall’organizzazione
• o almeno aver ricevuto un sostegno per l’incubazione
• avere un rapporto riconosciuto ufficialmente

Amber Group è un’entità nota nel settore delle criptovalute, con fondi e risorse considerevoli. amber.ac è il suo acceleratore dell’ecosistema. Per un nuovo progetto open source, ricevere il sostegno di Amber significa:

1. Avallo della credibilità: il progetto appare più affidabile e può attirare più utenti

2. Raccolta fondi più facile: altri investitori sono più propensi a seguirne l’esempio

3. Supporto in termini di risorse: potenziale sostegno tecnico, di marketing, legale e altro

4. Fiducia della community: gli utenti sono più disposti a partecipare e contribuire

È come per un imprenditore che riceve una term sheet da un VC di primo piano: anche senza ricevere denaro, il solo avallo ha un valore enorme.

La carta di Zack: posso coinvolgere Amber

Tornando al contesto dei conflitti interni, una delle carte importanti usate da Zack per chiedere una quota del 50% era la possibilità di coinvolgere Amber nella commercializzazione di Nofx.

Secondo Tinkle, Zack era stato in precedenza uno stagista presso Amber. Nel settore, un simile passato implica un certo accesso a risorse e contatti. Zack aveva promesso a Tinkle di poter coinvolgere Amber per ottenere investimenti o sostegno all’incubazione. In cambio, aveva chiesto una quota del 50%.

Dal punto di vista della logica commerciale, lo scambio ha senso:

• Se Zack fosse riuscito davvero a ottenere un investimento da Amber, il valore generato avrebbe superato di gran lunga quello di 14 giorni di contributi al codice
• Per un progetto open source, il sostegno di un’istituzione di primo piano può rappresentare il passaggio decisivo da zero a uno
• Nelle prime fasi di una startup, assegnare una quota del 50% a chi segnala risorse non è una pratica inusuale

Ma la domanda cruciale è: Amber è poi intervenuta?

L’ambiguità di Amber: nessuna incubazione, investimento o partnership commerciale formale

Nel 12/2025, nel pieno dei conflitti interni a Nofx e della controversia sull’open source, amber.ac ha pubblicato una dichiarazione ufficiale:

«Nessuna incubazione, investimento o partnership commerciale formale con Nofx. Abbiamo avuto scambi amichevoli con Nofx nell’ambito della nostra osservazione del settore, ma queste interazioni non hanno portato a una collaborazione formale. Tutte le nostre partnership formali vengono annunciate sul sito ufficiale».

La dichiarazione è sfumata:

1. Nega l’esistenza di un rapporto formale: niente investimenti, incubazione o collaborazione commerciale

2. Riconosce che ci sono stati contatti: «scambi amichevoli», «osservazione del settore»

3. Sottolinea la procedura: le collaborazioni formali saranno annunciate ufficialmente

4. Traccia un confine: si tratta di una presa di distanza pubblica

La domanda, quindi, è: quanto è ampio il divario tra «scambi amichevoli» ed essere «backed by»?

La scomparsa del sostegno: rimozione e spiegazioni

Poco dopo la dichiarazione di Amber, la community ha notato che Nofx aveva rimosso discretamente la frase «Backed by @amber_ac_» dalla biografia su Twitter.

Alcuni utenti hanno chiesto spiegazioni e il responsabile dei social media di Nofx ha risposto: «Apprezziamo il sostegno iniziale di Amber; vista la situazione attuale e la richiesta della controparte, rispettiamo la volontà di rimuovere la menzione».

Questa risposta ha sollevato nuovi interrogativi:

1. Che cosa significa «sostegno iniziale»: se non c’è stata una collaborazione formale, a quale sostegno ci si riferisce?

2. Richiesta di rimozione da parte dell’altra parte: Amber ha chiesto volontariamente di interrompere ogni associazione?

3. L’impatto degli «eventi attuali»: la rimozione è stata chiesta a causa di uno scandalo?

Dal punto di vista di Amber, prendere le distanze era necessario:

• Nofx è coinvolta in una vulnerabilità di sicurezza, una disputa sulle quote e una controversia sulla licenza
• Qualsiasi associazione con Nofx potrebbe danneggiare la reputazione di Amber
• Soprattutto se gli utenti subiscono perdite utilizzando Nofx, Amber non vuole assumersi alcuna responsabilità

Dal punto di vista di Nofx, la rimozione è piuttosto imbarazzante:

• Il sostegno di cui si era vantata è improvvisamente scomparso
• All’esterno si può avere l’impressione che «persino gli investitori se ne siano andati»
• La fiducia della community ne risulta ulteriormente compromessa

«Acceleratore dell’ecosistema» contro «investimento formale»: una zona grigia

amber.ac si definisce un «acceleratore dell’ecosistema», non un fondo di investimento diretto. L’ambiguità di questa definizione è proprio all’origine del problema.

Un acceleratore dell’ecosistema offre solitamente:

• Consulenza da parte di mentor e consigli sul settore
• Risorse per la community e contatti
• Partecipazione a eventi ed esposizione del brand
• Ma non necessariamente finanziamenti diretti

Un rapporto di investimento formale comprende:

• Importo dell’investimento e percentuale delle quote chiaramente definiti
• Documenti legali (accordo di investimento, patto parasociale)
• Un seggio nel consiglio di amministrazione o diritti di osservatore
• Rendicontazione finanziaria e operativa regolare

Il rapporto tra Nofx e amber.ac potrebbe trovarsi nella zona grigia tra queste due categorie:

• Ci sono stati scambi e indicazioni di qualche tipo («scambi amichevoli»)
• Nofx considera questo un «sostegno» e lo descrive come «backed by»
• amber.ac ritiene che ciò non costituisca una «collaborazione formale» e non dovrebbe essere promosso pubblicamente
• Zack potrebbe aver effettivamente facilitato questi scambi, che però alla fine non si sono concretizzati in un investimento

La proliferazione della cultura delle sponsorizzazioni: un problema comune nel settore delle criptovalute

La vicenda Nofx-Amber è solo la punta dell’iceberg. Nel settore delle criptovalute, la cultura delle sponsorizzazioni è dilagante:

Forme comuni di sponsorizzazione:

1. L’istituzione XYZ guida l’investimento: in realtà, potrebbe trattarsi solo di un piccolo investimento successivo

2. Un pezzo grosso di XYZ dà il suo sostegno: potrebbe aver semplicemente ricondiviso un post

3. L’acceleratore XYZ incuba il progetto: potrebbe aver soltanto partecipato a un workshop

4. Collaborazione con un exchange: potrebbe aver soltanto presentato una domanda di quotazione

La scala dei livelli di sostegno:

• Livello più alto: accordo formale di investimento con importo e condizioni definiti

• Livello intermedio: ammissione a un programma di accelerazione con un piano di supporto chiaro

• Livello inferiore: partecipazione a un evento e ottenimento di visibilità

• Livello più basso: conversazione privata e qualche consiglio

Il problema è che molti progetti presentano deliberatamente rapporti di livello inferiore come sponsorizzazioni di livello superiore.

Perché gli investitori tollerano questa vaghezza:

1. Maggiore influenza: più progetti citano l’istituzione, maggiore è la visibilità del brand

2. Logica opzionale: prima si stabiliscono legami deboli, che in futuro potrebbero trasformarsi in investimenti

3. Sforzo minimo: una singola interazione costa poco, ma ha un valore notevole per il team del progetto

4. Entrate grigie: alcune società potrebbero ricevere «compensi di consulenza» o «commissioni per il branding»

Perché i team di progetto sono così entusiasti:

1. Esigenze di raccolta fondi: con una sponsorizzazione è più facile ottenere finanziamenti successivi

2. Fiducia degli utenti: la community è più incline a fidarsi dei progetti sostenuti da istituzioni

3. Pressione della concorrenza: tutti gli altri progetti promuovono le proprie sponsorizzazioni; non farlo significa restare indietro

4. Psicologia dell’ego: anche i fondatori desiderano questo tipo di riconoscimento

Riflessione: quali sono i limiti della responsabilità legata al sostegno?

L’incidente Nofx-Amber solleva una questione profonda: quando il nome di un’istituzione viene usato come garanzia, quanta responsabilità dovrebbe assumersi quell’istituzione?

Se Amber avesse davvero investito in Nofx:

• In quanto azionista, avrebbe responsabilità di supervisione e governance
• In caso di problemi gravi nel progetto, gli investitori dovrebbero intervenire
• Le perdite degli utenti potrebbero comportare una certa responsabilità morale per gli investitori

Se invece si è trattato solo di «scambi amichevoli»:

• Amber non ha obblighi legali
• Ma se il progetto associa il proprio nome a quello di Amber, Amber dovrebbe rettificare tempestivamente
• Se è a conoscenza dell’uso improprio del proprio nome e non interviene, ciò può costituire un’approvazione implicita?

Nel caso Nofx:

1. Nofx ha indicato «Backed by Amber» su Twitter per settimane (forse mesi)

2. Amber, in quanto istituzione professionale, dispone di strumenti per monitorare i social media

3. Se non esisteva davvero una partnership formale, perché non chiarirlo prima?

4. Si è aspettato che Nofx finisse nei guai prima di affrettarsi a prenderne le distanze?

Questo schema del «rapporto prima ambiguo, poi interrotto» danneggia le fondamenta della fiducia nell’intero settore.

Conclusione chiave: il sostegno non è un pasto gratis

La vicenda Amber-Nofx offre alcune lezioni:

1. Per il team del progetto: non esagerare i rapporti con le istituzioni; prima o poi le false sponsorizzazioni vengono smascherate

2. Per gli istituti di investimento: definire i limiti del sostegno, correggere tempestivamente gli usi impropri e assumersi le relative responsabilità

3. Per gli utenti: imparare a riconoscere le sponsorizzazioni autentiche e verificarle tramite i canali ufficiali degli istituti di investimento

4. Per il settore: stabilire standard e norme sulle sponsorizzazioni per ridurre le zone grigie

Nel settore delle criptovalute, il sostegno è una forma di capitale sociale. Tuttavia, come ogni forma di capitale, richiede regole e responsabilità. Quando tutti abusano di questa fiducia, il risultato finale è il crollo della credibilità del settore

Domanda 5: quali problemi sistemici rivela questa controversia?

Se ci allontaniamo dalle singole accuse e repliche e guardiamo oltre i dettagli del caso Nofx, scopriamo che questa controversia indica cinque problemi sistemici profondi: non riguardano solo Nofx, ma rappresentano il «tallone d’Achille» dell’intero ecosistema open source delle criptovalute.

Primo problema: l’alienazione dello spirito open source nell’ondata di commercializzazione

Il passaggio di Nofx dalla MIT alla AGPL può sembrare una decisione tecnica, ma riflette in realtà il conflitto fondamentale tra lo spirito open source e gli interessi commerciali.

Le intenzioni originarie dell’open source:

• Condividere il codice per favorire la collaborazione
• Salire sulle spalle dei giganti ed evitare di reinventare la ruota
• Affidarsi alla community e alla sua intelligenza collettiva

La realtà della commercializzazione:

• Necessità di tutelare gli interessi commerciali
• Impedire ai concorrenti di beneficiare gratuitamente del lavoro altrui
• Cercare percorsi di monetizzazione

La licenza MIT rappresenta l’idealismo dell’open source: usala come vuoi, basta che ne riconosci l’autore. Questa generosità ha attirato numerosi sviluppatori e l’attenzione della community, consentendo a Nofx di accumulare rapidamente 9.000+ stelle.

Ma quando Nofx ha visto progetti come COAI, che ha raccolto 17 mln $ di finanziamenti, potenzialmente utilizzare il suo codice, ha cambiato idea. La licenza AGPL è il «firewall» più restrittivo del mondo open source: usi il mio codice? Allora devi rendere open source anche il tuo e non puoi utilizzarlo per scopi commerciali a codice chiuso.

Dal punto di vista di Nofx, questa modifica aveva una sua logica:

• Diritto di scegliere la licenza: gli autori di software open source hanno il diritto di rivalutare la scelta della licenza durante lo sviluppo del progetto; la licenza AGPL è di per sé una licenza open source legittima e ampiamente utilizzata

• Benefici asimmetrici: quando hanno scoperto che il loro codice veniva utilizzato su larga scala da progetti commerciali ben finanziati, i piccoli team open source hanno ritenuto che il contributo fornito non fosse proporzionato al ritorno ottenuto

• Tutela dell'ecosistema: la natura «virale» della licenza AGPL mira a impedire che il codice open source venga «appropriato», proteggendo così lo sviluppo sostenibile dell'ecosistema open source

• Posizione vulnerabile: di fronte a un concorrente con 17 mln $ di finanziamenti, i progetti open source sono chiaramente svantaggiati in termini di risorse, questioni legali e mercato

Questo cambiamento è di per sé comprensibile: gli autori di software open source hanno il diritto di scegliere una licenza. Tuttavia, il problema sta in:

1. Mancata comunicazione alla community: il cambiamento di licenza non è stato annunciato alla community e gli sviluppatori che già utilizzavano la versione MIT potrebbero non esserne al corrente

2. Applicazione retroattiva: utilizzare una licenza modificata il 04/11 per ritenere responsabili azioni compiute il 03/11

3. Accuse selettive: perché accusare proprio COAI e non gli altri progetti che utilizzano la versione MIT?

4. Raccolta di dati sulla privacy: durante la fase MIT era integrato Google Analytics per raccogliere dati degli utenti senza darne comunicazione

Da un'altra prospettiva, alcune pratiche di Nofx potrebbero avere un loro contesto:

• Intento originario: lo scopo fondamentale del cambiamento del protocollo potrebbe essere tutelare gli interessi di chi contribuisce alla community, anziché prendere di mira concorrenti specifici

• Limiti di capacità: essendo un piccolo team, durante la rapida fase di crescita del progetto potrebbero effettivamente aver trascurato le procedure standard di comunicazione con la community

• Esigenze tecniche: Google Analytics potrebbe essere stato utilizzato per comprendere il comportamento degli utenti, individuare problemi e migliorare il prodotto, anziché per raccogliere dati in modo illecito

• Pressione sulle risorse: di fronte alla concorrenza commerciale ben finanziata, i progetti open source non dispongono effettivamente di risorse legali e di mercato equivalenti

Tuttavia, anche comprendendo questi retroscena, restano i problemi legati all'esecuzione. Non si tratta più soltanto di difendere lo spirito open source, ma di trovare un equilibrio tra la tutela dei propri interessi e il mantenimento della fiducia nell'ecosistema open source.

La degenerazione dell'open source si manifesta in:

• Strumentalizzazione: l'open source è diventato uno strumento per acquisire utenti e attirare attenzione, anziché un fine

• Uso come arma: le licenze open source sono diventate armi per attaccare gli avversari, anziché le fondamenta della collaborazione

• Disparità: si pretende che gli altri rendano open source il proprio codice, pur potendo cambiare le regole a piacimento

Questi giudizi vanno formulati con cautela. Dall'esterno è difficile comprendere appieno i processi decisionali interni del team Nofx e le sue vere motivazioni. La modifica delle licenze open source è di per sé un diritto legittimo; le questioni fondamentali sono:

1. Esecuzione: come viene attuata la modifica, come vengono informati gli utenti e come vengono gestiti quelli già esistenti

2. Trasparenza: se il processo decisionale è pubblico e se le motivazioni vengono spiegate in modo adeguato

3. Coerenza: se tutte le situazioni simili vengono trattate allo stesso modo

Ciò che questo caso mette in luce è soprattutto un problema sistemico dell'intero ecosistema open source Web3, che è privo di norme mature, più che il comportamento doloso di una singola parte.

Entrambe le parti hanno rivendicazioni legittime:

• La rivendicazione di Nofx: il lavoro di chi contribuisce ai progetti open source non dovrebbe essere sfruttato ingiustamente da progetti commerciali senza riconoscimento né un compenso equo

• La rivendicazione di COAI: il codice utilizzato legalmente secondo la licenza MIT non dovrebbe essere assoggettato retroattivamente agli obblighi della licenza AGPL

• Il dilemma del settore: come creare un meccanismo di equilibrio tra la promozione della condivisione aperta e la tutela dei diritti dei creatori

Questo tipo di degenerazione danneggia le fondamenta della fiducia nell'intero ecosistema open source. Se gli sviluppatori non sanno se un progetto MIT possa passare improvvisamente ad AGPL e applicare retroattivamente le sue disposizioni, avranno ancora il coraggio di usare codice open source? Se gli autori open source vedono i propri contributi commercializzati senza ricevere alcun compenso, saranno ancora disposti a continuare a condividere il proprio codice?

È un dilemma in cui perdono tutti; ciò che serve davvero è la definizione di standard a livello di settore

Problema 2: scarsa consapevolezza dei rischi legali nei team di startup

La controversia sulle quote societarie tra Tinkle e Zack ha messo in luce un problema comune tra i team di startup crypto in materia di conformità legale.

Disordine nella distribuzione delle quote:

• Zack è in possesso di documenti legali che attestano una partecipazione del 50% (registrazione di APEIRON LABS)
• Tinkle ritiene che a Zack spetti solo una partecipazione del 10-20% (in base ai contributi al codice)
• Una divergenza di interpretazione del genere non dovrebbe esistere: la distribuzione delle quote dovrebbe essere definita chiaramente e documentata fin dall'inizio

Mancanza di documentazione delle decisioni:

• Zack sostiene che la sua partecipazione del 50% si basasse sull'impegno a coinvolgere Amber Investments
• Tinkle afferma che Zack abbia esagerato le proprie capacità e che, alla fine, non sia riuscito a ottenere alcun investimento
• Non esiste una documentazione scritta dei termini dell'accordo di allora: le quote sarebbero state assegnate per l'impegno profuso o solo al completamento dell'attività?

Confusione nelle procedure di comunicazione:

• Dopo aver ricevuto una lettera legale da Zack, Tinkle non ha risposto per un mese
• Zack ha dovuto rispondere pubblicamente solo quando Tinkle lo ha accusato pubblicamente di estorsione
• Perché non tentare prima una trattativa privata, ricorrendo direttamente a uno scontro mediatico?

Abuso degli strumenti legali:

• Tinkle ha definito la lettera legale un'estorsione, un'accusa penale grave
• Zack ha fornito un documento standard per la risoluzione di una controversia commerciale, dimostrando che si trattava di una procedura legale

Questi problemi sono estremamente comuni nel mondo delle startup crypto:

1. Preferenza per l'azione rispetto alle procedure formali: la cultura del «muoversi in fretta e rompere le cose» ha fatto sì che molti documenti legali venissero trascurati

2. Mentalità incentrata sulla tecnologia: i fondatori con un profilo da ingegnere spesso trascurano le questioni legali e di conformità

3. Illusione della decentralizzazione: la convinzione che nel mondo crypto si possano aggirare le leggi tradizionali

4. Considerazioni sui costi: i progetti nelle fasi iniziali non possono permettersi assistenza legale professionale

Tuttavia, man mano che il progetto cresce o emergono controversie, queste prime «omissioni» possono trasformarsi in responsabilità significative.

Cosa fare:

• Il team fondatore dovrebbe redigere un accordo tra fondatori per iscritto fin dal primo giorno
• Definire chiaramente il tipo di contributo di ciascuno, la quota di partecipazione e il calendario di vesting
• Conservare una documentazione scritta delle decisioni importanti (email, documenti firmati)
• Affidare regolarmente a un avvocato professionista la revisione della struttura societaria e della conformità
• In caso di controversie, ricorrere prima alle vie legali anziché ingaggiare uno scontro mediatico

Problema 3: grave divario tra competenze tecniche e consapevolezza della sicurezza

La vulnerabilità di sicurezza di Nofx ha rivelato una dura verità: nel settore crypto, competenze tecniche ≠ consapevolezza della sicurezza.

Manifestazioni del disallineamento delle competenze:

• Nofx è riuscito a sviluppare un sistema di trading automatizzato basato sull'IA, un'impresa che richiede notevoli competenze tecniche
• Allo stesso tempo, però, ha commesso errori di sicurezza basilari, come «autenticazione assente» e «chiavi predefinite»
• Saper scrivere codice funzionante non significa saper scrivere codice sicuro

La capacità di raccogliere fondi non equivale alla solidità tecnica:

• COAI ha raccolto 17 mln $, ma le sue capacità di programmazione sono state messe in dubbio
• Nofx ha suscitato entusiasmo nella community, ma ha subito frequenti vulnerabilità di sicurezza
• Nel settore crypto, la capacità di raccontare una storia attrae spesso più finanziamenti delle competenze tecniche

Marginalizzazione della sicurezza:

• Sotto la pressione di uno sviluppo rapido, la sicurezza è spesso considerata una questione da affrontare «più avanti»
• Le funzionalità prevalgono sulla sicurezza e la velocità di rilascio sulle verifiche del codice
• Solo quando si verificano perdite concrete ci si rende conto della gravità del problema

L'idea errata che open source ≠ sicurezza:

• Molti credono che il codice open source sia intrinsecamente più sicuro («più occhi lo controllano»)
• In realtà, però, la maggior parte degli utenti non legge il codice: guarda solo il numero di stelle
• Gli audit di sicurezza richiedono competenze specifiche e molto tempo; non avvengono automaticamente

I rischi specifici del trading con l'IA:

• Coinvolge fondi reali degli utenti e le perdite sono irreversibili
• L'esecuzione automatizzata riduce la finestra disponibile per gli attacchi: quando vengono individuati, spesso è già troppo tardi
• Il funzionamento 24 ore su 24, 7 giorni su 7 amplifica l'impatto dei problemi di sicurezza

Le lezioni del caso Nofx:

1. La sicurezza è un requisito fondamentale, non un'opzione: i sistemi che coinvolgono i fondi degli utenti devono essere sottoposti ad audit di sicurezza professionali

2. Configurazioni predefinite che privilegiano la sicurezza: è meglio creare qualche inconveniente agli utenti che facilitare il lavoro degli aggressori

3. L'iterazione rapida non è una scusa: un MVP può avere poche funzionalità, ma non può trascurare la sicurezza

4. La community ha bisogno di un meccanismo di risposta agli incidenti di sicurezza: ruoli come quello di SlowMist dovrebbero essere istituzionalizzati

Problema quattro: l'eccessiva diffusione della cultura delle sponsorizzazioni nel settore crypto

L'incidente Nofx-Amber ha svelato il velo che copriva la cultura delle sponsorizzazioni nel settore delle criptovalute

Inflazione delle sponsorizzazioni:

• Quasi ogni progetto dichiara di essere «sostenuto da» qualche istituzione
• Il significato di questo «sostegno», tuttavia, varia notevolmente
• Qualsiasi cosa, da un investimento formale a una chiacchierata informale, può essere presentata come un «sostegno»

Proliferazione delle zone grigie:

• Partnership strategiche: potrebbero ridursi a semplici relazioni d'affari
• Partner dell'ecosistema: potrebbero limitarsi a promozioni reciproche
• Team di consulenti: potrebbero esistere solo di nome
• Società di investimento: potrebbero aver semplicemente acquistato una piccola quantità di token

Perché questa cultura prospera:

1. Asimmetria informativa: per gli utenti comuni è difficile verificare l'autenticità delle sponsorizzazioni

2. Mentalità gregaria: «Se ha investito Tizio, allora dev'essere affidabile»

3. Pressione competitiva: si resta indietro nella competizione senza poter fare leva sulle sponsorizzazioni

4. Vuoto normativo: manca una vigilanza istituzionale sull'autenticità delle sponsorizzazioni

Circolo vizioso:

• Il progetto esagera le sponsorizzazioni → ottiene più attenzione e finanziamenti
• Altri progetti imitano i casi di successo
• Le istituzioni di investimento, per accrescere la propria influenza, approvano tacitamente relazioni poco chiare
• Quando il progetto si trova ad affrontare problemi, le istituzioni prendono rapidamente le distanze
• Gli utenti e il settore ne pagano le conseguenze

Come interrompere il circolo vizioso:

1. Istituzioni di investimento: istituire un elenco ufficiale del portafoglio di investimenti, specificando importi e date degli investimenti

2. Team di progetto: promuovere solo rapporti formali verificabili e fornire documenti a sostegno

3. Media e KOL: verificare l'autenticità delle sponsorizzazioni prima di darne notizia

4. Utenti: imparare a verificare, senza fidarsi ciecamente delle sponsorizzazioni

5. Regolamentazione: imporre sanzioni per le sponsorizzazioni false (misura già introdotta in alcune giurisdizioni)

Problema cinque: mancanza generalizzata di meccanismi di governance della community

Riassumendo la triplice crisi di Nofx, il problema fondamentale è che alla community open source mancano meccanismi di governance efficaci

Controversie sui protocolli senza meccanismi di arbitrato:

• Nella controversia tra Nofx e COAI, entrambe le parti sostengono la propria versione dei fatti
• Non esiste una terza parte riconosciuta che possa stabilire chi ha ragione e chi ha torto
• L'unico ricorso è affidarsi all'opinione pubblica e alla legge: la prima è parziale e la seconda è costosa

Problemi di sicurezza senza procedure standard:

• La pronta risposta di SlowMist è un'eccezione, non la norma
• Alla maggior parte dei progetti open source manca un team incaricato di rispondere agli incidenti di sicurezza
• La divulgazione delle vulnerabilità, le notifiche agli utenti e le patch di emergenza non seguono procedure standard

Mancanza di ricorsi per le controversie sulle quote:

• Il conflitto tra Tinkle e Zack può essere affrontato solo ricorrendo alle vie legali o all'opinione pubblica
• Alla community open source manca un meccanismo per risolvere le controversie
• La governance tramite DAO viene proposta da tempo, ma raramente è operativa

Mancanza di incentivi per la community:

• Gli audit di sicurezza e le revisioni del codice richiedono molto tempo

• Ma chi contribuisce ai progetti open source spesso lavora come volontario
• Le aziende commerciali dispongono di team dedicati, mentre i progetti open source si affidano all'altruismo

Tentativi di governance già esistenti:

1. OpenSSF (Open Source Security Foundation): promuove le migliori pratiche per la sicurezza open source

2. CVE (Common Vulnerabilities and Exposures): sistema di numerazione e tracciamento delle vulnerabilità

3. Bug bounty: incentiva i ricercatori di sicurezza offrendo ricompense

4. Codice di condotta: stabilisce gli standard di comportamento della community

5. Modello delle fondazioni: istituisce una fondazione per gestire il progetto (ad esempio, la Linux Foundation)

Tuttavia, l'applicazione di questi meccanismi nell'ambito open source crypto è ancora limitata.

Il meccanismo di governance ideale per l'open source e per bilanciare gli interessi di tutte le parti dovrebbe includere:

1. Standard per gli audit di sicurezza: definire chiaramente quali tipi di progetti devono essere sottoposti a un audit per ottenere una sponsorizzazione

2. Organo per la risoluzione delle controversie: una terza parte neutrale che si occupi delle controversie sui protocolli e sulle quote societarie

3. Procedura di divulgazione delle vulnerabilità: stabilire come notificare, correggere e divulgare le vulnerabilità una volta individuate

4. Incentivi per la community: ricompensare chi contribuisce tramite token, NFT o altri mezzi

5. Requisiti di trasparenza: rendere obbligatoria la divulgazione di informazioni fondamentali come finanziamenti, sponsorizzazioni e struttura delle quote

Origine dei problemi sistemici: il compromesso tra velocità e qualità

La causa di fondo di questi cinque problemi è l'estrema ricerca della velocità da parte del settore crypto:

• Sviluppo rapido: sfruttare le tendenze del momento, iterare rapidamente, ottenere un vantaggio da first mover
• Raccolta rapida di fondi: approfittare delle valutazioni elevate, trascurando i dettagli normativi
• Crescita veloce: competere su parametri come numero di utenti, numero di stelle e dimensioni della community
• Monetizzazione rapida: emettere monete, ottenere la quotazione e incassare

In questa cultura:

• La sicurezza è un peso che rallenta le attività
• La consulenza legale è un costo da ridurre dove possibile
• La governance è un ostacolo che intralcia il processo decisionale
• Pensare a lungo termine è una barzelletta, perché il mercato rialzista non aspetta nessuno

Ma quando la velocità regna sovrana, la qualità diventa una vittima. Nofx ha ottenuto 9000 stelle in due mesi, ma nello stesso periodo ha perso una notevole parte della propria reputazione.

Ep ilogo: il dilemma concreto dell'ideale open source

Dalla rapida ascesa alla triplice crisi, la storia di Nofx è un microcosmo del movimento open source Web3. Mostra sia la straordinaria forza della collaborazione open source sia le molteplici sfide che questo modello deve affrontare nella realtà

Hackergate ci ricorda che decentralizzazione non significa sicurezza; Infightinggate rivela che le fratture interne tra idealisti possono essere più distruttive degli attacchi esterni; Opengate porta sotto i riflettori una questione di lunga data: come proteggere i diritti di chi contribuisce ai progetti open source in un mondo Web3 guidato dal valore commerciale?

Merita particolare attenzione la questione della marcatura temporale nelle controversie sulle licenze open source, che richiede ancora ulteriori chiarimenti. Non riguarda soltanto la correttezza di casi specifici, ma anche lo sviluppo normativo dell'intero ecosistema open source Web3. In futuro potrebbe essere necessario istituire un meccanismo più affidabile per tracciare le modifiche ai protocolli e un sistema di arbitrato di terze parti più autorevole

Questo articolo si basa su informazioni pubblicamente disponibili e sulla relativa analisi e non rappresenta un sostegno né una smentita nei confronti di alcuna parte. Tutti i dettagli tecnici, le cronologie e i documenti legali menzionati nell'articolo possono essere verificati tramite canali pubblici come GitHub, Twitter e altri.

Link all'articolo originale