Creación de tokens ERC-20, BEP-20, SPL o Jetton

¿Qué formato de token se adapta a su proyecto?

El formato se elige según la red en la que operará el producto y la compatibilidad con sus billeteras, aplicaciones e infraestructura. ERC-20 se usa para un token en Ethereum, BEP-20 en BNB Smart Chain, SPL en Solana y Jetton en TON. Si el producto ya está vinculado a una red, normalmente es razonable comenzar con su estándar, en lugar de añadir otros formatos sin una necesidad concreta.

Al inicio, es útil definir el propósito del token: acceso a funciones, pagos dentro del producto, participación en la mecánica del protocolo u otro escenario. Luego se fijan las propiedades de emisión y gestión. Por ejemplo, es importante decidir de antemano si la emisión será limitada, si se necesitan derechos administrativos adicionales y qué acciones son posibles después del despliegue. Estas decisiones afectan la arquitectura y cómo el proyecto podrá explicar el funcionamiento del token a los usuarios.

Aclaramos la red elegida, los casos de uso y las integraciones necesarias antes de estimar el trabajo. Si los requisitos incluyen lógica personalizada más allá del token básico, es mejor separarla en una especificación propia y evaluarla como desarrollo de smart contract. Una visión general de las áreas está disponible en la sección de desarrollo Web3.

¿Qué acordar antes del despliegue de ERC-20, SPL o Jetton?

Antes del despliegue, es necesario aprobar los parámetros del token y la forma de gestionarlo: corregirlos después de la publicación puede ser imposible o requerir una migración separada. Recopilamos los requisitos iniciales en una especificación breve para que el propietario del proyecto confirme las decisiones clave antes de preparar el contrato o programa.

La especificación suele incluir:

• nombre y ticker, así como el número de decimales, si aplica al formato;
• volumen y modelo de emisión: emisión fija o creación adicional prevista por las reglas;
• direcciones del propietario y derechos administrativos, incluida su transferencia o renuncia, si está previsto en la tarea;
• funciones y restricciones requeridas, como la posibilidad de pausar operaciones, si son necesarias y permitidas;
• red, dirección de despliegue objetivo, materiales para la verificación e información para los metadatos.

Para SPL y Jetton, la composición de parámetros y la estructura de implementación difieren de los estándares compatibles con EVM, por lo que no transferimos una implementación entre redes mecánicamente. Para interactuar con la interfaz del producto, el token puede requerir una integración separada; se puede acordar junto con el desarrollo de dApp. Antes de confirmar la especificación, el cliente verifica direcciones, formulaciones y derechos de gestión, reduciendo así el riesgo de descubrir una decisión incorrecta después del despliegue.

¿Qué materiales incluye la creación de tokens?

El alcance del trabajo se fija antes de comenzar: usted sabe de antemano qué archivos, acciones y configuraciones recibirá. La composición básica incluye el desarrollo de parámetros, la implementación según el estándar elegido, el despliegue en la red acordada y la entrega del resultado del proyecto.

Según la tarea, el alcance puede incluir:

• código fuente y configuración de la implementación del token;
• despliegue en la red acordada y dirección del token creado;
• verificación del código en el explorador, si la red y el explorador elegidos admiten este proceso para el contrato;
• preparación o actualización de metadatos: nombre, símbolo, descripción y material gráfico en el formato acordado;
• instrucciones para la transferencia de derechos administrativos y la verificación de los parámetros principales.

Antes de la publicación, verificamos que la implementación cumpla con la especificación aprobada y contrastamos las direcciones proporcionadas por el cliente. Los metadatos y el diseño no sustituyen el registro del proyecto en recursos externos: estos pueden tener sus propios requisitos de solicitud y verificación. Si el token forma parte de un producto, discutiremos de antemano los puntos de integración y accesos necesarios. Para la interfaz de usuario, puede ser necesario un sitio web o landing page de un proyecto Web3, y para un producto de Telegram, un bot o Mini App. Estos trabajos se incluyen solo después de un acuerdo separado.

¿Cómo se desarrolla el trabajo con el token y cuándo planificar el lanzamiento?

El trabajo va desde la especificación acordada hasta un despliegue verificable. El calendario depende de la red, el alcance de las funciones, la disponibilidad de los datos y si la tarea incluye solo la implementación del token o también la integración con el producto. Acordamos la secuencia y los hitos antes de comenzar el desarrollo.

El orden típico es el siguiente:

