Boleto Guardian

1. Resumen ejecutivo

Boleto Guardian es el primer producto de Guardian Labs — marca matriz enfocada en infraestructura pública de autenticidad para las claves que mueven dinero en Brasil (boletos hoy; otros instrumentos en la hoja de ruta). La empresa emisora registra cada boleto en la blockchain Stellar; el pagador valida en segundos con los 44 a 48 dígitos del código de barras o de la línea digitável, sin app, registro ni jerga técnica.

Brasil emite más de 4 mil millones de boletos bancarios al año. Ese volumen convive con pérdidas elevadas por fraude digital que incluye boletos y otros medios (ClearSale, 2024; Finsiders, 2024).

Boleto Guardian crea una prueba pública, inmutable y auditable de autenticidad. Para el MVP del programa Stellar 37 Degrees, el producto también demuestra SEP-10 contra un ancla en Testnet (testanchor.stellar.org): Guardian actúa como relying party — no es un ancla — y sigue registrando boletos vía Manage Data.

La integración es por API REST con cualquier ERP; en este whitepaper usamos TOTVS Protheus como referencia, replicable a Sankhya, Omie y otros.

2. El problema

2.1 El escenario de fraude en Brasil

El boleto bancario es un pilar del sistema financiero brasileño. Presente en transacciones B2B, B2C y gubernamentales, atiende desde grandes corporaciones hasta consumidores finales. Su popularidad lo convirtió en uno de los blancos preferidos de los delincuentes digitales.

• 4 mil millones de boletos emitidos anualmente en Brasil (FEBRABAN)
• R$ 25 a 29 mil millones en pérdidas por fraude digital, incluyendo boletos y PIX
• El fraude del boleto adulterado figura entre las modalidades más comunes de delito digital en el país

2.2 Cómo ocurre la fraude

El ciclo de fraude explota vulnerabilidades en varios puntos de la cadena:

  Empresa emite      Boleto en tránsito  Delincuente        Pagador recibe
  boleto legítimo                    intercepta         boleto adulterado
  +-----------+        +-----------+        +-----------+        +-----------+
  | ERP       |        | E-mail,   |        | Altera     |        | Paga a    |
  | genera    | -----> | portal    | -----> | codebar    | -----> | cuenta    |
  | boleto    |        |           |        | o datos    |        | errónea   |
  +-----------+        +-----------+        +-----------+        +-----------+

Técnicas más comunes: interceptación de e-mails con sustitución del código de barras; malware que altera la línea digitável en visualización o impresión; ingeniería social con boletos falsos; adulteración física de boletos impresos.

2.3 La brecha de confianza

El problema fundamental es la ausencia de una capa de verificación pública y fiable entre empresa, institución financiera y pagador. Hoy el pagador depende exclusivamente de la confianza en el remitente. No existe un mecanismo público y a prueba de adulteración para verificar si el boleto recibido es idéntico al emitido por la empresa.

2.4 Limitaciones de las soluciones actuales

Todas comparten una falla común: el pagador no tiene autonomía para validar el boleto de forma independiente, pública e instantánea.

2.5 Dolores priorizados y personas

Dolores (P1?P4): (1) no saber si el boleto es el mismo que emitió la empresa; (2) pagar y el dinero ir al estafador; (3) empresa acusada injustamente de boleto falso; (4) ERP/banco no dan prueba simple al pagador.

2.6 Persona objetivo: Camila (finanzas de PYME)

Camila (nombre representativo) es gerente financiera o controller en una PYME brasileña que emite miles de boletos al mes (p. ej. Protheus, Sankhya, Omie). Sus dolores se suman: fraude descubierta tarde — el cliente pagó un boleto adulterado, cobranza, crisis con la dirección — y fricción diaria — horas confirmando autenticidad con clientes desconfiados. Boleto Guardian ataca ambos: riesgo reputacional y eficiencia operativa.

Otras personas: Pagador — validar con 44 a 48 dígitos; TI/ERP — API e integración; Compliance — trazabilidad sin datos personales on-chain.

3. La solución: Boleto Guardian

3.1 El concepto

Boleto Guardian resuelve la brecha de confianza de forma directa: al emitir un boleto, la empresa registra la línea digitável en la blockchain Stellar. A partir de ahí, cualquier persona que tenga el boleto puede verificar su autenticidad consultando la blockchain.

