Discovery & threat model
Threat model (contro chi si difende l'utente — phishing operator, admin malevolo, truffe di quotazione su exchange), invarianti no-custody, mappatura della postura GDPR + CCPA, revisione del settlement USDT.
Caso studio · Crypto Trading · Web
Come abbiamo rilasciato in produzione una piattaforma di trading crypto — live sul web, al servizio di utenti negli Stati Uniti e nell'Unione Europea — realizzata con Laravel e React, con acquisto/vendita in USDT, pricing dinamico gestito dall'admin, un grafico live a 9 giorni e un'architettura audit-ready conforme a GDPR e CCPA fin dal primo giorno.
Il team di prodotto Dragon Token aveva bisogno di una piattaforma di trading crypto che non sembrasse un ricordo della 2017 — nessun widget di exchange white-label integrato male, nessuna console admin abbandonata, nessun pricing opaco. L'intuizione centrale era che il moderno acquirente crypto consumer negli Stati Uniti e nell'Unione Europea non vuole solo un pulsante di acquisto — vuole una storia di price-discovery difendibile, uno storico delle transazioni auditabile e un livello admin che il team operativo possa gestire senza un deploy. Abbiamo realizzato la piattaforma Dragon Token dai principi fondamentali come applicazione web: una UI di trading React snella, un control plane Laravel che gestisce identità, diritti e pricing, e un flusso wallet in USDT che mantiene la superficie di esposizione on-chain il più ridotta possibile. Il prodotto è gestito da EverCoinBank, l'emittente dietro il portfolio di token di YuSMP Group, ed è posizionato per il pubblico di US e UE con conformità GDPR e CCPA fin dal primo giorno.
Uno sguardo a ciò che la realizzazione della Dragon Token Platform ha consegnato tra il client di trading web e la console admin Laravel per il pubblico di US e UE.

La scelta dello stack domina ogni altra decisione architetturale nella realizzazione di una piattaforma di trading crypto. Abbiamo scelto Laravel sul backend e React sul frontend perché i compromessi si allineano perfettamente con un prodotto greenfield del 2023 che ha bisogno di un livello admin affidabile fin dal primo giorno. Laravel include un modello di permessi collaudato, worker per le code, osservabilità di livello Horizon e un ecosistema di strumenti admin di prima parte (Nova, Filament) che uno stack Node + Express deve reinventare per ogni progetto. React offre all'UI di trading un ecosistema di componenti grafici — Recharts, Chart.js, lightweight-charts — che consente a un piccolo team di rilasciare un grafico prezzi credibile senza dipendenze SaaS.
Gli stack puramente Solidity-first — quelli che trattano lo smart contract come l'intero prodotto — sono stati scartati presto: il prodotto è una superficie di trading USDT custodial, non un DEX completamente on-chain, e pubblicare ogni aggiornamento di prezzo su un contratto avrebbe reso il pricing dinamico gestito dall'admin proibitivo. Scegliere Laravel + React significa che l'intero stack — client di trading, control plane, console admin — è aperto, citabile e gestibile da un piccolo team di prodotto end-to-end.
| Dimensione | Laravel + React (Dragon Token) | Node + Solidity-first | Widget exchange white-label |
|---|---|---|---|
| Maturità del livello admin | Nova / Filament + policy Laravel incluse | Sviluppato ad hoc per ogni progetto | Controllato dal fornitore — opaco |
| Modello di permessi | Primitive role/policy di prima classe | Portalo tu (Passport, librerie RBAC) | Solo preset del fornitore |
| Code / lavoro asincrono | Code Laravel integrate + Horizon | BullMQ + operazioni manuali | N/A — astratto via |
| Controllo del prezzo | L'admin imposta il prezzo — propagazione in sub-secondo | Richiede integrazione di oracle off-chain | Pricing del fornitore — non controllato dall'operatore |
| Superficie di custodia | Nessun seed material in piattaforma | Spesso include hot-wallet store | Custodial del fornitore — fiducia trasferita |
| Tempo all'MVP | 10–14 settimane tipiche | 16–24 settimane — più lavoro da zero | 2–4 settimane ma vincolato al fornitore |
| Auditabilità | Open source — catena di custodia completa | Aperto ma con superficie elevata | Black box — controllato dal fornitore |
Stack references: Laravel documentation, React documentation, USDT transparency reports.

Il client di trading React è realizzato come applicazione a pagina singola servita da una route Laravel. L'intera superficie rivolta all'utente si riduce a quattro stati — inattivo, acquisto, vendita, conferma — e la vista principale è un grande grafico dei prezzi con i pulsanti acquista e vendi accanto. Il grafico mostra una finestra mobile a 9 giorni dei prezzi token impostati dall'admin, con il prezzo live visualizzato chiaramente in alto e un delta verde/rosso sull'ultimo movimento. I moduli di acquisto e vendita si trovano un tap dopo il pulsante di azione corrispondente, con inserimento dell'importo in USDT e un passaggio di verifica dell'indirizzo wallet prima dell'invio.
Il pannello dello storico transazioni è quello in cui la maggior parte dei prodotti crypto nelle fasi iniziali sotto-investe, e dove abbiamo dedicato uno sforzo ingegneristico sproporzionato. Ogni utente dispone di un archivio completo dei propri acquisti e vendite con timestamp, importi in USDT, importi in token e il prezzo risolto per ogni operazione. Gli utenti in California, New York, Texas, Florida e Washington negli USA, e in Olanda, Germania, Francia, Irlanda e Svezia nell'UE, vedono la stessa interfaccia. La superficie React end-to-end è consegnata nell'ambito della nostra pratica di sviluppo di applicazioni web.

La console admin è una superficie basata su Laravel che consente al team operativo di gestire la piattaforma senza un deploy. Il prezzo del token è la variabile operativamente più sensibile del prodotto e l'admin può aggiornarlo in pochi secondi — con la modifica immediatamente riflessa nel grafico per gli utenti e in qualsiasi quotazione acquisto/vendita in corso. I controlli di capitalizzazione consentono all'operatore di limitare o rilasciare l'offerta di token per epoch, la vista di gestione utenti espone la coda di verifica dei wallet e l'archivio delle transazioni è filtrabile per utente, importo USDT e prezzo risolto.
Dietro la superficie admin, le code Laravel gestiscono il lavoro più lento — conferme di trasferimento USDT on-chain, retry su broadcast falliti, segnali anti-frode contro i wallet con pattern bot ed email di notifica agli utenti finali. Un modello di permessi a quattro ruoli (user, support, finance, admin) mantiene ridotto il raggio d'impatto di un account support compromesso; il ruolo finance è l'unico con il diritto di modificare il prezzo del token. L'intero livello admin è stato realizzato pensando all'estensibilità: aggiungere una vista multi-token, una coppia Cyber Token o un modulo di prestito è una modifica di configurazione al servizio di entitlement, non un rilascio di codice.

La postura no-custody di Dragon Token è stata una decisione architetturale prima ancora di essere un claim di marketing. La piattaforma non conserva mai le chiavi private o il seed material degli utenti — gli utenti forniscono indirizzi wallet verificati e i trasferimenti USDT avvengono direttamente on-chain tra i wallet degli utenti e il wallet treasury della piattaforma. Il control plane Laravel conserva solo ciò che è necessario: indirizzi pubblici dei wallet, stato di verifica KYC dove richiesto, entitlement di sottoscrizione e un registro delle transazioni indicizzato da un identificatore interno opaco. Non esiste una tabella seed per utente, nessun hot-wallet store custodial e nessun pipe di metadati verso uno stack di osservabilità centralizzato che colleghi l'identità di pagamento all'identità del wallet.
L'identità di fatturazione è deliberatamente separata dall'identità del wallet. Il modello di permessi admin a quattro ruoli mantiene il diritto di modificare il prezzo del token isolato al ruolo finance, e le policy infrastructure-as-code applicano gli invarianti no-custody — qualsiasi pull request che introduca memorizzazione di chiavi private, un campo seed phrase o un identificatore a lunga durata nel trading plane fallisce la CI. La postura è costruita per allinearsi agli obblighi GDPR per gli utenti nell'Unione Europea e agli obblighi CCPA / CPRA per gli utenti in California e negli Stati Uniti — e per rendere una futura verifica indipendente un esercizio documentale, non una revisione architetturale.
Postura di conformità: Conforme al GDPR · Pronto per ISO 27001 · SOC 2 Type II in corso · Compatibile HIPAA · CCPA riconosciuto.
Una realizzazione in cinque fasi che ha portato Dragon Token Platform dalla specifica di prodotto alla produzione per gli utenti negli Stati Uniti e nell'Unione Europea.
Threat model (contro chi si difende l'utente — phishing operator, admin malevolo, truffe di quotazione su exchange), invarianti no-custody, mappatura della postura GDPR + CCPA, revisione del settlement USDT.
Skeleton del control plane Laravel, scaffold del client di trading React, modello di permessi a quattro ruoli, flusso di settlement USDT, session token in RAM, engine di pricing admin.
Moduli React acquisto/vendita, grafico live a 9 giorni su lightweight-charts, console admin Laravel con pricing dinamico, archivio transazioni, coda di verifica wallet.
Policy infrastructure-as-code che bloccano regressioni di memorizzazione chiavi private, isolamento del ruolo finance per la modifica del prezzo, coda anti-frode, scaffolding per la valutazione di prontezza da terzi.
Lancio web negli store US e UE, runbook operativi per la console admin, dashboard di monitoraggio sull'API di trading e sui worker delle code, supporto post-lancio.
Il livello di monetizzazione di Dragon Token è stato realizzato per mantenere la piattaforma estensibile verso un futuro multi-token e con capacità di prestito senza una riscrittura v2. Il servizio di sottoscrizione/entitlement supporta già più livelli di prodotto, il modello di permessi admin isola già finance da support, e l'infrastruttura delle code gestisce già il settlement ritardato e la semantica dei retry. La roadmap pubblicata aggiunge una coppia Cyber Token sulla stessa superficie di trading, un modulo di prestito con deposito multi-token e maturazione degli interessi, una dashboard di analytics con storico prezzi più approfondito e una quotazione su MetaMask — ciascuno stratificato sul control plane Laravel esistente piuttosto che come stack separato. Nel trading plane, tutto ciò che fluisce è un token di sessione opaco di breve durata; il wallet on-chain non vede mai la superficie di identità della piattaforma anche se compromessa. Il comportamento di kill-switch nella console admin (blocco del trading a livello di piattaforma), l'entitlement per token e la disponibilità per regione leggono tutti dallo stesso record di entitlement, quindi un singolo stato si risolve nettamente tra il client di trading, la console admin e il futuro modulo di prestito. L'intero sottosistema è stato realizzato pensando all'estensibilità: aggiungere un livello B2B, una watchlist multi-token o una dashboard istituzionale è una modifica di configurazione al servizio di entitlement, non un rilascio di codice.
Dragon Token è stato lanciato sul web con il client di trading attivo negli Stati Uniti e nell'Unione Europea. La versione in lingua inglese serve utenti in California, New York, Texas, Florida e Washington negli USA, e in Olanda, Germania, Francia, Irlanda e Svezia nell'UE, senza una codebase separata per regione. I flussi di consenso sono region-aware a livello client: gli utenti nell'UE e nel SEE ricevono una schermata di consenso granulare in stile GDPR con toggle separati per eventuali analytics di prodotto opzionali; gli utenti in California ricevono la comunicazione CCPA « Do Not Sell or Share My Personal Information » nello stesso flusso. Le pratiche di gestione dei dati sono allineate al GDPR per gli utenti europei e alla normativa privacy statale USA — CCPA/CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) e CPA (Oregon). Poiché l'architettura no-custody elimina i dati wallet per utente di cui la normativa si occupa maggiormente, la conformità regionale si riduce a una divulgazione onesta piuttosto che a una segregazione dei dati per giurisdizione.
Il deployment Laravel è stato distribuito in parallelo nelle region cloud che coprono UE e USA, con i worker di ciascuna region predisposti in modo identico da immagini immutabili. L'API di trading che risolve i prezzi per utente esegue worker stateless che possono essere ancorati alle region UE o USA in modo indipendente per futuri impegni di residenza dei dati. L'informativa sulla privacy in-app è stata redatta per documentare esattamente l'architettura sopra descritta, citando direttamente gli obblighi GDPR e gli obblighi CCPA California. Il team di ingegneria è distribuito su CET con una giornata lavorativa nell'orario CET e sovrapposizione con la costa est degli Stati Uniti (9:00–13:00 ET) per gli stand-up, la coreografia di quotazione su exchange e la risposta agli incidenti.
La roadmap attiva di sviluppo software su misura per la piattaforma Dragon Token include una coppia Cyber Token sulla stessa superficie di trading, un modulo di prestito con deposito multi-token e maturazione degli interessi, una vista analytics avanzata con storico prezzi superiore a 9 giorni e una quotazione su MetaMask per gli utenti che preferiscono fare trading dalla propria UI wallet. È previsto un livello B2B con gestione del team e SSO per i casi d'uso di treasury management in US e UE, con il sottosistema di entitlement già strutturato per l'assegnazione multi-seat. I piani infrastrutturali includono ulteriore automazione della console admin, un harness di verifica continua interno sugli invarianti no-custody e una futura valutazione di prontezza indipendente nell'ambito della roadmap Cloud & DevOps.
Se stai pianificando una piattaforma di trading crypto, un prodotto di lancio token o qualsiasi applicazione web in cui l'architettura no-custody deve reggere una verifica esterna per il pubblico di US e UE, abbiamo consegnato questo stack end-to-end e possiamo comprimere significativamente i tempi di realizzazione. Il team di ingegneria è parte di YuSMP Group. Lavoriamo a prezzo fisso per MVP ben definiti e su team di sviluppo dedicati per la consegna continuativa, con una giornata lavorativa CET e una finestra garantita di sovrapposizione con la costa est degli Stati Uniti (9:00–13:00 ET) per stand-up, demo e risposta agli incidenti.
Un MVP di piattaforma di trading crypto custodial con client React, control plane Laravel, acquisto/vendita in USDT, console di pricing per admin e grafico a 9 giorni costa tipicamente €80k–€180k. Aggiungendo supporto multi-token, un modulo di prestito con maturazione degli interessi, quotazione su MetaMask, analytics avanzate e livello B2B con SSO si ottiene un prodotto completo da €220k–€450k. I principali fattori di costo sono il modello di permessi admin, il hardening no-custody e la coreografia per la quotazione su exchange.
Laravel include un modello di permessi collaudato, worker per le code, osservabilità tramite Horizon e un ecosistema di strumenti admin di prima parte che uno stack Node + Express deve reinventare per ogni progetto. React offre all'UI di trading un ecosistema maturo di componenti grafici. Uno stack puramente Solidity-first tratta lo smart contract come l'intero prodotto, rendendo molto più difficile il pricing dinamico gestito dall'admin e la conformità US/UE in 10–14 settimane. Per una superficie di trading USDT custodial come Dragon Token, Laravel + React è la scelta a minor rischio.
Una postura no-custody difendibile è una decisione architetturale, non un claim di marketing. La piattaforma non conserva mai le chiavi private o il seed material degli utenti — gli utenti forniscono indirizzi wallet verificati e i trasferimenti USDT avvengono on-chain tra i wallet degli utenti e il treasury della piattaforma. Il control plane Laravel conserva solo i metadati degli indirizzi pubblici, lo stato di verifica KYC e un registro opaco delle transazioni. Le policy infrastructure-as-code impediscono l'introduzione accidentale di memorizzazione di chiavi private o campi seed phrase. Il risultato è che una futura verifica indipendente è un esercizio documentale, non una revisione architetturale.
Per gli utenti nell'Unione Europea e nel SEE, il GDPR richiede un meccanismo di consenso granulare, una chiara informativa sulla privacy e una base documentata per qualsiasi trattamento dei dati collegati al wallet. Per gli utenti in California, il CCPA/CPRA richiede la comunicazione « Do Not Sell or Share My Personal Information » e il diritto alla cancellazione — con VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) e CPA (Oregon) che aggiungono aspettative simili stato per stato negli USA. Un'architettura no-custody elimina la maggior parte dei dati per utente, che è il modo più efficace per rendere la conformità regionale sostenibile.
Un MVP mirato con Laravel + React, acquisto/vendita in USDT, grafico prezzi a 9 giorni, console di pricing per admin e archivio transazioni richiede tipicamente 10–14 settimane. Aggiungere una vista multi-token (es. Cyber Token), un modulo di prestito con maturazione degli interessi, analytics avanzate e una quotazione su MetaMask aggiunge 6–10 settimane. Il passaggio di hardening audit-ready — invarianti no-custody applicati in IaC, isolamento del ruolo finance per la modifica del prezzo, valutazione di prontezza da terzi — è spesso sottovalutato e dovrebbe essere previsto per 3–5 settimane di lavoro dedicato.
Related cases

Lancio ERC-20 end-to-end — contratto Solidity, audit di sicurezza, quotazione su exchange, checkout MetaMask sul sito del progetto.
Vedi il caso →
Hub unificato per l'ecosistema crypto che aggrega più token — dati live degli exchange, ricerca, grafici, punto di accesso all'acquisto diretto.
Vedi il caso →
Piattaforma di finanziamento per dealer — flussi di lavoro multi-parte, automazione documentale e postura di gestione dati US + UE.
Vedi il caso →Condividete alcuni dettagli e un consulente senior risponderà entro un giorno lavorativo.