Gram (prev. Toncoin)

Gram (ticker : GRAM) est la cryptomonnaie native de The Open Network (TON), une blockchain de couche 1 et un ensemble de services. Elle existe directement sur TON (et non comme un ERC-20 ou un actif encapsulé) et sert de monnaie de base du réseau. Concrètement, Gram est l’unité utilisée pour faire fonctionner la blockchain et ses services intégrés : exécution des transactions et des smart contracts sur la Blockchain TON, opérations de services à travers TON DNS, TON Sites, TON Storage et TON Proxy.

Gram soutient également le modèle de sécurité proof-of-stake du réseau : les validateurs mettent en staking du GRAM pour faire fonctionner la chaîne et recevoir des récompenses protocolaires. Les détails opérationnels du staking et des rôles des validateurs sont abordés dans leurs sections dédiées.

Les outils de développement et le code font souvent référence aux soldes en nanotons (souvent écrits « nano »), la plus petite unité on-chain, bien que les utilisateurs interagissent en Gram. Cela rappelle le fonctionnement du “wei” sur Ethereum et permet d’éviter les arrondis dans la logique des smart contracts. Pour les usages pratiques du Gram dans les applications et services, voir « À quoi sert Gram dans l’écosystème ? »

Telegram a initialement développé le « Telegram Open Network » et prévoyait le token Gram, mais a interrompu le projet en 2020 suite à une action de la SEC américaine et à un règlement approuvé par un tribunal. Le code open source et la vision ont été repris par une communauté indépendante sous le nom The Open Network (TON), avec Gram comme actif natif. Aujourd’hui, TON est une blockchain pilotée par la communauté alors que Telegram est une entreprise distincte.

Telegram s’intègre désormais à TON sans en avoir le contrôle. L’entreprise propose un Wallet intégré à Telegram, avec deux modes : un Crypto Wallet custodial et un TON Wallet auto-custodial pour agir on-chain sur la blockchain TON. Disponibilité et fonctionnalités varient selon la région et les règles produits.

Telegram exploite aussi la plateforme publicitaire TON : les annonceurs paient les publicités de chaînes en Gram, et les propriétaires de chaînes éligibles peuvent retirer 50 % des revenus publicitaires (gérés via Fragment). Il s’agit d’une intégration de plateforme sur TON, sans rôle de gouvernance.

Fragment est la marketplace officielle de Telegram pour les @usernames et actifs associés ; enchères et règlements se font en Gram et se lient à des comptes Telegram.

À part, la TON Foundation est une association suisse à but non lucratif qui soutient l’écosystème TON ; elle ne possède pas Telegram et n'exploite pas la messagerie.

The Open Network (TON) est une plateforme open source de couche 1 pilotée par la communauté qui combine une blockchain de smart contracts avec des composants P2P et des services natifs. La spécification technique d’origine (le whitepaper TON) décrit une architecture multi-blockchain + une stack P2P et des « TON Services » comme DNS, Storage, Sites et Proxy, utilisables de façon cohérente dans le réseau. Dans ce modèle, la Blockchain TON est le registre principal, les autres modules assurant résolution de noms, stockage/servir de données et routage du trafic au sein du même écosystème.

Le code de TON et ses logiciels validateurs sont développés sur des repositories publics ; le projet fonctionne sans autorité centrale. La TON Foundation est une organisation suisse à but non lucratif qui soutient l’écosystème sans contrôler la technologie.

Gram (GRAM) est la monnaie native du réseau. Dans TON, la pièce native paie les frais on-chain et est mise en staking par les validateurs pour sécuriser le réseau ; le whitepaper (rédigé avant le rebranding communautaire de “Gram” en “Gram”) expose les rôles de la pièce native dans la tarification du calcul (“gas”) et le modèle économique des validateurs. Actuellement, Gram est l’unité d’échange dans l’écosystème, y compris pour les intégrations sur la plateforme Telegram comme la pub sur TON. Pour la mécanique précise des frais et du staking, voir les sections dédiées.

Gram est l’actif natif qui soutient l’activité sur The Open Network. Ses usages se regroupent autour de quatre domaines :

1. Payer les frais on-chain : Les transactions et l’exécution de smart contracts sur TON sont réglées en Gram. Les frais couvrent le calcul, le routage des messages et incluent la facturation du stockage.

2. Sécurisation du réseau via staking : Les validateurs mettent en staking du Gram pour participer à la validation proof-of-stake et toucher les récompenses protocolaires ; la délégation se fait via des contrats de pool de nominateurs (nominator-pool) on-chain.

3. Règlement des services au niveau du protocole : Les services intégrés de TON (par exemple TON DNS, Storage, Sites et Proxy) font partie de la stack réseau. Les interactions comme l’enregistrement ou les enchères de noms .ton, la résolution de noms ou l’exploitation de nœuds de stockage impliquent des transactions on-chain en Gram. La mécanique détaillée de chaque service figure dans la section Services TON.

