Gram (prev. Toncoin)

Gram (ticker: GRAM) es la criptomoneda nativa de The Open Network (TON), una blockchain de capa 1 y stack de servicios. Existe en TON propiamente dicha (no como un ERC-20 ni como un activo envuelto) y funciona como moneda base de la red. En la práctica, Gram es la unidad utilizada para operar la blockchain y sus servicios integrados: transacciones y ejecución de contratos inteligentes en la Blockchain TON, y operaciones de servicio en TON DNS, TON Sites, TON Storage y TON Proxy.

Gram también sustenta el modelo de seguridad proof-of-stake (prueba de participación) de la red: los validadores apuestan GRAM para ayudar a ejecutar la cadena y reciben recompensas del protocolo por hacerlo. Los detalles operativos sobre el staking y los roles de los validadores se tratan en secciones dedicadas.

Las herramientas de desarrollo y el código suelen referirse a saldos en nanotones (a menudo escrito como ‘nano’), la unidad más pequeña en la cadena aunque los usuarios interactúan con Gram. Esto es análogo a los “wei” en Ethereum y ayuda a evitar redondeos en la lógica de los contratos inteligentes. Para usos prácticos de Gram en aplicaciones y servicios, consulta “¿Para qué se usa Gram en el ecosistema?”

Telegram desarrolló originalmente la “Telegram Open Network” y planeaba el token Gram, pero detuvo el proyecto en 2020 tras una acción de la SEC estadounidense y un acuerdo aprobado por el tribunal. El código open-source y la visión se continuaron luego por una comunidad independiente como The Open Network (TON) con Gram como activo nativo. Hoy, TON es una blockchain gestionada por la comunidad, mientras que Telegram es una empresa separada.

Telegram ahora se integra con TON sin controlarla. La compañía opera una Wallet dentro de Telegram que ofrece dos modos: una Crypto Wallet custodial y una TON Wallet autocustodiada para actividad on-chain en la blockchain TON. La disponibilidad y las funciones dependen de la región y de las políticas de producto.

Telegram también opera Ads basados en TON: los anunciantes compran anuncios en canales usando Gram, y los propietarios de canales elegibles pueden retirar el 50% de los ingresos publicitarios (administrados a través de Fragment). Esto es una integración de plataforma construida sobre TON y no un rol de gobernanza en la red.

Fragment es el mercado oficial de Telegram para @usernames y activos relacionados; las subastas y liquidaciones se realizan usando Gram y enlazan con cuentas de Telegram.

Por otro lado, la Fundación TON es una organización sin ánimo de lucro suiza que apoya el ecosistema de TON; no es propietaria de Telegram ni gestiona la plataforma de mensajería.

The Open Network (TON) es una plataforma open-source, gestionada por la comunidad, de Capa 1 que combina una blockchain base de contratos inteligentes con componentes p2p y servicios nativos de soporte. La especificación técnica original (el whitepaper de TON) describe un diseño multiblockchain, además de un stack P2P y “TON Services” como DNS, Storage, Sites y Proxy que las aplicaciones pueden utilizar en una sola red cohesiva. En este modelo, la Blockchain TON es el libro mayor central, mientras que los demás módulos proporcionan resolución de nombres, almacenamiento y distribución de datos y enrutamiento de tráfico como parte del mismo ecosistema.

El código base y el software de validadores de TON se desarrollan en repositorios públicos; el proyecto opera sin una única autoridad de control. La Fundación TON es una organización sin ánimo de lucro suiza que apoya el ecosistema pero no controla la tecnología.

Gram (GRAM) es la moneda nativa de la red. En el diseño de TON, la moneda nativa paga las tarifas on-chain y es apostada por validadores para asegurar la red; el whitepaper (escrito antes del cambio de marca comunitario de “Gram” a “Gram”) describe los roles de la moneda en el metering de computación (“gas”) y la economía de los validadores. Hoy, Gram es la unidad utilizada en todo el ecosistema, incluyendo integraciones de plataforma como los anuncios basados en TON de Telegram. Para detalles sobre tarifas y staking, consulta las secciones dedicadas en esta descripción.

Gram es el activo nativo que sustenta la actividad en The Open Network. Sus usos se agrupan en cuatro áreas prácticas:

1. Pago de tarifas on-chain: Las transacciones y la ejecución de contratos inteligentes en TON se pagan en Gram. Las tarifas cubren la computación, el enrutamiento de mensajes y los cargos por almacenamiento.

2. Asegurar la red mediante staking: Los validadores apuestan Gram para participar en la validación proof-of-stake y ganar recompensas del protocolo; la delegación se implementa a través de contratos de pools nominadores en la cadena.

3. Liquidar servicios a nivel de protocolo: Los servicios integrados de TON (por ejemplo, TON DNS, Storage, Sites y Proxy) forman parte del stack de la red. Las interacciones como registrar o subastar nombres .ton, resolver nombres u operar nodos de almacenamiento implican transacciones on-chain denominadas en Gram. La mecánica detallada de cada servicio se cubre en la sección TON Services.

