Create Tokens Fun: Guía técnica para la creación de tokens en un launchpad

Qué hace realmente crear un token en un launchpad estilo fun

Cuando un usuario hace clic en un botón de crear en un launchpad como un sitio estilo pump.fun, el navegador construye una transacción que la billetera del usuario firma. Esa transacción típicamente realiza tres pasos lógicos: crea un nuevo mint de token con un suministro y decimales fijos, adjunta metadatos (nombre, símbolo, URI de imagen) ya sea directamente o a través de un programa de metadatos, y registra el token con el programa propio del launchpad para que el token sea negociable en una bonding curve o en un pool de liquidez inicial.

La distinción importante es que el launchpad es un coordinador, no un custodio de la identidad del token. La autoridad de mint, la autoridad de congelación y la autoridad de actualización de metadatos se establecen mediante las instrucciones de la transacción. Algunos launchpads revocan la autoridad de mint inmediatamente para que el suministro sea fijo; otros la dejan con el programa. Leer la transacción antes de firmar es la única forma confiable de saber qué modelo se aplica al launchpad específico que estás usando.

Esta página trata 'create tokens fun' como un problema de flujo de trabajo técnico: qué contiene la transacción, cómo verificarla y cómo reproducirla o monitorearla. No recomienda un launchpad específico, y no afirma el esquema de tarifas ni el conjunto de características de ninguna plataforma en particular, porque estos cambian con frecuencia y deben leerse desde la propia plataforma.

• Creación del mint: el suministro, los decimales y las asignaciones de autoridad se fijan en el momento de la creación.
• Metadatos: el nombre, el símbolo y la URI de imagen suelen ser inmutables después de la creación en los flujos de launchpad.
• Registro: el programa del launchpad registra el token para que pueda negociarse en una curva o pool.
• Modelo de autoridad: si se revoca la autoridad de mint o de congelación determina cómo puede cambiar el suministro después.

Requisitos previos y supuestos antes de lanzar

Necesitas una billetera con fondos en la cadena objetivo, un endpoint RPC confiable y una forma de inspeccionar las transacciones antes de firmar. Para los launchpads basados en Solana, normalmente usarás un adaptador de billetera en el navegador y un endpoint JSON-RPC para la verificación. Para los launchpads basados en EVM, el equivalente es una billetera más un endpoint RPC que admita eth_getTransactionReceipt y eth_call.

Supuestos en esta guía: controlas la billetera que firma la transacción de creación, tienes acceso a un endpoint RPC que puedes consultar directamente y te sientes cómodo leyendo datos de transacciones sin procesar. Si solo deseas un endpoint gestionado en lugar de ejecutar tu propio nodo, el servicio OnFinality API y las opciones de nodo dedicado son los puntos de partida relevantes; la elección concreta del endpoint es una decisión separada cubierta por RPC Assistant.

• Una billetera con suficiente token nativo de gas para la transacción de creación y cualquier compra inicial.
• Una RPC_URL que controles o en la que confíes, no un endpoint público compartido, para las consultas de verificación.
• Un explorador de bloques o un decodificador local para inspeccionar la transacción firmada.
• Un registro escrito del suministro, los decimales y la política de autoridad previstos antes de firmar.

Modelo mental: la transacción de lanzamiento como transición de estado

Piensa en el lanzamiento como una única transición de estado atómica. Antes de la transacción, la cuenta mint no existe. Después de que se confirma, el mint existe con un suministro y un conjunto de autoridades específicos, los metadatos están adjuntos y el programa del launchpad ha registrado el token. Si alguna instrucción de la transacción falla, toda la transición se revierte, por lo que un lanzamiento que 'parece hecho' en una interfaz pero no tiene una firma confirmada no está realmente hecho.

El modelo de bonding curve añade una segunda máquina de estados sobre el mint. La curva mantiene una reserva del activo de cotización y una reserva del nuevo token, y el precio es una función de esas reservas. La creación inicializa la curva; las compras y ventas posteriores mueven las reservas. Cuando la curva alcanza un umbral de graduación, la liquidez se migra a un pool externo. Cada uno de estos pasos es una transacción separada, por lo que 'creado' y 'graduado' son estados distintos que debes verificar por separado.

