Quel format de token convient à votre projet ?
Le format est choisi en fonction du réseau dans lequel le produit fonctionnera et de sa compatibilité avec les portefeuilles, applications et infrastructures associés. L'ERC-20 est utilisé pour un token sur Ethereum, le BEP-20 pour la BNB Smart Chain, le SPL pour Solana, et le Jetton pour TON. Si le produit est déjà lié à un réseau spécifique, il est généralement judicieux de commencer par son standard plutôt que d'ajouter d'autres formats sans objectif précis.
Au départ, il est utile de définir la fonction du token : accès à des fonctionnalités, paiements au sein du produit, participation à la mécanique du protocole ou tout autre scénario. Ensuite, les propriétés d'émission et de gestion sont fixées. Par exemple, il est important de décider à l'avance si l'émission sera limitée, si des droits d'administration supplémentaires sont nécessaires et quelles actions seront permises après le déploiement. Ces choix influencent l'architecture et la manière dont le projet pourra expliquer le fonctionnement du token à ses utilisateurs.
Nous précisons le réseau choisi, les cas d'usage et les intégrations nécessaires avant d'évaluer les travaux. Si les exigences incluent une logique personnalisée au-delà d'un token de base, il est préférable de la définir dans un cahier des charges distinct et de l'évaluer comme développement de smart contract. Un aperçu général des prestations est disponible dans la section Développement Web3.
Que faut-il accorder avant le déploiement d'un ERC-20, SPL ou Jetton ?
Avant le déploiement, il est nécessaire d'approuver les paramètres du token et le mode de gestion : les modifier après publication peut être impossible ou nécessiter une migration distincte. Nous rassemblons les exigences initiales dans un court cahier des charges afin que le propriétaire du projet valide les décisions clés avant la préparation du contrat ou du programme.
Le cahier des charges inclut généralement :
- le nom et le ticker, ainsi que le nombre de décimales si applicable au format ;
- le volume et le modèle d'émission : émission fixe ou création supplémentaire prévue par les règles ;
- les adresses du propriétaire et les droits administratifs, y compris leur transfert ou leur renonciation si cela est prévu par la tâche ;
- les fonctions et limitations requises, par exemple la possibilité de suspendre les opérations si nécessaire et autorisé ;
- le réseau, l'adresse cible de déploiement, les éléments de vérification et les informations pour les métadonnées.
Pour SPL et Jetton, la composition des paramètres et la structure d'implémentation diffèrent des standards compatibles EVM, c'est pourquoi nous ne transférons pas mécaniquement une implémentation d'un réseau à un autre. Pour interagir avec l'interface du produit, le token peut nécessiter une intégration séparée, qui peut être convenue parallèlement au développement d'une dApp. Avant de confirmer le cahier des charges, le client vérifie les adresses, les libellés et les droits de gestion, réduisant ainsi le risque de découvrir une décision incorrecte après le déploiement.
Quels sont les livrables inclus dans la création d'un token ?
Le périmètre des travaux est fixé avant le démarrage : vous savez à l'avance quels fichiers, actions et configurations vous recevrez. La composition de base comprend l'élaboration des paramètres, l'implémentation selon le standard choisi, le déploiement sur le réseau convenu et la transmission du résultat du projet.
Selon la tâche, la composition peut inclure :
- le code source et la configuration de l'implémentation du token ;
- le déploiement sur le réseau convenu et l'adresse du token créé ;
- la vérification du code dans l'explorateur, si le réseau et l'explorateur sélectionnés prennent en charge ce processus pour ce contrat ;
- la préparation ou la mise à jour des métadonnées : nom, symbole, description et élément graphique dans le format convenu ;
- des instructions pour le transfert des droits d'administration et la vérification des paramètres principaux.
Avant la publication, nous vérifions la conformité de l'implémentation avec le cahier des charges approuvé et recoupons les adresses fournies par le client. Les métadonnées et la présentation ne remplacent pas l'enregistrement du projet sur des ressources tierces, car celles-ci peuvent avoir leurs propres exigences de soumission et de vérification. Si le token fait partie d'un produit, nous discutons au préalable des points d'intégration nécessaires et des accès. Une interface utilisateur peut nécessiter un site ou une landing page pour projet Web3, et un produit Telegram peut nécessiter un bot ou une Mini App. Ces travaux ne sont inclus qu'après un accord séparé.
Comment se déroule le travail sur le token et quand planifier le lancement ?
Le travail va du cahier des charges convenu au déploiement vérifiable. Le calendrier dépend du réseau, du volume des fonctionnalités, de la disponibilité des données et de la question de savoir si la tâche inclut uniquement l'implémentation du token ou également l'intégration avec le produit. Nous convenons de la séquence et des points de contrôle avant le début du développement.
L'ordre typique est le suivant :
- Vous décrivez la fonction du token, le réseau et les fonctionnalités attendues.
- Nous précisons les paramètres, les accès et la composition du résultat, puis nous confirmons le cahier des charges.
- Nous préparons l'implémentation et la fournissons pour vérification dans le cadre du processus convenu.
- Après confirmation, nous effectuons le déploiement sur le réseau choisi et vérifions l'adresse et les propriétés principales.
- Nous configurons les métadonnées prévues, effectuons la vérification si possible et convenu, puis transmettons les éléments.
Pour ne pas retarder le lancement, préparez à l'avance l'orthographe du nom et du ticker, la description du projet, le fichier graphique, le réseau et les adresses nécessaires au déploiement. Déterminez séparément qui, du côté du projet, confirme les décisions et gère le portefeuille de déploiement. Si une interface ou d'autres composants doivent être connectés, indiquez-les avant l'évaluation finale : les tâches connexes de développement Web3 sont planifiées ensemble, mais leur composition et leurs délais sont fixés séparément.
Quelles limites sont importantes à considérer lors de l'émission d'un token ?
Avant l'émission, il faut tenir compte non seulement du code, mais aussi de l'irréversibilité de certaines actions réseau, des droits de gestion et des règles des explorateurs tiers. Dans le cahier des charges, nous séparons explicitement ce qui relève de notre travail et ce qui dépend de la décision du propriétaire du projet ou d'une plateforme externe.
L'adresse de déploiement et les paramètres enregistrés sur le réseau ne peuvent pas être considérés comme un brouillon : une erreur dans le réseau, l'adresse ou la configuration peut nécessiter un nouveau déploiement et un plan de migration distinct. C'est pourquoi le client confirme le cahier des charges final et les données du portefeuille avant l'envoi de la transaction. Si le token conserve des droits administratifs, leur propriétaire doit assurer la conservation sécurisée des clés et comprendre les conséquences de chaque action. Le transfert ou la renonciation aux droits ne s'effectue que selon le scénario convenu.
Nous sommes responsables du périmètre convenu de l'implémentation et des actions effectuées, mais nous ne pouvons pas garantir qu'un explorateur tiers acceptera la vérification, qu'un portefeuille affichera le token sans actions supplémentaires ou qu'un annuaire approuvera les métadonnées. La décision de ces services dépend de leurs propres procédures, exigences et conditions techniques. Pour vérifier la qualité du travail, recoupez l'adresse du token avec le réseau, comparez les paramètres avec le cahier des charges approuvé et vérifiez la disponibilité des sources convenues. Ne transmettez pas votre seed phrase ou votre clé privée de portefeuille à l'exécutant.
Comment lier l'émission d'un Jetton et le marketing pour les projets sur TON ?
Pour le marketing des projets sur TON, il faut d'abord disposer d'informations cohérentes sur le Jetton et le produit, qui peuvent être publiées en toute sécurité et de manière cohérente. Le déploiement d'un token en lui-même ne constitue pas un positionnement, un scénario utilisateur ou un plan de communication, ce sont des tâches distinctes, mais elles doivent être préparées en parallèle de l'émission.
Avant de préparer des documents publics, déterminez le rôle du token dans le projet, quelles fonctions sont déjà opérationnelles et quelles affirmations sont étayées par le produit. Recoupez le nom, le symbole, l'adresse du Jetton et les liens vers les canaux officiels sur tous les points de contact. Si le lancement est lié à une application, préparez un chemin court de la description du token à l'action de l'utilisateur : où aller, ce qu'on peut y faire et quelles limites il faut comprendre à l'avance.
Pour la planification, il est pratique de diviser le travail en trois flux : la préparation technique du Jetton, le contenu des pages publiques et la communication avec la communauté. Désignez un responsable pour chaque flux et un ordre de mise à jour des éléments, afin que les modifications de paramètres ne laissent pas d'informations obsolètes dans les canaux. La partie technique peut inclure le lien avec un bot Telegram ou une Mini App, et l'interface du produit peut nécessiter un développement de dApp séparé. La composition de ces travaux est convenue séparément de l'émission du token.
Tarifs
| Service | Prix | Devis |
|---|---|---|
| Création de token | à partir de 450 $ / projet |
Prix de départ en USD. Forfaits personnalisés et remises sur volume sur demande. Paiement en USDT, USDC, BTC, ETH, SOL, TON ou votre token de projet.
Comment ça marche
- Recueillir les besoinsVous communiquez le réseau, la fonction du token, les fonctionnalités nécessaires et les éléments disponibles. Nous précisons les intégrations et les responsables de l'approbation.
- Fixer le cahier des chargesNous accordons les paramètres d'émission, les droits de gestion et la composition du résultat. Le déploiement ne commence pas avant la confirmation des données clés.
- Préparer l'implémentationNous créons le contrat ou le programme selon le standard choisi et vérifions la conformité avec les exigences convenues.
- Déployer le tokenNous effectuons le déploiement sur le réseau choisi, recoupons l'adresse et les paramètres, puis réalisons les actions convenues sur les métadonnées et la vérification.
- Transmettre les livrablesNous fournissons l'adresse du token et les sources convenues, expliquons la procédure de vérification et la gestion des fonctions prévues.
Questions fréquentes
Combien coûte la création d'un token ?
Le prix commence à 450 $ / projet. La composition finale des travaux dépend du réseau, des exigences fonctionnelles, du déploiement, de la vérification et des métadonnées. Après avoir précisé la tâche, nous fixons la liste des livrables et convenons du périmètre avant le démarrage.
Combien de temps prend l'émission d'un token ?
Le délai est convenu après le choix du réseau et l'approbation des paramètres. Le calendrier dépend de la complexité des fonctions, de la disponibilité des données et de la nécessité d'intégrations. Avant le début des travaux, nous indiquons les étapes et ce qui doit être prêt du côté du projet.
Peut-on émettre un même token sur plusieurs réseaux à la fois ?
Il est possible de planifier des implémentations séparées pour plusieurs réseaux, mais il ne s'agit pas d'un contrat unique : chaque réseau nécessite sa propre implémentation et la validation de ses paramètres. Il faut d'abord déterminer pourquoi le projet a besoin de plusieurs versions et comment les utilisateurs distingueront les adresses et les scénarios.
Que faut-il préparer avant de commander ?
Préparez le nom et le ticker souhaités, la fonction du token, le réseau choisi, les exigences d'émission et la liste des fonctionnalités nécessaires. Seront également utiles les adresses pour le déploiement, les données pour les métadonnées et le contact de la personne qui approuvera le cahier des charges au nom du projet.
Garantissez-vous la vérification dans l'explorateur ?
Nous effectuons les actions convenues pour la vérification et transmettons les éléments nécessaires. L'acceptation du code par l'explorateur n'est pas contrôlée par le développeur : les exigences spécifiques et la vérification technique dépendent du service lui-même. Avant le démarrage, nous préciserons si ce travail est inclus et quelles informations seront nécessaires.
Est-il sûr de donner accès au portefeuille pour le déploiement ?
Ne transmettez pas votre seed phrase ou votre clé privée à l'exécutant. Convenez d'un schéma dans lequel vous conservez le contrôle du portefeuille et validez vous-même les transactions, ou utilisez un portefeuille séparé avec les autorisations nécessaires. Les modalités d'accès sont fixées avant le déploiement.
Parlez-nous de votre projet
Répondez à quatre questions et un responsable vous enverra un plan, un calendrier et une fourchette de prix sous une heure. Tout reste confidentiel.
Chargement du formulaire…