4. Integraciones de plataforma y aplicaciones: Gram se acepta para comprar Telegram Ads, y los propietarios de canales elegibles retiran ingresos a través de Fragment; las subastas de @usernames coleccionables en Fragment también se liquidan en una wallet TON conectada. Más allá de Telegram, las dApps en TON suelen cotizar precios y liquidar pagos en Gram.

Para la estructura de comisiones consulta “¿Qué acciones on-chain requieren TON y cómo se calculan las comisiones...?”; para roles y delegación de staking consulta “¿Cómo funciona el staking en TON...?”.

TON está diseñada como una colección de blockchains que operan en paralelo y se coordinan a través de una cadena especial llamada masterchain. Debajo se encuentran una o más workchains, cada una de las cuales puede fragmentarse dinámicamente en múltiples shardchains. Esta estructura permite a TON procesar actividades de forma concurrente manteniendo la coherencia del sistema.

Masterchain: La masterchain registra metadatos y datos de coordinación a nivel de red para todo el sistema (por ejemplo, hashes de los últimos bloques de todas las shardchains). Al incluir estas referencias, la masterchain hace que esos bloques fragmentados sean canónicos, permitiendo que otras partes confíen en ellos al instante en bloques sucesivos. Muchos parámetros clave del protocolo también se almacenan en el estado de la masterchain.

Workchains: Una workchain es una blockchain completa dentro de TON que define sus propias reglas y formato de bloque. El whitepaper prevé hasta 2³² workchains; en la práctica, la mayoría de las aplicaciones usan la “workchain básica” (también llamada Workchain Zero), donde se ejecutan los contratos inteligentes de TON y se realizan las transferencias de Gram. En el futuro pueden existir diferentes workchains para fines especializados.

Shardchains (fragmentación dinámica): Cada workchain se divide en shardchains, donde cada shard es responsable de un subconjunto de direcciones de cuenta. Los shards pueden dividirse cuando la carga es alta y fusionarse cuando es baja, proporcionando capacidad elástica sin coordinación manual. El enrutamiento entre shards y workchains utiliza el modelo de paso de mensajes de TON, de modo que los contratos inteligentes pueden enviar mensajes y valor entre shards de forma fiable.

Cómo encajan las piezas

• Las shardchains producen bloques en paralelo; la masterchain luego incluye los hashes de esos nuevos bloques, que otros shards tratan como finales para acciones posteriores.
• La “workchain básica” alberga hoy la actividad de contratos inteligentes y transferencias de Gram; otras workchains pueden adoptar reglas diferentes o incluso una máquina virtual diferente, mientras la masterchain mantiene todo en sincronía.

En TON, cada cuenta de usuario es un contrato inteligente. Una “wallet” es simplemente un contrato mínimo que almacena Gram y envía mensajes firmados en nombre del propietario. La wallet verifica firmas de la clave del usuario, lleva un seqno (para evitar repeticiones), y ejecuta acciones autorizadas por el propietario cuando recibe un mensaje externo. En la documentación de desarrolladores de TON, esto se resume a menudo como “todo es un contrato inteligente”, incluidas las wallets.

Wallet V4 (v4r2): V4 estandarizó un modelo de plugins/extensiones: la wallet puede autorizar contratos compañeros de confianza (“plugins”) para realizar acciones específicas con fondos (por ejemplo, suscripciones). El repositorio V4 documenta la interfaz de plugins y cómo las wallets instalan y eliminan plugins. V4 sigue siendo ampliamente utilizada y es compatible con las principales wallets.

Wallet V5 (W5): V5—comúnmente conocida como W5—es el estándar de contrato de wallet más reciente, mantenido en los repositorios centrales de TON. Capacidades clave definidas en la especificación y el código incluyen:

• Multi-envío: una orden firmada puede emitir hasta 255 mensajes salientes;
• Acciones firmadas internas y externas, habilitando patrones de relayer (usados a menudo en flujos “gasless”);
• Un mecanismo generalizado de extensiones (sucesor de los plugins V4), incluyendo la opción de que una extensión bloquee acciones firmadas (útil para 2FA o recuperación).

La especificación y el repositorio también describen cómo los relayers gasless pueden reenviar un mensaje firmado y pagar las comisiones Gram al enviarlo.

W5 en la práctica: Los exploradores muestran una etiqueta de interfaz como wallet_v5r1, reflejando los contratos W5 desplegados en mainnet. Las wallets tienden cada vez más a usar W5 por defecto para nuevas direcciones, con retrocompatibilidad con V4 cuando es necesario.

Como una wallet TON es código de contrato y datos, cambiar de versión de wallet (ej., V4 → W5) cambia el contrato y, por tanto, la dirección. Tu frase semilla puede derivar claves para múltiples versiones, pero los saldos no se “mueven automáticamente”: despliegas la nueva wallet y transfieres fondos o interactúas según lo necesites. Algunas aplicaciones te permiten gestionar varias versiones en paralelo.

Respuesta corta: TON no ejecuta la Ethereum Virtual Machine. Los contratos inteligentes en TON se ejecutan en la TON Virtual Machine (TVM), el entorno de ejecución nativo de la red. Las iniciativas del ecosistema pueden añadir compatibilidad EVM como capas o proyectos separados, pero esto no forma parte del protocolo base.