El código de barras numérico tiene 44 dígitos. La línea digitável suele tener 47 dígitos en boletos bancarios o 48 en boletos de concesionaria o de recaudación (layouts FEBRABAN). La validación acepta de 44 a 48 dígitos porque el pagador puede informar solo el código o la línea completa. La secuencia es única por boleto, impresa en el documento y compacta (cabe en los 64 bytes del Manage Data de Stellar). Esto elimina la necesidad de que el usuario conozca información técnica. El boleto es la propia credencial de consulta.

3.3 Stellar Manage Data

La blockchain Stellar ofrece de forma nativa la operación Manage Data: pares clave-valor en la cuenta del usuario. Clave hasta 64 bytes (línea digitável); valor hasta 64 bytes (nuestro número, valor, vencimiento, estado). No exige smart contracts ni infraestructura compleja.

3.4 Una cuenta por empresa

Cada empresa emisora tiene una única cuenta en la red Stellar. Todos los boletos quedan registrados en esa cuenta. El Account ID se configura una vez en la API — el usuario final nunca necesita conocerlo.

  Empresa (ej: DS2U)   Cuenta Stellar: GABCD...XYZ
  +--------------------------------------------------+
  | Manage Data    key: 23793.38128...004001...      |
  |               val: 000000040|120.50|20250805|pendiente
  |               key: 23793.38128...004002...        |
  |               val: 000000041|350.00|20250810|pendiente
  |               ... (todos los boletos de la empresa)
  +--------------------------------------------------+

3.5 Validación sin fricción

1) El pagador recibe el boleto. 2) Accede a la página de validación (o código QR). 3) Digita los 44 a 48 números del código de barras. 4) El sistema consulta Stellar y muestra los datos originales. 5) Si los datos coinciden, el boleto es auténtico. Si el código no existe en la blockchain, el boleto no fue emitido por la empresa — posible fraude.

4. Arquitectura conceptual

4.1 Visión general

Tres capas: ERP ? API Boleto Guardian ? red Stellar. El pagador usa la página pública de validación (44 a 48 dígitos). Para registro y panel autenticados en el MVP web, la API integra SEP-10 con el ancla testanchor.stellar.org (la wallet firma el desafío; JWT en sesión). La integración estilo ERP sigue disponible por endpoints administrativos.

Abrir flujo de login SEP-10 (panel)

+-------------------+       +-------------------+       +-------------------+
|   SISTEMA ERP     |       |  API MIDDLEWARE   |       | REDE STELLAR      |
| Genera boletos    | POST  | Recibe, valida,   |  TX   | Manage Data       |
| Envía codebar     |------>| construye TX,     |----->| Registro inmutable|
+-------------------+       | firma y envía     |       | Consulta pública  |
                            +--------^--------+       +-------------------+
                                     | GET
                            +--------+--------+
                            |  USUARIO FINAL   |
                            | Digita codebar   |
                            +-----------------+

4.2 Los tres momentos

Momento 1 — Emisión: El ERP genera el boleto y envía línea digitável y metadatos a la API. Momento 2 — Registro en la blockchain: La API valida, monta la transacción Manage Data y envía a la red; en ~5 segundos el registro está confirmado e inmutable. Momento 3 — Validación pública: Cualquier persona consulta la blockchain con la línea digitável; la API devuelve los datos originales para comparación.

4.3 Integración con ERP

Boleto Guardian es agnóstico al ERP. La comunicación es vía HTTP (REST). Usamos TOTVS Protheus como referencia; la misma integración puede replicarse para Sankhya, Omie, SAP, Oracle o cualquier ERP que soporte peticiones web.

5. ¿Por qué Stellar?

La elección de la blockchain es crítica. Boleto Guardian exige una red rápida, barata, segura y de fácil integración. Stellar cumple todos los requisitos.

5.2 Manage Data: operación nativa

A diferencia de blockchains que exigen smart contracts para almacenar datos, Stellar lo ofrece de forma nativa en el protocolo: sin escribir ni auditar contratos, sin riesgos de vulnerabilidades. Simplicidad que reduce desarrollo, mantenimiento y auditoría.

5.3 Costo operativo

Cada transacción cuesta aproximadamente 0,00001 XLM. El costo por boleto registrado permanece en el orden de fracciones de centavo. Comparación:

5.4 Finalidad rápida

Transacciones confirmadas en aproximadamente 5 segundos, con finalidad absoluta. No es necesario esperar múltiples confirmaciones como en blockchains proof-of-work.

5.5 Red pública y descentralizada