4. Intégrations plateforme et applications : Gram sert à l’achat de publicités Telegram, et les propriétaires de chaîne éligibles retirent leurs revenus via Fragment ; les enchères de @username sur Fragment sont également réglées sur un Wallet TON connecté. Au-delà de Telegram, les dApps sur TON effectuent souvent paiements et tarifs en Gram.

Pour la structure des frais, voir « Quelles actions on-chain exigent du TON et comment sont calculés les frais…? » ; pour le staking et la délégation, voir « Comment fonctionne le staking sur TON…? ».

TON est conçu comme une collection de blockchains opérant en parallèle et coordonnés via une chaîne spéciale dite masterchain. Dessous se trouvent une ou plusieurs workchains, chacune pouvant être dynamiquement fragmentée en de nombreuses shardchains. Cette structure permet à TON de traiter de l’activité en parallèle tout en conservant la cohérence globale.

Masterchain : La masterchain enregistre les métadonnées et coordonnées à l’échelle du réseau (ex : les hash des derniers blocs de chaque shardchain). En embarquant ces références, la masterchain rend ces blocs de shard canoniques, ce qui permet aux autres shards de s’y fier immédiatement sur les blocs suivants. De nombreux paramètres protocolaires sont également stockés dans la masterchain.

Workchains : Une workchain est une blockchain complète au sein de TON avec ses propres règles et format de bloc. Le livre blanc envisage jusqu’à 2³² workchains ; en pratique, la plupart des usages se font sur la « workchain de base » (aussi appelée Workchain Zero), qui héberge les smart contracts et les transferts Gram. D’autres workchains pourraient voir le jour pour des usages spécialisés.

Shardchains (fragmentation dynamique) : Chaque workchain est divisée en shardchains, chaque shard traitant un sous-ensemble d’adresses de comptes. Les shards se fragmentent dynamiquement sous fort trafic et fusionnent si la charge baisse, apportant une capacité élastique sans coordination manuelle. Le routage entre shards et workchains utilise le modèle de messages TON, permettant aux smart contracts d’envoyer messages et valeurs de façon fiable entre shards.

Comment tout s’assemble

• Les shardchains produisent des blocs en parallèle ; la masterchain inclut ensuite les hash des nouveaux blocs de shard, que les autres shards considèrent comme finaux pour leurs actions.
• La « workchain de base » héberge l’activité smart contract et les transferts Gram actuels ; d’autres workchains peuvent adopter des règles ou une VM différentes, la masterchain assurant la cohérence globale.

Sur TON, chaque compte utilisateur est un smart contract. Un « wallet » est en fait un contrat minimal qui détient du Gram et envoie des messages signés pour le propriétaire. Le wallet vérifie la signature de la clé utilisateur, gère un seqno (pour éviter les replay) et exécute les actions autorisées par le propriétaire lors de la réception d’un message externe. Dans la documentation développeur de TON, on résume cela en : « tout est un smart contract », y compris les wallets.

Wallet V4 (v4r2) : V4 a standardisé un modèle plugin/extension : le wallet peut autoriser des contrats compagnons (« plugins ») de confiance à effectuer des opérations spécifiques (ex : abonnements). Le repo V4 documente l’interface plugin et comment installer/supprimer des plugins. V4 reste très utilisé et supporté par les wallets principaux.

Wallet V5 (W5) : V5—souvent appelé W5—est le nouveau standard de contrat wallet maintenu dans les repositories principaux de TON. Fonctions clés :

• Multi-envoi : un seul ordre signé peut émettre jusqu’à 255 messages sortants ;
• Actions signées internes comme externes, permettant des schémas relayer (utilisés pour les transferts « sans gas ») ;
• Mécanisme d’extensions généralisé (successeur des plugins V4), incluant la capacité de bloquer des actions signées (utile pour la 2FA ou la récupération).

La spécification décrit aussi comment des relayers “gasless” peuvent relayer un message signé par l’utilisateur et payer les frais Gram au moment de l’envoi.

W5 en production : Les explorateurs affichent un tag d’interface comme wallet_v5r1, correspondant aux contrats W5 déployés sur le mainnet. Les apps wallet proposent de plus en plus W5 par défaut pour les nouvelles adresses, avec possibilité de revenir à V4 si besoin.

Parce qu’un wallet TON, c’est du code de contrat + des données, changer de version de wallet (ex : V4 → W5) change le contrat donc l’adresse. Votre phrase de récupération peut générer des clés pour plusieurs versions, mais les soldes ne sont pas « automatiquement » transférés : on déploie le nouveau wallet puis on transfère des fonds ou on interagit selon le besoin. Certaines applications permettent de gérer plusieurs versions parallèlement.

Réponse courte : TON n’exécute pas l’Ethereum Virtual Machine. Les smart contracts sur TON fonctionnent sur la TON Virtual Machine (TVM), le runtime natif du réseau. Des initiatives de l’écosystème peuvent ajouter la compatibilité EVM en tant que couches/projets séparés, mais ce n’est pas inclus dans le protocole de base.

