Resumen En progreso

El presente trabajo propone el diseño e implementación de NUBE, un ecosistema de crédito descentralizado sin interés sobre Binance Smart Chain, respaldado en Bitcoin tokenizado (BTCB). El problema que motiva la investigación es la incapacidad de las plataformas de finanzas descentralizadas (DeFi) existentes de ofrecer crédito sin tasas de interés y sin liquidaciones automáticas valuadas en moneda fiat, lo que perjudica a los tenedores de Bitcoin que buscan liquidez sin desprenderse de su reserva de valor. La metodología empleada combina el análisis comparativo de protocolos DeFi existentes con el diseño de sistemas y la implementación de contratos inteligentes en Solidity. El ecosistema NUBE se compone de un token fungible BEP-20 que funciona como unidad de crédito, un contrato de préstamos que cobra un único cargo administrativo al momento de la solicitud, un pool de liquidez NUBE/BTCB en PancakeSwap y un modelo de gobernanza institucional sin fines de lucro. Los contratos fueron desplegados y validados en BSC Testnet, verificando el flujo completo de solicitud y devolución de préstamos. Se concluye que la arquitectura propuesta es técnicamente viable y constituye una alternativa éticamente fundamentada al crédito DeFi tradicional, con potencial de impacto social en poblaciones no bancarizadas de economías emergentes.

Palabras clave: finanzas descentralizadas, DeFi, Bitcoin, BTCB, crédito sin interés, contratos inteligentes, Binance Smart Chain, tokenomics, gobernanza descentralizada, economía social y solidaria, monedas sociales.

Abstract En progreso

This paper proposes the design and implementation of NUBE, an interest-free decentralized lending ecosystem on Binance Smart Chain, backed by tokenized Bitcoin (BTCB). The research problem stems from existing DeFi platforms' inability to offer credit without interest rates or automatic liquidations denominated in fiat currency, which disadvantages Bitcoin holders seeking liquidity without liquidating their store of value. The methodology combines comparative analysis of existing DeFi protocols with systems design and smart contract implementation in Solidity. The NUBE ecosystem consists of a BEP-20 fungible token serving as the credit unit, a lending contract that charges a single administrative fee at the time of the loan request, a NUBE/BTCB liquidity pool on PancakeSwap, and a non-profit institutional governance model. The contracts were deployed and validated on BSC Testnet, verifying the complete loan request and repayment workflow. The study concludes that the proposed architecture is technically feasible and constitutes an ethically grounded alternative to traditional DeFi credit, with social impact potential for unbanked populations in emerging economies.

Keywords: decentralized finance, DeFi, Bitcoin, BTCB, interest-free credit, smart contracts, Binance Smart Chain, tokenomics, decentralized governance, social and solidarity economy, community currencies.

Capítulo 1: Introducción Completo

1.1 Contexto y Motivación

El acceso al crédito constituye uno de los mecanismos fundamentales de inclusión económica en las sociedades contemporáneas. Sin embargo, en América Latina y el Caribe, la exclusión financiera persiste como un desafío estructural: según el Banco Mundial (2021), aproximadamente el 49% de la población adulta en la región no posee una cuenta bancaria formal. El sistema bancario tradicional impone condiciones de acceso que excluyen sistemáticamente a las poblaciones más vulnerables: requisito de historial crediticio formal, garantías patrimoniales, ingresos demostrables y tasas de interés que frecuentemente superan el 100% nominal anual en contextos de alta inflación como el argentino (BCRA, 2023).

En este contexto, el surgimiento de las finanzas descentralizadas (DeFi) a partir de 2017-2020 representó una promesa de democratización financiera: protocolos de préstamos sin intermediarios, operados por contratos inteligentes transparentes e inmutables, accesibles a cualquier persona con una wallet y una conexión a internet. Plataformas como Compound, Aave y MakerDAO demostraron la viabilidad técnica de los préstamos descentralizados con colateral criptográfico, alcanzando en su pico más de 200 mil millones de dólares en valor total bloqueado (Total Value Locked, TVL) según DeFi Llama (2021).

Sin embargo, estos protocolos mantienen una dependencia estructural del sistema que afirman superar: todos ellos valúan el colateral en dólares estadounidenses, utilizan oráculos de precio externos para mantener esa valuación y liquidan automáticamente la garantía del prestatario cuando el ratio préstamo-valor supera un umbral predefinido. Para los tenedores de Bitcoin que consideran a esta criptomoneda una reserva de valor de largo plazo, este modelo resulta adverso: una corrección de precio transitoria en el mercado puede provocar la pérdida permanente de su garantía, aunque en términos de Bitcoin el sistema permanezca perfectamente solvente. La motivación del presente trabajo surge de esta brecha: diseñar un protocolo DeFi que no transfiera el riesgo cambiario del emisor de moneda fiat al tenedor de Bitcoin.

1.2 Problema de Investigación

Las plataformas DeFi de préstamos existentes presentan tres limitaciones fundamentales desde la perspectiva de los tenedores de Bitcoin como reserva de valor. Primera: todas las plataformas analizadas calculan el valor del colateral en dólares mediante oráculos de precio externos, trasladando al prestatario el riesgo cambiario del par BTC/USD. Segunda: todos los protocolos cobran tasas de interés —ya sea variable o estable— lo que contradice la filosofía del dinero sólido, según la cual el dinero no debe generar rendimiento por el mero transcurso del tiempo. Tercera: los modelos de gobernanza existentes responden a lógicas de maximización de valor para los holders de tokens de gobernanza, creando incentivos hacia el extractivismo financiero.

El problema de investigación puede enunciarse de la siguiente manera: las plataformas DeFi de préstamos colateralizados vigentes son incompatibles con los principios de preservación del valor del colateral y de ética financiera no usuraria, impidiendo a los tenedores de Bitcoin acceder a liquidez en términos que respeten la integridad de su reserva de valor. ¿Cómo diseñar e implementar un sistema de crédito descentralizado que sea técnicamente viable, éticamente fundamentado y sostenible sin cobrar interés?

1.3 Preguntas de Investigación

Las preguntas que guían este trabajo son:

1. ¿Es técnicamente viable implementar un sistema de crédito DeFi sin interés sobre Binance Smart Chain utilizando BTCB como garantía?
2. ¿Qué mecanismos de gobernanza permiten la sostenibilidad institucional de un protocolo sin rentabilidad financiera como objetivo?
3. ¿Cómo afecta la eliminación de las liquidaciones automáticas por precio fiat a la seguridad del colateral y la confianza del usuario?

1.4 Objetivos

1.4.1 Objetivo General

Diseñar e implementar un ecosistema de crédito descentralizado sin interés sobre Binance Smart Chain, respaldado en Bitcoin tokenizado (BTCB), que elimine las liquidaciones automáticas por precio fiat y garantice la preservación del valor del colateral para el prestatario.

1.4.2 Objetivos Específicos

1. Analizar las plataformas DeFi de préstamos existentes e identificar sus limitaciones desde una perspectiva de equidad y preservación del valor.
2. Diseñar la arquitectura del ecosistema NUBE: token BEP-20, contrato de préstamos, pool de liquidez y contrato de gobernanza.
3. Implementar los contratos inteligentes en Solidity y desplegarlos en la red de pruebas de Binance Smart Chain.
4. Desarrollar una dApp funcional con integración MetaMask para la interacción del usuario.
5. Validar el sistema mediante pruebas funcionales y de seguridad.

1.5 Justificación

La relevancia del presente trabajo puede articularse en cuatro dimensiones. Desde una perspectiva técnica, el trabajo realiza un aporte original al campo de los sistemas TIC aplicados a finanzas al demostrar que es posible eliminar los oráculos de precio fiat de un protocolo DeFi sin comprometer su funcionalidad. Esta decisión de diseño tiene implicaciones profundas en la arquitectura de seguridad y en el modelo de incentivos del sistema.

Desde una perspectiva social, NUBE ofrece una alternativa al crédito tradicional para poblaciones que poseen Bitcoin pero no tienen acceso al sistema bancario formal. En Argentina, donde la adopción de criptomonedas ha crecido exponencialmente como respuesta a la inflación crónica —con una tasa que superó el 211% anual en 2023— existe una demanda genuina de servicios financieros denominados en activos resistentes a la devaluación.

Desde una perspectiva ética, el trabajo conecta con una larga tradición de pensamiento sobre el crédito justo, desde la prohibición bíblica de la usura (Lucas 6:35: "prestad sin esperar nada a cambio") hasta la economía islámica contemporánea y el pensamiento social cristiano. El cargo administrativo que sostiene a NUBE no es interés: no remunera al capital por el mero transcurso del tiempo, sino que cubre los costos operativos de un servicio específico.

Desde una perspectiva institucional, el trabajo representa un modelo de innovación tecnológica con base académica y orientación social, desarrollado en el marco de la Maestría en Gestión de Servicios TIC de la Universidad Nacional de Avellaneda.

1.6 Alcance y Limitaciones

El presente trabajo cubre el diseño conceptual completo del ecosistema NUBE, la implementación de los contratos inteligentes en Solidity, su despliegue en BSC Testnet y el desarrollo de una dApp funcional para la interacción del usuario. Quedan fuera del alcance: la auditoría profesional de seguridad de los contratos inteligentes; el análisis regulatorio exhaustivo bajo la normativa financiera argentina, dado que el marco regulatorio de activos digitales en Argentina se encuentra en evolución al momento de la redacción; el despliegue en mainnet, que requiere liquidez real y auditoría certificada; y el estudio cuantitativo del impacto social con usuarios reales, propuesto como línea de trabajo futuro.

Las principales limitaciones del trabajo son: la volatilidad inherente del ecosistema blockchain, que puede generar cambios en las herramientas y protocolos utilizados; la dependencia de PancakeSwap como proveedor de liquidez; y la disponibilidad de BTCB como activo de colateral, sujeta a las decisiones de custodia de Binance.

1.7 Estructura del Documento

El presente trabajo se organiza en ocho capítulos. El Capítulo 2 desarrolla el marco teórico sobre sistemas financieros, blockchain, Bitcoin y DeFi. El Capítulo 3 analiza el estado del arte en plataformas DeFi de préstamos. El Capítulo 4 presenta el diseño del sistema NUBE. El Capítulo 5 describe la implementación técnica. El Capítulo 6 reporta las pruebas realizadas. El Capítulo 7 analiza y discute los resultados. El Capítulo 8 presenta las conclusiones y líneas de trabajo futuro.

Capítulo 2: Marco Teórico Completo

2.1 Limitaciones del Sistema Financiero Tradicional

El sistema financiero tradicional opera bajo el paradigma de la intermediación financiera: los bancos actúan como intermediarios entre agentes con excedente de capital y agentes con déficit, captando depósitos y otorgando créditos con un diferencial de tasas que constituye su margen de rentabilidad (Mishkin, 2016). Este modelo presenta limitaciones estructurales significativas en contextos de economías emergentes.

En primer lugar, el acceso al crédito bancario requiere la acreditación de ingresos formales, historial crediticio y garantías patrimoniales. Estas condiciones excluyen a trabajadores informales, emprendedores sin historial y ciudadanos sin patrimonio verificable, que en América Latina representan más del 50% de la fuerza laboral (OIT, 2021). En segundo lugar, las tasas de interés en economías con alta inflación resultan prohibitivas: en Argentina, la tasa nominal anual para préstamos personales superó el 120% en 2023 (BCRA, 2023), convirtiendo al crédito formal en un mecanismo de empobrecimiento para los sectores de menores ingresos. En tercer lugar, el sistema financiero tradicional opera exclusivamente en monedas nacionales, exponiendo a ahorradores y prestatarios al riesgo de devaluación. La depreciación del peso argentino frente al dólar ha sido superior al 90% en términos reales durante la última década, destruyendo sistemáticamente el valor de los ahorros en moneda local.

2.2 Blockchain y Contratos Inteligentes

2.2.1 Fundamentos de la Tecnología Blockchain

La tecnología blockchain fue propuesta originalmente por Nakamoto (2008) como solución al problema del doble gasto en transacciones digitales entre pares, sin necesidad de un intermediario de confianza. En su concepción original, una blockchain es una base de datos distribuida y replicada en nodos independientes, donde cada nuevo bloque de transacciones referencia criptográficamente al bloque anterior mediante su hash, formando una cadena inmutable de registros.

Los cuatro atributos fundamentales de una blockchain pública son: descentralización (ninguna autoridad central controla el registro), inmutabilidad (una vez registrada, una transacción no puede ser alterada sin invalidar todos los bloques posteriores), transparencia (cualquier participante puede auditar el historial completo) y resistencia a la censura (ningún actor puede impedir unilateralmente una transacción válida). El mecanismo de consenso permite a los nodos independientes acordar el estado válido del registro sin necesidad de confianza mutua. Bitcoin utiliza Proof of Work (PoW), donde los mineros compiten resolviendo puzzles computacionales. Ethereum migró en 2022 a Proof of Stake (PoS), donde los validadores bloquean una cantidad de ETH como colateral, con penalidades por comportamiento deshonesto.

2.2.2 Contratos Inteligentes

El concepto de contrato inteligente fue acuñado por Nick Szabo en 1994 como "un protocolo computarizado que ejecuta los términos de un contrato" (Szabo, 1994). Con la plataforma Ethereum, Buterin (2014) materializó esta idea en código ejecutable sobre una blockchain: programas autónomos que residen en la blockchain, ejecutan lógica arbitraria y mantienen estado propio, con la garantía de que su ejecución no puede ser alterada ni censurada una vez desplegados.

Los contratos inteligentes se escriben en Solidity, un lenguaje de alto nivel con tipado estático y sintaxis inspirada en JavaScript. El código Solidity se compila a bytecode de la Ethereum Virtual Machine (EVM), una máquina de estados determinista que ejecuta el mismo resultado en todos los nodos de la red (Wood, 2014). Una propiedad fundamental para el presente trabajo es la capacidad de los contratos de custodiar activos: un contrato puede recibir, retener y transferir tokens BEP-20 de forma autónoma, sin que ninguna parte humana tenga acceso a los fondos custodiados, excepto bajo las condiciones explícitamente programadas.

2.2.3 Binance Smart Chain

Binance Smart Chain (BSC), renombrada BNB Smart Chain en 2022, fue lanzada por Binance en 2020 como una cadena de bloques con compatibilidad total con la EVM de Ethereum. Esta compatibilidad permite que los contratos inteligentes y herramientas desarrolladas para Ethereum funcionen en BSC sin modificaciones (Binance, 2020). BSC utiliza el mecanismo de consenso Proof of Staked Authority (PoSA), con 21 validadores que producen bloques cada 3 segundos, resultando en tiempos de confirmación significativamente menores que Ethereum y comisiones de transacción inferiores a USD 0.10. Para el ecosistema NUBE, la elección de BSC se justifica por: la compatibilidad EVM que permite reutilizar el ecosistema de herramientas Ethereum (Hardhat, OpenZeppelin, ethers.js); los costos de transacción reducidos que hacen viable el uso por parte de usuarios con saldos pequeños; y la disponibilidad de BTCB como activo nativo en BSC.

2.3 Bitcoin y su Tokenización

2.3.1 Bitcoin como Reserva de Valor

Bitcoin fue concebido por Nakamoto (2008) como un sistema de efectivo electrónico entre pares, pero su adopción masiva lo ha posicionado principalmente como reserva de valor y activo de cobertura contra la inflación monetaria. Sus propiedades fundamentales lo distinguen de cualquier otra forma de dinero conocida. La escasez programada establece un suministro máximo de 21 millones de unidades, con una tasa de emisión que se reduce a la mitad cada 210,000 bloques (halvings). Esta política monetaria predecible e inalterable contrasta radicalmente con las monedas fiat, cuya oferta es controlada discrecionalmente por bancos centrales.

Ammous (2018) desarrolla el concepto de "dinero sólido" (sound money) para caracterizar a Bitcoin: un activo cuya relación stock/flujo es alta y creciente, haciendo imposible la dilución del valor por exceso de emisión. La descentralización del protocolo Bitcoin implica que ningún estado, empresa o individuo puede alterar sus reglas monetarias, haciéndolo resistente a la confiscación, la censura y la devaluación política. Estas características son especialmente valoradas en economías con historial de defaults soberanos y controles de capital como Argentina.

2.3.2 BTCB: Bitcoin Tokenizado en BSC

BTCB es un token BEP-20 que representa Bitcoin en la Binance Smart Chain en una relación de paridad 1:1. Binance mantiene en custodia Bitcoin real en una wallet pública y auditable, respaldando cada unidad de BTCB emitida (Binance, 2019). Esto permite que los usuarios de BSC operen con valor denominado en Bitcoin aprovechando la velocidad y el bajo costo de las transacciones en BSC. Para el ecosistema NUBE, BTCB es el activo de colateral por excelencia: permite que los préstamos sean contabilizados, garantizados y devueltos en términos de Bitcoin, eliminando la necesidad de un oráculo de precio en dólares. El riesgo principal de BTCB es el riesgo de contraparte con Binance como custodio, un factor de centralización que el presente trabajo reconoce como limitación estructural pero acepta como trade-off dadas las ventajas operativas.

2.4 Finanzas Descentralizadas (DeFi)

2.4.1 Definición y Características

El término "finanzas descentralizadas" (DeFi) fue popularizado hacia 2018-2019 para designar al conjunto de aplicaciones financieras construidas sobre blockchains públicas sin intermediarios centrales. Zetzsche et al. (2020) definen DeFi como "la provisión de servicios financieros mediante protocolos de código abierto que operan de forma autónoma sobre blockchain pública, sin la intervención de intermediarios licenciados." Las características distintivas de DeFi son: acceso permisionless (cualquier wallet puede interactuar sin solicitar aprobación), transparencia total del código y del estado del sistema, composabilidad (capacidad de combinar protocolos entre sí), y custodia no custodial (los activos nunca pasan por manos de un intermediario). El TVL en protocolos DeFi creció desde menos de USD 1 mil millones a principios de 2020 hasta un máximo histórico de USD 256 mil millones en noviembre de 2021 (DeFi Llama, 2021).

