Creazione token ERC-20, BEP-20, SPL o Jetton

Quale formato di token è adatto al tuo progetto?

Il formato si sceglie in base alla rete in cui opererà il prodotto e alla compatibilità con i suoi wallet, le applicazioni e l'infrastruttura. ERC-20 si usa per un token su Ethereum, BEP-20 su BNB Smart Chain, SPL su Solana e Jetton su TON. Se il prodotto è già legato a una rete, di solito è ragionevole partire dal suo standard, senza aggiungere altri formati senza una necessità specifica.

All'inizio è utile definire lo scopo del token: accesso a funzionalità, pagamenti all'interno del prodotto, partecipazione alla meccanica del protocollo o altro scenario. Poi si fissano le proprietà di emissione e gestione. Ad esempio, è importante decidere in anticipo se l'emissione sarà limitata, se servono diritti amministrativi aggiuntivi e quali azioni sono consentite dopo il deploy. Queste decisioni influenzano l'architettura e il modo in cui il progetto potrà spiegare la struttura del token agli utenti.

Chiariamo la rete scelta, gli scenari di utilizzo e le integrazioni necessarie prima di valutare il lavoro. Se i requisiti includono logiche personalizzate oltre al token base, è meglio separarle in una specifica a parte e valutarle come sviluppo di smart contract. Una panoramica generale è disponibile nella sezione Sviluppo Web3.

Cosa concordare prima del deploy di ERC-20, SPL o Jetton?

Prima del deploy è necessario approvare i parametri del token e le modalità di gestione: correggerli dopo la pubblicazione potrebbe essere impossibile o richiedere una migrazione separata. Raccogliamo i requisiti iniziali in una breve specifica, in modo che il proprietario del progetto confermi le decisioni chiave prima della preparazione del contratto o del programma.

La specifica di solito include:

• nome e ticker, oltre al numero di decimali, se applicabile al formato;
• volume e modello di emissione: emissione fissa o creazione aggiuntiva prevista dalle regole;
• indirizzi del proprietario e diritti amministrativi, inclusi il loro trasferimento o la rinuncia, se previsti dall'obiettivo;
• funzionalità e limitazioni richieste, ad esempio la possibilità di sospendere le operazioni, se necessarie e consentite;
• rete, indirizzo di destinazione del deploy, materiali per la verifica e informazioni per i metadati.

Per SPL e Jetton la composizione dei parametri e la struttura di implementazione differiscono dagli standard compatibili con EVM, quindi non trasferiamo meccanicamente un'implementazione tra reti diverse. Per l'interfaccia del prodotto, il token potrebbe richiedere un'integrazione separata; può essere concordata insieme allo sviluppo di dApp. Prima di confermare la specifica, il cliente verifica indirizzi, formulazioni e diritti di gestione: così si riduce il rischio di scoprire una decisione errata dopo il deploy.

Quali materiali sono inclusi nella creazione token?

Il perimetro dei lavori viene fissato prima dell'avvio: sai in anticipo quali file, azioni e impostazioni riceverai. La composizione base include l'elaborazione dei parametri, l'implementazione secondo lo standard scelto, il deploy nella rete concordata e la consegna del risultato del progetto.

A seconda dell'obiettivo, il perimetro può includere:

• codice sorgente e configurazione dell'implementazione del token;
• deploy nella rete concordata e indirizzo del token creato;
• verifica del codice nell'explorer, se la rete e l'explorer scelti supportano questo processo per il contratto;
• preparazione o aggiornamento dei metadati: nome, simbolo, descrizione e materiale grafico nel formato concordato;
• istruzioni per il trasferimento dei diritti amministrativi e la verifica dei parametri principali.

Prima della pubblicazione verifichiamo la conformità dell'implementazione alla specifica approvata e controlliamo gli indirizzi forniti dal cliente. I metadati e la presentazione non sostituiscono la registrazione del progetto su risorse di terze parti: queste possono avere requisiti propri per la richiesta e la verifica. Se il token fa parte di un prodotto, discutiamo in anticipo i punti di integrazione necessari e gli accessi. Per l'interfaccia utente potrebbe servire un sito o una landing page per progetti Web3, mentre per un prodotto Telegram potrebbe servire un bot o una Mini App. Questi lavori vengono inclusi solo dopo un accordo separato.

Come si svolge il lavoro sul token e quando pianificare il lancio?

Il lavoro procede dalla specifica concordata al deploy verificabile. Il calendario dipende dalla rete, dal volume delle funzionalità, dalla disponibilità dei dati e dal fatto che l'incarico includa solo l'implementazione del token o anche l'integrazione con il prodotto. Concordiamo la sequenza e i punti di controllo prima dell'inizio dello sviluppo.

L'ordine tipico è il seguente:

1. Descrivi lo scopo del token, la rete e le funzionalità previste.
2. Chiariamo parametri, accessi e composizione del risultato, poi confermiamo la specifica.
3. Prepariamo l'implementazione e la forniamo per la verifica secondo il processo concordato.
4. Dopo la conferma, eseguiamo il deploy nella rete scelta e verifichiamo l'indirizzo e le proprietà principali.
5. Configuriamo i metadati previsti, eseguiamo la verifica se possibile e concordata, e consegniamo i materiali.

Per non ritardare il lancio, prepara in anticipo il nome e il ticker, la descrizione del progetto, il file grafico, la rete e gli indirizzi necessari per il deploy. Definisci separatamente chi, da parte del progetto, conferma le decisioni e gestisce il wallet di deploy. Se è necessario collegare un'interfaccia o altri componenti, specificali prima della valutazione finale: le attività correlate di sviluppo Web3 vengono pianificate insieme, ma la loro composizione e tempistica vengono fissate separatamente.

Quali limiti è importante considerare quando si emette un token?

Prima dell'emissione bisogna considerare non solo il codice, ma anche l'irreversibilità di alcune azioni di rete, i diritti di gestione e le regole degli explorer di terze parti. Nella specifica separiamo chiaramente ciò che rientra nel nostro lavoro da ciò che dipende dalle decisioni del proprietario del progetto o dalla piattaforma esterna.

L'indirizzo di deploy e i parametri registrati sulla rete non possono essere considerati una bozza: un errore nella rete, nell'indirizzo o nelle impostazioni potrebbe richiedere un nuovo deploy e un piano di migrazione separato. Pertanto il cliente conferma la specifica finale e i dati del wallet prima dell'invio della transazione. Se il token mantiene diritti amministrativi, il loro proprietario deve garantire la custodia sicura delle chiavi e comprendere le conseguenze di ogni azione. Il trasferimento o la rinuncia ai diritti vengono eseguiti solo secondo lo scenario concordato.

Siamo responsabili per il perimetro di implementazione concordato e per le azioni eseguite, ma non possiamo garantire che un explorer di terze parti accetti la verifica, che un wallet visualizzi il token senza azioni aggiuntive o che un catalogo approvi i metadati. La decisione di tali servizi dipende dalle loro procedure, requisiti e condizioni tecniche. Per verificare la qualità del lavoro, confronta l'indirizzo del token con la rete, abbina i parametri alla specifica approvata e controlla la disponibilità dei materiali sorgente concordati. Non condividere con l'esecutore la seed phrase o la chiave privata del wallet.

Come collegare l'emissione di Jetton e il marketing per progetti su TON?

Per il marketing di progetti su TON è prima necessaria un'informazione concordata su Jetton e sul prodotto, che possa essere pubblicata in modo sicuro e coerente. Il deploy del token di per sé non crea posizionamento, scenario utente o piano di comunicazione: sono attività separate, ma è opportuno prepararle in parallelo all'emissione.

Prima di preparare i materiali pubblici, definisci il ruolo del token nel progetto, quali funzionalità sono già operative e quali affermazioni sono confermate dal prodotto. Verifica nome, simbolo, indirizzo Jetton e link ai canali ufficiali in tutti i punti di contatto. Se il lancio è legato a un'applicazione, prepara un percorso breve dalla descrizione del token all'azione dell'utente: dove andare, cosa si può fare lì e quali limitazioni è bene comprendere in anticipo.

Per la pianificazione è utile suddividere il lavoro in tre flussi: preparazione tecnica di Jetton, contenuti delle pagine pubbliche e comunicazione con la community. Assegna un responsabile per ogni flusso e definisci l'ordine di aggiornamento dei materiali, in modo che le modifiche ai parametri non lascino informazioni obsolete nei canali. La parte tecnica può includere il collegamento con un bot Telegram o una Mini App, mentre l'interfaccia del prodotto può richiedere uno sviluppo dApp separato. La composizione di questi lavori viene concordata separatamente dall'emissione del token.

Prezzi

Prezzi da in USD. Pacchetti personalizzati e sconti volume su richiesta. Pagamento in USDT, USDC, BTC, ETH, SOL, TON o token del progetto.

Come funziona

1. Raccogliamo i requisitiComunichi rete, scopo del token, funzionalità necessarie e materiali disponibili. Chiariamo integrazioni e responsabili dell'approvazione.
2. Fissiamo la specificaConcordiamo parametri di emissione, diritti di gestione e composizione del risultato. Il deploy non inizia fino alla conferma dei dati chiave.
3. Prepariamo l'implementazioneCreiamo il contratto o il programma secondo lo standard scelto e verifichiamo la conformità ai requisiti concordati.
4. Distribuiamo il tokenEseguiamo il deploy nella rete scelta, verifichiamo indirizzo e parametri, poi eseguiamo le azioni concordate su metadati e verifica.
5. Consegniamo i materialiForniamo l'indirizzo del token e i materiali sorgente concordati, spieghiamo la procedura di verifica e gestione delle funzionalità previste.