TON Virtual Machine (TVM) est une VM déterministe basée sur une pile, utilisée par la masterchain et la workchain de base. Elle exécute le code des contrats, analyse les messages entrants et la donnée persistante, met à jour l’état et génère les messages sortants. Les “get-methods” côté client sont exécutées localement sur une TVM et l’état vérifié, ce qui évite de devoir utiliser un full-node pour la lecture.

Langages sur TON :

• FunC – Langage bas-niveau proche du C pour écrire des contrats qui compilent en bytecode TVM ; l’outillage standard et le set d’instructions sont maintenus dans les dépôts officiels TON.
• Tact – Langage haut-niveau compilant pour TVM via la toolchain TON ; la documentation décrit la langue, le système de types et le build flow.

Workflow développeur : De nombreux projets initialisent, testent et déploient des contrats TVM avec l’environnement officiel Blueprint, compatible FunC et Tact.

À propos de l’EVM sur TON : Lorsque l’exécution EVM existe dans TON (ex : via TEVM/L2), c’est une couche additionnelle et non le runtime natif de TON.

Toute transaction on-chain sur TON—envoi de GRAM ou de tokens, déploiement de contrat, appel de contrat—entraîne des frais payés en Gram. Les wallets soumettent un message externe à votre contrat wallet, qui l’exécute et (souvent) émet des messages internes ; chaque étape génère des frais. Certains wallets proposent des transferts « sans gas » via W5 (un relayer paie pour vous ou les frais sont pris sur l’actif envoyé), mais le réseau solde toujours les frais en GRAM.

Comment les frais sont composés

Au niveau bas, les frais totaux d’une transaction sont la somme de plusieurs composantes représentant l’exécution et la messagerie entre shards/workchains :

• Frais de calcul (gas) : facturés en fonction du nombre d’étapes TVM ; la grille tarifaire vient de paramètres on-chain (masterchain/basechain).
• Frais d’action : facturés pour les actions exécutées durant la phase “action” (ex : création et envoi de messages sortants).
• Frais de forwarding : payés pour la transmission des messages ; dépendent de la taille (cells/bits) et des prix définis dans la configuration réseau. Il y a un frais pour la transmission entrante, puis à chaque relais sortant.
• Frais de stockage (“storage rent”) : facturés pour la quantité de données que votre compte/contrat conserve dans le temps (paramètre 18). Comportement et issues en cas de non-paiement expliqués dans la section suivante.

Les outils et API exposent ces parties directement. Par exemple, estimateFee retourne in_fwd_fee, storage_fee, gas_fee et fwd_fee pour source et destination, formant le coût total pour l’expéditeur et le receveur d’un message.

Un simple transfert, décomposé :

• Le message externe de votre wallet s’exécute (gas fee) → il aligne un transfert interne (action fee).
• Le message interne est délivré au destinataire (forwarding fee), qui paie la partie entrante pour traiter ce message et tout calcul nécessaire à l’exécution du code wallet. Les montants exacts varient selon la taille du message, le chemin de code et la configuration courante.

Notes pour les utilisateurs :

• Les wallets calculent automatiquement les frais ; le montant final apparaît avant confirmation. Certains offrent “Battery” ou des outils similaires pour abstraire le paiement des frais.
• Les développeurs peuvent calculer les frais de forwarding/calcul/stockage via les fonctions officielles lisant la configuration en direct (ex : helpers forward-fee et compute-fee).

Le storage rent est un frais temporel pour conserver un état sur la blockchain TON (code/data du wallet ou contrat). Il est payé en Gram, dépend de la quantité de state (nombre de cellules et de bits) et de la durée de stockage. Les prix viennent de la configuration réseau (Param 18), avec tarif plus haut sur la masterchain que sur la workchain de base. Les wallets et SDK lisent ces valeurs ; nul besoin de les calculer soi-même.

Paiement des frais : Les frais de stockage sont déduits lors de la phase Storage de toute transaction touchant le compte. Même la réception d’une toute petite valeur (ex : 1 nanoton) déclenche le paiement de toute la dette de stockage depuis le dernier règlement. Les messages « bounced » entraînent aussi le paiement des storage fees. Après une longue inactivité, la prochaine transaction inclura donc un composant stockage plus élevé.

Comment c’est calculé (vue développeur) : Au niveau bas, le frais est proportionnel à account.bits * bit_price + account.cells * cell_price fois les secondes écoulées (avec les prix pris de la Config 18). TON ne compte que les cellules uniques (dédupliquées par hash). Les outils officiels exposent des fonctions aidant à calculer les storage fees à partir de la config active.

Si le compte ne peut pas payer : Si le solde est insuffisant pour couvrir la dette de storage, le protocole peut geler le contrat : son code et ses données sont supprimés pour libérer des ressources, mais l’adresse et tout solde restant restent présents. Le réseau conserve les hash des cellules supprimées pour une éventuelle récupération. Pour réactiver, envoyez du Gram à l’adresse (pour régler les frais) et un message contenant le code/données originaux correspondant aux hash ; l’état est alors restauré.

Cas particuliers & notes historiques