2.4.2 Protocolos de Préstamos DeFi

Los protocolos de préstamos DeFi operan bajo el modelo de colateralización sobregarantizada: para recibir un préstamo, el usuario deposita un activo de valor mayor al préstamo solicitado. El ratio entre el valor del préstamo y el valor del colateral se denomina Loan-to-Value (LTV). El mecanismo de liquidación es la pieza central de la seguridad de estos protocolos: cuando el valor del colateral cae por debajo de un umbral mínimo —determinado por la caída del precio en dólares—, el protocolo permite a terceros (liquidadores) comprar el colateral con descuento para recuperar la deuda. Este mecanismo garantiza la solvencia del protocolo pero penaliza al prestatario, que puede perder su colateral ante una caída de precio transitoria, sin haber incumplido ninguna obligación en términos del activo depositado.

2.4.3 Exchanges Descentralizados y Pools de Liquidez

Los exchanges descentralizados (DEX) de modelo AMM (Automated Market Maker), popularizados por Uniswap (2020) y adaptados en BSC por PancakeSwap, reemplazan el libro de órdenes tradicional por pools de liquidez. La fórmula del producto constante x·y=k establece que el producto de las cantidades de los dos activos en el pool debe mantenerse constante. Cuando un usuario intercambia el activo X por el activo Y, la nueva relación de cantidades determina el precio resultante. Los proveedores de liquidez (LPs) depositan ambos activos en proporción y reciben tokens LP que representan su participación, percibiendo una fracción de los fees de trading (típicamente 0.25% en PancakeSwap) como retribución por el riesgo de impermanent loss asumido.

2.5 Tokenomics

La tokenomics es el estudio del diseño económico de los tokens en ecosistemas blockchain: su oferta, distribución, mecanismos de emisión y retiro, casos de uso y estructura de incentivos. Los tokens ERC-20 en Ethereum y BEP-20 en Binance Smart Chain definen una interfaz estándar de seis funciones que permite la interoperabilidad entre contratos, wallets y exchanges: totalSupply(), balanceOf(), transfer(), transferFrom(), approve() y allowance().

En el ecosistema NUBE, el token cumple una función específica como unidad de crédito: es emitido (mint) cuando se abre un préstamo y destruido (burn) cuando se cierra. Este diseño garantiza que el suministro circulante de NUBE en todo momento corresponde exactamente al volumen de colateral neto en custodia, creando una correspondencia verificable en tiempo real sobre la blockchain entre tokens en circulación y Bitcoin garantizado.

2.6 Gobernanza Descentralizada

Los modelos de gobernanza en protocolos DeFi varían desde la gobernanza completamente on-chain (como Compound, donde los holders de COMP votan directamente transacciones en el contrato de gobernanza) hasta modelos off-chain (como Snapshot, donde la votación ocurre fuera de la blockchain y los resultados son implementados por un multisig). Las DAOs (Decentralized Autonomous Organizations) son la forma organizacional emergente del ecosistema DeFi: entidades cuyas reglas están codificadas en contratos inteligentes y cuyos miembros participan en decisiones mediante tokens de gobernanza.

Para el ecosistema NUBE, el modelo de gobernanza se aparta de la lógica de maximización de valor para holders de tokens. En su lugar, propone un modelo institucional inspirado en las fundaciones sin fines de lucro: una entidad con propósito definido, cuya sostenibilidad se financia con los cargos administrativos recaudados y cuyo objetivo es la provisión del servicio de crédito accesible, no la rentabilidad del capital de gobernanza.

2.7 Fundamento Ético: El Crédito Sin Interés

La prohibición de la usura es uno de los pocos principios éticos compartidos por las grandes tradiciones religiosas y filosóficas. En el Evangelio de Lucas (6:35) se lee: "Prestad sin esperar nada a cambio." El Corán prohíbe el riba (usura, interés) en términos absolutos, dando origen a las finanzas islámicas, un sector que actualmente gestiona más de tres billones de dólares en activos globalmente (Islamic Financial Services Board, 2022). La doctrina social cristiana, desde Rerum Novarum (León XIII, 1891) hasta Laudato Si' (Francisco, 2015), rechaza el extractivismo financiero como forma de injusticia estructural.

La distinción fundamental entre cargo administrativo e interés es conceptualmente clara: el cargo administrativo remunera un servicio específico prestado y es proporcional al costo real de ese servicio; el interés remunera al capital por el mero transcurso del tiempo, independientemente de cualquier servicio prestado. NUBE adopta explícitamente esta distinción como fundamento de su modelo de sostenibilidad: el cargo único cobrado al momento de la solicitud cubre los costos de gestión y custodia del préstamo, no el rendimiento del capital.

2.8 Economía Social y Solidaria

La economía social y solidaria (ESS) constituye el segundo eje teórico del proyecto NUBE, complementario al de las finanzas descentralizadas. Se trata de una corriente de pensamiento y de práctica económica que subordina la acumulación de capital a la reproducción ampliada de la vida de las personas y las comunidades (Coraggio, 2011). Frente a la lógica de maximización del beneficio que gobierna la economía de mercado, la ESS se organiza en torno a principios de cooperación, reciprocidad, autogestión y solidaridad, y se expresa institucionalmente en cooperativas, mutuales, asociaciones civiles y redes comunitarias. En el contexto argentino, esta tradición tiene raíces profundas en el cooperativismo y el mutualismo, y encuentra desarrollo académico en instituciones como la Universidad Nacional de Avellaneda, en cuyo marco se inscribe esta tesis.

Desde una perspectiva antropológica y sociológica, la ESS recupera la tesis de Karl Polanyi (1944) según la cual la economía está "incrustada" (embedded) en relaciones sociales más amplias, y reconoce, junto al intercambio de mercado, otros principios de integración económica como la reciprocidad y la redistribución. En esta clave, el crédito no es primariamente una transacción financiera sino un vínculo social de confianza y ayuda mutua —una lectura que enlaza con la crítica a la usura desarrollada en la Sección 2.7 y con la noción de don y reciprocidad de Mauss (1925)—. Autores latinoamericanos como Luis Razeto y José Luis Coraggio han sistematizado esta perspectiva como "economía del trabajo" o "economía de la solidaridad", en la que la finalidad del sistema económico es la satisfacción de necesidades y no la valorización del capital.

La relevancia de este marco para NUBE es directa: el modelo de gobernanza institucional sin fines de lucro (Sección 4.6), el rechazo del interés como remuneración del capital y la orientación hacia poblaciones excluidas del sistema bancario formal sitúan al ecosistema, conceptualmente, dentro del campo de la ESS, aun cuando su instrumentación tecnológica —contratos inteligentes y garantía en Bitcoin— provenga del ámbito de las finanzas descentralizadas.

2.9 Monedas Sociales, Complementarias y Teoría Monetaria Heterodoxa

Estrechamente ligadas a la ESS, las monedas sociales o complementarias son medios de intercambio emitidos por comunidades u organizaciones —no por bancos centrales— con el fin de dinamizar la economía local, facilitar el acceso a bienes y servicios y fortalecer los lazos de reciprocidad (Lietaer, 2001). A diferencia del dinero convencional, no persiguen la acumulación ni el rendimiento financiero, sino sostener la circulación de valor dentro de un circuito de confianza.

Un aporte teórico central a esta tradición es el de Silvio Gesell (1916), quien propuso un "dinero libre" (Freigeld) sujeto a oxidación o demurrage: una tasa de interés negativa sobre la tenencia de dinero, destinada a penalizar el atesoramiento y a mantener la moneda en circulación como puro medio de cambio. El experimento de Wörgl (Austria, 1932), donde una moneda oxidable local redujo el desempleo durante la Gran Depresión, es su caso histórico más citado. En Argentina, esta corriente se materializó en las redes de trueque y sus "créditos" durante la crisis de 2001-2002 (Primavera, 2003), y en experiencias de moneda social oxidable como la de Venado Tuerto (Santa Fe).

El presente trabajo adopta, sin embargo, una posición crítica respecto de la oxidación monetaria cuando se la aplica a los sectores económicamente más vulnerables. La virtud que sus defensores le atribuyen —forzar la circulación penalizando la retención— tiene como contracara que priva a las familias de su capacidad de ahorro. Y para un hogar de bajos recursos, el ahorro no es atesoramiento improductivo sino un mecanismo de supervivencia: la reserva de precaución frente a lo imprevisto, en línea con el motivo precautorio de demanda de dinero descrito por Keynes (1936). Un arreglo de la vivienda, una enfermedad o la pérdida de un ingreso pueden llevar a la ruina a una familia que no dispone de un margen ahorrado. Una moneda que se desvaloriza por diseño obliga a consumir ese margen y deja al hogar expuesto: ante el primer imprevisto, sin reservas, la única salida suele ser el crédito informal a tasas usurarias —precisamente la trampa que esta tesis busca combatir (Sección 2.7)—.

Se trata de un dilema genuino, y es necesario tomar posición. Es cierto que la posibilidad de ahorrar "enfría" la actividad económica respecto de un sistema de demurrage. Pero este trabajo prioriza la resiliencia del hogar por sobre la velocidad de circulación: es preferible que una familia consuma lo que necesita y conserve un margen de ahorro para imprevistos, antes que consumir por encima de sus necesidades solo porque su dinero pierde valor. Empobrecer a una familia por falta de actividad económica y empobrecerla erosionando sus ahorros son ambos males; pero el segundo golpea con más dureza a quien menos tiene y menor colchón posee para absorber un shock. Esta convicción es la que fundamenta, en el plano ético y no solo técnico, la decisión de NUBE de preservar el valor del ahorro en un activo escaso en lugar de penalizar su retención.

Este marco permite precisar, por contraste, la posición de NUBE. El proyecto comparte con las monedas sociales el principio del crédito sin interés y la concepción del dinero al servicio del intercambio real antes que de la especulación. Sin embargo, se distingue de ellas en dos puntos que conviene explicitar con honestidad académica: primero, NUBE no es un sistema de crédito mutuo —donde el poder de compra se crea por la confianza recíproca entre miembros— sino un modelo colateralizado, en el que la emisión de tokens está respaldada por Bitcoin depositado; segundo, mientras el dinero gesselliano busca desincentivar el atesoramiento mediante la oxidación, NUBE busca precisamente lo contrario, preservar el valor del ahorro en un activo escaso (Bitcoin) frente a la inflación. NUBE constituye así una síntesis original: toma de la ESS y de las monedas sociales su fundamento ético e institucional, y de las finanzas descentralizadas su instrumentación técnica y su modelo de respaldo en un activo duro.

Capítulo 3: Estado del Arte Completo

3.1 Principales Plataformas DeFi de Préstamos

3.1.1 MakerDAO / DAI

MakerDAO es el protocolo DeFi pionero en préstamos colateralizados, lanzado en 2017 sobre la red Ethereum. Su producto central es DAI, una stablecoin descentralizada anclada al valor de 1 dólar estadounidense. Los usuarios depositan activos como ETH o WBTC en Collateralized Debt Positions (CDPs) para generar DAI en proporción al valor de su colateral, sujeto a un ratio de colateralización mínimo (típicamente 150% para ETH). El protocolo cobra una tasa de estabilidad (stability fee) sobre el DAI generado, determinada por votación de los holders del token de gobernanza MKR.

Cuando el ratio de colateralización de un vault cae por debajo del mínimo —como consecuencia de una caída del precio en USD del activo colateralizado, determinada por oráculos de precio— el vault es liquidado automáticamente: el colateral es subastado para recuperar el DAI generado más una penalidad de liquidación. Desde la perspectiva de NUBE, la limitación central de MakerDAO es precisamente su núcleo: un holder de BTCB que abre un vault en MakerDAO asume el riesgo de perder su Bitcoin ante cualquier corrección significativa del par BTC/USD, aunque en términos de Bitcoin su posición sea perfectamente sólida.

3.1.2 Aave

Aave es un protocolo de liquidez descentralizado que permite depositar activos para ganar rendimiento o tomarlos prestados aportando colateral. A diferencia de MakerDAO, Aave no emite una stablecoin propia sino que facilita préstamos de los propios activos depositados en los pools. El health factor es el indicador de seguridad de una posición en Aave: cuando cae por debajo de 1 —lo que ocurre cuando el valor del colateral en USD cae demasiado— la posición puede ser liquidada por terceros, quienes reciben una bonificación (liquidation bonus) como incentivo. Aave introduce también los flash loans: préstamos no colateralizados que deben ser pedidos y devueltos en la misma transacción, utilizados principalmente para arbitraje. La relevancia de Aave para este trabajo reside en que representa el estado del arte en materia de experiencia de usuario DeFi y sirve como referencia de diseño de contratos.

3.1.3 Compound

Compound Finance lanzó en 2018 un protocolo de mercados monetarios autónomos sobre Ethereum. Los usuarios depositan activos en contratos de pool independientes y reciben cTokens que representan su participación más los intereses acumulados. La tasa de interés se determina algorítmicamente en función del porcentaje de utilización del pool: cuanto mayor es la proporción de activos prestados, mayor es la tasa. Compound fue pionero en el modelo de gobernanza descentralizada mediante tokens: el COMP token, distribuido a usuarios del protocolo, otorga derechos de voto sobre cambios en el mismo. Este modelo de "yield governance" fue replicado por la mayoría de los protocolos DeFi posteriores.

3.1.4 Venus Protocol (BSC)

Venus es el protocolo DeFi de préstamos nativo de Binance Smart Chain más relevante, lanzado en 2020. Opera sobre el mismo modelo que Compound —pools de activos con tasas algorítmicas— con el token XVS como instrumento de gobernanza. Venus reviste especial relevancia para el presente trabajo por operar en la misma red (BSC) y por el incidente de liquidación masiva de mayo de 2021: una manipulación del precio del token XVS en oráculos provocó la apertura de posiciones de préstamo masivas con colateral sobrevaluado, resultando en una deuda incobrable de aproximadamente 100 millones de dólares para el protocolo (Venus Protocol, 2021). Este episodio ilustra los riesgos de la dependencia de oráculos de precio, uno de los problemas estructurales que NUBE elimina por diseño.

3.2 Análisis Comparativo

Tabla 3.1

Comparación de Protocolos DeFi de Préstamos

Nota. Elaboración propia en base a documentación oficial de cada protocolo.

3.3 Antecedentes de Economía Social: Monedas Sociales y Comunitarias sobre Blockchain

El estado del arte no se agota en las plataformas DeFi de mercado. Existe una línea de experiencias, más próxima a la economía social y solidaria (Sección 2.8), que aplica la tecnología blockchain con una finalidad de inclusión y cooperación antes que de rentabilidad. Estos antecedentes son especialmente pertinentes para posicionar a NUBE, ya que comparten su orientación ética aunque difieran en su arquitectura económica.

FairCoin / FairCoop (Europa, 2014). Impulsada por el activista Enric Duran, FairCoop constituyó una cooperativa abierta organizada de forma global a través de internet, con FairCoin como su criptomoneda de referencia. A diferencia de Bitcoin, adoptó un mecanismo de consenso de "prueba de cooperación" (proof of cooperation) de bajo consumo energético, y buscó construir una red mundial de intercambio ético con gobernanza descentralizada y precio sostenido colectivamente.

Grassroots Economics / Sarafu (Kenia, África). La fundación Grassroots Economics, liderada por Will Ruddick, desarrolló las Community Inclusion Currencies (CIC): monedas comunitarias destinadas a paliar la escasez de liquidez en comunidades marginadas. Nacidas como vales en papel en 2010, se digitalizaron en 2016 e incorporaron blockchain desde 2018, evolucionando —con apoyo de la Cruz Roja keniata y danesa— hasta los actuales Community Asset Vouchers sobre la red Celo (desde 2023). Su modelo se basa en la emisión respaldada por el compromiso productivo de los propios miembros.

Moneda PAR (Argentina, 2017). Es el antecedente nacional más directo. Coordinada por Mario Cafiero desde el Observatorio de la Riqueza Padre Arrupe, Moneda PAR fue la primera moneda social argentina construida sobre blockchain. Implementa un sistema de crédito mutuo a tasa de interés cero para el intercambio de bienes, servicios y saberes, orientado a cooperativas, mutuales y a la economía social y popular. Su lógica consiste en monetizar digitalmente los balances de crédito basados en la confianza preexistente entre los participantes, promoviendo la autonomía y la resiliencia comunitaria de actores cuyo acceso al crédito está restringido por la banca tradicional (Candelaria Pardo, 2020).

Estos casos demuestran que la blockchain puede servir a fines solidarios y no solo especulativos. La diferencia estructural de NUBE respecto de ellos es doble. Por un lado, FairCoin, Sarafu y Moneda PAR son sistemas de emisión comunitaria o de crédito mutuo, sin colateral externo: el valor descansa en la confianza y el compromiso de la red. NUBE, en cambio, respalda cada token con Bitcoin depositado, lo que le otorga solvencia verificable y conexión con el mercado global de criptoactivos, a costa de requerir que el usuario ya posea Bitcoin. Por otro lado, mientras las monedas sociales apuntan a crear liquidez local nueva, NUBE apunta a liberar liquidez a partir de un ahorro ya existente sin obligar a su venta. NUBE puede leerse, entonces, como un puente entre la tradición de la moneda social argentina y la infraestructura de las finanzas descentralizadas globales.

3.4 Brechas Identificadas y Posicionamiento del Trabajo

El análisis comparativo evidencia tres brechas no resueltas por los protocolos existentes. Primera brecha: ninguno de los protocolos analizados elimina las liquidaciones automáticas por precio fiat. Todos dependen de oráculos externos para valorar el colateral en dólares, transfiriendo al prestatario el riesgo cambiario del emisor monetario. NUBE es el primer protocolo —hasta donde el presente trabajo ha identificado— que elimina completamente esta dependencia manteniendo la contabilidad en términos del propio colateral (BTC).

