República con proceso

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.

→ Resumen visual (diagramas e ilustraciones)

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

CapacidadUso en Venezuela (piloto)
Wallets watch-only (xpub / descriptors)Visibilidad de saldos del fondo / entidad sin subir claves
Motor de políticaTechos, ventanas temporales, whitelist de destinos
Maker-checker + RBACTesorería propone; contraloría / segundo rol aprueba
Flujo PSBTFirma en HSM/cold nacional; TreasOS no firma con autoridad de gasto
Audit log / portal auditorEvidencia para Contraloría, auditoría externa, archivo
BIP-322 proof of reservesTransparencia selectiva de reservas cuando se decida publicar
Multi-tenant / vehículosVarios fondos o entidades aislados en un despliegue
Self-host / on-premNodo 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 EstadoAnalogíaRol en TreasOS
Legislativo / presupuestoAprueba techos y partidasPolítica: límites, ventanas, whitelist
Ejecutivo / tesoreríaPropone pagosInitiator / operator
Contraloría / control previo o concurrenteSegunda mirada humanaApprover / quorum
Custodia de clavesHSM / cold / multisig bajo régimen de seguridad del EstadoFuera del servidor; solo firma PSBT offline
Auditoría / ciudadanía (cuando aplique)Fiscalización posterior / transparenciaAudit 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 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ículoEn configuración TreasOS
Quién puede ser ordenador de pagoMapeo de esos roles a RBAC
Techos del ejercicioLímites numéricos y ventanas
Destinos permitidos (categorías)Whitelist concreta (direcciones / políticas)
Deber de archivo y fiscalizaciónRetención de logs y export de packs
Régimen de claves del EstadoIntegració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.