1. Qué construimos
CulturaGO Tickets es un prototipo de ticketing para eventos culturales. La hipótesis fue simple: una entrada no debería perder todo su valor después del acceso, sino transformarse en una prueba verificable de participación.
Una entrada cultural no termina cuando entras al evento. Puede convertirse en evidencia de que participaste de la cultura.
El flujo completo del MVP fue: Evento → Ticket → QR → Check-in → Ticket USED → Prueba en Stellar → Pasaporte Cultural.
2. El desafío: IDEA → RAVEN → BUILD → STELLAR
El enfoque del Builder Night evitaba comenzar por una tecnología. En vez de decidir de antemano “hagamos un NFT” o “usemos Soroban”, primero definimos el problema y usamos Raven MCP para investigar qué componentes reales del ecosistema Stellar tenían sentido.
3. Qué rol cumplió Raven MCP
Raven funcionó como fuente especializada de conocimiento Stellar para el agente de IA. El servidor MCP utilizado fue:
https://raven.stellar.org/mcpLe planteamos el problema de ticketing sin imponer una arquitectura: ownership, QR, single-use, check-in, prueba de asistencia y futura integración con un Pasaporte Cultural.
4. Tres arquitecturas consideradas
| Alternativa | Idea | Complejidad | Decisión |
|---|---|---|---|
| Soroban full on-chain | Contrato controla el ciclo completo del ticket. | Alta | Descartada para el tiempo disponible. |
| Stellar Classic | ManageData, cuentas, memo y Horizon. | Media-baja | Viable, pero menos flexible para UX inmediata. |
| Arquitectura híbrida | QR firmado off-chain + prueba de asistencia en Stellar Testnet. | Media | Elegida. |
La arquitectura híbrida separó dos necesidades distintas: validar el acceso con rapidez y registrar posteriormente una prueba verificable.
5. Cómo se firma un ticket
El ticket contiene datos como ticketId, eventId, nombre del asistente, timestamp y nonce. CulturaGO firma ese contenido usando Ed25519.
{
ticketId: "CG-SBN-7711",
eventId: "sbn-2026-culturago",
attendeeName: "Alex",
issuedAt: 1787260000,
nonce: "n9284x",
signature: "..."
}La private key no se incluye nunca en el QR. La firma permite comprobar que el contenido no fue alterado.
6. Trusted issuer: por qué no basta con una firma válida
Durante la revisión final apareció un detalle de seguridad importante: un QR no puede definir por sí mismo cuál es la clave pública confiable. Un atacante podría crear su propio par de claves y firmar su propio payload.
Por eso el scanner verifica la firma contra una clave pública de CulturaGO conocida por la aplicación. Si la clave del QR no coincide, se rechaza como UNTRUSTED_ISSUER.
7. Check-in y single-use
El scanner valida, en orden: estructura del QR, firma Ed25519, emisor confiable, existencia del ticket y estado de uso. Si todo es correcto, el ticket pasa de VALID a USED.
VALID → CHECK-IN SUCCESSFUL → USED
USED → TICKET ALREADY USEDEn este MVP el estado se mantiene en un repositorio en memoria. Esto demuestra la lógica single-use, pero no es todavía un sistema antifraude distribuido para múltiples puertas o scanners simultáneos.
8. Dónde entra Stellar
Después del check-in, el sistema envía una transacción real a Stellar Testnet usando @stellar/stellar-sdk, Horizon, ManageData y Memo.
https://horizon-testnet.stellar.org
StellarSdk.Networks.TESTNETEl objetivo no es almacenar todo el ticket on-chain. Stellar actúa como infraestructura de prueba de asistencia.
9. Qué significa que esté en Testnet
Testnet es la red de desarrollo y pruebas de Stellar. No usa valor económico real y es apropiada para prototipos, hackathons y validación técnica.
Una transacción real generada durante el proyecto fue:
fc4ad59d6db363839ce493a91e644a8379e4fbd59be82dc4c539733de1d57601Ver en Stellar Expert Testnet →
10. Stellar como infraestructura invisible
La experiencia para el usuario sigue siendo Web2: obtiene un ticket, muestra un QR y entra al evento. No necesita wallet, seed phrase, XLM ni firmar transacciones manualmente.
Stellar debajo del producto, no delante del usuario.
11. El puente hacia el Pasaporte Cultural
Después del check-in, la asistencia puede alimentar un perfil de participación: festivales, conciertos, museos, talleres y otras experiencias. El ticket deja de ser un simple permiso de acceso y se convierte en el inicio de un historial cultural verificable.
12. Qué corregimos durante el desarrollo
- Eliminamos cualquier posibilidad de confiar ciegamente en la public key del QR.
- Eliminamos un fallback que podía generar un hash local y confundirlo con una transacción real de Stellar.
- Separamos claramente
USED,CONFIRMEDySTELLAR_UNAVAILABLE. - No se guardan secret keys en Git ni dentro del QR.
13. Stack utilizado
| Frontend | React, TypeScript, Vite, Tailwind CSS |
|---|---|
| Criptografía | Ed25519 mediante Stellar SDK |
| Blockchain | Stellar Testnet, Horizon, ManageData, Memo |
| IA | Vibe coding + Raven MCP |
| Infraestructura | GitHub + Vercel |
14. Qué faltaría para producción
- Backend seguro para emisión y firma.
- Persistencia real de tickets y check-ins.
- Concurrencia y múltiples scanners.
- Autenticación de operadores.
- KMS/HSM para claves.
- Evaluar Soroban para estado distribuido y reglas de negocio.
- Pagos, transferencia y reventa controlada.
15. Aprendizajes principales
- Blockchain no significa necesariamente token.
- Un ticket no necesita obligatoriamente ser NFT.
- No todo debe vivir on-chain.
- Una arquitectura híbrida puede mejorar UX y reducir complejidad.
- Raven fue más útil como herramienta de arquitectura que como simple buscador de documentación.
- Diferenciar MVP de producción evita vender capacidades que aún no existen.
16. Conclusión
El principal resultado fue demostrar una vertical completa: Evento → Ticket → QR → Check-in → USED → Stellar Proof → Participation Verified.
No construimos un “ticket blockchain”. Construimos un ticket cultural y usamos Stellar solamente donde aportaba valor.
Eso deja una base concreta para evolucionar CulturaGO Tickets hacia un componente real del Pasaporte Cultural.