• Les contrats n’ayant jamais changé d’état entrent dans une phase “uninit” plutôt que gelée ; ils peuvent être rétablis.
• Le whitepaper TON original prévoit que si personne n’interagit avec un compte, le loyer n’est pas prélevé indéfiniment ; une tierce partie peut envoyer un message minimal pour déclencher le prélèvement et la suppression des comptes insolvables (avec une petite incitation). Les implémentations modernes exposent ce flux de gel/récupération comme ci-dessus.

Les « TON Services » sont des composants réseaux qui complètent la blockchain TON : système de noms (TON DNS), layer de contenu (TON Storage), accès web (TON Sites), et layer d’anonymisation/routage (TON Proxy). Ils reposent sur la stack P2P de TON (ADNL/RLDP) et, lorsqu’ils touchent la blockchain (ex : enregistrements ou paiements), les opérations sont réglées en Gram.

TON DNS : TON DNS associe des noms lisibles (ex : exemple.ton) aux ressources TON : adresses de contrats et endpoints ADNL utilisés par des services comme TON Sites. Il fonctionne comme un système hiérarchique on-chain ; les applications résolvent les noms vers les adresses 256 bits correspondantes. Les modifications (enregistrement, extension, update) génèrent une transaction on-chain payée en Gram.

TON Sites : TON Sites sont des « services réseau purs » accessibles via le transport TON (ADNL/RLDP). En général, l’utilisateur fait tourner/se connecte à un ton-proxy qui accepte les requêtes HTTP locales, les transmet via le réseau TON à l’adresse abstraite du service, puis retourne les réponses—pour une expérience type web sans dépendre d’Internet public. Les noms sont résolus via TON DNS. Publier ou mettre à jour l’adresse/le record utilise une transaction on-chain payée en Gram, mais la navigation est off-chain.

TON Storage : TON Storage assure le stockage décentralisé de fichiers accessible via le réseau TON (servant aussi aux données archivées blockchain). Le daemon storage de référence et ses smart contracts permettent de payer les stockeurs, qui retirent leurs fonds en produisant des preuves Merkle liées aux données stockées. Tous les paiements et interactions contracts sont en Gram, tandis que les transferts de data sont sur les protocoles P2P TON.

TON Proxy : TON Proxy est la couche proxy/anonymiseur réseau. Elle masque l’identité/IP des nœuds et permet l’accès aux TON Sites en relayant le HTTP local vers le transport TON, améliorant l’accessibilité en cas de filtrage ou de DDoS. Utiliser un proxy ou modifier sa config est off-chain ; la publication/découverte des endpoints proxy (“entry”) via des registres/DNS passe par des opérations on-chain donc en Gram.

Rôles en résumé :

• Les wallets détiennent les clés de l’utilisateur et demandent l’approbation lorsqu’une dApp veut effectuer une transaction ou signer des données. Dans Telegram, Wallet in Telegram propose un TON Wallet auto-custodial (clés on-chain) et un Crypto Wallet custodial ; les deux peuvent apparaître comme cibles de connexion.
• TON Connect est le protocole standard pour relier dApps et wallets. Il définit comment les apps découvrent les wallets, créent une session chiffrée et demandent des actions comme sendTransaction ou signData.
• Les Telegram Mini Apps sont des apps web dans Telegram. Elles ajoutent l’UI et l’auth Telegram, et intègrent la blockchain via TON Connect. Les paiements intégrés à Telegram (Bot Payments / Stars) sont distincts des transferts TON on-chain.

Flux de connexion (comment les actions sont approuvées par l’utilisateur) :

1. La dApp (site classique ou Mini App) affiche « Connecter un wallet ». Avec le SDK TON Connect, elle liste les wallets supportés et détecte le contexte (embarqué/injecté/distant). Si le wallet est embarqué (ex : dans Telegram), le SDK utilise un pont JS ; sinon il ouvre un lien universel/deep link ou QR vers le wallet choisi.
2. Le wallet et l’app créent une session sur un bridge hébergé côté wallet. Les messages sont chiffrés de bout en bout, donc le bridge ne les lit pas.
3. Une fois connecté, l’app peut demander :
   • sendTransaction — le wallet affiche la transaction et, si l’utilisateur accepte, signe et émet la transaction sur TON ; l’app reçoit le résultat (BOC/hash tx).
   • signData — demande au wallet de signer du texte ou bytes/cells pour vérification off-chain ou on-chain ; aucun fonds ne bouge.

Dans une Mini App Telegram : La Mini App charge le WebApp SDK Telegram pour l’UI/authorisation, puis ajoute TON Connect pour la blockchain. L’utilisateur vit un flow sans couture : ouvrir la mini app → connecter le wallet → accepter un virement GRAM ou un appel de contrat → l’app reçoit la confirmation, les clés restant dans le wallet.

Paiements : on-chain vs système Telegram :