TON Virtual Machine (TVM) es una máquina virtual determinista basada en pila, utilizada por la masterchain y la workchain base. Ejecuta el código de los contratos, analiza mensajes entrantes y datos persistentes, actualiza el estado y genera mensajes salientes. Los “get-methods” del lado del cliente se evalúan ejecutando una TVM local contra un estado verificado, lo que evita requerir un nodo completo para lecturas.

Lenguajes en TON:

• FunC – Lenguaje de bajo nivel, similar a C, para escribir contratos que se compilan a bytecode TVM; el conjunto de herramientas e instrucciones se mantiene en los repositorios oficiales de TON.
• Tact – Lenguaje de nivel más alto que compila a TVM a través de la toolchain de TON; la documentación oficial cubre el lenguaje, el sistema de tipos y el flujo de construcción.

Flujo para desarrolladores: Muchos equipos configuran, prueban y despliegan contratos TVM usando el entorno oficial Blueprint, que soporta proyectos en FunC y Tact.

Sobre EVM en TON: Allí donde se ofrece ejecución EVM en el ecosistema TON (por ejemplo, esfuerzos basados en TEVM o L2), se implementa como una capa adicional de compatibilidad y no como runtime nativo de TON.

Cualquier transacción on-chain en TON—enviar GRAM o tokens, desplegar un contrato o llamar a un contrato—incurre tarifas pagadas en Gram. Las wallets envían un mensaje externo a tu wallet contract, que luego se ejecuta y (típicamente) emite uno o más mensajes internos; cada paso tiene comisiones. Algunas wallets soportan flujos “gasless” vía W5 (un relayer paga por ti o las comisiones se cubren con el activo transferido), pero la red siempre liquida las comisiones en GRAM.

Cómo se componen las comisiones

A bajo nivel, la tarifa total de una transacción es la suma de varios componentes que reflejan ejecución y mensajería entre shards/workchains:

• Comisión de computación (gas): cobrada por los pasos TVM consumidos por tu contrato; los precios se extraen de parámetros de configuración on-chain (masterchain/basechain).
• Comisión de acción: cobrada por las acciones durante la “action phase” (por ejemplo, crear y enviar mensajes salientes).
• Comisiones de reenvío: pagadas por entregar mensajes; dependen del tamaño en celdas/bits y de los precios por cadena definidos en la configuración activa de la red. Hay comisión por entrega entrante y por cada salto saliente.
• Comisiones de almacenamiento (“storage rent”): cobradas por la cantidad de datos persistentes que tu cuenta/contrato almacene a lo largo del tiempo (parámetro 18). Explicamos comportamiento y consecuencias de impago en la siguiente sección.

Las herramientas y APIs para desarrolladores exponen directamente estas partes. Por ejemplo, estimateFee devuelve in_fwd_fee, storage_fee, gas_fee y fwd_fee para origen y destino, que en conjunto representan lo que pagan emisor y receptor por un mensaje dado.

Una transferencia simple, desglosada (conceptual):

• El mensaje externo de tu wallet se ejecuta (comisión de gas) → pone en cola una transferencia interna (comisión de acción).
• El mensaje interno se entrega al destinatario (comisión de reenvío); el destinatario paga la parte entrante por gestionar el mensaje, más cualquier computación necesaria para ejecutar su código de wallet. Los importes exactos varían según tamaño del mensaje, rutas de código y precios actuales de configuración.

Notas para usuarios:

• Las comisiones se calculan automáticamente por las wallets; verás el importe final antes de confirmar. Algunas wallets ofrecen herramientas tipo “Battery” para abstraer el pago de comisiones.
• Los desarrolladores pueden calcular programáticamente comisiones de envío/ejecución/almacenamiento usando las funciones oficiales que leen la configuración activa (por ejemplo, forward-fee y compute-fee helpers).

El storage rent es una tarifa basada en el tiempo que se cobra por mantener datos en la blockchain TON (código y datos de wallet/contrato). Está denominada en Gram y depende de la cantidad de estado que un contrato usa (número de celdas y bits) y cuánto tiempo ha estado almacenado. Los precios provienen de la configuración de red (Config Param 18), con tasas más altas en la masterchain que en la workchain base. Las wallets y SDKs leen estos valores; no hay que calcularlos manualmente.

Cuándo se recaudan: Las comisiones de almacenamiento se deducen durante la fase de almacenamiento de cualquier transacción que toque la cuenta. Incluso recibir un valor ínfimo (por ejemplo, 1 nanoton) desencadena el pago de toda la deuda de almacenamiento acumulada desde el último pago. Los mensajes rebotados también provocan el pago de la comisión de almacenamiento actual del contrato. Tras una larga inactividad, la siguiente transacción incluirá un componente de almacenamiento más elevado de lo habitual.

Cómo se calcula (vista desarrollador): A bajo nivel, la comisión es proporcional a account.bits * bit_price + account.cells * cell_price multiplicado por los segundos transcurridos (los precios se extraen del Config 18). TON cuenta sólo celdas únicas (deduplicación por hash). Las herramientas oficiales exponen funciones para calcular comisiones de almacenamiento directamente desde los valores activos de configuración.