• Creado: el mint existe, los metadatos están adjuntos, el registro del launchpad está confirmado.
• Negociable: bonding curve inicializada con reservas.
• Graduado: liquidez migrada a un pool externo, si el launchpad usa ese modelo.
• Revocado: autoridad de mint o de congelación eliminada, si la política del launchpad lo hace.

Verificar una transacción de lanzamiento con curl

La verificación independiente más rápida es obtener la transacción por firma e inspeccionar sus instrucciones y claves de cuenta. Reemplaza SIGNATURE con la firma devuelta por tu billetera y RPC_URL con tu endpoint. La respuesta muestra si la transacción tuvo éxito y qué programas se invocaron.

• Verifica que meta.err sea null antes de confiar en el resultado.
• Inspecciona transaction.message.accountKeys para encontrar la dirección del nuevo mint.
• Busca el programa de tokens y el programa de metadatos en las instrucciones invocadas.
• Confirma que el ID del programa del launchpad coincida con la plataforma que usaste.

curl -s RPC_URL -X POST -H 'Content-Type: application/json' -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getTransaction",
  "params": [
    "SIGNATURE",
    {"encoding": "jsonParsed", "maxSupportedTransactionVersion": 0}
  ]
}'

Leer el estado del mint después de la creación

Una vez que tengas la dirección del mint, consulta su estado parseado para confirmar el suministro, los decimales y las autoridades. Este es el paso que detecta la sorpresa más común: un launchpad que deja activa la autoridad de mint, o uno que establece una autoridad de congelación que no esperabas. El siguiente fragmento de Python usa solo la biblioteca estándar y tu RPC_URL.

• Un mintAuthority nulo significa que el suministro es fijo y no puede inflarse.
• Un freezeAuthority no nulo significa que las cuentas pueden ser congeladas por esa clave.
• Los decimales deben coincidir con tu intención; los tokens estilo meme suelen usar 6 o 9.
• Compara el suministro devuelto con el valor que esperabas de la interfaz.

import json, urllib.request

RPC_URL = "RPC_URL"
MINT = "MINT_ADDRESS"

payload = {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getAccountInfo",
    "params": [MINT, {"encoding": "jsonParsed"}]
}
req = urllib.request.Request(
    RPC_URL,
    data=json.dumps(payload).encode(),
    headers={"Content-Type": "application/json"},
)
with urllib.request.urlopen(req) as resp:
    data = json.load(resp)

info = data["result"]["value"]["data"]["parsed"]["info"]
print("supply:", info["supply"])
print("decimals:", info["decimals"])
print("mintAuthority:", info.get("mintAuthority"))
print("freezeAuthority:", info.get("freezeAuthority"))

Procedimiento de medición reproducible para la confiabilidad del lanzamiento

La confiabilidad del lanzamiento es principalmente una función de la capacidad de tu endpoint RPC para aterrizar y confirmar transacciones bajo carga. En lugar de confiar en afirmaciones anecdóticas, ejecuta una pequeña prueba controlada contra tu propio endpoint y registra los resultados. El procedimiento a continuación está diseñado para repetirse de modo que puedas comparar endpoints o momentos del día.

Procedimiento: (1) prepara un conjunto fijo de N transacciones de prueba, por ejemplo pequeñas transferencias o una creación de mint en devnet; (2) envíalas secuencialmente y registra el tiempo desde el envío hasta el estado confirmado; (3) repite la ejecución al menos tres veces y registra la mediana y el número de fallos; (4) anota el endpoint, la región y la hora de cada ejecución. No publiques números de una sola ejecución y no compares ejecuciones hechas en momentos diferentes sin señalar la diferencia.

• Registra: endpoint, región, marca de tiempo, N, tiempo medio de confirmación, número de fallos.
• Usa la misma forma de transacción en todas las ejecuciones para que la comparación sea justa.
• Trata cualquier ejecución con fallos como un dato, no como un benchmark a descartar.
• Vuelve a ejecutar después de cualquier cambio de endpoint o de red antes de sacar conclusiones.

Plantilla de tabla de resultados para tus propias ejecuciones

