Come spostare USDT da Tron a EVM senza rimanere intrappolati dalla liquidità

2 aprile 2026 15 minuti di lettura

Se sei stato abbastanza a lungo nella DeFi, l'exploit CrossCurve probabilmente non vi ha sorpreso. Il 1° febbraio 2026, CrossCurve ha subito un incidente nella catena trasversale che ha provocato circa $3M in perdite. Per noi questa non è solo una “notizia di mercato”. È un controllo di qualità obbligatorio prima di qualsiasi integrazione di partner. Siamo responsabili sia della nostra architettura che della sicurezza dei nostri clienti. Per questo motivo, parallelamente agli aggiornamenti pubblici di CrossCurve, abbiamo esaminato i dettagli dell'incidente e valutato come la causa principale potesse (o meno) avere un impatto sulle nostre integrazioni pianificate.

Il contesto di questo articolo

Cosa è successo esattamente a CrossCurve? Senza addentrarsi inutilmente nella terminologia, il problema non è stato un hacking della blockchain, ma una modello di progettazione poco intuitivo che può sfuggire anche agli audit professionali se il rischio non viene esplicitamente compreso. Il contratto ReceiverAxelar stesso era stato sottoposto a audit e verificato sulla catena, ma la vulnerabilità si trovava più in profondità in un percorso di esecuzione accelerato per i messaggi cross-chain, dove un'operazione critica poteva essere attivata senza la completa convalida della fonte attraverso il gateway. Nel caso specifico di CrossCurve, la situazione era ulteriormente amplificata da una configurazione debole della soglia di conferma (soglia = 1), che riduceva la robustezza complessiva del modello di convalida.

Questo incidente è anche un segnale più ampio per gli integratori Axelar: seguendo gli esempi ufficiali ed ereditando dai contratti di esecuzione “express”, i progetti possono esporre involontariamente una superficie di attacco pericolosa anche se il resto del codice è corretto e sembra pronto per la produzione. Un altro punto importante è che il rischio non scompare da solo con l'aggiornamento: anche le versioni più recenti dell'SDK contengono schemi simili e se i team migrano senza riconoscere il problema architetturale, possono portare avanti il rischio. In pratica, la conclusione è semplice: qualsiasi percorso di esecuzione veloce deve essere rigorosamente limitato o rafforzato con forti controlli di origine/autorizzazione da parte dell'integratore; altrimenti, le meccaniche in stile express possono diventare un aggiramento dei propri presupposti di sicurezza.

Allo stesso tempo, la nostra posizione su CrossCurve rimane positiva e, ironia della sorte, la complessità della loro architettura rende questo incidente uno scenario meno universale e ripetibile di quanto possa sembrare a prima vista. L'exploit si è basato su uno specifico modello di messaggero/esecuzione (una particolare scelta progettuale dell'SDK), mentre la soluzione verso cui CrossCurve si sta muovendo ora - e quella che stiamo considerando nei nostri prodotti per il trasferimento sicuro di beni attraverso la catena - non dipende da questo collegamento vulnerabile. Per questo motivo, anche se eravamo già integrati con CrossCurve al momento dell'incidente, questo esatto vettore di attacco non avrebbe avuto un impatto sulla nostra architettura., perché i nostri punti di fiducia e di convalida sono strutturati in modo diverso e non si basano sullo stesso percorso di esecuzione espresso.

Infine, l'aggiornamento ufficiale di CrossCurve, pubblicato il 13 febbraio 2026, ha effettivamente confermato le conclusioni a cui il nostro team è giunto in modo indipendente. Il ripristino del sistema avverrà per gradi, iniziando dai componenti non interessati (l'aggregatore è già attivo, con instradamento tramite Rubic e Bungee), per poi riabilitare il Token Bridge e il Consensus Bridge con misure di sicurezza aggiuntive. In particolare, l'azienda ha dichiarato che il Consensus Bridge sarà attivo solo dopo aver completato i controlli di sicurezza. Questo “ripristinare solo ciò che è stato verificato con sicurezza e indurire prima della riattivazione”.” L'approccio è in linea con il modo in cui valutiamo la maturità dei protocolli dei partner prima dell'integrazione.

Questo è esattamente il motivo per cui spostare USDT da Tron alle reti EVM non è così semplice come collegare un ponte e chiudere la questione. Tron è il luogo in cui si muove effettivamente un'enorme quantità di USDT: le commissioni erano a buon mercato (ora non lo sono più, da qui la necessità di ponti), i flussi sono familiari e i volumi sono reali. Quindi, quando si dice “abbiamo bisogno della liquidità di Tron”, la vera questione è dove si trova il denaro, chi è autorizzato a muoverlo e cosa succede quando un'ipotesi si rivela sbagliata.