• Paiements GRAM on-chain (ex : transferts GRAM/Jetton, appels contrat) utilisent TON Connect et sont payés on-chain ; détails des frais dans la section Frais.
• Bot Payments / Stars Telegram sont des flux de paiement natifs Telegram (prestataires fiat, Stars pour contenus digitaux). Ils ne nécessitent pas de transaction blockchain et sont configurés via les API Telegram. Beaucoup de Mini Apps combinent les deux modèles selon le cas d’usage.

Transferts P2P dans les chats (TON Wallet auto-custodial) : Avec TON Wallet (option auto-custodiale dans “Wallet in Telegram”), vous pouvez envoyer du Gram, jettons et NFTs à un contact Telegram depuis une discussion. L’app crée un contrat smart escrow qui retient les actifs jusqu’à acceptation ou refus. Si accepté, les fonds sont transférés on-chain au destinataire ; sinon ou en cas de non-réclamation sous 14 jours, ils sont renvoyés automatiquement à l’émetteur. Avec les wallets compatibles W5, les transferts « sans gas » sont possibles : le frais réseau peut être payé via l’actif transféré (ex : USDT), le règlement ayant toujours lieu on-chain en TON.

Transferts P2P dans les chats (Crypto Wallet custodial) : Le Mini App Crypto Wallet séparé permet des transferts instantanés off-chain entre utilisateurs Crypto Wallet dans Telegram, affichés comme des P2P sans frais dans le chat. Ceux-ci n’apparaissent pas sur la blockchain ; dépôts/retraits externes sont on-chain et soumis à frais réseau. La disponibilité dépend de la région.

P2P Market (ramp fiat avec escrow) : Au sein du Crypto Wallet, le P2P Market autorise l’achat/vente d’actifs supportés entre utilisateurs selon leurs modes de paiement acceptés. Les cryptos sont bloquées en escrow jusqu’à confirmation du paiement, puis délivrées à l’acheteur. Un maker fee s’applique pour chaque transaction réussie, affiché dans l’app selon la région.

Partage des revenus pubs de chaînes (payés en GRAM) : La plateforme pub de Telegram vend des annonces basées sur TON ; les annonceurs paient en Gram. 50 % du revenu généré par des pubs affichées sur des chaînes publiques éligibles sont reversés aux propriétaires. Les retraits se font via Fragment, avec des récompenses versées par défaut en Gram ; d'autres modes de paiement peuvent s'appliquer selon les pays (cf. conditions Fragment).

Notes pratiques :

• « Wallet in Telegram » combine les deux modes : TON Wallet (auto-custodial, on-chain) et Crypto Wallet (custodial mini-app). Les fonctionnalités varient selon la juridiction ; consulter l’aide intégrée si une fonctionnalité manque.
• Pour les frais sur envois on-chain (compute/action/forward/storage), voir la section dédiée ; les transferts internes Crypto Wallet sont gérés en interne et n’apparaissent que dans l’historique de l’app.

Oui. Tether a lancé USD₮ natif sur The Open Network en tant que jetton TON et référence le contrat officiel sur sa page Supported Protocols : EQCxE6mUtQJKFnGfaROTKOt1lZbDiiX1kCixRv7Nw2Id_sDs. Tether a aussi annoncé le lancement d’USD₮ (et XAU₮) sur TON en avril 2024.

USD₮ utilise le standard Jetton (token fongible TON). Vous disposez d’un contrat wallet par utilisateur qui miroir le master Jetton, les transferts étant de simples messages on-chain. Les frais de réseau sont toujours payés en GRAM ; le montant stablecoin envoyé est distinct du Gram utilisé pour les frais. Pour identifier un “USDT” légitime, comparez toujours l’adresse du master Jetton avec le listing officiel de Tether. Le framework Jetton de TON permet à tout le monde de créer des imitations, donc la vérification du contrat est cruciale.

Utilisation d’USDT dans Telegram et les wallets TON : Dans Wallet in Telegram, le TON Wallet auto-custodial gère les transferts USD₮ (TON) on-chain, tandis que le Crypto Wallet custodial prend en charge les transferts instantanés off-chain entre ses utilisateurs et un P2P Market intégré. Le P2P Market facture un maker fee de 0,9 % sur les transactions réussies. Disponibilité selon région et partenaires.

Support exchanges (on-/off-ramps) : Les grands exchanges supportent les dépôts/retraits USDT (TON), permettant aux utilisateurs de déplacer USD₮ directement sur/depuis TON sans bridge. Exemples : Binance, OKX, Bybit, KuCoin, chacun ayant publié un communiqué d’ouverture. Vérifiez le réseau de dépôt choisi avant tout envoi.

Bridge de stablecoins avec TON : Le transfert inter-chaînes est assuré par des bridges tiers. TON a des intégrations de bridge comme LayerZero/Stargate pour le transfert d’actifs supportés entre TON et d’autres chaînes. Le bridging n’est pas natif du protocole TON, implique donc un risque de confiance supplémentaire et smart contract ; utilisez toujours les endpoints officiels et vérifiez le contrat de l’actif de destination.

Recommandations de sécurité :

