Resumen de la Arquitectura

Topología de seis capas

┌──────────────────────────────────────────────────────────┐
│  L0 — Telegram Bot API                                   │
│      • Bot framework (Telegraf, Node)                    │
│      • WebApp UI (Next.js, TON Connect)                  │
│      • Inline keyboards + WebApp launches                │
├──────────────────────────────────────────────────────────┤
│  L1 — Round Engine                                       │
│      • Deterministic FSM (Go)                            │
│      • Phases: Announce → Commit → Reveal → Settle       │
│      • Commit-Reveal verification                        │
│      • Merkle Root construction                          │
├──────────────────────────────────────────────────────────┤
│  L2 — Oracle Aggregator                                  │
│      • Question reservoir (Postgres + IPFS)              │
│      • LLM ensemble pipeline (Claude + GPT + Gemini)     │
│      • Adversarial debiaser                              │
│      • DRAND beacon fetcher                              │
│      • TON-VRF poll                                      │
├──────────────────────────────────────────────────────────┤
│  L3 — Identity Layer                                     │
│      • Trust Ladder L0–L7 state machine                  │
│      • Worldcoin / PoH / Gitcoin Passport adapters       │
│      • KYC vendor integration (Sumsub)                   │
│      • Reputation Score Bayesian updater                 │
├──────────────────────────────────────────────────────────┤
│  L4 — Ad-Revenue Settlement                              │
│      • AdMob SDK (mobile + WebApp)                       │
│      • Telegram Ads SDK                                  │
│      • AdMob SSV callback receiver                       │
│      • zk-SNARK prover (SP1, Phase 2)                    │
├──────────────────────────────────────────────────────────┤
│  L5 — TON Settlement                                     │
│      • $POP Jetton contract (FunC)                       │
│      • Vesting wrapper contract                          │
│      • Round Merkle Root commit contract                 │
│      • Dispute resolution contract                       │
│      • DAO governance contracts (Phase 3)                │
└──────────────────────────────────────────────────────────┘

Flujo de datos

El usuario toca "Jugar" en Telegram
    ↓
L0: Se abre la WebApp, solicita entrada al Round (ronda)
    ↓
L4: Se muestra anuncio (AdMob), se espera callback SSV
    ↓
L4: SSV verificado → se emite crédito POP (puntos)
    ↓
L1: El usuario recibe la pregunta del Round (desde L2)
    ↓
L1: El usuario realiza Commit (compromiso) c_i durante la fase Commit
    ↓
L1: El usuario revela (s_i, b_i) durante la fase Reveal (revelación)
    ↓
L1: El Round Engine calcula la mayoría, construye Merkle Root (raíz Merkle)
    ↓
L3: Peso efectivo = α × r_i aplicado
    ↓
L1: Prize Pool (fondo de premios) distribuido a los supervivientes
    ↓
L5: Merkle Root enviado a TON (lote cada 24h)
    ↓
El usuario ve crédito POP + resultado del Round en la WebApp

Presupuesto de latencia

Fase	Objetivo	Real (P50)	Real (P95)
Announce (anuncio)	5 s	4,2 s	4,8 s
Commit	30 s	29,5 s	30 s
Reveal	15 s	14,7 s	15 s
Settle (liquidación)	10 s	7,3 s	9,8 s
Total del Round	60 s	55,7 s	59,6 s

La fase Settle incluye la construcción y verificación del Merkle Root; el envío on-chain a TON se agrupa por separado con una cadencia de 24 horas.

Infraestructura

• Alojamiento: Cloudflare Workers + R2 + KV (distribuido en el borde, baja latencia).
• Base de datos: Postgres (principal), Redis (estado del Round, efímero), R2 (artefactos del Round, archivo).
• Round Engine: binario Go sin estado; escalable horizontalmente detrás del anycast de Cloudflare.
• Cliente TON: SDK ton-core; conexiones a nodos completos mediante TonAPI Cloud.
• Observabilidad: OpenTelemetry → Grafana Cloud; Sentry para errores de cliente.

Componentes de código abierto

• Round Engine: MIT, github.com/cashpop-protocol/round-engine
• WebApp: MIT, github.com/cashpop-protocol/webapp
• Smart contracts (post-TGE): MIT, github.com/cashpop-protocol/contracts
• Pipeline de construcción del reservoir de preguntas: fuente disponible, github.com/cashpop-protocol/reservoir

La pila completa de CashPop será auto-alojable después del TGE: cualquier operador puede poner en marcha una instancia bifurcada, aunque no podrá emitir $POP sin aprobación de la DAO.