Si la cuenta no puede pagar: Si el saldo de un contrato es insuficiente para cubrir el storage rent acumulado, el protocolo puede congelar el contrato: se eliminan su código y las celdas de datos para liberar recursos, mientras la dirección y cualquier saldo restante permanecen. La red conserva los hashes de las celdas eliminadas para que el contrato pueda restaurarse más adelante. Para descongelar, envía Gram a la dirección (para abonar comisiones) y un mensaje con el código y datos originales coincidiendo con esos hashes; el estado se restablece.

Casos límite y nota histórica

• Contratos que nunca cambiaron estado pueden pasar a un estado “uninit” en vez de congelados; aún pueden restaurarse.
• El whitepaper original de TON señala que si nadie envía mensajes a una cuenta, el storage rent no se cobra indefinidamente; cualquier parte puede enviar un mensaje mínimo para activar la recaudación y eliminación de cuentas insolventes (con un pequeño incentivo). Las implementaciones modernas exponen esto como el flujo freeze/recover arriba descrito.

“TON Services” son componentes a nivel de red adyacentes a la Blockchain TON: un sistema de nombres (TON DNS), una capa de contenidos (TON Storage), acceso tipo web (TON Sites) y una capa de enrutamiento/anonimización (TON Proxy). Funcionan sobre el stack P2P de TON (ADNL/RLDP) y, donde interactúan con la blockchain (por ejemplo, registros de nombres o pagos), las operaciones se liquidan en Gram.

TON DNS: TON DNS vincula nombres legibles por humanos (por ejemplo, ejemplo.ton) con recursos de TON: direcciones de contratos inteligentes y endpoints ADNL usados por servicios como TON Sites. Se especifica como un sistema on-chain, mayormente jerárquico; las aplicaciones pueden resolver nombres a las direcciones subyacentes de 256 bits y luego conectar. Las interacciones que modifican el estado DNS (registro, extensión o actualización de registros) son transacciones on-chain pagadas en Gram.

TON Sites: TON Sites son “servicios puros de red” alcanzables mediante el transporte de TON (ADNL/RLDP). Un usuario suele ejecutar o conectarse a un ton-proxy que acepta solicitudes HTTP locales, las reenvía vía la red de TON a la dirección abstracta del servicio y devuelve respuestas, brindando una experiencia web sin depender de Internet pública. Los nombres se resuelven con TON DNS. Publicar o actualizar la dirección/registros del servicio usa transacciones on-chain pagadas en Gram; la navegación es tráfico off-chain.

TON Storage: TON Storage proporciona almacenamiento de archivos descentralizado accesible a través de The TON Network (también se utiliza para datos de archivo de blockchain). El storage-daemon de referencia y sus contratos inteligentes permiten a los usuarios pagar a proveedores de almacenamiento y que estos retiren fondos al presentar pruebas Merkle asociadas a los datos almacenados. Pagos e interacciones de contrato se hacen en Gram; los datos reales fluyen sobre los protocolos P2P de TON.

TON Proxy: TON Proxy es la capa proxy/anonymizer de la red. Oculta identidades/IPs de nodos y permite el acceso a TON Sites al puentear HTTP local al transporte de TON, mejorando la conectividad frente a filtrados o DDoS. Usar un proxy o cambiar ajustes es off-chain; cuando los servicios publican o descubren endpoints “entry” de proxy vía registros o DNS, esas operaciones usan mecanismos on-chain y, por tanto, Gram para las transacciones asociadas.

Roles resumidos:

• Las wallets almacenan las claves de usuario y piden aprobación cuando una dApp quiere enviar una transacción o firmar datos. En Telegram, Wallet in Telegram ofrece una TON Wallet autocustodiada (claves on-chain) y una Crypto Wallet custodiada separada; ambas pueden aparecer como destinos de conexión.
• TON Connect es el protocolo estándar que conecta dApps con wallets. Define cómo las apps descubren wallets, establecen una sesión cifrada y solicitan acciones como sendTransaction o signData.
• Los Telegram Mini Apps son aplicaciones web dentro de Telegram. Añaden UI y autorización de Telegram, y pueden incluir acciones blockchain integrando TON Connect. Los flujos de pago propios de Telegram (Bot Payments / Stars) son distintos de las transferencias on-chain de TON.

Flujo de conexión (cómo los usuarios aprueban acciones):

1. La dApp (sitio regular o Mini App) muestra “Conectar wallet”. Usando TON Connect SDK, enumera las wallets soportadas y detecta el contexto (embebida/inyectada/remota). Si la wallet está embebida (por ejemplo, en Telegram), el SDK usa un bridge JS; si no, abre un enlace universal/deep link o QR a la wallet escogida.
2. La wallet y la app crean una sesión sobre un bridge alojado por la wallet. Los mensajes están cifrados end-to-end, así que el bridge no lee el contenido.
3. Tras conectar, la app puede solicitar:
   • sendTransaction — la wallet muestra la transacción y, si el usuario aprueba, la firma y la envía a TON; la app recibe un resultado (por ejemplo, BOC/hash de tx).
   • signData — pide a la wallet que firme texto/bytes/celdas para comprobaciones off-chain o verificación on-chain; no se mueven fondos.