• Vérifiez que le master Jetton d’USD₮ correspond à l’adresse officielle de Tether avant toute interaction.
• Méfiez-vous des token “wrapped” ou des anciens tickers antérieurs à USD₮ natif sur TON ; vérifiez la nature de ce que vous recevez et s’il s’agit d’un token bridge. (Des explorateurs comme Tonviewer pointent sur l’adresse officielle ci-dessus.)

Les données de supply changent en continu. Pour l’offre totale et circulante à jour, consultez les métriques en direct de cette page ou un explorateur TON de référence.

Émission (comment le GRAM entre en circulation) : Les nouveaux GRAM sont créés par le protocole en tant que récompense proof-of-stake. À chaque round de validation, les validateurs élus mettent leur stake dans le contrat Elector ; à la fin du round, Elector paie les récompenses, ce qui augmente la supply totale. Les pools nominateurs sont des contrats qui regroupent les TON des utilisateurs et interagissent avec Elector en leur nom, redistribuant ensuite les récompenses selon leurs règles.

Inflation (ce qui la détermine) : L’inflation effective n’est pas un calendrier fixe ; elle résulte de l’émission (issuance) déduction faite de tout burn sur une période. Les paramètres de récompense des validateurs et la cadence des élections sont on-chain et peuvent changer via la gouvernance/configuration. Pour estimer l’inflation actuelle, comparez la création via Elector avec toute destruction relevée (voir section “Burn”).

Burn (comment la supply peut baisser) : Deux voies existent pour détruire du GRAM :

1. Burn partiel des frais : le réseau peut être configuré pour brûler une partie des frais au lieu de les reverser aux validateurs. Une proposition communautaire pour brûler 50 % des frais de transaction a été publiée en 2023 ; la part réellement brûlée est dictée par la config réseau en cours, donc à vérifier à chaque instant.
2. Burn explicite vers une adresse sink : les coins envoyés vers l’adresse canonique de burn (souvent burn-address.ton) sont irrécupérables et retirés de la supply. Les explorateurs exposent cette adresse et son activité.

Rôles et contrat Elector : TON fonctionne en proof-of-stake. Les validateurs bloquent du Gram et entrent dans des élections orchestrées par le contrat Elector on-chain ; les élus produisent des blocs. À la fin du round, Elector verse les récompenses on-chain. Explorateurs et SDK exposent des get-methods Elector (ex : active elections, minStake, past rounds, unfreezeAt).

Validateurs (staking direct) : Un validateur stake depuis son contrat contrôler vers Elector, fait tourner le logiciel de validation, et touche des récompenses s’il reste sain. Le stake est gelé pour le round concerné et retirable uniquement après l’unfreeze de l’Elector pour la période. Le min stake et autres paramètres sont dynamiquement consultés dans l’état Elector ; ils ne sont pas constants. (Les pénalités en cas de faute sont détaillées dans la section suivante.)

Pools nominateurs (délégation à un validateur) : La majorité des détenteurs délèguent via des contrats de pool de nominateur open source. Vous déposez des Gram sur le contrat du pool ; celui-ci stake chez Elector pour tous les déposants puis distribue les récompenses comme prévu. Les retraits s’effectuent en envoyant un simple message (ex : commentaire “w”) au pool ; les fonds sont libérés après la complétion du round associé et lorsque le pool a la liquidité nécessaire. Il n’y a généralement pas de retrait instantané ; l’attente est la fin de cycle. Les règles du pool (ex : nominators max) sont imposées dans le contrat.

Pool à nominateur unique (un délégant, un validateur) : Un design alternatif simplifie le pool à un seul délégant vers un validateur ; surface de code réduite, même logiques d’interaction. Ce schéma est open source et utilisé par certains opérateurs.

Liquid staking (receipt tokens) : TON fournit aussi une implémentation de liquid staking. Les déposants reçoivent un jetton (receipt token) qui représente leur part du pool et accrédite les récompenses ; le pool stake ensuite auprès des validateurs via Elector. Les rachats suivent le timing de sortie du validator, mais les receipts peuvent être transférés/vendus pour la liquidité avant la fin du cycle de retrait. Le code est maintenu dans le GitHub core TON.

Lockup et unbonding – ce qu’il faut retenir :

• Validateurs : le stake est bloqué sur le round actif puis retirable après l’unfreezeAt Elector. Les rewards sont récupérables à partir du règlement.
• Nominators en pool classique : les sorties sont mises en file et traitées après la fin d’un round ; pas de sortie garantie immédiate. Vérifiez la politique du pool (batching, mini…).
• Utilisateurs de liquid staking : les receipts tokens sont liquides par transfert ; les brûler pour obtenir GRAM suit les règles de sortie du pool, dépendant du cycle validator.

TON applique le slashing pour pénaliser les comportements défaillants détectés sur un round :

• Idle/sous-performance : un validateur traite trop peu de blocs lors d’un round. Les plaintes sont générées et votées par les autres validateurs (souvent via mytonctrl), entraînant une amende prélevée sur son stake pour la période.
• Triche/équivocation : ex : création de messages conflictuels (fork) détectés par le consensus Catchain ; les validateurs fautifs sont isolés et sanctionnés (à la même hauteur qu’inactivité dans l’historique, des hausses ayant été proposées).