Questo articolo è qui per rallentare la conversazione in modo positivo. Vi illustrerò i principali modi in cui USDT si sposta da Tron alle reti EVM, come si comportano questi approcci quando il volume reale colpisce, e poi farò un passo indietro per porre l'unica domanda che conta davvero: quali rischi siete effettivamente disposti a correre.

Ottenere una rapida revisione del percorso dei messaggi della catena trasversale

Definire la cornice: Tron, la liquidità e i reali compromessi

A questo punto, la domanda diventa come USDT si sposti effettivamente da Tron in una rete EVM, e cosa si assume quando si sceglie un percorso piuttosto che un altro.

La maggior parte delle discussioni si blocca a livello di protocollo, ma questa non lo farà. Prima di nominare soluzioni specifiche, voglio essere esplicito sulle dimensioni che contano effettivamente quando si tratta di volumi reali. In pratica, ogni progetto a catena incrociata finisce per fare compromessi lungo le stesse axe, anche se il linguaggio del marketing è diverso.

Il primo è liquidità. Alcuni modelli richiedono che il capitale sia pre-posizionato da entrambe le parti. Altri lo evitano del tutto, ma introducono diverse forme di fiducia. Il secondo è identità del bene. A volte gli utenti ricevono quello che tutti concordano essere “l'USDT”. A volte non lo ricevono, e questa distinzione ha effetti reali a valle nella DeFi. Poi c'è comportamento dei costi sotto carico, velocità di finalizzazione, ipotesi di sicurezza, sforzo di integrazione, e quanto si diventa dipendenti dalla tabella di marcia di qualcun altro.

Se si mettono in fila queste dimensioni, lo spazio di progettazione si riduce a quattro approcci generali. Non sono variazioni della stessa cosa, perché risolvono problemi diversi e falliscono in modi diversi. La tabella che segue è un rapido orientamento.

Una rapida mappa dei quattro approcci

Approccio	Dove vive la liquidità	Tipo di attività	UX a volume reale	Rischio primario
Ponti / piscine LP	Prefinanziato su entrambi i lati	USDT nativo	Buono fino allo svuotamento delle piscine	Esaurimento della liquidità, squilibrio
Blocca-stacca / brucia-sblocca	Bloccato su Tron	A ponte / avvolto	Prevedibile	Fiducia, frammentazione
Esecuzione basata sugli intenti	Con solutori / MM	Dipende dal percorso	Molto bene se i solutori rimangono	Uscita dal solutore, prezzi
Ingresso ibrido	Catene liquide esterne	Canonical-by-design	Stabile se l'instradamento è valido	Messaggistica, aggregazione

La cosa importante da notare è che nessuno di questi approcci elimina il rischio, ma lo ridistribuisce soltanto. Alcuni concentrano il rischio nella fornitura di liquidità, mentre altri lo spostano nella fiducia, nella logica di esecuzione o negli operatori esterni. Una volta chiarito questo punto, il resto della discussione diventa molto più semplice.

Tenendo a mente questo quadro, possiamo ora analizzare in dettaglio ogni approccio e vedere cosa si ottiene effettivamente e cosa si assume tranquillamente quando lo si sceglie.

Scopri quali sono i servizi correlati che offriamo

Approccio #1. Ponti LP e pool di liquidità nativi

Il modello è semplice. Un utente deposita USDT in un pool su Tron e riceve USDT da un pool corrispondente sulla catena EVM di destinazione. Idealmente, non appaiono token avvolti o sintetici. Lo stesso asset si muove tra le catene, ma per renderlo possibile è necessaria la liquidità “qui e là”.

Dal punto di vista dell'utente, questo è spesso simile a un trasferimento diretto. Il ponte non conia una nuova attività. Ridistribuisce la liquidità esistente tra pool distribuiti su reti diverse.

Pro

Quando i ponti LP sono impostati correttamente, offrono diversi vantaggi evidenti.

L'UX è solitamente molto buona. I trasferimenti sono veloci, i flussi sono facili da capire e gli utenti hanno la sensazione di “avere la stessa risorsa” dall'altra parte.
Nessuna frammentazione della liquidità a livello di attività. Non c'è una proliferazione di “diverse versioni di USDT”, il che semplifica le integrazioni DeFi sugli EVM.
Economia trasparente per i fornitori di liquidità. Le commissioni si comportano “come in un pool DEX”, il che rende i rendimenti più facili da spiegare e ragionare.