1. Usted describe el propósito del token, la red y las funciones esperadas.
2. Aclaramos los parámetros, accesos y composición del resultado, luego confirmamos la especificación.
3. Preparamos la implementación y la proporcionamos para su revisión dentro del proceso acordado.
4. Tras la confirmación, realizamos el despliegue en la red elegida y verificamos la dirección y las propiedades principales.
5. Configuramos los metadatos previstos, realizamos la verificación si es posible y entregamos los materiales.

Para no retrasar el lanzamiento, prepare de antemano la redacción del nombre y ticker, la descripción del proyecto, el archivo gráfico, la red y las direcciones necesarias para el despliegue. Determine también quién confirmará las decisiones y gestionará la billetera de despliegue. Si se van a conectar la interfaz u otros componentes, indíquelos antes de la estimación final: las tareas relacionadas de desarrollo Web3 se planifican juntas, pero su alcance y plazos se fijan por separado.

¿Qué limitaciones es importante considerar al emitir un token?

Antes de la emisión, hay que considerar no solo el código, sino también la irreversibilidad de algunas acciones en la red, los derechos de gestión y las reglas de los exploradores externos. En la especificación separamos explícitamente lo que forma parte de nuestro trabajo y lo que depende de la decisión del propietario del proyecto o de una plataforma externa.

La dirección de despliegue y los parámetros registrados en la red no pueden considerarse un borrador: un error en la red, la dirección o la configuración puede requerir un nuevo despliegue y un plan de migración separado. Por eso, el cliente confirma la especificación final y los datos de la billetera antes de enviar la transacción. Si el token conserva derechos administrativos, su propietario debe garantizar el almacenamiento seguro de las claves y comprender las consecuencias de cada acción. La transferencia o renuncia de derechos se realiza solo según el escenario acordado.

Somos responsables del alcance acordado de la implementación y de las acciones realizadas, pero no podemos garantizar que un explorador externo acepte la verificación, que la billetera muestre el token sin acciones adicionales o que un catálogo apruebe los metadatos. La decisión de estos servicios depende de sus propios procedimientos, requisitos y condiciones técnicas. Para verificar la calidad del trabajo, compare la dirección del token con la red, coteje los parámetros con la especificación aprobada y compruebe la disponibilidad de los materiales fuente acordados. No entregue al ejecutor la frase semilla ni la clave privada de la billetera.

¿Cómo vincular la emisión de Jetton y el marketing para proyectos en TON?

Para el marketing de proyectos en TON, primero se necesita información acordada sobre el Jetton y el producto que se pueda publicar de forma segura y coherente. El despliegue del token por sí solo no crea posicionamiento, escenario de usuario ni plan de comunicación: son tareas separadas, pero conviene prepararlas en paralelo con la emisión.

Antes de preparar materiales públicos, defina el papel del token en el proyecto, qué funciones ya funcionan y qué afirmaciones están respaldadas por el producto. Verifique el nombre, símbolo, dirección del Jetton y enlaces a los canales oficiales en todos los puntos de contacto. Si el lanzamiento está vinculado a una aplicación, prepare un camino corto desde la descripción del token hasta la acción del usuario: a dónde ir, qué se puede hacer allí y qué limitaciones se deben entender de antemano.

Para la planificación, es útil dividir el trabajo en tres flujos: preparación técnica del Jetton, contenido de las páginas públicas y comunicación con la comunidad. Asigne un responsable para cada flujo y el orden de actualización de los materiales, para que los cambios de parámetros no dejen información desactualizada en los canales. La parte técnica puede incluir la integración con un bot de Telegram o Mini App, y la interfaz del producto, un desarrollo de dApp separado. El alcance de estos trabajos se acuerda por separado de la emisión del token.

Precios

Precios iniciales en USD. Paquetes a medida y descuentos por volumen bajo solicitud. Pago en USDT, USDC, BTC, ETH, SOL, TON o con el token de tu proyecto.

Cómo trabajamos

1. Recopilamos los requisitosUsted indica la red, el propósito del token, las funciones necesarias y los materiales disponibles. Aclaramos las integraciones y los responsables de la aprobación.
2. Fijamos la especificaciónAcordamos los parámetros de emisión, los derechos de gestión y la composición del resultado. No comenzamos el despliegue hasta confirmar los datos clave.
3. Preparamos la implementaciónCreamos el contrato o programa según el estándar elegido y verificamos que cumpla con los requisitos acordados.
4. Desplegamos el tokenRealizamos el despliegue en la red elegida, contrastamos la dirección y los parámetros, y luego llevamos a cabo las acciones acordadas con los metadatos y la verificación.
5. Entregamos los materialesProporcionamos la dirección del token y los materiales fuente acordados, explicamos el proceso de verificación y la gestión de las funciones previstas.