Uso en Telegram Mini Apps: Las Mini Apps cargan el WebApp SDK de Telegram para la UI y autorización dentro de Telegram, luego añaden TON Connect para acciones blockchain. El resultado es un flujo fluido: abrir Mini App → conectar wallet → aprobar un envío de GRAM o llamada de contrato → la app recibe confirmación, sin que las claves salgan de la wallet.

Pagos: on-chain vs sistema propio de Telegram:

• Pagos GRAM on-chain (por ejemplo, transferencias GRAM/Jetton, llamadas a contratos) funcionan vía TON Connect y se pagan on-chain; los detalles sobre comisiones están en la sección de comisiones de esta guía.
• Telegram Bot Payments / Stars son flujos nativos de Telegram para checkout (proveedores fiat, Stars para bienes digitales). No requieren transacción en blockchain y se configuran mediante las APIs de Telegram. Muchas Mini Apps combinan ambos modelos según el caso de uso.

Envíos P2P en chats (TON Wallet autocustodiada): Con TON Wallet (la opción autocustodiada dentro de “Wallet in Telegram”), puedes enviar Gram, jettons y NFTs a un contacto de Telegram directamente desde un chat. La app crea un contrato inteligente escrow que retiene los activos hasta que el destinatario los acepta o rechaza. Si acepta, los fondos pasan on-chain al destinatario; si rechaza o no reclama en 14 días, se devuelven automáticamente al remitente. Con wallets compatibles con W5, se soportan transferencias ‘gasless’: la comisión de red puede cubrirse con el saldo del token transferido (ej., USDT), mientras que la liquidación on-chain sigue ocurriendo en TON.

Envíos P2P en chats (Crypto Wallet custodial): La Crypto Wallet Mini App independiente permite envíos instantáneos off-chain entre usuarios de Crypto Wallet en Telegram, mostrados como envíos P2P sin comisiones en los chats. No aparecen en la blockchain; depósitos/retiros externos sí son on-chain y conllevan comisión de red. La disponibilidad depende de la región.

P2P Market (fiat on-/off-ramp con escrow): Dentro de Crypto Wallet, el P2P Market permite comprar o vender activos soportados con otros usuarios, usando métodos de pago aceptados por el vendedor. La cripto se bloquea en escrow hasta que el vendedor confirma el pago, luego se libera al comprador. Se aplica una comisión de maker en operaciones exitosas, mostrada por región en la app.

Reparto de ingresos por anuncios en canales (pagado en GRAM): La plataforma de anuncios de Telegram vende anuncios basados en TON; los anunciantes pagan en Gram. El 50% de los ingresos por anuncios que aparezcan en canales públicos (con requisito de elegibilidad) va a los propietarios de canales. Los retiros se procesan por Fragment, con recompensas en Gram por defecto; los T&C de Fragment indican métodos alternativos en ciertos países.

Notas prácticas:

• “Wallet in Telegram” muestra ambos modos: TON Wallet (autocustodiada, on-chain) y Crypto Wallet (mini-app custodial). El acceso y funciones varían según jurisdicción; revisa la ayuda in-app si una función no está disponible.
• Para comisiones en envíos on-chain (compute/action/forward/storage), consulta la sección de comisiones de esta guía; las transferencias off-chain entre usuarios de Crypto Wallet se gestionan internamente y sólo se muestran en el historial de la app.

Sí. Tether lanzó USD₮ nativo en The Open Network como un jetton de TON y publica su contrato oficial en su página Supported Protocols: EQCxE6mUtQJKFnGfaROTKOt1lZbDiiX1kCixRv7Nw2Id_sDs. Tether también anunció el lanzamiento de USD₮ (y XAU₮) en TON en abril de 2024.

USD₮ se implementa usando el estándar de tokens fungibles de TON (Jettons). Tienes un contrato jetton wallet exclusivo por usuario vinculado al jetton master; las transferencias son mensajes on-chain normales. Las comisiones de red por transferencia se pagan en GRAM; la cantidad de stablecoin transferida es independiente al Gram usado para comisiones. Si dudas sobre si un token “USDT” es genuino, compara siempre la dirección master del jetton con la de Tether. El marco jetton de TON permite que cualquiera despliegue imitaciones, por lo que la verificación del contrato es clave.

Uso de USDT en Telegram y wallets TON: En Wallet in Telegram, la TON Wallet autocustodiada gestiona transferencias on-chain de USD₮ (TON), mientras que la Crypto Wallet permite envíos instantáneos off-chain entre usuarios y acceso a un P2P Market integrado. El mercado P2P aplica una comisión de 0,9% sobre trades exitosos para makers. La disponibilidad depende de la región y los proveedores integrados.

Soporte en exchanges (rampas on/off): Los grandes exchanges admiten depósitos y retiros de USDT (TON), permitiendo transferir USD₮ directamente a/la red TON sin puentes. Ejemplos son Binance, OKX, Bybit y KuCoin, todos con anuncios sobre apertura de USDT en TON. Revisa la red de depósito en el exchange antes de enviar fondos.

Puentes de stablecoins hacia/desde TON: El movimiento cross-chain de activos lo gestionan bridges de terceros. TON cuenta con integraciones como LayerZero/Stargate que habilitan transferencias de activos soportados entre TON y otras chains. Bridging no es parte del protocolo base de TON, y conlleva riesgos adicionales de confianza y smart contracts; usa siempre endpoints oficiales y verifica el contrato del activo destino.