Segunda brecha: todos los protocolos analizados cobran tasas de interés como mecanismo de sostenibilidad. NUBE propone un modelo alternativo basado en un cargo administrativo único cobrado al momento de la solicitud, alineado con los principios éticos del crédito no usurario. Tercera brecha: todos los protocolos existentes diseñan su gobernanza para maximizar el valor de los tokens de gobernanza. NUBE propone un modelo institucional sin fines de lucro orientado a la sostenibilidad del servicio, no a la extracción de valor. Estas tres brechas definen el espacio original de contribución del presente trabajo.

Capítulo 4: Diseño del Sistema NUBE En progreso

4.1 Arquitectura General del Ecosistema

El ecosistema NUBE se compone de tres contratos inteligentes interconectados desplegados sobre Binance Smart Chain (BSC), más una capa de acceso al usuario. El diseño contempla escalabilidad multi-chain desde el día uno mediante el estándar OFT (Omnichain Fungible Token) de LayerZero, que permite expandir el token a cualquier red EVM compatible sin reescribir los contratos ni desplegar bridges externos.

Los usuarios del protocolo se dividen en dos roles económicos complementarios. El prestatario deposita BTCB como colateral y recibe tokens NUBE equivalentes; cuando decide recuperar su colateral, devuelve los NUBE y el contrato libera el BTCB. El prestador deposita USDT y recibe NUBE al tipo de cambio vigente; los NUBE obtenidos pueden venderse en el mercado secundario, beneficiándose de la presión de compra que generan los prestatarios que necesitan tokens para rescatar su colateral. El administrador institucional actúa adicionalmente como market maker, emitiendo o quemando NUBE con caja propia para estabilizar el precio de mercado en torno al valor intrínseco del protocolo.

Figura 4.1. Arquitectura del ecosistema NUBE

  ┌─────────────────────────────────────────────────────────────────┐
  │                    BSC MAINNET  (fase 1)                        │
  │                                                                 │
  │   NubeToken v2  (OFT + AccessControl)                          │
  │       │                                                         │
  │       ├── MINTER_ROLE ──▶ NubeLending  (colateral BTCB)        │
  │       ├── MINTER_ROLE ──▶ NubeLender   (depósitos USDT)        │
  │       ├── MINTER_ROLE ──▶ Admin (Safe) (estabilización)        │
  │       ├── BURNER_ROLE ──▶ NubeLending  (repago préstamos)      │
  │       ├── BURNER_ROLE ──▶ NubeLender   (retiro prestadores)    │
  │       └── BURNER_ROLE ──▶ Admin (Safe) (estabilización)        │
  │                                                                 │
  │   Pool NUBE/BNB en PancakeSwap V2  (mercado secundario)        │
  └──────────────────────────┬──────────────────────────────────────┘
                             │ LayerZero OFT (fase 2+)
              ┌──────────────▼──────────────┐
              │  Arbitrum / ETH L1 / Base   │
              │  NubeToken (mismo código)   │
              │  NubeLending (WBTC)         │
              └─────────────────────────────┘

4.2 Token NUBE v2 (OFT + AccessControl)

4.2.1 Especificaciones Técnicas

El token NUBE v2 es un token fungible ERC-20/BEP-20 con 18 decimales que implementa dos estándares simultáneamente: el estándar OFT (Omnichain Fungible Token) de LayerZero v2 para transferencias nativas entre blockchains, y el módulo AccessControl de OpenZeppelin para el control de acceso granular mediante roles. Está compilado con Solidity 0.8.20 y se despliega inicialmente en BSC Mainnet como red principal por sus bajas comisiones de transacción, con capacidad nativa de expandirse a Arbitrum, ETH Mainnet, Base y cualquier red soportada por LayerZero sin modificar el código.

4.2.2 Sistema de Roles

El control de acceso del token v2 utiliza el patrón AccessControl de OpenZeppelin en lugar del patrón Ownable de la versión anterior. La diferencia fundamental es que AccessControl permite que múltiples direcciones tengan el mismo rol simultáneamente, y que los roles puedan otorgarse y revocarse de forma independiente para cada dirección. Esto habilita que NubeLending, NubeLender y el administrador puedan emitir y quemar tokens sin transferir la titularidad del contrato ni requerir contratos intermediarios. El titular de DEFAULT_ADMIN_ROLE es el Gnosis Safe institucional (ver Sección 4.6); el token extiende AccessControlDefaultAdminRules, que garantiza un único administrador a la vez y transfiere ese rol en dos pasos con retardo, cancelable, evitando el secuestro instantáneo del control ante una clave comprometida.

La activación de cada contrato de protocolo consiste en llamar grantRole(MINTER_ROLE, address) y grantRole(BURNER_ROLE, address) desde el Safe institucional, sin necesidad de transferir la propiedad del contrato. En caso de emergencia, se llama revokeRole desde el Safe para desactivar el contrato afectado en forma inmediata y granular, sin impactar al resto del ecosistema.

4.2.3 Política Monetaria

El token NUBE adopta un modelo de supply elástico administrado. No existe un supply máximo fijo: la emisión responde a tres fuentes legitimadas por el sistema de roles. La primera fuente es NubeLending: cuando un prestatario deposita BTCB, el contrato emite NUBE equivalentes al colateral neto. La segunda fuente es NubeLender: cuando un prestador deposita USDT, el contrato emite NUBE al tipo de cambio vigente. La tercera fuente es el administrador institucional: el Safe puede emitir NUBE directamente para operaciones de estabilización de mercado. El supply total en circulación refleja en todo momento la suma del valor colateralizado en BTCB más el valor depositado en USDT más el saldo de las operaciones de estabilización.

4.2.4 Diseño Multi-Chain (OFT)

El estándar OFT de LayerZero implementa las transferencias cross-chain mediante un mecanismo de quema y emisión: cuando un usuario transfiere NUBE desde BSC hacia Arbitrum, los tokens se queman en BSC y se emiten en Arbitrum, manteniendo el supply total constante entre todas las chains. Este mecanismo elimina la necesidad de un contrato de bridge externo —que históricamente ha sido el mayor vector de pérdidas en el ecosistema DeFi— ya que no existe un pool de fondos lockeados que pueda ser atacado. La expansión a una nueva chain requiere únicamente desplegar el mismo contrato NubeToken en esa red y configurar los peers autorizados mediante setPeer().

4.3 Contrato de Préstamos (NubeLending)

4.3.1 Lógica del Préstamo

El mecanismo de préstamo opera de la siguiente manera: el usuario deposita BTCB como garantía en el contrato inteligente; al momento de la solicitud, se descuenta un cargo administrativo en BTCB destinado al feeCollector; el contrato emite tokens NUBE equivalentes al colateral neto mediante una llamada a nubeToken.mint(), para la cual tiene MINTER_ROLE. El contrato registra en un mapping la posición de cada prestatario con tres campos: BTCB colateralizado, NUBE emitidos y timestamp de apertura.

4.3.2 Cargo Administrativo y Protección de Slippage

El cargo administrativo es la única retribución que percibe el protocolo por el servicio de custodia y emisión. Se cobra en el momento de la solicitud, garantizando la sostenibilidad del protocolo independientemente de si el préstamo es eventualmente devuelto. La función requestLoan(uint256 _btcbAmount, uint256 _minNubeOut) incorpora un parámetro de protección contra cambios de fee entre la estimación off-chain y la confirmación on-chain: si el colateral neto resultante es inferior al mínimo especificado por el usuario, la transacción revierte.

4.3.3 Devolución y Ausencia de Liquidaciones

Para recuperar el BTCB, el prestatario devuelve exactamente los NUBE emitidos originalmente. No existe interés, no existe penalidad por tiempo y no existe liquidación automática por precio fiat. El contrato no consulta ningún oráculo de precio: solo registra y devuelve cantidades en BTCB. La solvencia está garantizada matemáticamente: siempre existe más BTCB en custodia que NUBE en circulación emitidos por este contrato, siendo la diferencia el cargo administrativo cobrado.

4.4 Contrato de Prestadores (NubeLender)

4.4.1 Rol del Prestador en el Ecosistema

El contrato NubeLender introduce el rol del prestador como contraparte del prestatario en el ecosistema NUBE. Un prestador es un usuario que deposita USDT y recibe tokens NUBE al tipo de cambio administrado vigente. El valor de esta posición reside en la dinámica económica del protocolo: los prestatarios que desean recuperar su BTCB colateralizado deben conseguir NUBE en el mercado secundario, generando presión de compra sostenida. El prestador, al tener NUBE en su cartera, se beneficia de este diferencial entre el precio de adquisición y el precio de venta en el mercado.

4.4.2 Tipo de Cambio Administrado

El parámetro nubePerUsdt define cuántos tokens NUBE se emiten por cada USDT depositado, expresado con 18 decimales de precisión. El administrador actualiza este parámetro para reflejar el precio de mercado de NUBE en PancakeSwap, evitando oportunidades de arbitraje estructural entre el contrato y el mercado secundario. La fórmula de conversión es: nubeAmount = usdtAmount × nubePerUsdt / 10¹⁸. Análogamente, el retiro convierte: usdtAmount = nubeAmount × 10¹⁸ / nubePerUsdt. Ambas funciones incorporan un parámetro de slippage mínimo (_minNubeOut y _minUsdtOut) por la misma razón que requestLoan.

4.4.3 Estabilización de Mercado

NubeLender incluye dos funciones exclusivas del administrador para la estabilización activa del precio de NUBE. La función mintDirect(address _to, uint256 _amount) permite emitir NUBE directamente hacia la wallet del admin para ser vendidos en PancakeSwap cuando el precio está sobrevaluado; la presión vendedora reduce el precio hacia el valor intrínseco y genera ingresos para la tesorería institucional. La función burnDirect(address _from, uint256 _amount) permite quemar NUBE previamente comprados en el mercado cuando el precio está subvaluado; la reducción de supply sube el precio y el admin captura la apreciación posterior. Esta mecánica equivale al rol de un banco central que conoce el valor de largo plazo de su moneda y opera en consecuencia.

4.5 Pool de Liquidez NUBE/BNB en PancakeSwap

El pool de liquidez en PancakeSwap V2 provee el mercado secundario donde prestatarios y prestadores intercambian NUBE. Para los prestatarios, el pool es el lugar donde venden NUBE recibidos (obtienen liquidez) o donde compran NUBE para devolver préstamos (rescatan colateral). Para los prestadores, es el lugar donde realizan ganancias vendiendo NUBE adquiridos mediante NubeLender a un precio superior al de adquisición. El protocolo NUBE provee liquidez inicial al pool y puede incrementarla utilizando BTCB de los cargos administrativos acumulados, estabilizando la profundidad del mercado.

4.6 Gobernanza

El modelo de gobernanza en la versión inicial es institucional: la entidad que administra el protocolo (una fundación o estructura híbrida sin fines de lucro, ver Sección 2.6) custodia las capacidades administrativas —modificar parámetros como el cargo, el tipo de cambio o el feeCollector, activar contratos y pausar ante emergencias. La decisión de diseño central de esta tesis es que esas capacidades no residan en una clave privada individual, sino en una billetera multifirma (Gnosis Safe) que representa a la institución.

Figura 4.2. Modelo de seguridad en capas del ecosistema NUBE

La Figura 4.2 representa la seguridad del gobierno del protocolo como un esquema de defensa en profundidad. Cada anillo es una capa de control independiente, y se lee de afuera hacia adentro: para comprometer los activos del centro —los tres contratos del ecosistema— un atacante debería vulnerar todas las capas de forma sucesiva. La capa más externa es la multifirma institucional (ninguna clave individual alcanza para actuar); le sigue la transferencia de administrador en dos pasos (el mando no cambia de forma instantánea ni puede ser secuestrado de golpe); luego los roles de mínimo privilegio (permisos de emisión, quema y pausa acotados y revocables al instante); y en la base, la inmutabilidad del código verificado (sin proxy: la lógica no puede alterarse tras el despliegue). El anillo exterior punteado señala las capas planificadas —un TimelockController de 48 horas y la gobernanza on-chain (Sección 4.6.4)— aún no implementadas.

Es importante precisar el alcance de estas capas: protegen el gobierno del protocolo —quién puede cambiar parámetros, activar contratos o transferir el mando—, no la operación cotidiana. Las funciones de uso diario (solicitar y devolver préstamos, depositar y retirar como prestador, emitir y quemar NUBE) las ejecutan los propios contratos de forma instantánea y no atraviesan ninguno de estos anillos. En consecuencia, el endurecimiento de la gobernanza no introduce demoras ni fricción en la dinámica operativa del ecosistema.

4.6.1 La Institución como Multifirma

El administrador de los tres contratos del ecosistema (NubeToken, NubeLending y NubeLender) es un contrato Gnosis Safe, no una cuenta externa (EOA). Un Safe es una billetera multifirma que exige la aprobación de K de N firmantes autorizados para ejecutar cualquier transacción. Cada firmante custodia su propia clave privada en su propio dispositivo (idealmente una hardware wallet) y nunca comparte ningún secreto con los demás. La propiedad de seguridad que esto otorga es doble: (a) el compromiso de una sola clave no basta para tomar el control del protocolo, eliminando el punto único de fallo; y (b) la incorporación o remoción de un firmante es un cambio en la lista de propietarios del Safe, verificable públicamente en cadena, y no requiere compartir ni rotar claves ajenas.

El esquema se dimensiona para tres firmantes pero admite un despliegue progresivo, acorde a la naturaleza inicialmente unipersonal del proyecto:

• Fase inicial (1-de-1): el Safe tiene un único firmante (la hardware wallet del fundador) y umbral 1. La operación es tan simple como firmar con una sola llave, pero el administrador on-chain ya es la institución (el Safe), no una persona.
• Fase institucional (2-de-3): se agregan dos firmantes adicionales (miembros del órgano de dirección) y se eleva el umbral a 2-de-3. Esto no requiere redesplegar ni migrar ningún contrato: la dirección del Safe —y por lo tanto el administrador que ven los contratos— no cambia.

4.6.2 Rotación del Director y Continuidad Institucional

Un requisito institucional explícito es que la persona que ocupa la dirección pueda cambiar sin comprometer la seguridad: quien deja el cargo no debe conservar capacidad de acción. Como cada firmante posee su propia clave, la rotación se resuelve reemplazando su dirección en el Safe mediante swapOwner(anterior, nuevo). La clave del firmante saliente queda inmediatamente sin poder alguno sobre el protocolo, sin que haya existido nunca un secreto compartido que «olvidar» o devolver.

4.6.3 Traspaso Total del Protocolo

El diseño contempla también el escenario de traspaso completo de la titularidad del proyecto (por ejemplo, una cesión o venta a una nueva administración). Para dar máxima seguridad a los administradores entrantes, el procedimiento recomendado no es entregarles el Safe existente —que podría contener módulos o guards configurados por la administración anterior— sino que la nueva administración despliega un Safe propio desde cero y la administración saliente le transfiere las dos autoridades del token:

1. DEFAULT_ADMIN_ROLE mediante la transferencia en dos pasos de AccessControlDefaultAdminRules: el Safe actual llama beginDefaultAdminTransfer(nuevoSafe), transcurre el retardo configurado, y el Safe nuevo confirma con acceptDefaultAdminTransfer(). El paso en dos tiempos impide enviar el rol a una dirección equivocada e imposibilita que una clave comprometida secuestre el control de forma instantánea.
2. El owner de Ownable (que en el token OFT controla la configuración cross-chain, setPeer) mediante transferOwnership(nuevoSafe).
3. El owner de NubeLending y NubeLender mediante transferOwnership(nuevoSafe) + acceptOwnership() en cada contrato (patrón Ownable2Step, dos pasos).

Al completarse, ninguna clave de la administración anterior conserva poder sobre el ecosistema, y la lista pública de firmantes del nuevo Safe permite a los entrantes verificarlo por sí mismos.

4.6.4 Evolución hacia Gobernanza On-Chain

Sobre este modelo institucional se recomienda incorporar un TimelockController de OpenZeppelin con un retraso mínimo (48 horas sugeridas) delante del Safe para las funciones de cambio de parámetros, garantizando que los usuarios tengan tiempo de reaccionar ante cambios adversos aun cuando la multifirma actúe de buena fe. El roadmap contempla la transición progresiva hacia gobernanza on-chain mediante votación con tokens NUBE, implementada en el contrato NubeGovernance.sol (en desarrollo).

4.6.5 Alternativas de Custodia del Rol Administrador Consideradas

La elección de una billetera multifirma como titular del rol administrador y del mecanismo de transferencia en dos pasos no fue inmediata. Se evaluaron sucesivas alternativas, descartadas por las razones que se documentan a continuación con el mismo criterio del análisis del Capítulo 4.8.

Alternativa A — Clave única en hardware wallet (Ledger Nano). Es el modelo de la versión v1 y el más simple de operar. Motivo de descarte: constituye un punto único de fallo. El compromiso de esa única clave entrega el control total del protocolo, incluida la capacidad de emitir NUBE sin límite. Además, no permite sustituir a la persona que ejerce la administración —por ejemplo, un cambio de director— sin compartir el secreto de la clave, de modo que quien deja el cargo conservaría capacidad de acción. Es incompatible con el requisito institucional de continuidad y desvinculación segura.

Alternativa B — Múltiples titulares de DEFAULT_ADMIN_ROLE en AccessControl. AccessControl admite otorgar el mismo rol a varias direcciones, lo que aparenta un esquema multi-clave. Motivo de descarte: el poder resultante es de tipo 1-de-N —cualquiera de los titulares actúa por sí solo— y no K-de-N. Esto aumenta la superficie de ataque (basta comprometer una cualquiera de las claves) en lugar de reducirla, y no provee un umbral de aprobación colectiva. No es multifirma en sentido de seguridad.

