Venezuela, Bitcoin y el plano de control TreasOS — Joubert López · Trebuoj Zepol · 2026
Diseño / pensamiento institucional. No es asesoría legal, monetaria ni política. No es programa de gobierno ni oferta a un Estado concreto. No es CBDC.
De: República con proceso — Venezuela, Bitcoin y el plano de control TreasOS
Este no es el libro de Nodos soberanos. Aquel contó cómo una firma construyó un orquestador de tesorería Bitcoin para empresas que ya tienen satoshis en el balance y no quieren ser héroes a las once de la noche. Este libro abre otra pregunta, más delicada y más venezolana:
¿Puede un Estado — o un pedazo serio del Estado: un fondo, un municipio, un ministerio — operar Bitcoin con la misma disciplina que exige a cualquier tesorería institucional, sin entregar las claves a un exchange y sin fingir que el software es el Congreso?
Escribo desde Caracas en la memoria y desde el software en el presente. Venezuela no es un apéndice exótico para vender slides. Es el país donde la presión cambiaria, la desconfianza hacia contrapartes centralizadas y la necesidad de evidencia no son teoría de comités europeos: son el aire que respira quien cierra un mes. Si un modelo de gobierno con Bitcoin aguanta ese aire, aguanta conversaciones más calmadas en otras latitudes. Si se rompe aquí en el papel, mejor que se rompa aquí y no en un decreto apresurado.
Mi nombre es Joubert López. Fundé Trebuoj Zepol y diseñé TreasOS: software propietario, non-custodial, watch-only. El servidor no puede gastar los fondos del cliente. Esa premisa, aplicada a una empresa, es soberanía con proceso. Aplicada a un país, es la misma premisa con nombres más pesados: Contraloría, Asamblea, Tesorería, BCV, ciudadanía.
Seré explícito en lo que este libro no es:
No es un programa de gobierno ni un manifiesto partidista.
No es asesoría constitucional, monetaria ni tributaria.
No propone sustituir al bolívar por decreto ni convertir a TreasOS en banco central.
No vende “cumplimiento certificado” ni CBDC disfrazada de Bitcoin.
No promete que un vendor extranjero firme el gasto de la República.
Propone un modelo conceptual — y una hoja de ruta de piloto acotado — donde Bitcoin ancla reservas o liquidación on-chain, la ley orgánica define quién puede gastar, y TreasOS impone el proceso: política, maker-checker, rastro de auditoría, claves en el perímetro del Estado.
La frase que sostiene todo el arco es la misma del producto:
El servidor TreasOS no puede gastar los fondos de la República.
Si esa frase no se sostiene en el diseño, el resto es teatro.
Joubert López
Trebuoj Zepol · TreasOS
Julio 2026
Capítulo 1 — La tesis: gobierno con proceso sobre Bitcoin
Hay dos tentaciones que destruyen cualquier conversación seria sobre Bitcoin y el Estado.
La primera es el maximalismo político: “el Congreso sobra; la blockchain basta.” Eso no es gobernanza. Es abdicar. Un país no es una DAO con himno. Las decisiones de gasto público cargan con legitimidad, representación, control fiscal y consecuencias humanas que ninguna confirmación de bloque puede suplantar.
La segunda es el custodio con bandera: el Estado “adopta Bitcoin” depositándolo en un exchange o en un intermediario que concentra spend authority. Eso no es soberanía. Es contraparte con narración patriótica. Venezuela conoce demasiado bien lo que significa depender de un intermediario que un día bloquea, limita o desaparece.
Entre ambas tentaciones existe un espacio que las instituciones ya conocen en otros activos — y que TreasOS ocupa en Bitcoin corporativo:
Orquestar, no custodiar.
El Estado (o el vehículo piloto) conserva las claves en su perímetro: HSM, cold storage, multisig nacional, ceremonias documentadas. El software ve saldos (xpub / descriptores), aplica política de gasto, exige maker-checker, construye PSBTs, registra evidencia. La firma ocurre offline. El broadcast deja un txid. El auditor — interno, Contraloría, o ciudadano cuando lo publicado lo permita — puede preguntar quién propuso, quién aprobó, qué regla aplicó, qué transacción salió.
Eso es gobierno con proceso sobre Bitcoin. No es “gobierno en el blockchain”.
Tres capas que no se confunden
Capa monetaria / de reserva — qué rol juega Bitcoin en la política de reservas o en un fondo específico. Esa decisión es política y de la autoridad monetaria competente. TreasOS no la toma.
Capa legal — quién puede autorizar movimientos, con qué quórum, bajo qué techos. Esa decisión es del ordenamiento jurídico venezolano. TreasOS no la inventa; la ejecuta como reglas.
Capa operativa — cómo se propone, aprueba, firma y evidencia un pago on-chain. Ahí entra TreasOS.
Confundir las tres capas es el error de casi todo whitepaper “nación Bitcoin”. Este libro las mantiene separadas a propósito. Si alguien le vende un paquete donde el mismo vendor define la política monetaria, firma el gasto y emite el dictamen de cumplimiento, usted no está comprando soberanía: está comprando un intermediario con mejor marketing.
Analogía que sí funciona
Piense en la tesorería de una empresa seria: no guarda el efectivo del mes en la billetera personal del analista; no aprueba pagos por chat a medianoche; no responde al auditor con capturas. Tiene roles, límites, segundas firmas, archivos. Bitcoin no deroga esa disciplina: la exige con más fuerza, porque el error on-chain no se “estorna” con una llamada al banco amigo.
TreasOS es esa disciplina convertida en flujo: borrador → política → aprobación → PSBT → firma fuera del servidor → broadcast → evidencia.
Por qué importa en Venezuela
En Venezuela, el costo de operar mal no es abstracto. Improvisación con wallets personales, chats y capturas de pantalla ya destruyó confianza en el sector privado; elevada al Estado, el daño es civilizatorio. Al mismo tiempo, la desconfianza hacia contrapartes centralizadas hace que “dejar las claves en un custodio extranjero” sea políticamente y operativamente frágil.
El modelo no pide fe en una ideología. Pide disciplina:
Claves en perímetro soberano.
Política antes de la urgencia.
Quien propone no aprueba.
Evidencia antes del titular de prensa.
Si usted acepta esas cuatro líneas, el resto del libro es ingeniería institucional. Si no las acepta, ningún capítulo posterior le va a servir: buscará un atajo, y el atajo volverá a ser el héroe operativo con otra camiseta.
Capítulo 2 — Por qué Venezuela (y no como anécdota)
Venezuela concentra, en una sola mesa de riesgo, presiones que en otros países aparecen dispersas. Por eso este libro no empieza en un paraíso fiscal teórico. Empieza aquí.
Presión cambiaria real
Quien opera tesorería en Venezuela piensa en bolívares y dólares al mismo tiempo. El tipo de cambio no es decoración de slide; es variable de cierre, de nómina, de importación, de supervivencia. Bitcoin — y a veces USDT en la práctica cotidiana — ya forma parte del lenguaje de liquidez de empresas y ciudadanos. Ignorarlo en un modelo de Estado es negacionismo operativo. Mitificarlo como solución mágica a toda la economía es otro negacionismo, simétrico e igual de peligroso.
Un modelo sobrio nombra la volatilidad. Nombra el FX. Nombra que un vehículo público que toque BTC necesita reglas de concentración, de valuación para reportes, y de quién decide cuándo convertir. TreasOS no decide eso. Obliga a que, cuando se mueva, el movimiento deje rastro.
Memoria de contraparte
La desconfianza hacia intermediarios no es postureo libertario importado. Es memoria institucional: bloqueos, restricciones, quitas de confianza, sistemas que prometieron custodia y entregaron dependencia. Un modelo que diga “adoptemos Bitcoin” y luego deposite las claves en un exchange offshore repite el patrón con otra etiqueta.
Por eso la premisa non-custodial no es marketing de producto: es condición de posibilidad política. Si el spend authority vive fuera del perímetro soberano, la “adopción” es teatro.
Necesidad de evidencia
En el ámbito corporativo venezolano, el Boletín Aplicado VEN-NIF N° 12 (FCCPV) exige lenguaje de existencia, medición y presentación para criptoactivos propios. El héroe operativo con WhatsApp no sobrevive ese lenguaje. TreasOS, en el pack ven_enterprise, ya se diseñó para exportar evidencia — no para dictaminar.
En el ámbito público, el paralelo no es aplicar el mismo boletín como si el Estado fuera una C.A. El paralelo es cultural: Contraloría, archivo, control fiscal, ciudadanía. La forma jurídica cambia; la exigencia de “muéstrame el rastro” no.
Laboratorio, no vitrina
Elegir Venezuela como escenario del modelo no es turismo regulatorio. Es reconocer que si el diseño aguanta FX dual, desconfianza de custodia y demanda de rastro, el núcleo — orquestar, no custodiar — se puede llevar a otros países latinoamericanos con menos fricción narrativa. Caracas como microscopio; no como souvenir.
Lo que Venezuela no es en este libro
No es un llamado a un bando. No es un plan de dolarización encubierta ni de “bitcoinización” por decreto. No es una crítica a funcionarios concretos. Es un ejercicio de arquitectura institucional escrito por alguien que construyó el software de orquestación y conoce el límite exacto donde el código termina y empieza el abogado, el contador y el legislador.
Beachhead soberano
El error clásico es “todo el fisco el día uno”. El beachhead sensato es el mismo del producto comercial: un circuito acotado.
Ejemplos de piloto (ilustrativos, no prescritos):
Un fondo con mandato de reserva parcial en Bitcoin.
Un municipio o entidad descentralizada con partida on-chain limitada.
Un programa con techo duro y whitelist de destinos.
Mismos controles: watch-only, política, maker-checker, firma offline, audit trail. Misma regla: el servidor no gasta. Mismo criterio de éxito: un mes aburrido.
Capítulo 3 — Bitcoin en la República: reserva, no religión
Antes de hablar de TreasOS hay que hablar de lo que Bitcoin puede y no puede ser para un Estado venezolano.
Lo que sí puede ser (en un diseño sobrio)
Componente de reserva de un fondo o de una política de activos de un vehículo público, con límites de concentración definidos por autoridad competente.
Riel de liquidación para pagos específicos donde la contraparte acepta BTC y el marco legal del vehículo lo permite.
Ancla de verificación: saldos UTXO auditable on-chain, proof of reserves cuando se publique, sin depender de un extracto opaco de custodio.
Lo que no debe fingir ser
Sustituto automático del bolívar como unidad de cuenta de todo el presupuesto nacional.
Reemplazo del BCV o de la política monetaria.
Garantía de estabilidad de poder adquisitivo (la volatilidad existe; el modelo la nombra, no la niega).
Sistema de votos o de legislación on-chain.
Separación útil: tenencia vs operación
Tener Bitcoin en un balance público es una decisión de activos. Operarlo — pagar, mover, cambiar, demostrar existencia — es una decisión de proceso. Muchos Estados (y empresas) tropiezan al confundirlas: celebran la tenencia e improvisan la operación.
TreasOS entra solo en la operación. No decide cuánto Bitcoin debe tener la República. Decide — cuando se le configura así — que ningún satoshi se mueva sin política, sin segunda firma y sin rastro.
Riesgo de narrativa
El mayor riesgo político del modelo no es técnico: es el titular. “Venezuela adopta Bitcoin” se lee como mil cosas que este libro no afirma. Por eso el lenguaje recomendado es deliberadamente aburrido:
Vehículo X opera tesorería Bitcoin non-custodial con controles institucionales (política, maker-checker, auditoría), claves en perímetro soberano, software TreasOS como plano de control watch-only.
Aburrido es una virtud. El heroísmo operativo es el enemigo.
Capítulo 4 — TreasOS como plano de control del Estado
TreasOS no es un banco. No es un exchange. No es un custodio. No es el Congreso.
Es un sistema operativo de tesorería watch-only: organiza quién propone, bajo qué reglas, quién aprueba, cómo se construye el PSBT, cómo se archiva la evidencia — mientras las claves privadas permanecen fuera del servidor.
Capacidades que importan al modelo país
Capacidad
Uso en Venezuela (piloto)
Wallets watch-only (xpub / descriptors)
Visibilidad de saldos del fondo / entidad sin subir claves
Motor de política
Techos, ventanas temporales, whitelist de destinos
Maker-checker + RBAC
Tesorería propone; contraloría / segundo rol aprueba
Flujo PSBT
Firma en HSM/cold nacional; TreasOS no firma con autoridad de gasto
Audit log / portal auditor
Evidencia para Contraloría, auditoría externa, archivo
BIP-322 proof of reserves
Transparencia selectiva de reservas cuando se decida publicar
Multi-tenant / vehículos
Varios fondos o entidades aislados en un despliegue
Self-host / on-prem
Nodo en perímetro venezolano — no SaaS con spend authority remota
Premisa operativa
El servidor TreasOS no puede gastar. Si un diseño de “gobierno Bitcoin” requiere que el vendor co-firme o custodie, ese diseño no es este libro.
Perfil regional (ámbito corporativo, lección para lo público)
En el producto comercial, Venezuela ya tiene el perfil ven_enterprise: español por defecto, exports pensados para evidencia de cierre, frontera explícita con el contador bajo BA VEN-NIF 12. Eso no convierte a TreasOS en software de contabilidad pública nacional. Pero sí demuestra una cultura de producto útil al Estado: evidencia exportable, disclaimers honestos, locale local, sin fingir dictamen.
Un piloto público debería heredar esa cultura, no el Excel del héroe.
Capítulo 5 — Separación de poderes en el gasto on-chain
La Constitución venezolana — y la tradición republicana — separan funciones. El modelo no inventa poderes nuevos; mapea funciones de gasto a roles de tesorería institucional.
Función del Estado
Analogía
Rol en TreasOS
Legislativo / presupuesto
Aprueba techos y partidas
Política: límites, ventanas, whitelist
Ejecutivo / tesorería
Propone pagos
Initiator / operator
Contraloría / control previo o concurrente
Segunda mirada humana
Approver / quorum
Custodia de claves
HSM / cold / multisig bajo régimen de seguridad del Estado
Fuera del servidor; solo firma PSBT offline
Auditoría / ciudadanía (cuando aplique)
Fiscalización posterior / transparencia
Audit trail, packs, PoR selectivo
Regla de oro
Quien propone no aprueba. Quien aprueba no necesariamente firma. Quien firma no altera la política en caliente sin procedimiento. Quien audita no opera.
Si el piloto colapsa esas funciones en una sola persona “de confianza”, no es piloto de República: es wallet con himno.
Multisig nacional ≠ gobernanza
Tener 2-de-3 o 3-de-5 en hardware es necesario y no suficiente. Sin política, sin roles, sin log, el multisig solo reparte la llave del mismo heroísmo. TreasOS añade el proceso alrededor de la llave.
Coerción y captura
Todo sistema de firmas estatales enfrenta coerción. El modelo mitiga con: quórums por umbral de monto, separación geográfica/institucional de firmantes, runbooks de ceremonia, y política que bloquea destinos no listados. No elimina la política humana. Reduce la improvisación.
Capítulo 6 — Flujo de un gasto público en Bitcoin
Paso a paso, en lenguaje de República:
01 — Tesorería watch
Se importa el descriptor / xpub del vehículo piloto. Saldos y UTXOs visibles. Cero claves privadas en el servidor TreasOS.
02 — Propuesta
La unidad de gasto (dirección, ministerio, alcaldía — según el piloto) crea un borrador: destino, monto, partida / etiqueta presupuestaria, justificación.
03 — Puerta de política
El motor evalúa: ¿el destino está en whitelist? ¿el monto cabe en el techo diario / mensual / de partida? ¿el rol del proponente puede iniciar ese tipo de movimiento? Si falla, se detiene con razón explícita — auditable.
04 — Separación de poderes (maker-checker)
Un segundo rol — analogía de contraloría o comité — aprueba. Quórum según umbral. Sin aprobación, no hay PSBT “listo para firmar” en el sentido institucional del flujo.
05 — Firma offline
El PSBT sale al perímetro de claves del Estado (HSM, cold, multisig). TreasOS no tiene spend authority. La ceremonia sigue el runbook nacional del piloto.
06 — Broadcast y archivo
La transacción se transmite. El txid, el change, el log de quién hizo qué, quedan en el rastro. Lo que se publique a la ciudadanía es decisión de transparencia del vehículo — no del vendor.
Este flujo es el mismo que ya demostramos en humo mainnet institucional controlado en el producto. La diferencia aquí es el vocabulario de Estado y el peso del error.
Capítulo 7 — Presupuesto como código (sin sustituir la ley)
La ley aprueba el presupuesto. El software no legisla.
Lo que el software sí puede hacer es impedir que la operación cotidiana contradiga techos y destinos ya decididos:
Límites por transacción y por ventana temporal.
Techos por partida / etiqueta.
Whitelist de direcciones o de categorías de destino.
Quórum escalonado: montos bajos con dos roles; montos altos con N aprobadores + rol adicional.
Eso es presupuesto como código en el sentido operativo: reglas ejecutables que fallan cerradas (fail closed). No es un smart contract que reemplace a la Asamblea.
Qué vive en la ley vs qué vive en TreasOS
En la ley / reglamento del vehículo
En configuración TreasOS
Quién puede ser ordenador de pago
Mapeo de esos roles a RBAC
Techos del ejercicio
Límites numéricos y ventanas
Destinos permitidos (categorías)
Whitelist concreta (direcciones / políticas)
Deber de archivo y fiscalización
Retención de logs y export de packs
Régimen de claves del Estado
Integración operativa con HSM/cold (fuera del app)
Cuando la política en TreasOS y el reglamento divergen, gana el reglamento — y se corrige la configuración. El software es siervo de la norma, no al revés.
Capítulo 8 — Evidencia, Contraloría y la frontera honesta
Qué debe poder responder el sistema
¿Quién propuso el movimiento?
¿Quién lo aprobó y cuándo?
¿Qué regla de política lo permitió o lo bloqueó?
¿Qué PSBT se firmó?
¿Qué txid quedó en Bitcoin?
¿Qué change volvió y cómo se indexó?
Sin esas respuestas, no hay República con proceso: hay narrativa.
Ámbito corporativo venezolano (lección, no copia ciega)
En empresas, TreasOS exporta evidencia orientada al cierre bajo el lenguaje del BA VEN-NIF 12: existencia, movimientos, FX indicativo VES/USD con fuente, packs de auditor con boundary explícito. TreasOS no calcula valor razonable definitivo ni registra asientos. El contador aplica la norma en su ERP.
En un piloto público, el paralelo no es “VEN-NIF 12 para el Estado” como si fuera el mismo boletín. El paralelo es la cultura de frontera:
El software entrega operación + evidencia.
El órgano de control y el profesional competente interpretan y dictaminan.
Nadie vende un sello que no existe.
Transparencia selectiva
Publicar cada UTXO en tiempo real puede ser inseguro u operativamente torpe. Publicar PoR periódico, agregados y reportes de cumplimiento operativo puede ser virtuoso. El modelo exige decidir qué es público; no improvisar filtraciones ni opacidad total.
Contraloría
El rol de Contraloría en el diseño es doble: participación en maker-checker cuando el régimen lo prevea, y acceso de lectura a trails / packs. TreasOS no reemplaza a la Contraloría General de la República. Le da material mejor que capturas de pantalla.
Capítulo 9 — Piloto venezolano: cómo empezar sin incendiar el país
Principio
Acotar. Un vehículo. Un techo. Una whitelist corta. Un quórum real. Un runbook de claves. Un período de prueba con montos pequeños. Mainnet solo cuando el drill en ambiente controlado aburra de lo predecible.
Si el anuncio precede al reglamento, usted ya perdió. El titular comerá al diseño.
Fase 0 — Papel (antes del software)
Identidad jurídica del vehículo piloto y competencia para operar el activo.
Reglamento interno: roles (proponente, aprobador, firmante, auditor de lectura).
Matriz de techos y quórums por monto.
Lista inicial de destinos permitidos (corta a propósito).
Régimen de claves: quién custodia qué, ceremonias, recuperación, ausencia de un firmante.
Disclaimers: qué no promete el piloto (estabilidad de precio, cumplimiento abstracto, sustitución del bolívar).
Criterios de aborto: qué hecho detiene el piloto de inmediato.
Sin Fase 0, instalar TreasOS es ponerle motor a un carro sin frenos.
Fase 1 — Laboratorio
TreasOS en perímetro controlado (on-prem / VPS soberano según el régimen de seguridad del vehículo). Español por defecto. Wallets watch-only de prueba. Política estricta. Maker-checker con personas reales — no con la misma persona en dos usuarios. Firma offline. Sin fondos materiales.
Objetivo: que el equipo odie el bypass. Que el “hazlo por chat” duela porque el sistema no colabora.
Fase 2 — Testnet / montos simbólicos
Mismo flujo con valor insignificante o testnet. Export de evidencia. Revisión por el órgano de control interno del vehículo. Corrección de roles que en la práctica se colapsaron. Revisión del runbook de claves con un simulacro de ausencia.
Fase 3 — Mainnet acotado
Techo duro. Montos pequeños. Misma disciplina. Cada movimiento con post-check: ¿coinciden política, aprobaciones, txid y archivo? N movimientos después: post-mortem obligatorio, escrito, sin adornos.
Fase 4 — Evaluación
Preguntas honestas:
¿Se rompió la separación de roles?
¿Hubo bypass por canales paralelos?
¿El log bastó para reconstruir la historia sin testimonios heroicos?
¿El HSM/cold aguantó el procedimiento sin improvisación?
¿Alguien pidió “excepción solo esta vez”?
Solo entonces se discute ampliar techo o segundo vehículo.
Anti-patrones (lista de incendio)
Anunciar “Venezuela Bitcoin Nation” antes del Fase 0.
Poner claves en laptop de un funcionario “de confianza”.
Un solo aprobador para montos materiales.
Dependencia de un exchange como billetera del Estado.
Prometer al público volatilidad cero.
Pedirle a TreasOS que “cumpla la ley” en abstracto sin reglamento del vehículo.
Mezclar fondos personales y públicos en la misma wallet.
Cambiar la whitelist por urgencia sin acta.
Dejar que el vendor co-firme “por practicidad”.
Medir éxito en likes y no en meses sin incidente.
Éxito aburrido
El éxito del piloto no es un titular. Es un mes en el que nadie fue héroe, cada pago dejó rastro, y el servidor no pudo gastar. Si eso le parece poco ambicioso, usted todavía está pensando en narrativa. La República se defiende con aburrimiento operativo.
Capítulo 10 — Riesgos, límites y lo que el software no lava
Riesgos políticos
Captura del relato (“ya resolvimos el país con una app”). Polarización que convierta el piloto en trinchera. Titulares que prometan lo que el diseño no entrega.
Riesgos operativos
Coerción a firmantes. Quórum demasiado bajo. Bypass por canales paralelos (el eterno chat). Pérdida de seed / HSM sin DR. Lista blanca mal mantenida.
Riesgos técnicos
Dependencia de un solo nodo Bitcoin mal administrado. Confusión entre watch-only y hot wallet. Vendor lock-in si el Estado no conserva exports y descriptores.
Riesgos legales
Confundir software non-custodial con actividad de intermediación. Operar sin competencia legal del vehículo. Ignorar régimen de contrataciones y control fiscal.
Lo que TreasOS no resuelve
Legitimidad política. Diseño constitucional. Emisión monetaria. Cobranza tributaria. Justicia. Volatilidad del precio de Bitcoin. La voluntad de no hacer trampa.
El software es un multiplicador de disciplina cuando hay disciplina que multiplicar. Sin ella, automatiza el desorden.
Capítulo 11 — Cierre: soberanía con proceso, en venezolano
América ya enseñó, en el libro de nodos soberanos, que el héroe operativo es un riesgo sistémico. Venezuela enseña que ese héroe, cuando se pone la camiseta del Estado, no solo arriesga un balance: arriesga la confianza pública.
El modelo que sostengo es sobrio a propósito:
Bitcoin como ancla posible de reserva o liquidación en un vehículo acotado.
Ley y reglamento como fuente de quién gasta y con qué techo.
TreasOS como plano de control watch-only: política, maker-checker, evidencia.
Claves en el perímetro de la República.
Frontera honesta: el software no dictamina; el órgano competente sí.
No pido que Venezuela “se convierta en Bitcoin”. Pido que, si alguna parte del Estado va a tocar satoshis, lo haga como República: con proceso, con separación de funciones, con rastro — y con un servidor que no pueda gastar.
Eso es todo el libro en una frase. El resto fue para que nadie la confunda con un slogan.
Joubert López
Trebuoj Zepol · TreasOS
treasos.com
Rutas de este trabajo:docs/modelo-gobierno-pais-btc/venezuela/ · diagrama y libro HTML en la misma carpeta.