Cualquiera puede consultar datos de cualquier cuenta (Stellar Explorer, Horizon API), verificar el historial y auditar registros de forma independiente. Esta transparencia es fundamental para una capa de confianza que no dependa de una entidad centralizada.

5.6 Gobernanza

La red es mantenida por la Stellar Development Foundation (SDF), organización sin fines de lucro dedicada al desarrollo del protocolo y a la inclusión financiera global.

6. Viabilidad y escalabilidad

Costo favorable: El costo por boleto registrado es órdenes de magnitud menor que el perjuicio medio de una sola fraude. Reserva XLM: Cada entrada Manage Data consume una pequeña reserva en la cuenta de la empresa; a escala, es manejable y predecible. Escalabilidad: Stellar procesa miles de transacciones por segundo con ~5 s de confirmación; la API es stateless y escalable horizontalmente. Mercado direccionable: 4 mil millones de boletos/año en Brasil, con crecimiento estimado del 15% anual.

7. Seguridad, privacidad y cumplimiento

7.1 Inmutabilidad

Una vez registrado en Stellar, un Manage Data solo puede ser alterado por una nueva transacción firmada por la clave de la cuenta. Terceros no pueden adulterar; cualquier cambio genera una transacción visible en el historial.

7.2 Protección de la clave

La clave privada de la cuenta Stellar de la empresa es el único activo sensible. Debe almacenarse en un entorno seguro (cofre digital, HSM o almacenamiento cifrado) y nunca exponerse al usuario final. La API debe operar con HTTPS obligatorio.

7.3 Privacidad por diseño — LGPD

Ningún dato personal se almacena en la blockchain. La línea digitável y los metadatos no identifican al pagador. Nombre, CPF/CNPJ y dirección nunca se registran on-chain. El sistema es compatible con la LGPD desde la concepción.

7.4 Transparencia y auditoría

Los datos en Stellar son públicos. Cualquiera puede auditar vía Stellar Explorer; los reguladores pueden verificar la integridad; la empresa demuestra transparencia sin esfuerzo adicional.

7.5 Infraestructura de producción

8. Estrategia de adopción

Alianzas con consultorías ERP: Consultorías certificadas (TOTVS, Sankhya, Omie) tienen acceso directo a bases de clientes. Integraciones nativas: Módulos en los ERPs líderes, disponibles en marketplaces oficiales. Modelo white-label: La solución puede ser rebrandeada por ERPs y fintechs. Contratos corporativos directos: Para grandes empresas con alto volumen de emisión, con customizaciones y SLAs diferenciados.

Cuantas más empresas adoptan, más boletos se registran, más usuarios validan, mayor la confianza del mercado — creando un ciclo virtuoso de adopción.

9. Visión de futuro

Boleto Guardian es el primer producto de Guardian Labs; el mismo enfoque de autenticidad pública puede extenderse a otros documentos críticos:

• Próximo paso — Liquidación en Boleto Guardian: Evolucionar para que la liquidación del boleto (confirmación de pago y cierre del ciclo) ocurra en el propio entorno del producto, integrada con la validación y el registro on-chain.
• Seguridad — Firma con HSM (HSM2): Hoja de ruta para una versión en que las transacciones Stellar se firmen vía HSM (Hardware Security Module), incluyendo perfiles de cumplimiento como FIPS 140-2 Level 2, sin mantener la clave privada en software en la API.
• Fase 1 — Estándar nacional en boletos: Consolidar como referencia en validación de boletos en Brasil, con integración en los principales ERPs y reconocimiento como sello de seguridad.
• Fase 2 — Notas fiscales electrónicas: Validar NF-e y NFS-e, combatiendo fraude en documentos fiscales.
• Fase 3 — Contratos digitales: Registro inmutable de términos, firmas y cambios contractuales.
• Fase 4 — Infraestructura nacional de confianza: Plataforma como capa de validación digital de Brasil, con APIs públicas para documentos gubernamentales y privados.

10. Conclusión

El mercado brasileño de boletos mueve miles de millones de transacciones al año, y la fraude representa uno de los mayores desafíos de seguridad financiera. La ausencia de una capa de verificación pública, inmutable y accesible entre emisor y pagador es cubierta por Boleto Guardian de forma elegante y eficiente.

Al usar la blockchain Stellar y su operación nativa Manage Data, la solución prescinde de smart contracts complejos, opera con costo mínimo y ofrece confirmación en segundos. La línea digitável como clave de consulta garantiza que el usuario no precise conocimiento técnico — basta tener el documento en mano.