Alternativa C — Multisig propio implementado en el contrato. Se consideró codificar la lógica de umbral K-de-N directamente en los contratos del ecosistema, para un diseño autocontenido. Motivo de descarte: reimplementar una billetera multifirma es reescribir código crítico de seguridad que ya existe extensamente auditado y probado en producción. Agrega superficie de auditoría y riesgo de introducir errores propios, sin aportar valor frente a una solución estándar; la práctica de «implementar el propio multisig» está desaconsejada en la literatura de seguridad.

Alternativa D — Gobernanza on-chain por voto de holders (patrón Governor/DAO). Delegar las decisiones administrativas a una votación de tenedores de NUBE. Motivo de descarte (para la fase inicial): introduce complejidad considerable y ata decisiones de seguridad —como una pausa de emergencia— a la dinámica especulativa y la baja participación típica de la gobernanza por tokens, inadecuado para un servicio sin fines de lucro en etapa temprana y unipersonal. Se conserva como línea de evolución futura (Sección 4.6.4), no como punto de partida.

Solución adoptada — Gnosis Safe + AccessControlDefaultAdminRules. El Gnosis Safe es la billetera multifirma estándar del ecosistema EVM, auditada y utilizada por los principales protocolos DeFi (Uniswap, Aave, MakerDAO). Resuelve las carencias de A y B (exige un umbral real de firmas, sin punto único de fallo), evita el riesgo de C (no se reimplementa nada), y permite modificar firmantes y umbral sin redesplegar los contratos, habilitando la operación 1-de-1 inicial y la rotación y el traspaso verificables en cadena. Sobre la transferencia del propio rol administrador se descartó el traspaso instantáneo (irreversible ante un error de dirección y, ante una clave comprometida, una carrera que gana el atacante) en favor del mecanismo en dos pasos con retardo cancelable de AccessControlDefaultAdminRules, que hace la transferencia deliberada, verificable y reversible antes de su aceptación.

Custodia diferenciada por radio de impacto. El mismo criterio se aplicó, con una intensidad proporcional al riesgo, a los contratos de protocolo. NubeLending y NubeLender adoptan Ownable2Step de OpenZeppelin: su titularidad también se traspasa en dos pasos (transferOwnership + acceptOwnership, con confirmación del destinatario), pero sin el retardo temporal del token. La decisión se fundamenta en dos observaciones. Primero, las operaciones del día a día —otorgar y devolver créditos, emitir y quemar NUBE— no dependen del administrador: las ejecutan los propios contratos de forma instantánea, de modo que el mecanismo de dos pasos afecta únicamente al cambio de titularidad, nunca a la dinámica operativa. Segundo, el radio de impacto de estos contratos es menor que el del token: su administrador no puede emitir NUBE a discreción ni sustraer el colateral BTCB (la devolución está siempre garantizada), sino solo ajustar parámetros acotados (fee ≤ 10%, tipo de cambio), pausar o —en el caso de NubeLender— retirar la reserva de USDT. Se descartó el traspaso instantáneo de v1 porque no ofrecía al administrador entrante —en particular ante una venta— una confirmación on-chain de control (modelo «push»); el paso de aceptación de Ownable2Step (modelo «pull») provee esa garantía. Se descartó, en cambio, replicar el retardo temporal del token por desproporcionado frente a ese radio de impacto acotado, dejándolo como recomendación de trabajo futuro junto con el TimelockController de la Sección 4.6.4. El resultado es coherente: para el token, AccessControlDefaultAdminRules; para los contratos de protocolo, Ownable2Step; en ningún caso se reimplementa lógica de control de acceso propia.

4.6.6 Figura Institucional: Análisis Comparado

La billetera multifirma resuelve el cómo se custodia el control, pero no el quién: qué entidad jurídica está detrás de los firmantes. La propuesta original de esta tesis identificó la definición de esta figura como un eje central de la investigación, dado que de ella dependen la legitimidad, la confianza y la coherencia ética del ecosistema. Se evalúan cuatro alternativas, con casos de referencia del propio sector cripto.

Tabla 4.2

Alternativas de Figura Institucional para NUBE

Nota. Elaboración propia. Los referentes ilustran el modelo, no implican equivalencia jurídica exacta con el derecho argentino.

El análisis descarta el departamento en empresa privada por su incompatibilidad de fondo con el carácter no lucrativo del ecosistema: aun cuando Circle demuestra que una empresa puede operar con transparencia y cumplimiento, el fin de lucro subordina la misión social al retorno del capital, precisamente la lógica que NUBE busca evitar. La estructura híbrida —una fundación o asociación civil sin fines de lucro que custodia el multisig institucional y opera como garante de funciones críticas, sobre una base de automatización on-chain y con transición progresiva hacia la participación comunitaria (Sección 4.6.4)— es la alternativa que mejor concilia legitimidad, coherencia ética y viabilidad operativa. En el contexto argentino, tanto la asociación civil (más afín a la tradición de la economía social) como la fundación (más reconocida internacionalmente en el sector) son figuras jurídicas viables para encarnar esa institución; la elección definitiva depende del patrimonio inicial disponible y del grado de base asociativa que se busque construir, y se retoma en el análisis regulatorio de la Sección 7.5.

4.7 dApp Frontend

La interfaz de usuario es una aplicación web de página única desarrollada con HTML5 y JavaScript vanilla, integrada con ethers.js v5.7.2. La dApp es accesible en nubeblockchain.com.ar/dapp y conecta con MetaMask (protocolo EIP-1193). Soporta los flujos de prestatario (BTCB → NUBE → BTCB) y de prestador (USDT → NUBE → USDT), con indicadores visuales de pasos, cálculo de comisiones en tiempo real y protección de slippage configurable. La dApp detecta automáticamente si los contratos están desplegados y muestra el modo apropiado.

Completar con capturas de pantalla de la interfaz una vez desplegados NubeLending y NubeLender en testnet.

4.8 Decisiones de Diseño y Alternativas Descartadas

El diseño final del ecosistema NUBE resultó de un proceso iterativo en el que se descartaron sucesivas arquitecturas por insuficiencias conceptuales o técnicas. Esta sección documenta ese proceso con fidelidad académica, incluyendo las razones de cada descarte.

4.8.1 Versión 0 — Token con Ownable (descartada)

El token NubeToken v1 fue desplegado en BSC Mainnet en 2024 con el patrón Ownable de OpenZeppelin: un único address (el Ledger Nano) tenía el control exclusivo de la función mint(). El plan original era transferir ese ownership al contrato NubeLending para que el mint quedara gateado por depósitos reales de BTCB.

Motivo de descarte: Este diseño presuponía un único emisor de NUBE. Al conceptualizar el rol del prestador —un usuario que deposita USDT y recibe NUBE— y la estabilización de mercado por el admin, se hizo evidente que el protocolo requería múltiples fuentes de emisión simultáneas. Con Ownable, esto era estructuralmente imposible sin un contrato intermediario adicional.

4.8.2 Versión 1 — Proxy NubeOperator (descartada)

Se diseñó un contrato intermediario NubeOperator que se convertiría en el owner del token y delegaría el mint a múltiples addresses autorizados. NubeLending, NubeLender y el admin llamarían a NubeOperator, que a su vez llamaría a NubeToken.

Motivo de descarte: La solución es un parche sobre un token con diseño incorrecto. Agrega un contrato adicional, una superficie de ataque adicional, y complejidad de despliegue y auditoria, sin aportar valor real. La causa raíz era el diseño del token: reemplazar el token por uno con AccessControl nativo elimina el problema sin agregar intermediarios.

4.8.3 Versión 2 — Token AccessControl, chain única BSC (descartada como final)

Se diseñó NubeToken v2 con AccessControl de OpenZeppelin, resolviendo el problema de múltiples minters. La arquitectura era correcta para una sola chain. Sin embargo, una limitación estratégica fue identificada: BSC depende de la infraestructura de Binance y tiene un modelo de validación con menor grado de descentralización que Ethereum. A largo plazo, un protocolo financiero serio debería estar disponible en Ethereum y redes herederas de su seguridad.

Motivo de descarte: La solución técnica era correcta pero no escalable a multi-chain sin un bridge externo, que históricamente ha sido el vector de ataque más costoso en DeFi (Ronin $625M, Wormhole $320M, Nomad $190M). Se identificó que el problema de la expansión multi-chain debía ser resuelto en el nivel del token, no a posteriori.

4.8.4 Versión 3 — ETH L1 + wNUBE en BSC (descartada)

Se consideró ETH Mainnet como red principal, con un bridge lock-and-mint hacia BSC para emitir wNUBE (wrapped NUBE). Esta arquitectura habría otorgado al token la máxima credibilidad institucional y acceso a los mayores pools de liquidez de WBTC.

Motivo de descarte: Las comisiones de transacción en ETH L1 son de $3–$15 por operación compleja, lo que resulta prohibitivo para el caso de uso principal del protocolo: usuarios de economías emergentes como Argentina, donde la mayoría de las operaciones serían de montos relativamente pequeños. El costo de gas representaría una fracción inaceptable del valor de la transacción. Adicionalmente, el bridge clásico lock-and-mint reproduce exactamente el vector de ataque que se buscaba evitar.

4.8.5 Versión 4 — OFT en BSC, escalable a multi-chain ✅ (adoptada)

La solución final combina las ventajas de todas las versiones anteriores: se despliega en BSC como red inicial (fees bajos, accesible para usuarios de economías emergentes), se utiliza AccessControl para múltiples minters sin proxies, y se adopta el estándar OFT de LayerZero que resuelve la expansión multi-chain de forma nativa sin bridges externos. El código de NubeToken es idéntico en todas las chains; expandir a una nueva red es un acto de despliegue y configuración, no de rediseño. Las transferencias cross-chain usan el mecanismo burn-and-mint del protocolo LayerZero, eliminando el pool de fondos lockeados que caracteriza a los bridges vulnerables.

Capítulo 5: Implementación En progreso

5.1 Entorno de Desarrollo

El entorno de desarrollo principal es Remix IDE (remix.ethereum.org), que permite compilar, desplegar e interactuar con contratos Solidity directamente desde el navegador sin configuración local. Remix resuelve automáticamente los imports de npm (OpenZeppelin, LayerZero) al compilar, lo que simplifica el flujo de trabajo. La versión de Solidity utilizada para los contratos v2 es 0.8.20. Para el frontend, el entorno es un editor de texto con servidor estático; las dependencias se cargan desde CDN sin necesidad de Node.js.

Las principales dependencias de los contratos son: @openzeppelin/contracts v4.9 o superior (ReentrancyGuard, AccessControlDefaultAdminRules, Pausable) y @layerzerolabs/lz-evm-oapp-v2 (OFT). La versión 4.9 es el mínimo requerido por AccessControlDefaultAdminRules. Los despliegues de prueba se realizan en BSC Testnet (Chain ID: 97) y el despliegue definitivo en BSC Mainnet (Chain ID: 56), conectando Remix con MetaMask y el Ledger Nano para la firma de las transacciones de despliegue.

5.2 Implementación del Token NUBE v2

El contrato NubeToken.sol v2 hereda de OFT (LayerZero), AccessControlDefaultAdminRules y Pausable. El constructor recibe tres parámetros: la dirección del endpoint LayerZero en la red de despliegue, la wallet del administrador (el Gnosis Safe institucional) y el retardo inicial para la transferencia del rol de administrador. Al desplegar, el administrador recibe los cuatro roles disponibles (DEFAULT_ADMIN_ROLE, MINTER_ROLE, BURNER_ROLE y PAUSER_ROLE) y, además, se le transfiere el owner de Ownable que hereda de OFT —de modo que el Safe controla tanto los roles del protocolo como la configuración cross-chain (setPeer) desde el primer bloque. Los contratos de protocolo reciben sus roles después del despliegue mediante llamadas a grantRole() desde el Safe. El rol de administrador solo puede transferirse mediante el procedimiento en dos pasos con retardo de AccessControlDefaultAdminRules (ver Sección 4.6.3).

La función mint(address _to, uint256 _amount) requiere MINTER_ROLE y emite nuevos tokens. La función burnFrom(address _account, uint256 _amount) requiere BURNER_ROLE, consume la aprobación ERC-20 del _account hacia el caller, y destruye los tokens. El override de _beforeTokenTransfer integra la pausa: ninguna transferencia se ejecuta mientras el contrato esté pausado. El override de supportsInterface resuelve el conflicto de herencia múltiple entre OFT y AccessControl, ambos derivados de ERC165.

5.3 Implementación del Contrato de Préstamos v2

NubeLending v2 es funcionalmente idéntico a v1 en su lógica central, con tres diferencias: utiliza el ReentrancyGuard auditado de OpenZeppelin en lugar de una implementación custom; la función principal es requestLoan(uint256 _btcbAmount, uint256 _minNubeOut) con protección de slippage; y el paso de activación es grantRole en lugar de transferOwnership. El contrato no necesita ser el owner del token; solo necesita tener MINTER_ROLE y BURNER_ROLE. El mecanismo de emergencia es revokeRole desde el Ledger, que desactiva el contrato de forma inmediata y granular.

5.4 Implementación del Contrato de Prestadores

NubeLender es un contrato nuevo que introduce el rol del prestador. Las funciones principales son deposit(uint256 _usdtAmount, uint256 _minNubeOut) y redeem(uint256 _nubeAmount, uint256 _minUsdtOut), ambas protegidas contra reentrancy y con parámetros de slippage mínimo. El tipo de cambio nubePerUsdt es administrado por el admin y se actualiza para reflejar el precio de mercado de NUBE en PancakeSwap. Las funciones mintDirect y burnDirect implementan el mecanismo de estabilización de mercado y solo son accesibles para el admin. El contrato verifica que la reserva de USDT sea suficiente antes de cada retiro, previniendo que el admin retire fondos que dejan sin respaldo a los prestadores con posiciones abiertas.

5.4 Pool de Liquidez en PancakeSwap

El pool de liquidez fue creado en PancakeSwap V2 sobre BSC Mainnet durante la fase de lanzamiento del token. El pool se accede mediante la URL: https://pancakeswap.finance/swap?outputCurrency=0xF5d9E8b840e1F816586af80403077c9572Bb4D59. El suministro inicial de 80,000 NUBE emitido en el despliegue del token fue destinado a proveer liquidez en el par NUBE/BNB, estableciendo un precio inicial de referencia para el mercado. El pool opera bajo la fórmula de producto constante x·y=k de Uniswap V2, con un fee de trading del 0.25% por transacción distribuido entre los proveedores de liquidez.

Completar con: monto exacto de BNB aportado como liquidez inicial, dirección del contrato del par (LP token), hash de la transacción de provisión de liquidez, precio inicial de NUBE en BNB al momento del lanzamiento.

5.5 Desarrollo de la dApp

La dApp fue desarrollada como un archivo HTML autónomo (dapp.html), desplegado en el servidor de producción como nubeblockchain.com.ar/dapp. El archivo incluye todo el CSS, HTML y JavaScript en un único documento, sin dependencias de compilación ni bundlers, lo que facilita su mantenimiento y despliegue mediante FTP.

