Desarrollo de tokens

Un token es un contrato inteligente desplegado en una blockchain: un programa que registra quién posee qué y bajo qué reglas se puede transferir. Desarrollarlo es decidir esas reglas y escribirlas en código que después no se cambia a la ligera.

Es un trabajo distinto de la operación de colocación —la ronda, la documentación, el registro—, que tratamos en emisión de tokens. Tiene sentido cuando ya sabes qué representa el token y necesitas que exista on-chain con garantías; no lo tiene si aún no está claro si resuelve algo, y ahí conviene empezar por tokenomics.

El estándar condiciona todo lo demás, así que se decide primero.

• ERC-20: unidades fungibles e intercambiables. Tokens de utilidad, puntos, gobernanza o unidades de cuenta internas.
• ERC-721: piezas únicas con identificador propio, cuando cada unidad tiene identidad: certificados, títulos individuales, coleccionables.
• ERC-1155: varias series fungibles y no fungibles en un mismo contrato. Menos gas y un inventario más simple cuando manejas muchas colecciones.
• ERC-1400 y ERC-3643: pensadas para instrumentos con restricciones. Añaden registro de titulares autorizados, bloqueos temporales, transferencias condicionadas a identidad verificada y recuperación forzosa de posiciones.

La decisión entre unos y otros no es técnica: si el token se comporta como instrumento financiero no le aplica MiCA, sino la normativa de valores (LMVSI y MiFID II), y el contrato debe imponer esas restricciones en la propia transferencia. El clasificador MiCA/MiFID ordena ese debate antes de escribir código.

Antes de programar cerramos por escrito lo que marcará el contrato de por vida:

• Supply: fijo, con tope máximo o abierto; quién puede acuñar, con qué límite y hasta cuándo.
• Permisos: roles separados para administrar, pausar y quemar, en manos de una multifirma y no de una cuenta única.
• Actualizabilidad: un contrato inmutable da certeza y no admite correcciones; un proxy permite corregir y concentra mucho poder en quien controla la actualización.
• Pausa y listas de bloqueo: necesarias en entornos regulados, difíciles de justificar en un token de utilidad.
• Comportamientos no estándar: comisiones en la transferencia, rebases o decimales inusuales rompen integraciones con exchanges, puentes y protocolos DeFi.

El código se entrega probado, no solo escrito:

• Pruebas unitarias con cobertura sobre los caminos de fallo, no solo sobre el caso feliz.
• Invariantes y fuzzing sobre las reglas que nunca deben romperse, como que la suma de saldos cuadre con el supply.
• Análisis estático y revisión manual de control de acceso, reentrada, desbordamientos y redondeos.
• Despliegue en red de pruebas, ensayo de la operativa real y solo después salto a producción.
• Verificación del código fuente en el explorador y publicación de la dirección.

Cuando el contrato va a custodiar valor real añadimos una revisión independiente: auditoría de smart contracts. A julio de 2026, ninguno de los contratos que hemos desplegado ha sufrido un incidente de seguridad conocido.

Recibes el repositorio con código y scripts de despliegue, la suite de pruebas, el informe de cobertura, la documentación de roles y funciones administrativas, las direcciones verificadas y un runbook de operativa.

Los fallos que más se repiten:

• Elegir el estándar después de prometer una funcionalidad que ese estándar no soporta.
• Desplegar con la clave de administrador en una cartera caliente de una sola firma.
• Dejar un proxy actualizable sin plazo de espera ni gobierno, y descubrirlo en la primera due diligence.
• Copiar un contrato de un repositorio público sin revisar en qué se desvía del estándar.
• Programar restricciones de transferencia a mano cuando el proyecto es un security token y ERC-3643 ya lo resuelve.