La tesorería es el lugar donde los proyectos de tokenización se juegan su supervivencia. En ella conviven dinero fiduciario, bitcoin u otros criptoactivos de reserva y el propio token del proyecto, cuyos aspectos fiscales, de custodia y de gobernanza rara vez se diseñan correctamente desde el principio. Sin embargo, esas decisiones condicionarán todo el desarrollo futuro del proyecto.

Todo proyecto de tokenización termina gestionando tres tipos de activos claramente diferenciados:

• El dinero fiduciario recibido de los inversores o generado por la actividad.
• Las reservas en criptoactivos, normalmente bitcoin o ether.
• El token nativo del propio proyecto.

Cada uno plantea problemas distintos de valoración, fiscalidad, contabilidad, control y gobierno corporativo. Las decisiones que se adopten —o que se omitan— antes del lanzamiento marcarán el futuro del proyecto.

La tesorería no es simplemente una cuestión contable.

Es, ante todo, una cuestión de arquitectura jurídica.

Primera decisión: ¿qué entidad es titular de cada activo?

Los proyectos bien estructurados suelen separar claramente sus funciones.

Lo habitual es contar con:

• Una entidad titular del protocolo, de la propiedad intelectual y de la tesorería a largo plazo.
• Otra sociedad operativa encargada de la emisión del token y de la relación con los usuarios, especialmente cuando el proyecto desarrolla su actividad dentro de la Unión Europea.

La entidad que mantiene la tesorería suele establecerse en jurisdicciones donde la fiscalidad de los criptoactivos sea previsible.

En este punto, Suiza continúa siendo una de las jurisdicciones más atractivas.

Una de sus principales ventajas es la posibilidad de obtener tax rulings cantonales, mediante los cuales puede acordarse previamente con la administración tributaria el tratamiento fiscal de la emisión de los tokens. Así, puede determinarse con antelación si los fondos obtenidos constituyen un ingreso inmediato sujeto a tributación o un pasivo diferido vinculado a servicios futuros.

Además, cantones como Zug mantienen tipos efectivos del impuesto sobre sociedades cercanos al 12 %, lo que explica que Suiza siga siendo una jurisdicción especialmente interesante para proyectos con financiación relevante.

Naturalmente, emitir un token desde Suiza no elimina la obligación de cumplir con MiCA cuando el proyecto se dirige al mercado europeo.

Simplemente demuestra que la elección de la jurisdicción y el cumplimiento regulatorio son dos decisiones jurídicas diferentes.

Segunda decisión: ¿cómo tributa lo que todavía no has vendido?

Uno de los errores más frecuentes aparece al cierre del primer ejercicio.

Muchos promotores descubren entonces que la emisión del token ha generado un beneficio fiscalmente gravable sin haber producido liquidez suficiente para pagar los impuestos correspondientes.

Antes del lanzamiento conviene analizar cuestiones como:

• Cómo debe contabilizarse el token nativo.
• Cuándo deben imputarse los ingresos procedentes de preventas.
• Cómo deben valorarse las reservas en criptoactivos.
• Qué tratamiento tiene el IVA de los utility tokens, frente a la exención ya consolidada para los criptoactivos utilizados como medios de pago.

La respuesta dependerá de la jurisdicción elegida.

La planificación fiscal internacional es perfectamente legítima.

Lo que no resulta posible es intentar reorganizar fiscalmente una operación una vez que los hechos imponibles ya se han producido.

Dentro de Europa existen modelos diferentes.

Por ejemplo, el régimen de Estonia, donde la tributación empresarial se produce, con carácter general, cuando se distribuyen beneficios y no cuando se generan, puede resultar especialmente interesante para proyectos que reinviertan su tesorería.

En España, más que el tipo impositivo, suele ser determinante documentar correctamente desde el primer día la naturaleza jurídica de cada flujo económico.

Tercera decisión: ¿quién controla las claves?

El control de la tesorería constituye un problema de gobernanza mucho más que de seguridad informática.

Las mejores prácticas internacionales convergen actualmente en varios principios básicos:

• Carteras multifirma (multisig) con umbrales claramente definidos.
• Separación entre las carteras operativas y las reservas estratégicas.
• Políticas escritas para autorizar movimientos, establecer límites y aprobar operaciones.
• Protocolos de actuación en caso de fallecimiento, incapacidad, renuncia o sustitución de un firmante.
• Procedimientos específicos para conflictos entre fundadores o requerimientos de autoridades públicas.

Todo ello puede parecer excesivo durante las primeras fases del proyecto.

La experiencia demuestra exactamente lo contrario.

La mayoría de los proyectos blockchain no fracasan por un ciberataque.

Fracasan porque sus fundadores nunca acordaron claramente quién podía mover los activos y bajo qué condiciones.

Cuarta decisión: ¿qué ocurre cuando aparece un conflicto?

Y el conflicto llegará.

Puede surgir entre fundadores con períodos de vesting pendientes, con inversores de la preventa, con el custodio, con proveedores tecnológicos o incluso con la propia comunidad.

En prácticamente todos esos supuestos, la tesorería terminará siendo el centro de la controversia.

La peor situación posible consiste en descubrir entonces que los distintos contratos remiten los litigios a tribunales estatales diferentes, en varios países, con procedimientos que pueden prolongarse durante años mientras los activos digitales permanecen bloqueados.

La solución consiste en diseñar desde el inicio un sistema coherente de resolución de conflictos.

Los estatutos sociales, los pactos entre socios, los contratos de custodia, la documentación de la emisión y las condiciones del token deberían incorporar cláusulas compatibles de resolución de controversias.

El arbitraje especializado ante instituciones con conocimiento del ecosistema blockchain, como el Tribunal Arbitral de BACS, permite transformar múltiples procedimientos dispersos en un único proceso especializado, rápido y con la posibilidad de obtener la ejecución internacional del laudo.

Probablemente sea uno de los elementos menos costosos de incorporar al proyecto.

Con frecuencia termina siendo uno de los más valiosos.

Conclusión: la arquitectura jurídica del proyecto

Con este artículo concluye nuestra serie sobre la emisión de tokens en Europa.

Los tres artículos desarrollan una misma idea.

En 2026, emitir un token ya no es únicamente un ejercicio tecnológico.

Es, sobre todo, un ejercicio de clasificación jurídica, diseño institucional y gobernanza.

Las tres grandes decisiones están estrechamente relacionadas:

• ¿Dónde debe constituirse el proyecto?
• ¿Necesita realmente una licencia CASP?
• ¿Cómo debe organizarse su tesorería?

Responder correctamente a estas cuestiones antes del lanzamiento siempre será mucho menos costoso que intentar corregirlas una vez que el proyecto ya está en funcionamiento.

La arquitectura jurídica no frena la innovación.

La hace posible.

Este artículo tiene carácter meramente informativo y no constituye asesoramiento jurídico. Cada proyecto de tokenización requiere un análisis individualizado. Si estás preparando la emisión de un token, BACS puede ayudarte a realizar una primera clasificación jurídica y diseñar la estructura legal más adecuada antes del lanzamiento.