Una empresa propone tokenizar un restaurante turístico ubicado en una zona de alta afluencia. El restaurante actualmente está operativo y el propietario quiere levantar capital para financiar la compra del inmueble donde funciona, realizar algunas mejoras y cubrir parte del capital de trabajo. DATOS DEL PROYECTO Valor de compra del inmueble: US$1,800,000 Adecuación y remodelación: US$300,000 Equipamiento: US$100,000 Capital de trabajo: US$100,000 Gastos legales, estructuración y otros: US$100,000 Capital total necesario: US$2,400,000 El propietario no dispone de capital suficiente para realizar la operación. Por lo tanto, plantea financiar mediante tokenización prácticamente el 100% de los US$2,400,000. DATOS DEL NEGOCIO El restaurante genera actualmente: US$900,000 de ingresos anuales. Sus gastos operativos ascienden aproximadamente a: US$780,000 anuales. Por lo tanto, el flujo operativo neto estimado es: US$120,000 anuales. El propietario proyecta que después de la remodelación los ingresos podrían aumentar hasta: US$1,050,000 anuales. Sin embargo, los gastos también aumentarían aproximadamente a: US$900,000 anuales. El flujo operativo proyectado después de la remodelación sería: US$150,000 anuales. PROPUESTA DE TOKENIZACIÓN El propietario propone emitir tokens por los US$2,400,000 necesarios. Los inversionistas recibirían un rendimiento objetivo del: 8% anual. El plazo propuesto sería de: 5 años. Al finalizar el quinto año, el propietario pretende devolver el capital a los inversionistas. Además, plantea vender el inmueble al finalizar el periodo. El valor esperado de venta sería: US$2,700,000. INFORMACIÓN ADICIONAL El propietario no cuenta actualmente con un comprador para el inmueble. El valor de US$2,700,000 es solamente una estimación. El restaurante depende principalmente del turismo. La ocupación turística de la zona ha sido variable durante los últimos años. No existen contratos de ingresos mínimos garantizados. No existe un arrendatario externo que garantice el pago de una renta.

Una empresa llamada Caribe Stay Group posee un pequeño hotel boutique ubicado en una zona turística de alta demanda. El hotel actualmente se encuentra operativo y genera ingresos. La empresa quiere levantar capital mediante tokenización para: - remodelar habitaciones; - construir una terraza; - mejorar zonas comunes; - invertir en marketing; - aumentar la ocupación; - y posteriormente vender el hotel a un inversionista institucional. La empresa solicita levantar US$1,500,000 mediante tokenización. DATOS DEL ACTIVO Valor comercial actual del hotel: US$4,000,000 Ingresos brutos anuales: US$1,250,000 Gastos operativos anuales: US$850,000 Flujo operativo neto estimado: US$400,000 anuales Ocupación promedio: 67% Horizonte estimado de inversión: 5 años Valor estimado del hotel después de la remodelación: US$5,500,000 USO DEL CAPITAL TOKENIZADO La empresa propone utilizar los US$1,500,000 de la siguiente manera: - Remodelación: US$700,000 - Marketing: US$200,000 - Construcción de terraza y nuevas zonas comunes: US$250,000 - Capital de trabajo: US$150,000 - Gastos legales, tecnológicos y estructuración: US$100,000 - Reserva: US$100,000 Total: US$1,500,000 PROPUESTA DEL PROMOTOR El propietario quiere mantener el 100% de la propiedad legal del hotel. Los inversionistas tokenizados no serán propietarios directos del inmueble. A cambio de sus US$1,500,000, recibirían: 10% anual fijo durante 5 años. Al finalizar el año 5, recibirían nuevamente el capital invertido. La empresa espera vender el hotel aproximadamente por US$5,500,000 al finalizar ese periodo. Sin embargo, los inversionistas tokenizados: no recibirían ninguna participación en la plusvalía de la venta. INFORMACIÓN ADICIONAL Actualmente el hotel produce aproximadamente US$400,000 anuales de flujo operativo. Después de la remodelación, el promotor estima que podría aumentar hasta: US$550,000 anuales. Sin embargo, ese incremento todavía no está garantizado. La empresa tiene experiencia operando hoteles, pero nunca ha realizado una tokenización.

Después de hacer el ejercicio con Hardhat, quise repetirlo con Foundry para usar el comando tal como lo vimos en clase. Algo que no sabía es que Foundry corre nativo en Windows. La documentación dice que no anda en PowerShell y eso confunde, pero lo único que necesita otra terminal es el instalador. Y alcanza con Git Bash, que ya viene con Git. El comando funcionó tal cual el de la clase, sin los parámetros extra que había necesitado con Hardhat. Slither detecta que es un proyecto Foundry y le pide a Foundry que compile, así que no hay que indicarle donde están las librerías. El resultado: 0 hallazgos altos, medios y bajos. Pero eso no es mérito del código ya que es un contrato de ejemplo de 10 líneas que solo guarda un número, en este caso simple no maneja fondos ni llama a otros contratos en definitiva no tiene donde fallar. Lo que si estuvo bueno fue correr forge test y ver "runs: 256" es decir que Foundry generó 256 valores al azar y probó la función con cada uno (fuzzing). Esto es bueno porque no prueba los casos que se te ocurrieron, prueba los que no se te ocurrieron (que es lo que haría un atacante). Con eso me quedó mas claro lo del slide en clase que menciona que Slither busca patrones conocidos, el fuzzing explora lo desconocido. Adjunto un cuadro con algunas comparaciones y comentarios de ambas tareas.

Tarea de la semana: Correr Slither sobre el contrato ERC-3643 Como todavía no tengo el contrato del proyecto, audité el T-REX de Tokeny, que es la implementación oficial del ERC-3643 que venimos viendo en clase, el mismo es open source, así que se puede descargar y analizar sin problema desde el siguiente link: github.com/TokenySolutions/T-REX Tuve que armar el entorno antes de correr Slither ya que debí instalar Node, Slither y el compilador de Solidity. El resultado fue el siguiente, sobre 823 líneas de código: 0 hallazgos de severidad alta, 3 medios, 17 bajos. 91 informativos Todavía no entiendo en profundidad qué significa cada hallazgo ya que recién estoy arrancando con Solidity pero me llamó la atención algo del resumen que sí pude leer: La herramienta marca que el contrato es "pausable", que puede "emitir sin límite" y que es "actualizable". Comprendí que no son errores sino especie de poderes que alguien tiene, y que en un activo regulado son necesarios. Entonces el tema no debería centrarse en si el código está bien escrito, sino quién tiene las llaves o la autorizaciones. Eso me pareció lo más importante del ejercicio, además de entender que el contrato en este caso esta en Solidity, que existen frameworks como Hardhat, Foundry que es donde los mismos se compilan, testean, simulan y despliegan. Además me quedó claro que "cero hallazgos altos" no significa que este todo bien ya que Slither encuentra patrones conocidos, no problemas de diseño propios del contrato. Ahora quiero repetirlo con Foundry para ver la otra forma de hacerlo.