Comprobaciones de seguridad prácticas:

• Confirma que el jetton master para USD₮ coincida con la dirección oficial de TON de Tether antes de interactuar.
• Ten precaución con “wrapped” o tickers heredados que preceden a USD₮ nativo en TON; verifica qué recibes y si es un token bridge. (Exploradores como Tonviewer resuelven el jetton oficial USD₮ en la dirección anterior.)

Los valores cambian continuamente. Para números actualizados live de suministro total y circulante, usa las métricas en esta página o un explorador fiable de TON.

Emisión (cómo entra nuevo GRAM al suministro): Nuevo GRAM se crea por el protocolo como recompensas proof-of-stake. En cada ronda de validación, los validadores elegidos bloquean stake con el contrato Elector on-chain; tras la ronda, el Elector paga recompensas, lo que incrementa el total supply. Los pools nominadores son smart contracts ordinarios que agrupan TON de usuarios e interactúan con Elector en su nombre; luego, los pools reparten recompensas según sus reglas.

Inflación (qué determina el ritmo): La inflación efectiva no sigue un calendario fijo; resulta de nuevas emisiones menos cualquier quema en un periodo. Los parámetros de recompensas y las cadencias de elecciones se establecen on-chain y pueden cambiarse vía configuración/gobernanza. Para conocer la inflación actual, compara el minting registrado de pagos Elector con las monedas destruidas (ver “Burning” abajo).

Burning (cómo puede bajar el suministro): Hay dos formas de destruir GRAM:

1. Quema de comisiones por protocolo o configuración: la red puede configurarse para que parte de las comisiones se queme en vez de pagarse a los validadores. En 2023 se publicó una propuesta comunitaria para quemar el 50% de comisiones; si se quema y el volumen se determina por la configuración de red, así que consulta el ajuste live.
2. Quema explícita a una dirección sink: las monedas enviadas a la dirección de quema canónica (a menudo llamada burn-address.ton) son irrecuperables y eliminadas del suministro. Los exploradores exponen esta dirección y su actividad.

Roles y el contrato Elector: TON usa proof-of-stake. Los validadores bloquean Gram y entran en elecciones gestionadas por el contrato Elector on-chain; los elegidos producen bloques. Tras la ronda, Elector paga recompensas en cadena. Exploradores y SDKs exponen get-methods de Elector (ej., elecciones activas, minStake, rondas pasadas, unfreezeAt).

Validadores (staking directo): Un validador apuesta desde su contrato de control al Elector, ejecuta el software validador y recibe recompensas si mantiene buena salud. El stake queda congelado durante la ronda y sólo puede retirarse tras el tiempo unfreeze del Elector para esa ronda. El stake mínimo y otros parámetros se leen del estado de Elector; no son valores fijos. (Las penalizaciones se cubren en la siguiente sección.)

Pools nominadores (delegación a validador): La mayoría delega vía pools nominadores oficiales en los repos de TON. Depositas Gram en el pool; este apuesta al Elector en nombre de los depositantes y luego reparte recompensas conforme a las reglas del pool. El retiro se solicita con un simple mensaje (ej., comentario “w”) al contrato del pool; los fondos se liberan tras finalizar la ronda de validación y cuando el pool tenga liquidez. Los pools estándar no ofrecen redención inmediata; tu retiro suele esperar al fin de un ciclo. Las implementaciones y límites de pools (máx. nominadores, por ejemplo) se gestionan en el contrato.

Pools de nominador único (un delegador, un validador): Un diseño alternativo “único nominador” simplifica el pool a un solo delegador para un validador, reduciendo el área de ataque contractual y manteniendo las mismas interacciones con Elector. Este patrón es open-source y lo usan algunos operadores.

Staking líquido (tokens recibo): TON ofrece también una implementación oficial de staking líquido. Los depositantes reciben un jetton (token recibo) que representa su parte del pool y acumula recompensas; el pool apuesta a validadores vía Elector. Las redenciones on-chain siguen los tiempos de salida de validadores, pero los tokens recibo pueden transferirse o venderse para obtener liquidez antes que el pool complete un ciclo de unbonding. El diseño y los contratos se mantienen en el core GitHub de TON.

Lockups y unbonding – qué esperar:

• Validadores: el stake se bloquea la ronda activa y puede retirarse tras el unfreezeAt del Elector de esa ronda. Las recompensas son reclamables desde el Elector en el settlement o después.
• Nominadores en pools estándar: las salidas se ponen en cola y procesan tras acabar una ronda; no hay salida instantánea garantizada. Consulta la política de cada pool (batching, mínimos).
• Usuarios de staking líquido: los tokens recibo proveen liquidez por transferencia; quemarlos por GRAM sigue las reglas del pool, según ciclos de validadores.

TON aplica slashing para penalizar mala conducta de validadores detectada en una ronda de validación. Se aplican dos categorías:

• Idle/bajo rendimiento: un validador procesa muy pocos bloques durante una ronda. Otros validadores generan quejas y votan (usualmente automatizado por mytonctrl), y se aplica una penalización al stake del validador de esa ronda.
• Trampa/equivocación: ej., producir mensajes conflictivos (forks) detectados por el consenso Catchain; tales validadores se aíslan y multan (históricamente misma sanción que idle, con propuestas para aumentarla).

El proceso: tras cada ronda, los validadores auditan el desempeño de sus pares; quejas válidas se votan y la sanción definida en la red se deduce del stake congelado del infractor. Quienes no usan mytonctrl pueden ejecutar el script oficial Punisher para participar en el voto de quejas. Los parámetros de slashing se guardan explícitamente en la config de red (añadidos vía actualización de red).

Impacto en delegadores/pools: Los pools nominadores apuestan ante Elector por los depositantes y luego recuperan fondos tras la ronda. Si un validador recibe penalización, la devolución del Elector baja esa ronda, así que los delegadores comparten la pérdida según reglas del pool. (Los pools “suelen” recuperar más de lo que enviaron; el slashing es la excepción). Revisa el contrato/política antes de delegar.

Requerimientos de capital de validador:

• Stake mínimo para participar en elecciones: la página oficial de validadores indica un mínimo de 300.000 GRAM para ser validador. En la práctica, el umbral real depende de la competencia y parámetros on-chain de cada elección.
• Mecánica de ciclos: los candidatos bloquean stake ante Elector por una ronda; tras el settlement, stake y recompensas se devuelven on-chain.

Hardware y operaciones (en líneas generales):

• La guía oficial recomienda hardware de alto rendimiento y conexión de red de alta disponibilidad (disponibilidad 24/7 y baja latencia son esenciales para evitar penalizaciones idle).
• Los manuales comunitarios suelen recomendar CPUs multinúcleo modernas, RAM abundante y SSD/NVMe rápidos; un guía común sugiere 8 vCPU, 64GB RAM, ~1TB SSD y 1 Gb/s como base práctica. Trátalo como recomendación de la comunidad, no como regla del protocolo.
• La mayoría de operadores usan mytonctrl para gestionar nodos validador, mantener software al día y automatizar quejas/telemetría.

Conclusiones clave:

• TON sí aplica slashing a validadores inactivos o tramposos (equivocación/fork) detectados por Catchain; las multas se fijan en la configuración de la red y se deducen del stake usado esa ronda.
• Para minimizar riesgos, mantén alto uptime, supervisa desempeño, actualiza nodos y elige pools/validadores con reputación probada si delegas.

Jettons (tokens fungibles) — estándar y modelo: Los jettons siguen TEP-74. Un Jetton consta de un contrato Jetton Minter (master), que define la política (mint, burn, metadata), y contratos Jetton Wallet por titular para los balances reales. Las interfaces (ej., get_jetton_data, opcodes de transfer) están estandarizadas, permitiendo interoperabilidad con wallets, exchanges e indexadores.

Emitir un Jetton (flujo típico):

1. Parte de una implementación de referencia (FunC o Tact) y configura metadata (nombre, símbolo/decimales vía TEP-64), política de supply y privilegios de admin.
2. Despliega el Jetton Minter, pasando el código elegido de Jetton Wallet como celda de librería.
3. Haz “mint” enviando mensajes del minter para crear/acreditar contratos Jetton Wallet de destinatarios; los burns son mensajes para reducir supply.

Los repositorios oficiales ofrecen un minter y wallet de nivel producción, más una “Jetton Deployer” via browser.

Metadata de jettons: Los datos de presentación (nombre, descripción, imagen, decimales) usan el TEP-64 Token Data Standard. Los creadores pueden almacenar metadata on-chain (celda) u off-chain (URL a JSON). Usar los campos estándar asegura despliegue uniforme en wallets y exploradores.

NFTs — estándares y contratos: Los NFTs emplean TEP-62. Cada NFT Item es su propio contrato; normalmente se agrupan en un contrato NFT Collection, que expone datos comunes y descubrimiento. TEP-62 define métodos de transferencia y descubrimiento; TEP-64 aporta el esquema de metadata tanto para items como colecciones.

Emitir una colección e items NFT (flujo típico):

1. Despliega la Collection con su metadata TEP-64 (nombre, imagen de portada, contenido base).
2. Haz “mint” de Items desplegando contratos que referencian la colección; la metadata TEP-64 a nivel de item (nombre, imagen, atributos) se puede definir por emisión.
3. Las transferencias son mensajes estándar TEP-62 entre contratos de items de diferentes dueños, permitiendo a wallets y mercados detectar y procesar movimientos confiables.

Herramientas (oficiales y habituales):

• Blueprint — el entorno todo-en-uno oficial para construir, probar y desplegar contratos TON (soporta FunC, Tact y Tolk). Es la ruta más directa para Jettons/NFTs, e incluye test y scripting.
• Tact — lenguaje de más alto nivel con plantillas, incluyendo implementación Jetton compatible TEP; la documentación y el GitHub aportan patrones y ejemplos.
• FunC — lenguaje bajo nivel y stdlib para contratos TVM; muchas referencias de Jetton/NFT están escritas en FunC.
• SDKs — TypeScript @ton/ton (ton-core) aporta helpers para Jettons/NFTs (ej., JettonMaster), y TonWeb es una librería JS madura usada en muchas guías e integraciones. TonAPI añade acceso REST/SDK a saldos, metadata y transferencias.