Usa una tabla como la siguiente para registrar tus propias mediciones. Las celdas están intencionalmente en blanco porque los valores dependen de tu endpoint, región y condiciones de red; completarlas con observaciones reales es el objetivo. Una tabla completa es mucho más útil que una afirmación genérica sobre velocidad.

• | Ejecución | Endpoint | Región | N | Mediana confirmación (ms) | Fallos | Notas |
• | 1 | RPC_URL | REGION | 20 | | | |
• | 2 | RPC_URL | REGION | 20 | | | |
• | 3 | RPC_URL | REGION | 20 | | | |

Solución de problemas de lanzamientos que fallan o parecen incorrectos

La mayoría de los problemas de lanzamiento caen en unas pocas categorías: la transacción nunca se confirmó, se confirmó pero el estado del mint no es el esperado, o el token se creó pero no es negociable. Cada una tiene una ruta de diagnóstico distinta, y el orden importa porque un síntoma posterior puede ser causado por un fallo anterior.

Si la transacción no se confirmó, verifica primero el estado de la firma y luego la expiración del blockhash. Si se confirmó pero el estado del mint es incorrecto, vuelve a leer la cuenta parseada y compárala con las instrucciones de la transacción. Si el token no es negociable, verifica si se incluyó la instrucción de registro del launchpad y si se inicializó la bonding curve.

• Firma no encontrada: la transacción puede haber sido descartada; reenvíala con un blockhash nuevo.
• Confirmada pero revertida: inspecciona meta.err y el índice de la instrucción fallida.
• El mint existe pero faltan metadatos: la instrucción de metadatos puede haberse omitido o fallado silenciosamente.
• Creado pero no negociable: falta el paso de registro del launchpad o de inicialización de la curva.
• Autoridad inesperada: la política del launchpad difiere de lo que asumiste; lee la transacción antes de firmar la próxima vez.

Limitaciones, compensaciones y lo que ocultan los launchpads

Los launchpads optimizan la velocidad de creación, lo que significa que ocultan decisiones que importan para el comportamiento del token a largo plazo. Los metadatos suelen ser inmutables, las políticas de autoridad las fija el programa y los parámetros de la bonding curve no son configurables por el usuario. Es una compensación razonable para el lanzamiento de una memecoin y pobre para un token que necesita metadatos actualizables o suministro controlado.

También hay una compensación de infraestructura. El front-end de un launchpad puede usar su propio endpoint RPC, que tú no controlas. Si quieres verificar o monitorear lanzamientos de forma independiente, necesitas tu propio endpoint y tu propia lógica de sondeo o suscripción. Ejecutar eso tú mismo es más trabajo pero te da una visión consistente del estado que no depende de la interfaz del launchpad.

• Los metadatos inmutables son convenientes pero limitan las correcciones posteriores al lanzamiento.
• La política de autoridad fijada por el programa puede no coincidir con tu tokenomics prevista.
• Los parámetros de la bonding curve generalmente no son ajustables por el creador.
• La verificación independiente requiere tu propio acceso RPC y monitoreo.

Próximos pasos: monitoreo e infraestructura

Una vez creado un token, el siguiente paso útil es el monitoreo: observar la cuenta mint, las reservas de la bonding curve y el estado de graduación. Para Solana, una suscripción websocket a los cambios de cuenta es más eficiente que el sondeo, pero el sondeo con un intervalo acotado es más simple de operar y más fácil de razonar. Elige según la rapidez con la que necesites reaccionar.

Para el lado de la infraestructura, revisa las guías de red y las opciones de endpoint antes de comprometerte con un proveedor. La guía de Solana devnet es un buen lugar para ensayar el flujo completo de lanzamiento y verificación sin gastar fondos reales, y la página de precios de RPC te ayuda a estimar el costo para el volumen de consultas que generará tu monitoreo. Si necesitas un rendimiento consistente para un monitor de alta frecuencia, un nodo dedicado es la opción relevante.

• Ensaya el flujo completo en devnet antes de lanzar en mainnet.
• Decide entre suscripciones websocket y sondeo acotado para el monitoreo.
• Estima el volumen de consultas a partir de tu intervalo de sondeo antes de elegir un plan.
• Guarda un registro de cada firma de transacción de lanzamiento para verificación posterior.