Le processus : après chaque round, les validateurs s’auditent entre eux ; les plaintes valides sont votées et la pénalité, définie dans la config du réseau, déduite du stake gelé du fautif pour ce round. Les opérateurs non utilisateurs de mytonctrl peuvent recourir au script officiel Punisher pour participer au vote de plainte. Les paramètres de slashing sont explicitement stockés dans la configuration réseau (ajouté via update réseau).

Impact pour délégants/pools : Les pools nominateurs stake pour leurs déposants auprès de l’Elector puis récupèrent les fonds après le round. Si un validateur est slashed, le montant rendu par l’Elector est réduit pour cette période, la perte étant partagée entre délégants selon les règles du pool. (Les pools reçoivent “en général” plus qu’envoyé, sauf slashing.) Relisez le contrat/politique du pool avant de déléguer.

Exigences de capital pour validateur :

• Stake minimum pour participer à l’élection : la page officielle indique 300 000 GRAM au moins. En pratique, le minimum effectif d’élection dépend de la concurrence et des paramètres on-chain de l’élection.
• Mécanisme de cycle : le stake est gelé chez l’Elector pour une période ; après règlement, stake et reward sont rendus on-chain.

Hardware & opérations (vue d’ensemble) :

• La recommandation officielle : matériel performant, connexion réseau très disponible (24/7, faible latence, évite l’idle penalty).
• Les guides communautaires conseillent généralement CPU multi-cœurs modernes, RAM abondante, SSD/NVMe rapides ; un guide fréquemment cité préconise 8 vCPU, 64 Go RAM, ~1 To SSD et 1 Gb/s de bande passante comme base pratique. À voir comme recommandations, pas comme règles protocolaires.
• La majorité des opérateurs utilisent mytonctrl pour gérer les nœuds, tenir le logiciel à jour et automatiser la gestion des plaintes/télémétrie.

À retenir :

• TON sanctionne le slashing pour les validateurs inactifs et tricheurs (équivocation/fork) détectés par Catchain ; les amendes sont fixées dans la config active et déduites du stake sur le round concerné.
• Pour minimiser les risques : uptime maximal, suivi de la perf, mises à jour du node, choix de validateurs/pools reconnus si délégation.

Jetton (tokens fongibles) — standard et modèle : Jettons suivent TEP-74. Un Jetton regroupe un contrat Jetton Minter (master) définissant la politique (émission, burn, metadata) et, pour chaque détenteur, des Jetton Wallet contracts où sont conservés les soldes. Les interfaces (ex : get_jetton_data, opcodes de transfert) sont standardisées pour l’interopérabilité wallets, exchanges, indexeurs.

Émission d’un Jetton (étapes type) :

1. Partir d’une implémentation de référence (FunC ou Tact), renseigner metadata (nom, symbole/décimales via TEP-64), policy supply et droits admin.
2. Déployer le Jetton Minter, en passant le code Wallet souhaité comme library cell.
3. Émettre en envoyant des messages du minter pour créer/créditer les Jetton Wallet contracts des receveurs ; brûler revient à envoyer des messages réduisant le supply.

Les repos officiels fournissent minter/wallet de production + un « Jetton Deployer » accessible par navigateur.

Jetton metadata : Les infos d’affichage (nom, description, image, décimales) utilisent le Token Data Standard TEP-64. On peut stocker les metadata on-chain (cells) ou off-chain (URL vers JSON). L’usage des champs standard garantit la lisibilité côté wallets/explorateurs.

NFT — standards et contrats : Les NFT reposent sur TEP-62. Chaque NFT Item est son propre contrat ; les items sont groupés sous un contrat Collection exposant les infos globales/découverte. TEP-62 standardise transfert et découverte ; TEP-64 apporte le schéma metadata pour chaque item et collection.

Émission d’une collection et items NFT (étapes type) :

1. Déployer la Collection avec ses metadata TEP-64 (nom, image de couverture, layout contenu).
2. Émettre les Items par le déploiement de contrats, chaque item référant la collection ; metadata TEP-64 item (nom, image, attributs) lors du mint.
3. Les transferts sont des messages TEP-62 entre contrats d’items ; wallets/markets affichent les moves standardisés.

Outils (officiels et majeurs) :

• Blueprint — l’environnement tout-en-un pour initialiser, tester, déployer des contrats TON (FunC, Tact, Tolk). Idéal pour monter un Jetton/NFT, avec gestion des tests/scripts.
• Tact — langage haut-niveau avec templates, Jetton TEP-ready ; docs et GitHub proposent exemples et patterns.
• FunC — langage bas-niveau + stdlib TVM ; beaucoup de Jetton/NFT de référence écrits en FunC.
• SDKs — le TypeScript @ton/ton (ton-core) embarque helpers Jetton/NFT (ex : JettonMaster), TonWeb étant une mature librairie JS utilisée dans nombre de guides. TonAPI fournit le REST/SDK pour soldes, metadata, transferts.