Buenas prácticas:

• Sigue interfaces TEP. Si extiendes lógica (comisiones, pausas, roles de minter), mantén getters y formatos TEP para que wallets y mercados sigan reconociendo tu token.
• Usa TEP-64 de manera consistente. Decide desde el principio si metadata es on-chain u off-chain y respeta el esquema para evitar visualizaciones rotas.
• Verifica contratos y direcciones. Publica direcciones de minter/colección y hashes de código; para tokens fungibles, haz pública la dirección Jetton master para que usuarios e integraciones validen el activo.

Fragment es el marketplace oficial de Telegram para usernames coleccionables y activos relacionados. Las ventas funcionan como subastas públicas o tratos a precio fijo y se liquidan en Gram (GRAM). Tras la compra, el coleccionable aparece en la cuenta Fragment del comprador y puede asignarse a un perfil, canal o grupo de Telegram. El material de ayuda de Fragment describe conexión de wallet, pujas y asignación post-venta, y confirma que puja y liquidación usan Gram.

Cómo funcionan las subastas @username en Fragment:

• Pujas y liquidación: Los usuarios se loguean por Telegram, conectan una wallet TON y pujan on-chain en Gram; si son superados, los fondos se devuelven automáticamente. Si ganas, el coleccionable se transfiere a tu wallet.
• Listados y cancelación: Puedes listar un nombre elegible y cancelar la subasta antes de que haya pujas. Una vez que existe una puja, la subasta sigue hasta el final bajo las reglas marcadas.
• Comisiones: Fragment indica una comisión de plataforma (mostrada en cada lote) para ventas completadas y una comisión única de conversión. Toma los importes como valores de plataforma que pueden cambiar; revisa siempre la línea de comisión antes de listar.
• Tras la subasta: El collectible username puede asignarse a una entidad de Telegram desde Fragment; la asignación puede cambiarse posteriormente por el propietario.

Dónde interviene TON: Todos los pagos en Fragment se hacen en Gram. Por otro lado, la ad platform de Telegram también usa Gram para comprar anuncios y pagar a owners elegibles, con retiros en Fragment, pero los flujos publicitarios son independientes a las subastas de usernames.

Subastas de dominio TON (.ton):

• Estándar y propósito: TON DNS asigna nombres legibles (.ton) a recursos TON (direcciones de contrato, endpoints ADNL). El estándar es TEP-81.
• Cómo se encuentran: Las subastas de dominios se ejecutan con contratos on-chain y son visibles en exploradores (ej., la página “Auctions” de Tonviewer para cada nombre). Los marketplaces pueden mostrar también DNS como items comerciables que referencian esos contratos. Revisa siempre la dirección de contrato del dominio antes de pujar.
• Pago y cierre: Las pujas se hacen en Gram y se liquidan on-chain; finalizada la subasta, la titularidad del contrato de dominio pasa al ganador, quien puede establecer registros según TEP-81. Las herramientas/APIs muestran la titularidad y expiración de cada DNS.

Checklist rápido de seguridad:

• Comprueba la URL oficial del lote en Fragment y revisa líneas de comisión antes de listar o pujar.
• Para dominios .ton, confirma la dirección de contrato y lee los registros compatibles con TEP-81; usa un explorador/API fiable para titularidad y caducidad.

La tecnología que sustenta TON fue desarrollada originalmente por Telegram (Pavel y Nikolai Durov), con planes para lanzar el token Gram. En mayo de 2020, Telegram anunció públicamente que cesaba su implicación en el proyecto tras acción de la SEC de EE. UU.; un acuerdo judicial obligó a Telegram y su subsidiaria TON Issuer a devolver fondos a inversores y pagar una sanción civil. El código quedó open source.

De “Telegram Open Network” a una TON gestionada por la comunidad con Gram: Tras apartarse Telegram, desarrolladores independientes continuaron la red como The Open Network (TON). La gobernanza la ostenta la comunidad y la Fundación TON, organización suiza sin ánimo de lucro que apoya el ecosistema; el activo nativo es Gram (GRAM). Telegram no controla la blockchain.

¿Cómo se relaciona Telegram con TON ahora? Telegram integra TON como una funcionalidad de plataforma, pero sigue siendo una empresa separada:

• Wallet in Telegram ofrece una TON Wallet autocustodiada (claves sólo on-chain, no en Telegram) y una Crypto Wallet custodial separada.
• La plataforma de anuncios de Telegram vende anuncios basados en TON y reparte el 50% de ingresos a owners de canales elegibles; los retiros se gestionan vía Fragment.
• Fragment gestiona subastas y ventas de usernames coleccionables, liquidando en Gram.

Resumen:

• Creado por: el equipo de Telegram (hermanos Durov) originó la tecnología y el concepto “Telegram Open Network”.
• Red y moneda actual: continuado por la comunidad independiente; gobernada y apoyada por la Fundación TON; activo nativo Gram.
• Rol de Telegram: integrador y canal de distribución, no operador de red ni emisor. Los productos de Telegram se conectan con TON pero no lo controlan.