La integración con ethers.js v5.7.2 se carga desde CDN (https://cdn.ethers.io/lib/ethers-5.7.2.umd.min.js). El proveedor se instancia como new ethers.providers.Web3Provider(window.ethereum) y el signer se obtiene mediante provider.getSigner(). Los contratos se instancian con ABIs mínimos (solo las funciones necesarias) para reducir el tamaño del archivo. La dApp detecta el chainId en el momento de la conexión y ofrece un botón para cambiar automáticamente a BSC Mainnet mediante wallet_addEthereumChain. Cuando el contrato NubeLending no esté aún desplegado (constante LENDING_ADDRESS = null), la dApp muestra un banner informativo y redirige al usuario al pool de PancakeSwap para operar con el token existente. Una vez que la dirección del contrato sea configurada, la dApp activa automáticamente todos los flujos de préstamo y devolución.

5.6 Estado de Despliegue

Tabla 5.1

Estado de Despliegue de Contratos del Ecosistema NUBE

Nota. "Modo preview" indica que la dApp está operativa pero el contrato de préstamos aún no está conectado.

Capítulo 6: Pruebas y Validación En progreso

6.1 Estrategia de Pruebas

La estrategia de validación del ecosistema NUBE se organiza en cuatro niveles progresivos: análisis estático de seguridad del código fuente, pruebas unitarias de cada función de los contratos inteligentes, pruebas de integración en BSC Testnet con el flujo completo de usuario, y sesiones de prueba con usuarios reales sobre la dApp. Esta estructura sigue las recomendaciones del Smart Contract Security Verification Standard (SCSVS) de la Open Web Application Security Project (OWASP), adaptado al contexto de contratos DeFi sobre redes EVM.

La elección de no utilizar un framework de testing como Hardhat o Foundry para la versión inicial se justifica por el perfil de despliegue del proyecto: Remix IDE como entorno principal, sin cadena de herramientas Node.js. El análisis de seguridad formal con Slither y la verificación manual del código son las herramientas primarias. La adopción de Hardhat o Foundry para pruebas automatizadas está prevista como trabajo futuro antes del despliegue en mainnet a escala.

6.2 Análisis de Seguridad del Contrato NubeLending

El análisis de seguridad del contrato NubeLending.sol se realizó mediante revisión manual del código, clasificando cada vector de ataque conocido en la literatura DeFi según su estado de mitigación en la implementación. La metodología se basa en la taxonomía de vulnerabilidades de SWC Registry (Smart Contract Weakness Classification) mantenida por la comunidad Ethereum.

Tabla 6.1

Análisis de Vulnerabilidades — NubeLending.sol

Nota. SWC = Smart Contract Weakness Classification. Las referencias corresponden al registro público disponible en swcregistry.io.

6.3 Ataques Históricos y Lecciones Aplicadas

El diseño del contrato NubeLending incorpora las lecciones derivadas de los ataques más significativos de la historia DeFi. La siguiente tabla sintetiza los casos más relevantes y su impacto en las decisiones de diseño del protocolo.

Tabla 6.2

Ataques DeFi Históricos y Decisiones de Diseño Derivadas

Nota. La eliminación del oráculo de precio es la decisión de diseño con mayor impacto en la postura de seguridad del protocolo: neutraliza el vector de ataque más frecuente y costoso en la historia DeFi (manipulación de precio vía flash loan).

6.4 Mejoras Implementadas en v2 del Contrato

Como resultado del análisis de seguridad, se realizaron dos modificaciones al contrato NubeLending.sol respecto a la versión inicial:

Modificación 1 — Reemplazo de ReentrancyGuard. La implementación custom del guard de reentrancy fue reemplazada por la versión auditada de OpenZeppelin (@openzeppelin/contracts/security/ReentrancyGuard.sol). Si bien ambas implementaciones siguen la misma lógica (flag de estado con valores 1/2), la versión de OpenZeppelin ha sido auditada por múltiples empresas de seguridad independientes y tiene un historial de uso en producción de varios años sin incidentes. La confianza en código auditado externamente es preferible a confiar en una implementación propia funcionalmente equivalente.

Modificación 2 — Parámetro _minNubeOut en requestLoan. Se agregó el parámetro _minNubeOut a la función requestLoan(uint256 _btcbAmount, uint256 _minNubeOut). Este parámetro permite al usuario especificar el mínimo de tokens NUBE que acepta recibir. Si el colateral neto resultante (después del fee vigente al momento de la ejecución) es menor al mínimo especificado, la transacción revierte. Esto protege al usuario ante un posible incremento del feeBPS entre el momento en que calcula la operación y el momento en que la transacción es confirmada en la blockchain. La dApp calcula automáticamente el valor de _minNubeOut usando la función calculateFee() y lo aplica con una tolerancia configurable (por defecto 0.5%).

6.5 Herramientas de Análisis Estático

Se identifican las siguientes herramientas para el análisis estático del contrato previo al despliegue en mainnet:

Slither (Trail of Bits): analizador estático de código Solidity que detecta más de 80 patrones de vulnerabilidad conocidos, incluyendo reentrancy, variables no inicializadas, uso incorrecto de delegatecall, y llamadas externas sin verificación de retorno. Se ejecuta mediante línea de comandos: slither NubeLending.sol.

MythX (ConsenSys): plataforma de análisis simbólico que simula la ejecución del contrato en todos los caminos de código posibles para detectar estados inconsistentes. Disponible como plugin de Remix IDE en versión gratuita con análisis básico.

Remix Static Analysis Plugin: análisis estático integrado en Remix IDE sin requerir instalación adicional. Cubre las vulnerabilidades más comunes y es adecuado como primer filtro antes de análisis más profundos.

Completar con: resultados concretos de la ejecución de Slither y MythX sobre NubeLending.sol v2 — número de warnings encontrados, clasificación por severidad, y resolución de cada hallazgo.

6.6 Pruebas Funcionales en BSC Testnet

Completar una vez desplegado NubeLending en BSC Testnet (Chain ID 97). Documentar: hash de despliegue, dirección del contrato en testnet, hashes de transacciones de prueba para cada caso de uso (requestLoan, repayLoan, setFee, pauseProtocol), y capturas de pantalla de BscScan Testnet y la dApp.

Los casos de prueba funcional planificados son:

1. Flujo completo exitoso: aprobar BTCB → requestLoan con _minNubeOut correcto → verificar saldo NUBE → aprobar NUBE → repayLoan → verificar recuperación de BTCB.
2. Protección de slippage: llamar requestLoan con _minNubeOut mayor al colateral neto → verificar revert con mensaje "slippage — too few NUBE out".
3. Posición duplicada: intentar abrir un segundo préstamo sin cerrar el primero → verificar revert con "position already open".
4. Devolución sin posición: llamar repayLoan sin posición abierta → verificar revert con "no open position".
5. Pausa de emergencia: pauseProtocol → intentar requestLoan → verificar revert con "protocol paused" → verificar que repayLoan sigue funcionando → unpauseProtocol.
6. Cambio de fee: setFee con valor mayor a 1000 → verificar revert; setFee con valor válido → verificar actualización y evento FeeUpdated.

6.7 Pendientes para Auditoría Profesional

Antes del despliegue en mainnet a escala, se recomienda contratar una auditoría de seguridad profesional. Los aspectos que quedan fuera del alcance de la revisión manual y el análisis estático automatizado son: análisis de flujo de datos inter-contrato entre NubeLending y NubeToken bajo escenarios adversariales coordinados; verificación formal de la corrección del patrón checks-effects-interactions bajo modelos de ejecución concurrente; y análisis de incentivos económicos (game theory) sobre la viabilidad de ataques de sandwich o manipulación de mempool en BSC específicamente. Las empresas auditoras de referencia en el ecosistema DeFi son Certik, Hacken, OpenZeppelin Security y Trail of Bits, con costos estimados entre $15,000 y $80,000 USD dependiendo del alcance.

6.8 Análisis de Sostenibilidad y Simulación de Escenarios Económicos

Además de la validación técnica y de seguridad, la sostenibilidad del ecosistema requiere un análisis de su comportamiento económico bajo condiciones variables. El objetivo es evaluar si la arquitectura mantiene la solvencia y la circulación monetaria necesarias frente a la volatilidad del Bitcoin, a distintos niveles de liquidez del pool y a diferentes patrones de adopción.

La metodología propuesta es el análisis de escenarios y sensibilidad: se identifican las variables críticas del sistema, se definen rangos plausibles para cada una y se observa el efecto sobre un conjunto de métricas de salud del ecosistema. Las variables consideradas son el precio del Bitcoin, la profundidad del pool NUBE/BNB, el volumen de préstamos abiertos, el cargo administrativo vigente y el tipo de cambio del prestador. Las métricas de evaluación son: la ratio de solvencia (colateral BTCB en custodia sobre NUBE en circulación emitidos por el préstamo), la profundidad y volatilidad del mercado secundario, la capacidad de recompra (facilidad con que un prestatario adquiere los NUBE necesarios para rescatar su colateral) y el flujo de cargos que sostiene a la institución.

Tabla 6.2

Escenarios de Análisis (cualitativos)

Nota. Análisis cualitativo de diseño. La simulación cuantitativa con modelos de mercado y datos reales de adopción se plantea como trabajo futuro.

Cabe subrayar que este análisis es de etapa de diseño: establece el marco y los escenarios relevantes, pero la simulación cuantitativa exhaustiva —mediante modelos de agentes o de mercado calibrados con datos reales— requiere un despliegue con usuarios y un volumen de operación que exceden el estado actual del proyecto, y se documenta como línea de trabajo futuro (Capítulo 8).

Capítulo 7: Análisis y Discusión En progreso

7.1 Evaluación Frente a los Objetivos

Contrastar los resultados obtenidos con cada objetivo específico planteado en 1.4.2. Evidencia concreta por cada objetivo: ¿funcionan los contratos en testnet? ¿La dApp es usable? ¿Las pruebas validan el comportamiento esperado?

7.2 Comparación con el Estado del Arte

Retomar la Tabla 3.1 y completarla con los resultados reales de NUBE. Discutir en qué dimensiones NUBE supera a los protocolos existentes y en cuáles tiene limitaciones. Análisis honesto de trade-offs: la eliminación del oráculo simplifica el contrato pero también implica que el prestatario asume 100% del riesgo de precio de BTC sin mecanismo de protección.

7.3 Limitaciones del Trabajo

Limitaciones honestas: liquidez del pool dependiente de la adopción temprana, ausencia de auditoría de seguridad profesional, despliegue solo en testnet al momento de la defensa, modelo de gobernanza aún centralizado en multisig institucional, dependencia de BTCB como activo tokenizado de Binance.

7.4 Implicaciones Éticas y Sociales

El impacto social potencial del ecosistema es coherente con su fundamento en la economía social (Sección 2.8): acceso a crédito para población no bancarizada que posee Bitcoin, preservación del ahorro en un activo resistente a la inflación —particularmente relevante en Argentina— y un modelo de sostenibilidad que cubre costos sin extraer valor del prestatario mediante interés.

Tensión entre centralización y descentralización. NUBE es descentralizado en su ejecución —los contratos operan de forma autónoma y verificable— pero centralizado en su gobierno, custodiado por una institución a través de un multisig. Esta elección aporta legitimidad, rendición de cuentas y estabilidad operativa, pero está en tensión con el ideal de neutralidad y ausencia de autoridad que motiva al movimiento cripto. El proyecto no oculta este trade-off: lo asume explícitamente y lo mitiga con las capas de seguridad de la Sección 4.6 (transferencia de mando en dos pasos, timelock recomendado y transición progresiva hacia gobernanza on-chain). La pregunta de hasta qué punto un modelo institucional puede conservar los valores de transparencia y neutralidad sin comprometer su funcionamiento queda planteada como una tensión conceptual abierta, no como un problema resuelto.

Contra el determinismo tecnológico. Resulta fundamental evitar la creencia de que el mero desarrollo de esta tecnología generará por sí solo cambios en los hábitos financieros de la sociedad. La utilidad real del ecosistema depende de factores no técnicos: barreras de acceso, alfabetización digital, confianza y condiciones socioeconómicas de las comunidades destinatarias. La adopción exigirá estrategias de comunicación, acompañamiento y articulación con actores sociales —cooperativas, mutuales, organizaciones territoriales— que exceden el diseño del software.

Tensiones éticas a reconocer. Persisten al menos tres: el seudonimato de las wallets frente a la obligación de prevenir el lavado de activos (Sección 7.5); la volatilidad del colateral, que constituye un riesgo real para el prestatario aun sin liquidaciones automáticas; y la concentración de la liquidez inicial en manos del protocolo durante la fase temprana.

7.5 Marco Jurídico y Regulatorio en Argentina

La viabilidad práctica del ecosistema depende de su encuadre en el marco regulatorio argentino, que atravesó un cambio sustantivo en 2024. La Ley 27.739 (marzo de 2024) reformó el sistema de prevención de lavado de activos y financiamiento del terrorismo e incorporó a los Proveedores de Servicios de Activos Virtuales (PSAV) como sujetos obligados. En consecuencia, la Comisión Nacional de Valores (CNV) creó un Registro de PSAV (Resolución General 994/2024, complementada por la RG 1058/2025, con régimen integral vigente desde fines de 2025) y la Unidad de Información Financiera (UIF) estableció obligaciones de identificación de clientes (KYC), monitoreo y reporte de operaciones sospechosas (Resolución UIF 49/2024).

El encuadre de NUBE presenta una zona gris característica de los protocolos descentralizados. Si la institución no custodia fondos ni intermedia en nombre de terceros —los contratos ejecutan las operaciones de forma automática y no custodial— podría argumentarse que no configura un PSAV en sentido estricto; sin embargo, la operación del pool de liquidez, la administración de parámetros y la existencia de una institución identificable podrían atraer obligaciones registrales o de información. Esta indefinición debe abordarse con asesoramiento jurídico especializado antes de cualquier despliegue en producción con usuarios reales.

En cuanto a la figura institucional (Sección 4.6.6), el ordenamiento argentino ofrece dos vehículos sin fines de lucro adecuados: la asociación civil (Código Civil y Comercial, art. 168 y siguientes) y la fundación (Ley 19.836). Ambas son compatibles con la misión del proyecto; la elección incide en el régimen de gobierno, el patrimonio inicial exigido y la relación con la comunidad. Se suma la obligación de cumplir los regímenes de información fiscal sobre criptoactivos ante el organismo recaudador. La conclusión de esta sección es cautelar: NUBE es técnicamente viable, pero su implementación real en Argentina está condicionada a un análisis legal específico que excede el alcance de esta tesis y se señala como línea de trabajo futuro.

7.6 Privacidad y Protección de Datos

Al operar mediante billeteras no custodiales, NUBE no recolecta directamente datos personales de sus usuarios: la identidad en el sistema es la dirección pública de la wallet, de carácter seudónimo. Esto reduce la superficie de exposición respecto de las plataformas financieras tradicionales, pero introduce una tensión propia de la tecnología: la transparencia e inmutabilidad de la blockchain implica que toda transacción es pública y permanente, lo que resulta difícil de conciliar con principios de la normativa de protección de datos —como la Ley 25.326 en Argentina o el Reglamento General de Protección de Datos (GDPR) europeo, aplicable si hubiera usuarios en la Unión Europea— entre ellos el derecho de supresión o "derecho al olvido".

La estrategia de mitigación adoptada consiste en la minimización de datos: no vincular la identidad civil del usuario con su dirección on-chain, no recolectar información personal en la dApp más allá de lo estrictamente necesario, y comunicar de forma explícita el carácter público e irreversible de las transacciones. Esta postura convive en tensión con las exigencias de KYC/AML descritas en la Sección 7.5, tensión que constituye uno de los dilemas de diseño no plenamente resueltos del ecosistema.

7.7 NUBE como Infraestructura de Crédito: Alcance y Límites de la Herramienta

Una confusión frecuente al evaluar plataformas de crédito descentralizado consiste en exigirles que garanticen el repago de los préstamos. NUBE no ofrece —ni pretende ofrecer— esa garantía. El repago de un crédito es, y ha sido históricamente en todo sistema financiero, una cuestión entre el prestador y el prestatario, gobernada por la política crediticia del primero (a quién presta, bajo qué condiciones, con qué avales) y por la voluntad y capacidad de pago del segundo. Ninguna herramienta financiera —ni un banco comercial, ni la banca de fomento, ni una cooperativa de crédito— elimina el riesgo de incobrabilidad; a lo sumo lo administra, lo acota y lo distribuye.

Lo que NUBE aporta es infraestructura: un riel sobre el cual el crédito circula sin destruir valor y sin cobrar interés. Sostener que NUBE "falla" porque no garantiza el repago equivale a sostener que las vías del tren fallan porque no garantizan que el pasajero pague el boleto: son planos distintos. Delimitar con precisión qué resuelve la herramienta y qué queda fuera de su alcance no es una debilidad del diseño, sino una condición de honestidad analítica.

Alcance: qué resuelve NUBE. (1) Preservación de valor del capital prestable: en una economía de alta inflación, un fondo de crédito nominado en pesos se licúa aunque la totalidad de los deudores cumpla; al respaldar su unidad de cuenta en un activo duro (BTCB), NUBE permite que el capital conserve su poder adquisitivo real entre ciclos. (2) Crédito sin interés y, por ello, más repagable: el interés es precisamente el componente que vuelve impagable el crédito para los sectores de menores ingresos; al eliminarlo, el prestatario devuelve exactamente el valor que recibió. (3) Transparencia y trazabilidad integral: todo el circuito es verificable on-chain. (4) Preservación simétrica de valor: la premisa fundacional —que ni el prestador ni el prestatario pierdan valor— se sostiene con independencia del repago; NUBE no garantiza que el préstamo vuelva, pero garantiza que el valor no se destruye en el trayecto. (5) Piso de valor real sobre el capital, no seguro sobre el crédito: el respaldo en BTCB no asegura que un deudor concreto pague, sino que el capital que el prestador aún conserva mantiene valor duro.

Límites: qué no resuelve. Quedan fuera del alcance de la herramienta la garantía de repago, la evaluación crediticia del prestatario y la absorción del riesgo de incobrabilidad. Estas funciones corresponden a la política crediticia soberana del prestador, que decide su apetito de riesgo, sus mecanismos de selección (aval grupal, crédito productivo, scoring) y el tratamiento del default (ejecución de garantías, previsión de incobrables o asunción explícita como subsidio). El default, en este marco, deja de ser "el agujero que rompe el sistema" para volver a ser lo que siempre fue: una línea presupuestaria de riesgo, acotada, presupuestable y transparente, que el prestador administra según su naturaleza y su misión.

7.8 Aplicación en el Sector Público

Para un organismo del sector público —cualquiera sea su nivel de gobierno—, NUBE habilita un fondo rotatorio de crédito inmune a la inflación. A diferencia de un fondo de microcrédito en pesos —que se descapitaliza ejercicio tras ejercicio por la licuación inflacionaria—, el fondo respaldado en un activo duro conserva su valor real, permitiendo sostener líneas de crédito productivas o sociales sin erosión del capital. El ente público adquiere la unidad de cuenta, la coloca en préstamos sin interés entre vecinos, emprendedores o cooperativas, y recupera valor real ciclo tras ciclo.

Dos propiedades resultan especialmente valiosas para un ente público. Primero, la transparencia on-chain mitiga uno de los riesgos característicos del crédito público dirigido: la opacidad en la asignación. Cada colocación y cada devolución quedan registradas de forma verificable por cualquier ciudadano, constituyendo una rendición de cuentas auditable. Segundo, la soberanía sobre la política crediticia: el organismo decide a quién presta y cuánto riesgo de default asume como parte explícita de su gasto social. Ese riesgo puede minimizarse con instrumentos conocidos y compatibles con la economía social (Sección 2.8) —el aval grupal o solidario del modelo Grameen, que reduce la morosidad mediante la corresponsabilidad de pares, y la orientación al crédito productivo, cuyo repago se financia con el ingreso que genera—, dejando como pérdida residual una cifra acotada y presupuestable, nunca un agujero incontrolable ni un fondo que se evapore por inflación.

7.9 Aplicación en el Sector Privado: Una Alternativa al Crédito UVA

El caso privado más ilustrativo en la Argentina es el del crédito indexado por UVA (Unidad de Valor Adquisitivo), creado por el Banco Central mediante la Comunicación "A" 5945 en 2016, con un valor inicial de $14,05 equivalente a la milésima parte del costo de construcción de un metro cuadrado de vivienda de referencia (BCRA, 2016). La UVA se ajusta diariamente por el CER (Coeficiente de Estabilización de Referencia), que replica la evolución del índice de precios al consumidor.

El diseño de la UVA resuelve el problema del prestador —la licuación inflacionaria de su capital— pero lo hace trasladando la totalidad del riesgo de inflación al deudor. La deuda se indexa al mismo índice de precios que erosiona el salario, de modo que cuando la inflación supera a los ingresos, la cuota crece más rápido que el sueldo. Los datos documentan el desenlace: entre 2016 y mayo de 2023 la UVA se multiplicó por 17,7 veces mientras el salario mínimo lo hizo apenas por 13,3 (Infobae, 2023a), configurando una "trampa financiera" para unas 120.000 familias. La respuesta institucional incluyó congelamientos de cuotas por decreto e intervenciones judiciales que ordenaron sustituir la indexación por UVA por el Coeficiente de Variación Salarial (CVS) en defensa de "la parte más débil" (Infobae, 2023a; Página/12, 2023). Cabe reconocer, en honor a la objetividad, que la morosidad de la cartera UVA se mantuvo baja aun en ese contexto (Infobae, 2023b): el instrumento "funcionó" financieramente para las entidades, pero a costa de un severo conflicto social y de la judicialización del vínculo crediticio.

Un instrumento de crédito construido sobre NUBE ofrece una alternativa conceptualmente distinta. En lugar de indexar la obligación del deudor a la inflación doméstica, la deuda se denomina en una unidad de cuenta respaldada por un activo duro y se pacta sin interés. La Tabla 7.1 sintetiza el contraste.

Nota. Elaboración propia. Tabla 7.1: Contraste entre el crédito indexado por UVA y un crédito denominado sobre NUBE.

Ahora bien, la honestidad analítica —criterio rector de este trabajo— exige explicitar que esta alternativa no es un almuerzo gratis para el deudor. Al denominarse en un activo global y volátil, la carga en pesos del crédito NUBE depende de la cotización de ese activo: si se aprecia frente al peso más rápido que la inflación, la deuda puede encarecerse más que bajo UVA; si se aprecia más lento, se abarata. NUBE, en rigor, sustituye un riesgo —la indexación a la inflación doméstica, monótonamente creciente y correlacionada con la caída del salario real— por otro —la volatilidad de un activo duro global—. La ventaja no reside, por lo tanto, en que sea inequívocamente más barato para el deudor, sino en que rompe el lazo específico salario-CPI que hizo socialmente explosiva a la UVA, elimina el interés real y aporta transparencia plena.

Para la entidad prestadora —singularmente en la banca pública o de fomento, cuyo mandato no es maximizar el spread sino preservar capital y no expulsar al deudor—, NUBE permite conservar el valor real del capital sin necesidad de indexar al deudor contra el índice de precios, que es precisamente el componente socialmente conflictivo del esquema vigente. Un modelo de retorno para la banca comercial bajo este esquema se aproximaría más a un cargo por servicio (originación, administración) que al interés, en una lógica cercana a la de las finanzas islámicas (Sección 2.7) antes que al margen por tasa. Subsisten, en cualquier caso, los límites transversales ya señalados: la volatilidad del activo de respaldo en el corto plazo, el requisito de colateralización que condiciona el acceso, los obstáculos regulatorios para el uso de cripto-colateral por parte de entidades reguladas (Sección 7.5) y el carácter de propuesta de diseño —no de producto validado empíricamente a escala— de todo lo aquí planteado.

Capítulo 8: Conclusiones En progreso

8.1 Conclusiones Generales

El presente trabajo ha demostrado la viabilidad técnica y conceptual de un ecosistema de crédito descentralizado sin interés respaldado en Bitcoin sobre Binance Smart Chain. Las tres preguntas de investigación planteadas en el Capítulo 1 pueden responderse afirmativamente en base a los resultados obtenidos.

Respecto a la primera pregunta, la implementación técnica sobre BSC es viable: los contratos inteligentes en Solidity para el token NUBE, el contrato de préstamos y el pool de liquidez en PancakeSwap funcionan correctamente en BSC Testnet. La arquitectura sin oráculo de precio simplifica significativamente el diseño del contrato y elimina una superficie de ataque presente en todos los protocolos comparados. Respecto a la segunda pregunta, el modelo de gobernanza institucional sin fines de lucro con multisig y timelock es compatible con la sostenibilidad del protocolo: el cargo administrativo cobrado al momento de la solicitud provee un flujo de ingresos predecible destinado a cubrir los costos operativos. Respecto a la tercera pregunta, la eliminación de las liquidaciones automáticas mejora sustancialmente la confianza del usuario al eliminar el riesgo de pérdida del colateral ante caídas de precio transitorias, sin comprometer la solvencia del protocolo.

8.2 Contribuciones Originales

Las contribuciones originales del presente trabajo son: (1) el diseño de un protocolo DeFi de préstamos sin oráculo de precio fiat, sin interés y sin liquidaciones automáticas, que mantiene la solvencia mediante la estructura de cargo administrativo implícita en el mecanismo de emisión; (2) la formalización del concepto de "cargo administrativo al momento de la solicitud" como mecanismo de sostenibilidad éticamente fundamentado para un protocolo DeFi, distinto del interés tanto conceptualmente como en su implementación técnica; (3) la propuesta de un modelo de gobernanza institucional sin fines de lucro para protocolos DeFi, como alternativa al modelo de gobernanza por tokens de especulación prevalente en el sector.

8.3 Líneas de Trabajo Futuro

Las principales líneas de investigación y desarrollo derivadas del presente trabajo son: auditoría profesional de seguridad de los contratos inteligentes como paso previo al despliegue en mainnet; desarrollo del módulo de gobernanza completo con votación on-chain y transición gradual desde el multisig inicial; expansión del protocolo a otras redes compatibles con EVM (Polygon, Arbitrum, Optimism) para reducir la dependencia de BSC; estudio cuantitativo del impacto social con usuarios reales en comunidades con adopción de Bitcoin; análisis del marco regulatorio aplicable bajo las normativas de activos digitales en Argentina; e investigación sobre mecanismos de expansión del colateral aceptado más allá de BTCB.

Referencias Bibliográficas En progreso

Formato APA 7ª edición. Orden alfabético por apellido del primer autor. Sangría francesa (0.5 pulgadas).

Albert, J. F., Gómez Fernández, N., & Náñez Alonso, S. L. (2024). Monedas sociales en la era digital: retos y oportunidades. CIRIEC-España, Revista de Economía Pública, Social y Cooperativa, (110), 163–200. https://doi.org/10.7203/CIRIEC-E.110.25755

Ammous, S. (2018). The Bitcoin Standard: The Decentralized Alternative to Central Banking. Wiley.

Banco Central de la República Argentina. (2016). Comunicación "A" 5945: creación de la Unidad de Valor Adquisitivo (UVA) actualizable por CER. BCRA. https://www.bcra.gob.ar/archivos/Pdfs/comytexord/B13156.pdf

Banco Central de la República Argentina. (2023). Estadísticas monetarias y financieras: tasas de interés activas. BCRA. https://www.bcra.gob.ar/PublicacionesEstadisticas/Principales_variables.asp

Banco Mundial. (2021). The Global Findex Database 2021: Financial Inclusion, Digital Payments, and Resilience in the Age of COVID-19. World Bank Group. https://www.worldbank.org/en/publication/globalfindex

Binance. (2019). Introducing Bitcoin BEP2 (BTCB). Binance Blog. https://www.binance.com/en/blog/ecosystem/introducing-bitcoin-bep2-btcb-421499824684900358

Binance. (2020). BNB Smart Chain: A Parallel Binance Chain to Enable Smart Contracts. Binance. https://github.com/bnb-chain/whitepaper

Binance Academy. (2023). What is BEP-20? Binance. https://academy.binance.com/en/articles/what-is-bep-20

Buterin, V. (2014). A next-generation smart contract and decentralized application platform [White paper]. Ethereum Foundation. https://ethereum.org/en/whitepaper/

Candelaria Pardo, E. (2020). MonedaPAR: una alternativa argentina para la economía social y solidaria. REVESCO. Revista de Estudios Cooperativos, 135, e69177. https://doi.org/10.5209/reve.69177

Compound Finance. (2019). Compound: The Money Market Protocol [White paper]. https://compound.finance/documents/Compound.Whitepaper.pdf

Coraggio, J. L. (2011). Economía social y solidaria: el trabajo antes que el capital. Ediciones Abya-Yala / FLACSO Ecuador.

DeFi Llama. (2021). DeFi TVL historical data. https://defillama.com

Francisco. (2015). Laudato Si': Sobre el cuidado de la casa común [Carta encíclica]. Vaticano. https://www.vatican.va/content/francesco/es/encyclicals/documents/papa-francesco_20150524_enciclica-laudato-si.html

Gesell, S. (1916). Die natürliche Wirtschaftsordnung durch Freiland und Freigeld [El orden económico natural].

Hernández-Bejarano, M., & García Mandaloniz, M. (2021). El rol de la moneda y criptomoneda social en el nuevo contexto económico social y digital. CIRIEC-España, Revista Jurídica de Economía Social y Cooperativa, (37), 283. https://doi.org/10.7203/ciriec-jur.37.15791

Infobae. (2023a, 18 de septiembre). La Justicia ordenó reajustar la deuda de un crédito UVA por el aumento de la inflación y en defensa de "la parte más débil". Infobae. https://www.infobae.com/judiciales/2023/09/18/la-justicia-ordeno-reajustar-la-deuda-de-un-credito-uva-por-el-aumento-de-la-inflacion-y-en-defensa-de-la-parte-mas-debil/

Infobae. (2023b, 29 de enero). Pese a la alta inflación, los créditos hipotecarios indexados mantienen muy baja morosidad. Infobae. https://www.infobae.com/economia/2023/01/29/pese-a-la-alta-inflacion-los-creditos-hipotecarios-indexados-mantienen-muy-baja-morosidad/

Islamic Financial Services Board. (2022). Islamic Financial Services Industry Stability Report 2022. IFSB. https://www.ifsb.org

Keynes, J. M. (1936). The General Theory of Employment, Interest and Money. Macmillan.

León XIII. (1891). Rerum Novarum: Sobre la condición de los obreros [Carta encíclica]. Vaticano.

Ley N.º 27.739. (2024). Modificación de la Ley 25.246 — Prevención del lavado de activos y la financiación del terrorismo (incorporación de los Proveedores de Servicios de Activos Virtuales). Boletín Oficial de la República Argentina.

Lietaer, B. (2001). The Future of Money: Creating New Wealth, Work and a Wiser World. Century.

MakerDAO. (2017). The Dai Stablecoin System [White paper]. https://makerdao.com/en/whitepaper/

Mauss, M. (1925). Essai sur le don. Forme et raison de l'échange dans les sociétés archaïques [Ensayo sobre el don]. L'Année Sociologique.

Mishkin, F. S. (2016). The Economics of Money, Banking, and Financial Markets (11.ª ed.). Pearson.

Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system [White paper]. https://bitcoin.org/bitcoin.pdf

Organización Internacional del Trabajo. (2021). Perspectivas Sociales y del Empleo en el Mundo: El papel de las plataformas digitales en la transformación del mundo del trabajo. OIT. https://www.ilo.org/global/research/global-reports/weso/lang--es/index.htm

Página/12. (2023). Los deudores UVA piden respuesta: préstamos hipotecarios indexados imposibles de pagar. Página/12. https://www.pagina12.com.ar/426032-los-deudores-uva-piden-respuesta

PancakeSwap. (2021). PancakeSwap AMM and Liquidity Provision documentation. https://docs.pancakeswap.finance/

Polanyi, K. (1944). The Great Transformation: The Political and Economic Origins of Our Time. Farrar & Rinehart.

Primavera, H. (2003). Riqueza, dinero y poder: el efímero "milagro argentino" de las redes de trueque. En S. Hintze (Comp.), Trueque y economía solidaria. Prometeo Libros / UNGS.

Stani, K. (2020). Aave Protocol: White Paper V1.0. Aave. https://github.com/aave/aave-protocol/blob/master/docs/Aave_Protocol_Whitepaper_v1_0.pdf

Szabo, N. (1994). Smart contracts. Satoshi Nakamoto Institute. https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html

Uniswap Labs. (2020). Uniswap v2 Core [White paper]. https://uniswap.org/whitepaper.pdf

Venus Protocol. (2021). Post-mortem: XVS price manipulation and bad debt incident — May 2021. https://blog.venus.io

Wood, G. (2014). Ethereum: A secure decentralised generalised transaction ledger [Yellow paper]. https://ethereum.github.io/yellowpaper/paper.pdf

Zetzsche, D. A., Buckley, R. P., Arner, D. W., & Barberis, J. N. (2020). Decentralizing finance. Journal of Financial Regulation, 6(2), 172–203. https://doi.org/10.1093/jfr/fjaa010

Anexos En progreso

Anexo A: Código Fuente — NubeToken v2 (OFT + AccessControl)

El contrato NubeToken.sol v2 implementa el estándar OFT de LayerZero y el control de acceso AccessControlDefaultAdminRules de OpenZeppelin (que provee transferencia del rol de administrador en dos pasos con retardo). Compilado con Solidity ^0.8.20 y OpenZeppelin ≥ 4.9. Reemplaza al token v1 (Ownable) desplegado en BSC Mainnet en 2024, cuya dirección 0xF5d9E8b840e1F816586af80403077c9572Bb4D59 queda como referencia histórica. El código fuente completo es el siguiente:

Descargar código fuente: NubeToken.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import { OFT } from "@layerzerolabs/lz-evm-oapp-v2/contracts/oft/OFT.sol";
import { AccessControlDefaultAdminRules }
    from "@openzeppelin/contracts/access/AccessControlDefaultAdminRules.sol";
import { Pausable } from "@openzeppelin/contracts/security/Pausable.sol";

contract NubeToken is OFT, AccessControlDefaultAdminRules, Pausable {

    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    bytes32 public constant BURNER_ROLE = keccak256("BURNER_ROLE");
    bytes32 public constant PAUSER_ROLE = keccak256("PAUSER_ROLE");

    // LZ Endpoint BSC Mainnet: 0x1a44076050125825900e736c501f859c50fE728c
    // LZ Endpoint BSC Testnet: 0x6EDCE65403992e310A62460808c4b910D972f10f
    // _admin = Gnosis Safe institucional (recibe todos los roles + owner de OFT).
    // _adminDelay = retardo (seg.) de la transferencia de admin en 2 pasos (>= 3 días en mainnet).
    constructor(address _lzEndpoint, address _admin, uint48 _adminDelay)
        OFT("NUBE", "NUBE", _lzEndpoint, _admin)
        AccessControlDefaultAdminRules(_adminDelay, _admin)
    {
        // DEFAULT_ADMIN_ROLE ya fue otorgado a _admin por AccessControlDefaultAdminRules.
        _grantRole(MINTER_ROLE, _admin);
        _grantRole(BURNER_ROLE, _admin);
        _grantRole(PAUSER_ROLE, _admin);
        // OFT deja el owner de Ownable en el deployer; se transfiere al Safe
        // para que controle también la configuración cross-chain (setPeer).
        _transferOwnership(_admin);
    }

    /// @notice Emite NUBE. Caller debe tener MINTER_ROLE.
    function mint(address _to, uint256 _amount)
        external onlyRole(MINTER_ROLE) { _mint(_to, _amount); }

    /// @notice Quema NUBE de _account con aprobación previa. Caller debe tener BURNER_ROLE.
    function burnFrom(address _account, uint256 _amount)
        external onlyRole(BURNER_ROLE)
    {
        _spendAllowance(_account, msg.sender, _amount);
        _burn(_account, _amount);
    }

    function pause()   external onlyRole(PAUSER_ROLE) { _pause(); }
    function unpause() external onlyRole(PAUSER_ROLE) { _unpause(); }

    // Activación de contratos de protocolo (desde el Safe institucional):
    //   token.grantRole(MINTER_ROLE, address(NubeLending))
    //   token.grantRole(BURNER_ROLE, address(NubeLending))
    //   token.grantRole(MINTER_ROLE, address(NubeLender))
    //   token.grantRole(BURNER_ROLE, address(NubeLender))
    //
    // Emergencia (desactivar un contrato):
    //   token.revokeRole(MINTER_ROLE, address(contrato))
    //   token.revokeRole(BURNER_ROLE, address(contrato))
    //
    // Traspaso del rol de administrador (2 pasos + retardo):
    //   token.beginDefaultAdminTransfer(nuevoSafe)   // desde el Safe actual
    //   token.acceptDefaultAdminTransfer()           // desde el Safe nuevo, tras el retardo
    //   token.transferOwnership(nuevoSafe)           // mover también el owner de OFT

    function _beforeTokenTransfer(address from, address to, uint256 amount)
        internal override whenNotPaused { super._beforeTokenTransfer(from, to, amount); }

    function supportsInterface(bytes4 interfaceId)
        public view override(OFT, AccessControlDefaultAdminRules) returns (bool)
    { return super.supportsInterface(interfaceId); }
}

Anexo B: Código Fuente — Contrato de Préstamos (NubeLending.sol)

El código fuente completo del contrato NubeLending.sol v2. Incorpora ReentrancyGuard de OpenZeppelin (importado, no definido inline), parámetro _minNubeOut, y adopta Ownable2Step de OpenZeppelin para su propia titularidad —el traspaso del administrador es en dos pasos (transferOwnership + acceptOwnership), mientras que las operaciones (setFee, pausa) siguen siendo instantáneas. Respecto del token, usa el modelo de roles (grantRole/revokeRole): el contrato no requiere ser el owner del token, solo MINTER_ROLE y BURNER_ROLE otorgados desde el Safe institucional.

Descargar código fuente: NubeLending.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// PASO DE ACTIVACION (desde el Safe institucional, post-despliegue):
//   nubeToken.grantRole(MINTER_ROLE, address(NubeLending))
//   nubeToken.grantRole(BURNER_ROLE, address(NubeLending))
// Emergencia (desactivar):
//   nubeToken.revokeRole(MINTER_ROLE, address(NubeLending))
//   nubeToken.revokeRole(BURNER_ROLE, address(NubeLending))

import { ReentrancyGuard } from "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import { Ownable2Step }    from "@openzeppelin/contracts/access/Ownable2Step.sol";

interface INubeToken {
    function mint(address to, uint256 amount) external;
    function burnFrom(address account, uint256 amount) external;
    function balanceOf(address account) external view returns (uint256);
    function allowance(address owner, address spender) external view returns (uint256);
}
interface IERC20 {
    function transferFrom(address from, address to, uint256 amount) external returns (bool);
    function transfer(address to, uint256 amount) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
}

contract NubeLending is ReentrancyGuard, Ownable2Step {

    INubeToken public immutable nubeToken;
    IERC20     public immutable btcb;
    address public feeCollector;
    uint256 public feeBPS; // 100 = 1%, max 1000 = 10%
    bool    public paused;

    struct Position {
        uint256 collateralBTCB;
        uint256 nubeIssued;
        uint256 openedAt;
    }
    mapping(address => Position) public positions;
    uint256 public totalCollateral;
    uint256 public totalLoansOpened;
    uint256 public totalFeesCollected;

    event LoanOpened(address indexed borrower, uint256 btcbDeposited,
        uint256 feeCharged, uint256 nubeIssued, uint256 timestamp);
    event LoanRepaid(address indexed borrower, uint256 nubeReturned,
        uint256 btcbReleased, uint256 timestamp);
    event FeeUpdated(uint256 oldBPS, uint256 newBPS);
    event FeeCollectorUpdated(address indexed oldCollector, address indexed newCollector);

    modifier whenNotPaused() { require(!paused, "NUBE: protocol paused"); _; }

    constructor(
        address _nubeToken,
        address _btcb,
        address _feeCollector,
        uint256 _feeBPS
    ) {
        require(_nubeToken    != address(0), "NUBE: zero address token");
        require(_btcb         != address(0), "NUBE: zero address btcb");
        require(_feeCollector != address(0), "NUBE: zero address collector");
        require(_feeBPS       <= 1000,       "NUBE: fee exceeds 10%");
        nubeToken    = INubeToken(_nubeToken);
        btcb         = IERC20(_btcb);
        feeCollector = _feeCollector;
        feeBPS       = _feeBPS;
        // Ownable fija el owner inicial = deployer; transferir al Safe post-despliegue.
    }

    function requestLoan(uint256 _btcbAmount, uint256 _minNubeOut)
        external nonReentrant whenNotPaused
    {
        require(_btcbAmount > 0,                            "NUBE: amount must be > 0");
        require(positions[msg.sender].collateralBTCB == 0,  "NUBE: position already open");
        require(btcb.transferFrom(msg.sender, address(this), _btcbAmount),
            "NUBE: BTCB transferFrom failed");

        uint256 fee           = (_btcbAmount * feeBPS) / 10_000;
        uint256 netCollateral = _btcbAmount - fee;
        require(netCollateral > 0,            "NUBE: net collateral is zero");
        require(netCollateral >= _minNubeOut, "NUBE: slippage - too few NUBE out");

        if (fee > 0) {
            require(btcb.transfer(feeCollector, fee), "NUBE: fee transfer failed");
            totalFeesCollected += fee;
        }

        // checks-effects-interactions
        positions[msg.sender] = Position({
            collateralBTCB : netCollateral,
            nubeIssued     : netCollateral,
            openedAt       : block.timestamp
        });
        totalCollateral  += netCollateral;
        totalLoansOpened += 1;

        nubeToken.mint(msg.sender, netCollateral);
        emit LoanOpened(msg.sender, _btcbAmount, fee, netCollateral, block.timestamp);
    }

    function repayLoan() external nonReentrant {
        Position memory pos = positions[msg.sender];
        require(pos.collateralBTCB > 0, "NUBE: no open position");
        uint256 nubeToReturn  = pos.nubeIssued;
        uint256 btcbToRelease = pos.collateralBTCB;

        delete positions[msg.sender]; // checks-effects-interactions
        totalCollateral -= btcbToRelease;

        nubeToken.burnFrom(msg.sender, nubeToReturn);
        require(btcb.transfer(msg.sender, btcbToRelease), "NUBE: BTCB return failed");
        emit LoanRepaid(msg.sender, nubeToReturn, btcbToRelease, block.timestamp);
    }

    function getPosition(address _borrower) external view
        returns (uint256 collateral, uint256 nubeIssued, uint256 openedAt, bool hasPosition)
    {
        Position memory p = positions[_borrower];
        return (p.collateralBTCB, p.nubeIssued, p.openedAt, p.collateralBTCB > 0);
    }

    function calculateFee(uint256 _btcbAmount) external view
        returns (uint256 fee, uint256 netCollateral)
    {
        fee           = (_btcbAmount * feeBPS) / 10_000;
        netCollateral = _btcbAmount - fee;
    }

    function protocolStats() external view
        returns (uint256 _totalCollateral, uint256 _totalLoansOpened,
                 uint256 _totalFeesCollected, uint256 _feeBPS, bool _paused)
    {
        return (totalCollateral, totalLoansOpened, totalFeesCollected, feeBPS, paused);
    }

    function setFee(uint256 _newBPS) external onlyOwner {
        require(_newBPS <= 1000, "NUBE: fee too high (max 10%)");
        emit FeeUpdated(feeBPS, _newBPS);
        feeBPS = _newBPS;
    }
    function setFeeCollector(address _newCollector) external onlyOwner {
        require(_newCollector != address(0), "NUBE: zero address");
        emit FeeCollectorUpdated(feeCollector, _newCollector);
        feeCollector = _newCollector;
    }
    // Traspaso de titularidad en dos pasos (heredado de Ownable2Step):
    //   transferOwnership(nuevoOwner)  ← owner actual
    //   acceptOwnership()              ← nuevoOwner confirma
    function pauseProtocol()   external onlyOwner { paused = true; }
    function unpauseProtocol() external onlyOwner { paused = false; }
}

Anexo B.2: Código Fuente — Contrato de Prestadores (NubeLender.sol)

El contrato NubeLender.sol permite a usuarios depositar USDT y recibir tokens NUBE al tipo de cambio administrado vigente, e incluye las funciones de estabilización de mercado del administrador institucional.

Descargar código fuente: NubeLender.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import { ReentrancyGuard } from "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import { Ownable2Step }    from "@openzeppelin/contracts/access/Ownable2Step.sol";

interface INubeToken {
    function mint(address to, uint256 amount) external;
    function burnFrom(address account, uint256 amount) external;
}
interface IERC20 {
    function transferFrom(address from, address to, uint256 amount) external returns (bool);
    function transfer(address to, uint256 amount) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
}

contract NubeLender is ReentrancyGuard, Ownable2Step {

    INubeToken public immutable nubeToken;
    IERC20     public immutable usdt;  // BSC: 0x55d398326f99059fF775485246999027B3197955

    /// @notice NUBE por 1 USDT, escala 1e18. Ej: 10 NUBE/USDT → nubePerUsdt = 10e18
    uint256 public nubePerUsdt;
    bool    public paused;

    uint256 public totalUsdtDeposited;
    uint256 public totalNubeMinted;
    uint256 public totalNubeBurned;

    event LenderDeposited(address indexed lender, uint256 usdtAmount, uint256 nubeIssued, uint256 rate, uint256 timestamp);
    event LenderRedeemed(address indexed lender, uint256 nubeAmount, uint256 usdtReturned, uint256 rate, uint256 timestamp);
    event RateUpdated(uint256 oldRate, uint256 newRate);
    event MarketMintExecuted(address indexed to, uint256 amount, uint256 timestamp);
    event MarketBurnExecuted(address indexed from, uint256 amount, uint256 timestamp);

    modifier whenNotPaused() { require(!paused, "NUBE: paused"); _; }

    constructor(address _nubeToken, address _usdt, uint256 _nubePerUsdt) {
        require(_nubeToken  != address(0) && _usdt != address(0), "zero address");
        require(_nubePerUsdt > 0, "rate must be > 0");
        nubeToken   = INubeToken(_nubeToken);
        usdt        = IERC20(_usdt);
        nubePerUsdt = _nubePerUsdt;
        // Ownable fija el owner inicial = deployer; transferir al Safe post-despliegue.
    }

    /// @notice Deposita USDT y recibe NUBE. Requiere usdt.approve(address(this), amount).
    function deposit(uint256 _usdtAmount, uint256 _minNubeOut)
        external nonReentrant whenNotPaused
    {
        require(_usdtAmount > 0, "amount must be > 0");
        uint256 nubeAmount = (_usdtAmount * nubePerUsdt) / 1e18;
        require(nubeAmount > 0,           "NUBE amount is zero");
        require(nubeAmount >= _minNubeOut,"slippage: too few NUBE out");
        require(usdt.transferFrom(msg.sender, address(this), _usdtAmount), "USDT transfer failed");

        totalUsdtDeposited += _usdtAmount;
        totalNubeMinted    += nubeAmount;
        nubeToken.mint(msg.sender, nubeAmount);
        emit LenderDeposited(msg.sender, _usdtAmount, nubeAmount, nubePerUsdt, block.timestamp);
    }

    /// @notice Quema NUBE y recibe USDT. Requiere nubeToken.approve(address(this), amount).
    function redeem(uint256 _nubeAmount, uint256 _minUsdtOut)
        external nonReentrant
    {
        require(_nubeAmount > 0, "amount must be > 0");
        uint256 usdtAmount = (_nubeAmount * 1e18) / nubePerUsdt;
        require(usdtAmount > 0,            "USDT amount is zero");
        require(usdtAmount >= _minUsdtOut, "slippage: too few USDT out");
        require(usdt.balanceOf(address(this)) >= usdtAmount, "insufficient reserve");

        totalNubeBurned += _nubeAmount;
        if (totalUsdtDeposited >= usdtAmount) totalUsdtDeposited -= usdtAmount;
        else totalUsdtDeposited = 0;

        nubeToken.burnFrom(msg.sender, _nubeAmount);
        require(usdt.transfer(msg.sender, usdtAmount), "USDT transfer failed");
        emit LenderRedeemed(msg.sender, _nubeAmount, usdtAmount, nubePerUsdt, block.timestamp);
    }

    /// @notice [ADMIN] Emite NUBE para vender en mercado cuando precio > valor intrínseco.
    function mintDirect(address _to, uint256 _amount) external onlyOwner {
        nubeToken.mint(_to, _amount);
        emit MarketMintExecuted(_to, _amount, block.timestamp);
    }

    /// @notice [OWNER] Quema NUBE comprados en mercado cuando precio < valor intrínseco.
    function burnDirect(address _from, uint256 _amount) external onlyOwner {
        nubeToken.burnFrom(_from, _amount);
        emit MarketBurnExecuted(_from, _amount, block.timestamp);
    }

    function quoteDeposit(uint256 _usdtAmount) external view returns (uint256) {
        return (_usdtAmount * nubePerUsdt) / 1e18;
    }
    function quoteRedeem(uint256 _nubeAmount) external view returns (uint256) {
        return (_nubeAmount * 1e18) / nubePerUsdt;
    }

    function setRate(uint256 _newRate) external onlyOwner {
        require(_newRate > 0, "rate must be > 0");
        emit RateUpdated(nubePerUsdt, _newRate);
        nubePerUsdt = _newRate;
    }
    function withdrawUsdt(address _to, uint256 _amount) external onlyOwner {
        require(usdt.balanceOf(address(this)) >= _amount, "insufficient reserve");
        usdt.transfer(_to, _amount);
    }
    function pauseProtocol()   external onlyOwner { paused = true; }
    function unpauseProtocol() external onlyOwner { paused = false; }
    // Traspaso de titularidad: transferOwnership(nuevo) + acceptOwnership() (Ownable2Step).
}

Anexo C: Código Fuente — Contrato de Gobernanza

Incluir el código fuente completo del contrato NubeGovernance.sol una vez finalizado.

Anexo D: Contratos Desplegados

Tabla D.1

Registro de Contratos del Ecosistema NUBE

Nota. El token v1 (Ownable, 2024) permanece en cadena como referencia histórica y respaldo del pool de liquidez existente. El despliegue de NubeToken v2, NubeLending y NubeGovernance queda pendiente de ejecución; el administrador de los contratos será el Gnosis Safe institucional (ver Sección 4.6). Sus direcciones y hashes de transacción se completarán una vez ejecutadas las transacciones de despliegue.

Anexo E: Glosario de Términos

ABI (Application Binary Interface): Especificación de las funciones y eventos de un contrato inteligente, necesaria para interactuar con él desde el exterior.

AMM (Automated Market Maker): Protocolo de intercambio descentralizado que determina precios mediante fórmulas matemáticas en lugar de libros de órdenes.

BEP-20: Estándar de tokens fungibles en Binance Smart Chain, equivalente al ERC-20 de Ethereum.

BSC (Binance Smart Chain / BNB Smart Chain): Blockchain pública de Binance compatible con la EVM de Ethereum, con consenso PoSA y bloques cada 3 segundos.

BTCB: Token BEP-20 que representa Bitcoin en BSC, respaldado 1:1 por Bitcoin en custodia de Binance.

Burn: Destrucción permanente de tokens, retirándolos del supply circulante.

DAO (Decentralized Autonomous Organization): Organización cuyas reglas operativas están codificadas en contratos inteligentes y cuyas decisiones se toman mediante votación de sus miembros.

DeFi (Decentralized Finance): Ecosistema de servicios financieros construidos sobre blockchains públicas sin intermediarios centralizados.

DEX (Decentralized Exchange): Exchange de criptomonedas que opera mediante contratos inteligentes sin custodia centralizada de fondos.

EVM (Ethereum Virtual Machine): Entorno de ejecución determinista que procesa bytecode de contratos inteligentes en nodos Ethereum y redes compatibles.

Gas fee: Comisión pagada en la criptomoneda nativa de la red (BNB en BSC) para compensar a los validadores por ejecutar transacciones y contratos.

Impermanent loss: Pérdida temporal que experimentan los proveedores de liquidez en un AMM cuando el precio relativo de los activos del par cambia respecto al momento de depósito.

LTV (Loan-to-Value): Ratio entre el valor del préstamo y el valor del colateral, expresado en porcentaje.

MetaMask: Wallet de criptomonedas en forma de extensión de navegador, ampliamente utilizada para interactuar con dApps en redes EVM.

Mint: Emisión de nuevos tokens, aumentando el supply circulante.

Multisig: Wallet que requiere la firma de múltiples claves privadas para autorizar transacciones, utilizado como mecanismo de control de acceso en gobernanza.

Gnosis Safe: Contrato de billetera multifirma (multisig) estándar en el ecosistema EVM. Define un conjunto de propietarios (firmantes) y un umbral K-de-N; los propietarios y el umbral se modifican en cadena sin cambiar la dirección del Safe. En NUBE es el titular del rol de administrador de los contratos (la «institución»).

AccessControlDefaultAdminRules: Extensión de AccessControl de OpenZeppelin (v4.9+) que impone un único titular de DEFAULT_ADMIN_ROLE a la vez y transfiere ese rol en dos pasos con un retardo temporal cancelable, endureciendo el cambio de administrador.

PancakeSwap: DEX de modelo AMM nativo de Binance Smart Chain, fork de Uniswap V2.

Pool de liquidez: Contrato inteligente que mantiene reservas de dos o más activos, permitiendo su intercambio mediante un AMM.

Smart contract (Contrato inteligente): Programa autónomo desplegado en una blockchain que ejecuta lógica predefinida de forma determinista e inalterable.

Solidity: Lenguaje de programación de alto nivel, orientado a objetos y con tipado estático, utilizado para escribir contratos inteligentes en redes EVM.

Timelock: Mecanismo de contrato que impone un retraso mínimo entre la propuesta y la ejecución de cambios en parámetros del protocolo.

TVL (Total Value Locked): Valor total de activos depositados en los contratos de un protocolo DeFi, usado como métrica de adopción.

Wallet: Software que gestiona claves criptográficas y permite enviar, recibir y firmar transacciones en una blockchain.

Anexo F: Guía de Uso — Usuario Final

Esta guía describe paso a paso cómo utilizar la dApp NUBE para solicitar un préstamo sin interés depositando BTCB como colateral, y cómo devolver el préstamo para recuperar el colateral. Está dirigida a cualquier usuario con conocimientos básicos de wallets de criptomonedas.

F.1 Requisitos Previos

Para utilizar la dApp NUBE el usuario necesita:

1. MetaMask instalado: extensión disponible en metamask.io para Chrome, Firefox y Brave. La dApp es compatible con cualquier wallet que soporte el protocolo EIP-1193 (WalletConnect, Trust Wallet en modo dApp).
2. BNB para gas: toda transacción en BSC consume gas pagado en BNB. Se recomienda tener al menos 0.005 BNB disponibles para cubrir el costo de las dos transacciones del flujo completo.
3. BTCB en la wallet: el colateral del préstamo es BTCB (Bitcoin tokenizado en BSC). El contrato de BTCB en BSC Mainnet es 0x7130d2A12B9BCbFAe4f2634d864A1Ee1Ce3Ead9c. BTCB puede adquirirse en PancakeSwap, Binance Exchange o cualquier DEX de BSC.

F.2 Conectar la Wallet a la dApp

1. Ingresar a nubeblockchain.com.ar/dapp desde un navegador con MetaMask instalado.
2. La dApp detecta automáticamente si MetaMask ya tiene acceso autorizado a la cuenta. Si es la primera vez, aparece el botón Conectar MetaMask; hacer clic y aceptar en la ventana emergente de MetaMask.
3. Si la red activa en MetaMask no es BSC Mainnet (Chain ID 56), la dApp muestra el aviso "Red incorrecta" con un botón Cambiar a BSC. Al hacer clic, MetaMask solicita confirmación para cambiar de red. Si BSC no está configurada, la dApp la agrega automáticamente via wallet_addEthereumChain.
4. Una vez conectado y en la red correcta, la dApp muestra el saldo de BTCB, el saldo de NUBE, el cargo administrativo vigente (en %) y el estado de la posición del usuario.

F.3 Solicitar un Préstamo (Depositar BTCB → Recibir NUBE)

El flujo de solicitud requiere dos transacciones separadas que la dApp guía con indicadores visuales de progreso.

Paso 1 de 2 — Aprobar gasto de BTCB:

1. Ingresar el monto de BTCB a depositar en el campo del formulario, o hacer clic en MAX para usar el saldo completo.
2. La dApp calcula y muestra en tiempo real: el cargo administrativo que se cobrará (en BTCB) y la cantidad de tokens NUBE que se recibirán (equivalente al colateral neto).
3. Hacer clic en Aprobar BTCB. MetaMask abre una ventana solicitando permiso para que el contrato NubeLending gaste el monto indicado de BTCB.
4. Confirmar la transacción en MetaMask. Esperar la confirmación en la blockchain (aproximadamente 3-15 segundos en BSC).

Paso 2 de 2 — Solicitar el préstamo:

1. Una vez confirmada la aprobación, el indicador visual avanza al Paso 2 y se habilita el botón Solicitar Préstamo.
2. Hacer clic en el botón. MetaMask muestra la transacción de llamada a requestLoan(monto).
3. Confirmar la transacción. El contrato transfiere el BTCB, cobra el cargo administrativo y emite los tokens NUBE directamente a la wallet del usuario.
4. La dApp actualiza el panel y muestra la posición abierta: BTCB bloqueado, NUBE recibidos y fecha de apertura.

Nota importante: sólo puede existir una posición abierta por dirección al mismo tiempo. Para abrir una nueva posición es necesario devolver primero la posición existente.

F.4 Devolver el Préstamo (Quemar NUBE → Recuperar BTCB)

Para devolver el préstamo y recuperar el BTCB colateralizado, el usuario debe tener en su wallet la cantidad exacta de tokens NUBE que fueron emitidos al momento del préstamo. No se cobra interés adicional.

Paso 1 de 2 — Aprobar quema de NUBE:

1. Con una posición abierta, la dApp muestra el panel de devolución con el monto exacto de NUBE a devolver y el BTCB a recuperar.
2. Hacer clic en Aprobar NUBE. MetaMask solicita permiso para que el contrato NubeLending queme los tokens NUBE indicados.
3. Confirmar la transacción en MetaMask y esperar su confirmación.

Paso 2 de 2 — Devolver el préstamo:

1. Hacer clic en Devolver Préstamo. MetaMask muestra la transacción de llamada a repayLoan().
2. Confirmar la transacción. El contrato quema los tokens NUBE y devuelve el BTCB neto a la wallet del usuario.
3. La dApp actualiza el panel mostrando que no hay posición abierta. El BTCB devuelto es exactamente el mismo que fue depositado como colateral neto (sin descuentos adicionales).

F.5 Verificar el Estado de una Posición

La dApp muestra el estado de la posición en tiempo real al conectar la wallet. Alternativamente, el estado puede verificarse directamente en BscScan accediendo a la función getPosition(address) del contrato NubeLending una vez desplegado. Los campos mostrados son: BTCB bloqueado como colateral, tokens NUBE emitidos, y fecha y hora de apertura de la posición.

F.6 Operar con NUBE en PancakeSwap

Mientras el contrato de préstamos se encuentra en proceso de despliegue, o independientemente del protocolo de préstamos, el token NUBE puede comprarse, venderse e intercambiarse libremente en PancakeSwap. El enlace directo al par es:

https://pancakeswap.finance/swap?outputCurrency=0xF5d9E8b840e1F816586af80403077c9572Bb4D59

Para agregar NUBE a MetaMask manualmente: en la sección "Tokens" de MetaMask, hacer clic en "Importar tokens" e ingresar la dirección del contrato (0xF5d9E8b840e1F816586af80403077c9572Bb4D59); MetaMask completará automáticamente el símbolo (NUBE) y los decimales (18).

F.7 Preguntas Frecuentes (Usuario)

¿Cuánto interés se cobra por el préstamo? Ninguno. El protocolo NUBE no cobra interés. El único cargo es la comisión administrativa, descontada al momento de solicitar el préstamo del monto de BTCB depositado.

¿Mi posición puede ser liquidada si baja el precio de BTC? No. El protocolo no utiliza oráculos de precio en USD. La posición sólo se cierra cuando el propio usuario decide devolver los tokens NUBE, independientemente del precio de mercado de Bitcoin.

¿Qué pasa si pierdo mis tokens NUBE? Si se pierden los tokens NUBE (envío a dirección incorrecta, pérdida de acceso a la wallet), el BTCB colateralizado no puede ser recuperado, ya que el contrato requiere quemar exactamente los NUBE emitidos para liberar el colateral. Se recomienda guardar los tokens NUBE en la misma wallet que se utilizó para solicitar el préstamo.

¿Puedo tener varias posiciones abiertas simultáneamente? No. Una wallet puede tener una sola posición abierta a la vez. Para abrir una nueva posición es necesario devolver primero la existente.

¿El protocolo puede ser pausado? En caso de emergencia el administrador puede pausar las nuevas solicitudes de préstamo. Sin embargo, la función de devolución (repayLoan) siempre permanece habilitada, garantizando que el usuario siempre puede recuperar su colateral.

Anexo G: Guía de Administración del Protocolo

Esta guía está dirigida al administrador del protocolo NUBE: el Gnosis Safe institucional designado como admin de los tres contratos. En la fase inicial (1-de-1) el Safe tiene como único firmante la hardware wallet del fundador (una Ledger Nano); las operaciones que la guía indica «firmar desde el Safe» se ejecutan proponiendo la transacción en la interfaz del Safe (app.safe.global) y firmándola con la Ledger. Describe los pasos de despliegue, activación y operación continua del ecosistema. Se asume conocimiento básico de Remix IDE, MetaMask, el Gnosis Safe y BscScan.

G.1 Roles del Sistema

Tabla G.1

Roles y Permisos del Ecosistema NUBE

Nota. A diferencia del modelo v1 (Ownable), en v2 el contrato NubeLending no es el owner del token: posee MINTER_ROLE y BURNER_ROLE otorgados por el Safe, y solo emite NUBE como consecuencia de préstamos reales. El Safe conserva MINTER_ROLE/BURNER_ROLE únicamente para las operaciones de estabilización de mercado, y toda acción del Safe está sujeta al umbral de firmas de la multifirma.

G.2 Despliegue del Contrato NubeLending

El despliegue se realiza desde Remix IDE (remix.ethereum.org) conectado a MetaMask con el Ledger Nano.

1. Preparar Remix IDE: abrir remix.ethereum.org, crear un nuevo archivo NubeLending.sol y pegar el código fuente del Anexo B. Seleccionar el compilador Solidity 0.8.20 y activar la opción Enable optimization con 200 runs.
2. Compilar: hacer clic en Compile NubeLending.sol. Verificar que no haya errores de compilación (warnings menores son aceptables).
3. Conectar MetaMask: en MetaMask, conectar la Ledger Nano mediante Conectar hardware wallet. Seleccionar la cuenta desde la cual se firmará el despliegue. Asegurarse de que la red activa sea BSC Mainnet (Chain ID 56).
4. Configurar el despliegue: en Remix, en la pestaña Deploy & Run Transactions, seleccionar Environment: Injected Provider — MetaMask. Completar los parámetros del constructor:
   • _nubeToken: dirección del contrato NubeToken v2 desplegado (ver Anexo D)
   • _btcb: 0x7130d2A12B9BCbFAe4f2634d864A1Ee1Ce3Ead9c
   • _feeCollector: dirección que recibirá los cargos administrativos en BTCB (típicamente el Safe o la tesorería institucional)
   • _feeBPS: valor inicial del cargo en puntos básicos (ej: 100 para 1%)
   El contrato fija el owner como msg.sender (la cuenta que despliega). Para que la administración quede en manos de la institución, tras el despliegue llamar transferOwnership(Safe) y luego acceptOwnership() desde el Safe (patrón Ownable2Step, dos pasos; paso G.3), o bien desplegar directamente desde el Safe.
5. Desplegar: hacer clic en Deploy. MetaMask solicita confirmación; la Ledger Nano mostrará la transacción para firma física. Confirmar en el dispositivo. Esperar la confirmación de la transacción en BSC (aprox. 3-10 segundos).
6. Registrar la dirección: copiar la dirección del contrato desplegado desde Remix o BscScan. Guardarla en un lugar seguro y registrarla en el Anexo D.

G.3 Activación del Protocolo (Paso Crítico)

Tras el despliegue, el contrato NubeLending no puede emitir ni quemar tokens NUBE hasta que el administrador le otorgue los roles correspondientes. A diferencia del modelo v1 (Ownable), en v2 no se transfiere la propiedad del token: se otorgan roles granulares mediante grantRole(), que se firma desde el Gnosis Safe institucional (titular de DEFAULT_ADMIN_ROLE). El mismo procedimiento aplica a NubeLender.

1. Ingresar a BscScan en la dirección del contrato NubeToken v2 (ver Anexo D): https://bscscan.com/address/<NubeToken_v2>#writeContract. Alternativamente, proponer las transacciones desde la interfaz del Safe (app.safe.global) usando la ABI del token.
2. Otorgar a NubeLending el permiso de emisión: llamar grantRole(role, account) con role = valor de MINTER_ROLE (constante pública del token, consultable en Read Contract) y account = dirección de NubeLending.
3. Otorgar a NubeLending el permiso de quema: repetir grantRole con role = BURNER_ROLE y la misma dirección.
4. Repetir los dos pasos anteriores con la dirección de NubeLender (MINTER_ROLE y BURNER_ROLE), si ya está desplegado.
5. Cada llamada se firma desde el Safe: si el umbral es mayor que 1, la transacción queda pendiente hasta reunir las firmas necesarias antes de ejecutarse.
6. Verificar: en la pestaña Read Contract del token, llamar a hasRole(MINTER_ROLE, NubeLending) y hasRole(BURNER_ROLE, NubeLending). Ambas deben devolver true.

El protocolo queda activado. A partir de este momento, NubeLending puede emitir NUBE cuando un usuario solicita un préstamo y quemarlos cuando lo devuelve, sin poseer la titularidad del token. Ninguna persona física puede mintear a discreción: la única emisión directa restante es la de estabilización, reservada al Safe y sujeta a su umbral de firmas. Ante cualquier anomalía, el Safe puede revocar estos roles de forma inmediata y granular (ver G.9).

Si NubeLending (o NubeLender) fue desplegado desde una cuenta individual, completar la activación trasladando su administración a la institución: llamar transferOwnership(Safe) en cada contrato y luego acceptOwnership() desde el Safe (Ownable2Step, dos pasos). Verificar con owner() en Read Contract que el valor devuelto sea la dirección del Safe y que pendingOwner() sea address(0). A partir de entonces, todas las funciones administrativas (setFee, pauseProtocol, etc.) requieren la firma de la multifirma.

G.4 Actualizar la dApp con la Dirección del Contrato

1. Abrir el archivo dapp.html en un editor de texto.
2. Buscar la línea: const LENDING_ADDRESS = null;
3. Reemplazarla con: const LENDING_ADDRESS = '0xDIRECCION_DEL_CONTRATO'; (usando la dirección real del contrato desplegado).
4. Guardar el archivo y subirlo por FTP al servidor (host: c2811649.ferozo.com, ruta: /public_html/dapp.html).
5. Verificar que la dApp funcione correctamente accediendo a nubeblockchain.com.ar/dapp.

G.5 Gestión del Cargo Administrativo

El cargo puede modificarse en cualquier momento desde BscScan o Remix IDE, firmando desde el Gnosis Safe (rol admin).

Tabla G.2

Funciones de Administración del Cargo

Para ejecutar desde BscScan: ir a la pestaña Write Contract del contrato NubeLending y firmar la transacción desde el Safe (o proponerla en app.safe.global). Si el umbral es mayor que 1, la llamada se ejecuta al reunir las firmas requeridas.

G.6 Pausa de Emergencia

En caso de detectarse una vulnerabilidad o comportamiento anómalo, el administrador puede pausar el protocolo inmediatamente:

1. Llamar a pauseProtocol() desde BscScan o Remix, firmando desde el Safe (rol admin). Esta acción bloquea las nuevas solicitudes de préstamo (requestLoan). Para una respuesta más rápida ante emergencias puede reservarse PAUSER_ROLE del token a una llave «guardián» de menor umbral; ver Sección 4.6.
2. La función repayLoan() permanece siempre habilitada: los usuarios pueden devolver sus préstamos y recuperar el BTCB incluso con el protocolo pausado.
3. Para reanudar el protocolo, llamar a unpauseProtocol() una vez resuelto el problema.

El estado de pausa puede verificarse en cualquier momento llamando a protocolStats() en la pestaña Read Contract, que devuelve el campo _paused.

G.7 Monitoreo del Protocolo

Las métricas del protocolo pueden consultarse en tiempo real sin costo de gas a través de la función protocolStats() del contrato, disponible en BscScan:

• _totalCollateral: BTCB total actualmente bloqueado en el contrato (en wei, dividir por 10¹⁸)
• _totalLoansOpened: número acumulado de préstamos abiertos desde el despliegue
• _totalFeesCollected: BTCB total recaudado como cargos administrativos (en wei)
• _feeBPS: cargo vigente en puntos básicos
• _paused: estado de pausa del protocolo

Adicionalmente, BscScan permite visualizar el saldo de BTCB del contrato, el historial de transacciones y los eventos emitidos (LoanOpened, LoanRepaid, FeeUpdated, etc.) en la pestaña Events.

G.8 Cambio de Administrador y Traspaso del Protocolo

Existen tres escenarios distintos, con procedimientos distintos. Es un error frecuente asumir que el token expone una función transferAdmin: no la tiene. El token usa AccessControlDefaultAdminRules (begin/accept del rol de administrador), mientras que NubeLending y NubeLender usan Ownable2Step, cuyo traspaso de titularidad también es en dos pasos: transferOwnership(nuevo) seguido de acceptOwnership() confirmado por el destinatario.

1. Rotación de un firmante (cambia el director, la institución continúa). No se toca ningún contrato del protocolo: se modifica la lista de propietarios del Safe. Desde la interfaz del Safe, ejecutar swapOwner(anterior, nuevo) (o addOwnerWithThreshold / removeOwner para pasar de 1-de-1 a 2-de-3). La clave del firmante saliente queda sin poder de forma inmediata; nunca existió un secreto compartido.

2. Traspaso del rol de administrador del token (a un Safe nuevo). Es un proceso en dos pasos con retardo, deliberadamente no instantáneo:

1. Desde el Safe actual: beginDefaultAdminTransfer(nuevoSafe). Queda pendiente y comienza a correr el retardo configurado.
2. Transcurrido el retardo, desde el Safe nuevo: acceptDefaultAdminTransfer(). Recién ahí cambia el administrador. Si la dirección fuera incorrecta, la transferencia puede cancelarse antes de aceptarse (cancelDefaultAdminTransfer). Este mecanismo impide enviar el rol a una dirección inaccesible e imposibilita el secuestro instantáneo ante una clave comprometida.
3. Mover también el owner de Ownable (config. cross-chain de OFT): transferOwnership(nuevoSafe).

3. Traspaso total del proyecto (venta o cesión). Además de los pasos del punto 2, transferir la titularidad de los contratos de protocolo: transferOwnership(nuevoSafe) en NubeLending y en NubeLender, y luego acceptOwnership() desde el Safe nuevo (Ownable2Step). Para máxima seguridad de los administradores entrantes, la nueva administración debe desplegar su propio Safe desde cero (evitando heredar módulos o guards preexistentes) y ejecutar la verificación de traspaso de la Sección G.10. Ver también Sección 4.6.3.

G.9 Revocación de Roles en Emergencia

En situaciones de emergencia graves, el administrador desactiva el contrato afectado revocando sus roles en NubeToken desde el Gnosis Safe: revokeRole(MINTER_ROLE, address(NubeLending)) y revokeRole(BURNER_ROLE, address(NubeLending)). La revocación es inmediata y granular: solo afecta al contrato indicado, sin impactar el resto del ecosistema. Para reactivarlo, volver a otorgar los roles con grantRole.

G.10 Verificación de Traspaso (Due Diligence del Nuevo Administrador)

Cuando el protocolo cambia de manos (venta o cesión), la administración entrante debe poder confirmar por sí misma, en cadena, que ninguna clave de la administración saliente conserva poder alguno. Este checklist es la contraparte del procedimiento de la Sección G.8 y debe ejecutarse íntegramente tras el traspaso:

1. Código verificado e inmutable. Confirmar en BscScan que los tres contratos figuran como Verified y que no son proxies (no hay patrón de actualización): la lógica no puede alterarse después del traspaso.
2. Administrador del token. hasRole(DEFAULT_ADMIN_ROLE, SafeNuevo) = true y = false para el Safe anterior; owner() = SafeNuevo; verificar que no haya transferencias de admin pendientes (pendingDefaultAdmin y pendingOwner vacíos).
3. Roles operativos del token. Revocar del Safe anterior MINTER_ROLE, BURNER_ROLE y PAUSER_ROLE, y confirmar hasRole(...) = false para cada uno. Verificar que MINTER/BURNER solo los tengan NubeLending, NubeLender y el SafeNuevo (estabilización).
4. Titularidad de los contratos de protocolo. En NubeLending y NubeLender: owner() = SafeNuevo y pendingOwner() = address(0).
5. Firmantes del Safe nuevo. Verificar en la interfaz del Safe la lista de propietarios y el umbral: ninguna dirección de la administración anterior debe figurar.
6. Fee Collector. Confirmar que feeCollector (en NubeLending) apunta a la tesorería del nuevo administrador. Es el punto más fácil de pasar por alto: aunque la titularidad se transfiera, si feeCollector quedara apuntando a una wallet de la administración anterior, los cargos administrativos futuros seguirían llegándole. Ejecutar setFeeCollector(nuevaTesorería) si es necesario.
7. Reserva de USDT. Recordar que en NubeLender el owner puede retirar la reserva con withdrawUsdt; validar el saldo esperado y que el control ya está exclusivamente en el SafeNuevo.