Bonnes pratiques :

• Rester dans les interfaces TEP. Si extension métier (frais, pause, rôles minter), conserver les getters/messages TEP sinon le token ne sera pas reconnu par wallets/markets.
• Utiliser TEP-64 partout. Choisir dès le début on-chain ou URL off-chain, garder le schéma stable (évite displays cassés).
• Vérifier contrats et adresses : publier adresse/codes hash du minter/collection ; pour les fongibles, rendre l’adresse du Jetton master publique pour que les utilisateurs/intégrations valident le bon actif.

Fragment est la marketplace officielle Telegram pour les usernames collectables et actifs associés. Les ventes se tiennent par enchères publiques ou prix fixe, et sont réglées en Gram (GRAM). Après achat, le collectable apparaît dans le compte Fragment de l’acheteur et peut être assigné à un profil, chaîne ou groupe Telegram. La documentation Fragment décrit la connexion wallet, enchères et attribution, et confirme que règlement et enchères s’effectuent en Gram.

Comment fonctionnent les enchères @username sur Fragment :

• Enchères et règlement : Les utilisateurs se connectent via Telegram, lient un wallet TON et enchérissent on-chain en Gram ; en cas de surenchère, les fonds sont automatiquement rendus. Le gagnant reçoit le collectable dans son wallet.
• Listing & annulation : Vous pouvez proposer un nom éligible à la vente et annuler tant qu’aucune enchère n’a été placée. Après une enchère, l’enchère va à son terme selon les règles indiquées.
• Frais : Fragment annonce un frais plateforme (sur la page du lot) pour chaque vente + un frais de conversion unique. Considérez les frais affichés comme seule référence, à vérifier sur la fiche du lot avant tout listing.
• Après l’enchère : Le username peut être attribué à une entité Telegram via Fragment ; l’assignation est modifiable par le propriétaire.

Rôle de TON : Tous les paiements sur Fragment sont en Gram. Par ailleurs, la plateforme pub de Telegram utilise aussi Gram pour l’achat/retrait de pubs, via Fragment—mais les flux pub sont distincts des enchères de usernames.

Enchères de domaines TON (.ton) :

• Standard & objectif : TON DNS associe des noms humains (ex : nom.ton) aux ressources TON (adresses, endpoints ADNL), défini selon TEP-81.
• Affichage côté utilisateurs : Les enchères de domaines sont assurées par contrats on-chain, visibles sur les explorateurs (ex : Tonviewer “Auctions” pour tel nom). Les places de marché peuvent référencer des DNS comme actifs négociables, le contrat étant la source vérité. Toujours vérifier l’adresse contractuelle avant d’enchérir.
• Paiement et finalisation : Les enchères se paient en Gram et se règlent sur la chaîne ; après l’enchère, l’état du contrat du domaine est transféré au gagnant, qui peut alors définir les records selon TEP-81. Les outils/API listent propriétaire DNS et expiration.

Checklist sécurité rapide :

• Toujours vérifier l’URL officielle du lot sur Fragment, relire les lignes de frais avant tout listing/enchère.
• Pour les domaines .ton, confirmer l’adresse du contrat et lire les records TEP-81 ; utiliser un explorateur ou API fiable pour vérifier propriétaire/expirations.

La technologie TON a été développée à l’origine par Telegram (Pavel et Nikolaï Durov), avec l’intention de lancer le Gram token. En mai 2020, Telegram annonce l’arrêt du projet suite à une action de la SEC américaine ; le règlement judiciaire contraint Telegram et sa filiale TON Issuer à restituer les fonds aux investisseurs et à régler une amende civile. Le code source est resté public.

Du « Telegram Open Network » à un TON communautaire avec Gram : Après le retrait de Telegram, des développeurs indépendants poursuivent le réseau sous le nom The Open Network (TON). La gouvernance actuelle appartient à la communauté et à la TON Foundation (association suisse à but non lucratif) ; l’actif natif est Gram (GRAM), et non Gram. Telegram ne contrôle pas la blockchain.

Quelle relation entre Telegram et TON aujourd’hui ? Telegram intègre TON comme fonctionnalité plateforme, mais reste une entreprise indépendante :

• Wallet in Telegram propose un TON Wallet auto-custodial (clés sur la blockchain TON, non détenues par Telegram) et un Crypto Wallet custodial distinct.
• La plateforme publicitaire Telegram vend des pubs basées TON, partage 50 % des revenus pubs avec les chaînes éligibles, retraits via Fragment.
• Fragment héberge les enchères/ventes de usernames collectables, payées en Gram.

En résumé :

• Créateurs : l’équipe Telegram (frères Durov) a conçu la technologie et le concept “Telegram Open Network”.
• Réseau et coin actuels : portés par la communauté indépendante, gouvernés et soutenus par la TON Foundation ; actif natif Gram.
• Rôle de Telegram : intégrateur et canal de distribution, pas opérateur ni émetteur du réseau. Les produits Telegram se connectent à TON sans le contrôler.