Contro

Il principale svantaggio è la liquidità. I ponti LP richiedono una liquidità di partenza, a volte di milioni di euro.. Senza di esso, i trasferimenti di grandi dimensioni “mangeranno il pool”, portando a limiti rigidi o a un forte aumento delle commissioni e degli slittamenti. Questo vincolo si applica indipendentemente dalla rete EVM sul lato ricevente.

C'è anche un dipendenza critica dall'infrastruttura di messaggistica. I bridge di questo tipo si affidano alla messaggistica cross-chain per coordinare i rilasci dei pool e la maggior parte delle soluzioni già pronte si integra con i principali fornitori di messaggistica. In pratica, ciò significa che:

onboarding di un protocollo di messaggistica di primo livello,
pagando costi di integrazione che in genere variano da $250k a $500k a seconda dell'urgenza,
in attesa di code di integrazione che possono durare anche mezzo anno.

A quel punto, non si tratta più di “collegare un ponte”. Si tratta del lancio e del mantenimento di un mercato della liquidità.

I rischi

I ponti LP comportano più livelli di rischio contemporaneamente.

Rischio di contratto intelligente e rischio di infrastruttura di messaggistica o relayer. Eventuali errori nei contratti o nella gestione dei messaggi possono bloccare i fondi o rilasciarli in modo errato.
Scenari di bank-run in condizioni di squilibrio e panico. Se i flussi si inclinano fortemente in una direzione, le piscine possono svuotarsi più velocemente di quanto possano recuperare.
Rischio di conformità delle Stablecoin. L'inserimento nella lista nera o la sospensione da parte di un emittente si applica a tutti gli approcci, ma nei ponti basati su pool è particolarmente visibile perché i pool rappresentano un obiettivo chiaro e concentrato.

Recenti incidenti di catena hanno dimostrato come i malfunzionamenti nella convalida dei messaggi possano propagarsi a cascata attraverso le reti. Sebbene questi incidenti non coinvolgano necessariamente i pool di LP, essi sottolineano che la corretta gestione dei messaggi è un elemento critico anche per i bridge basati sui pool.

Esempi del mondo reale e loro significato

Nucleo Allbridge (messaggistica all'interno di Allbridge)
Allbridge si posiziona come uno swap di stablecoin cross-chain costruito attorno al modello del pool, con commissioni distribuite a favore dei fornitori di liquidità. I materiali pubblici sottolineano che la sicurezza non si basa su un singolo controllo, ma su molteplici pratiche e livelli di controllo. Le comunicazioni pubbliche descrivono anche una ripartizione delle commissioni sulla falsariga di “80% agli LP e 20% alla tesoreria”.

Stargate / ecosistema LayerZero (messaggistica via LayerZero)
Stargate storicamente affronta i pool unificati e le dinamiche di squilibrio regolando le commissioni in risposta alla direzione del flusso. Allo stesso tempo, l'ecosistema si è mosso verso la “distribuzione ufficiale omnichain” delle monete stabili, compresa la comparsa di USDT0 come asset OFT secondo lo standard LayerZero.

La documentazione di LayerZero elenca esplicitamente USDT0 come compatibile con OFT. Nelle descrizioni pubbliche, il lancio di USDT0 segue il modello “lock on Ethereum, mint on target networks”.

Si tratta di una sfumatura importante. Dimostra che La logica LP e la logica lock-and-mint spesso si fondono nella pratica. In alcuni casi, la “natività” non deriva dai pool, ma dalla creazione a livello di emittente o di infrastruttura di un asset omnichain canonico.

Celer cBridge / Stato di simbiosi (messaggistica e convalida tramite la rete Guardian)
Queste soluzioni offrono in genere un'ampia copertura della catena, ma ritornano alla stessa domanda di fondo: dove si trova la liquidità e chi la detiene?

Per le reti EVM, la risposta si riduce di solito a due opzioni:

I partner o gli investitori immettono liquidità nei pool,
oppure il sistema accetta limiti sul volume e sulla qualità del percorso.

La questione ricorrente di chi finanzia la liquidità è ciò che in ultima analisi definisce fino a che punto i ponti LP possono portare un ecosistema EVM.

Ottenete un promemoria sui rischi della vostra attuale configurazione del ponte.

Approccio #2. Ponti bloccati e mentalizzati / bruciati e sbloccati

Questo modello segue una logica diversa rispetto ai pool di liquidità. Su Tron, l'asset originale viene bloccato. Sul lato di destinazione, viene coniata una versione “bridged” di quell'asset. Quando i fondi tornano indietro, l'asset bridged viene bruciato e l'asset originale viene sbloccato su Tron.

Non ci sono pool che devono essere bilanciati tra le catene. La capacità è determinata da quanto è bloccato, non da quanta liquidità è disponibile altrove. Tuttavia, c'è una complessità tecnica da tenere presente. Poiché le reti basate su Tron e quelle basate su EVM differiscono in modo significativo, la maggior parte dei ponti lock-and-mint si basa su tecnologie diverse per ogni lato. Ciò aumenta la complessità dell'implementazione e innalza il livello di correttezza del funzionamento, soprattutto quando sono coinvolte le monete stabili.

Vantaggi del modello a ponte canonico

Nessun requisito di liquidità bilaterale
- Le piscine LP non sono richieste come condizione obbligatoria.
- Non è necessario prefinanziare la liquidità sulla catena di destinazione.
Capacità prevedibile
- I trasferimenti non falliscono perché un pool è “esaurito”.
- La capacità varia in base alla quantità di materiale bloccato.
Veloce da avviare
- Può essere lanciato “da zero”, anche con un TVL piccolo.
- Non dipende dai partner o dagli investitori che seminano i fondi in anticipo.

Il costo delle attività avvolte

Il compromesso è l'identità degli asset.

In quasi tutti i casi, nella rete EVM compare un bene avvolto o collegato a un ponte. Ciò introduce diversi problemi:

Rischio di fiducia e di riscatto
- Gli utenti devono fidarsi del corretto funzionamento del meccanismo di blocco e sblocco.
- Il riscatto dipende dal fatto che il ponte continui a funzionare come previsto.
Frammentazione di “USDT”
- Più versioni di USDT possono coesistere sulla stessa rete.
- Ogni versione compete per la liquidità e l'adozione.
Resistenza all'adozione della DeFi
- I protocolli e i pool possono rifiutarsi di supportare la versione “sbagliata”.
- Le integrazioni diventano più selettive e frammentate.

Per le monete stabili, questo problema è particolarmente acuto. Il mercato preferisce costantemente la versione più canonica di un asset.

Profilo di rischio dei ponti chiusi e sigillati

Rischio del validatore, della chiave o dell'amministratore
- Se il ponte non è completamente minimizzato dal punto di vista della fiducia, il controllo sul conio e sullo sblocco diventa un presupposto critico per la fiducia.
Rischio di messaggistica e coerenza
- I bridge che dipendono dall'orchestrazione o dalla messaggistica asincrona possono soffrire di eventuali problemi di coerenza.
- Le mancanze o i ritardi nel coordinamento possono portare a stati bloccati o incoerenti.

I ponti lock-and-mint eliminano la pressione costante dei pool di finanziamento, ma la sostituiscono con questioni di fiducia, identità degli asset e accettazione a lungo termine all'interno degli ecosistemi DeFi.

Approccio #3. Esecuzione basata sugli intenti (solutori e market maker)

I sistemi basati sugli intenti capovolgono il flusso abituale. Invece di dire al sistema come per spostare le risorse passo dopo passo, l'utente dichiara il risultato che desiderano. Ad esempio, “voglio USDT sulla rete EVM”. I dettagli di routing, swapping e bridging sono lasciati al mercato.

I solutori competono per soddisfare questo intento offrendo quotazioni. Le regole di esecuzione sono applicate sulla catena, quindi una volta accettata la quotazione di un solutore, il regolamento segue le condizioni del protocollo. L'atomicità non deriva da un singolo contratto ponte, ma dalle regole che governano il modo in cui gli intenti vengono abbinati ed eseguiti.

Perché gli intenti sembrano interessanti per Tron

Questo modello si adatta al caso d'uso di Tron per alcune ragioni concrete:

Velocità: I risolutori dispongono già dell'inventario, quindi l'esecuzione può avvenire rapidamente senza attendere il riequilibrio dei pool.
Efficienza del capitale: La liquidità non è bloccata in pool di proprietà dei protocolli. Si trova presso i market maker che decidono come impiegarla.
Disponibilità dei MM a detenere le scorte: Alcuni market maker sono disposti a detenere USDT e asset correlati se vi è un chiaro rendimento o un flusso di ordini affidabile, spostando l'onere del capitale dalla rete stessa.

Dove brillano i sistemi basati sull'intento

Quando la partecipazione dei solutori è sana, l'esecuzione basata sull'intento produce ottimi risultati.

La migliore UX della categoria: Gli utenti eseguono un'unica azione invece di concatenare i passaggi bridge, swap e bridge.
Costo potenzialmente più basso: La concorrenza tra solutori può comprimere gli spread, rendendo gli intenti più economici dei percorsi multi-hop.
Accesso alla liquidità su scala di rete: La copertura cresce con il mercato dei solutori piuttosto che con la liquidità posseduta dai protocolli, il che consente di espandersi senza dover ricostruire i pool su ogni rete.

Dove il modello inizia a sforzarsi

Le stesse proprietà che rendono interessanti gli intenti ne definiscono anche i limiti.

Dipendenza dal solutore: Se i solutori abbandonano o riducono l'attività, la qualità dell'esecuzione diminuisce immediatamente.
Rischio di prezzo implicito: I costi sono incorporati nelle quotazioni dei solutori, che possono aumentare o diventare aggressivi in mercati poco dinamici.
Prevedibilità limitata per flussi molto grandi: I prezzi riflettono le regole contabili fisse anziché il comportamento dei market maker, motivo per cui i modelli "mint-and-burn" sono spesso preferiti per i binari pesanti.

Profilo di rischio degli intenti

L'esecuzione basata sull'intento comporta tre rischi principali. C'è rischio di vivacità se i risolutori se ne vanno. C'è rischio di integrità dei prezzi se le quotazioni diventano aggressive o distorte in condizioni di bassa liquidità. E c'è rischio operativo, Ciò significa che la qualità dell'esecuzione deve essere monitorata e che devono essere disponibili percorsi di ripiego quando l'esecuzione dell'intento si deteriora.

Inviate il vostro flusso di chiamate e noi tracceremo le lacune in termini di fiducia.

Approccio #4. Modello ibrido. Meta-aggregazione più ingresso uno a uno

Il modello ibrido parte da una premessa diversa rispetto ai progetti basati sul pool: non possiedono liquidità.

Invece di cercare di attirare e mantenere il capitale all'interno di pool di proprietà dei protocolli, il sistema si affida alla liquidità già presente nelle grandi reti liquide. La rete EVM stessa controlla solo il punto di entrata e di uscita finale, piuttosto che l'intero percorso della catena.

Questo design evita il vincolo principale dei bridge basati su LP. Non c'è un pool locale da esaurire, perché la liquidità non è concentrata all'interno della rete di destinazione. Non ci sono limiti di volume imposti dalla TVL locale. I trasferimenti scalano con la profondità dei mercati esterni, non con la quantità di capitale che la rete è riuscita ad attrarre.

La liquidità rimane dove già esiste, nelle grandi catene, nei DEX consolidati e nei sistemi di routing maturi.

Come funziona in pratica. L'esempio di Haust

Haust è una rete Layer-2 compatibile con EVM costruita su zk-rollup, con supporto nativo per l'astrazione dei conti, l'esecuzione cross-chain e il routing aggregato. Questo lo rende un buon caso di riferimento per il modello ibrido, perché tratta già l'ingresso nella catena trasversale come un'infrastruttura, non come un componente aggiuntivo.

In pratica, il flusso si presenta come segue:

Selezione della catena di origine
Haust seleziona una o due catene EVM in cui la liquidità di stablecoin è già profonda e attivamente instradata. I candidati tipici sono BNB Smart Chain, Arbitrum o Base. Non viene fatto alcun tentativo di replicare tale liquidità all'interno di Haust.
Ingresso singolo in Haust
Un ponte dedicato collega ogni catena sorgente selezionata ad Haust. Il ponte segue un modello lock-and-mint o un modello equivalente one-to-one:
- USDT è bloccato sulla catena di origine.
- Una rappresentazione a ponte è coniata all'interno di Haust.
Questa risorsa è sintetica a livello di protocollo, ma trattata come canonica all'interno dello stack DeFi di Haust.
Instradamento aggregato a monte
Gli utenti non interagiscono direttamente con il ponte. Invece:
- L'utente accede tramite un aggregatore di percorsi da qualsiasi catena supportata,
- L'aggregatore convoglia i fondi nella catena di origine scelta e li normalizza nella stablecoin richiesta,
- Il salto finale verso Haust viene eseguito attraverso il ponte uno a uno.
Cucitura ed esecuzione del percorso
Tutti i passaggi sono uniti a livello di aggregazione. Dal punto di vista dell'utente, si tratta di un unico percorso. Dal punto di vista di Haust, solo la voce finale è posseduta e applicata.

La proprietà chiave è che La liquidità non si trova mai all'interno delle piscine Haust. Rimane su grandi catene, DEX e aggregatori. Haust controlla la correttezza dell'esecuzione al limite e integra il risultato direttamente nel suo livello di astrazione di portafogli e conti.

I compromessi architettonici

L'approccio ibrido non è gratuito.

Un compromesso è l'identità degli asset. Un ponte uno-a-uno nella rete di destinazione crea una versione della stablecoin che è canonica all'interno della rete, ma non a livello globale. Ciò richiede una decisione consapevole su quali risorse sono trattate come canoniche e quali sono considerate importate o legacy.

Esistono anche requisiti di integrazione. La messaggistica, l'indicizzazione e il supporto dei portafogli devono essere gestiti in modo pulito, in modo che l'esperienza di ingresso e di uscita sia coerente, anche se il percorso si estende su più sistemi.

Infine, possono esserci vincoli temporali. Il supporto per catene di origine specifiche, come Tron, dipende dalle roadmap degli aggregatori e dei ponti, che possono introdurre ritardi temporanei.

Profilo di rischio del modello ibrido

È importante capire che il modello ibrido non sposta il rischio, ma lo elimina.

Dipendenza dagli aggregatori: La qualità dell'esecuzione dipende dagli aggregatori esterni, compresa la loro copertura, la logica di instradamento e il comportamento di degradazione.
Esposizione finanziaria ridotta rispetto ai modelli LP: La rete evita i costi continui di sovvenzionamento dei pool e di gestione degli squilibri.
Rischio di tempistica legato all'abilitazione della catena: La disponibilità dipende dal momento in cui specifiche catene di sorgenti sono supportate dall'infrastruttura circostante.

In cambio della rinuncia al controllo diretto sulla liquidità, la rete guadagna flessibilità ed evita di dipendere in modo permanente dal proprio bilancio.

Non fatevi prendere dal panico. Pensate con chiarezza.

Questo incidente non riguardava un “hack” appariscente. Si trattava di un percorso di esecuzione che permetteva di eseguire un'azione sensibile senza i controlli che si pensava ci fossero. Il mio consiglio: utilizzate incidenti come questo nel modo giusto. Trattateli come una verifica forzata delle vostre ipotesi. Scrivete ciò di cui vi fidate, perché vi fidate e cosa succede se la fiducia è sbagliata.

Se desiderate esaminare il vostro flusso esatto, passo dopo passo, e vedere dove può piegarsi o spezzarsi, il nostro consulenti blockchain può esaminarlo con voi prima che la liquidità prenda la decisione al posto vostro.

Andrew Nalichaev

Esperto di blockchain e analista DeFi

Andrew vive e respira la blockchain. Aiuta i clienti a navigare in uno spazio in continua evoluzione, traducendo le grandi idee in strategie tecniche sicure, scalabili e costruite per l'uso reale.

Per saperne di più

Indice dei contenuti

Contattateci

Prenota una chiamata oppure compilate il modulo sottostante e sarete ricontattati una volta elaborata la vostra richiesta.

Nome

Azienda

Telefono

Messaggio

Inviaci un messaggio vocale

Allegare i documenti

Caricare il file

È possibile allegare 1 file di dimensioni massime di 2 MB. Formati di file validi: pdf, jpg, jpeg, png.

Facendo clic su Invia, l'utente acconsente al trattamento dei propri dati personali da parte di Innowise in base alla nostra Informativa sulla privacy per fornirvi informazioni pertinenti. Inviando il vostro numero di telefono, accettate che possiamo contattarvi tramite chiamate vocali, SMS e applicazioni di messaggistica. Potrebbero essere applicate tariffe per chiamate, messaggi e dati.

Potete anche inviarci la vostra richiesta
a contact@innowise.com

Cosa succede dopo?

Una volta ricevuta ed elaborata la vostra richiesta, vi contatteremo per illustrarvi le esigenze del vostro progetto. Progetto e firmare un NDA per garantire la riservatezza.

Dopo aver esaminato i vostri desideri, le vostre esigenze e le vostre aspettative, il nostro team elaborerà una proposta di progetto con l'ambito di lavoro, le dimensioni del team, i tempi e le stime dei costi stimati.

Organizzeremo un incontro con voi per discutere l'offerta e definire i dettagli.

Infine, firmeremo un contratto e inizieremo subito a lavorare sul vostro progetto.