Smart Contracts

Todos los contratos en cadena se implementan en el TGE (Q1–Q2 2027). Antes del TGE, esta página es una especificación prospectiva.

Suite de contratos

Contrato	Red	Propósito
POP_Jetton	TON	Token $POP (estándar Jetton TEP-74)
POP_Vesting	TON	Envoltorio de vesting por bucket, aplica cliff + liberación lineal
Round_Merkle_Registry	TON	Almacena las Merkle Roots (raíces de Merkle) por Round (ronda), admite verificación de pruebas
Dispute_Resolver	TON	Ventana de disputa de 24 horas, penaliza al operador ante un desafío válido
Treasury	TON	Desembolso de fondos controlado por la DAO
Governance	TON	Sistema de votación cuadrática + propuestas ponderadas por reputación
Burn_Address	TON	Recibe $POP de la quema por tarifas; verificablemente no gastable
Ad_Settlement_Verifier	TON	Verificador Groth16 para vistas de anuncios atestiguadas con zk (Fase 2)

Especificación del Jetton $POP

• Estándar: TEP-74 (TON Jetton)
• Metadatos: Metadatos en cadena TEP-64
• Nombre: CashPop
• Símbolo: $POP
• Decimales: 9 (coincide con la convención de TON)
• Suministro total: 10 000 000 000 × 10^9 = 10^19 unidades base
• Acuñable: No (limitado en la implementación)
• Quemable: Sí (por cualquier titular, sin privilegio requerido)
• Actualizable: No (el Jetton en sí es inmutable; los envoltorios pueden evolucionar)

Lógica del contrato de Vesting

Cada bucket de asignación recibe su propia instancia de POP_Vesting. Parámetros por instancia:

• beneficiary: dirección autorizada para reclamar
• total_amount: total de Jettons bloqueados
• cliff_end: timestamp antes del cual no se permiten reclamaciones
• linear_end: timestamp en el que el 100% es reclamable
• claimed: total acumulado de reclamaciones

El monto liberable en el tiempo t:

releasable(t) =
    if t < cliff_end: 0
    elif t >= linear_end: total_amount
    else: total_amount * (t - cliff_end) / (linear_end - cliff_end)

Menos lo ya reclamado. Sin desbloqueo anticipado bajo ninguna condición.

Round Merkle Registry (Registro de Merkle por Round)

El Round Engine (motor de rondas) compromete una Merkle Root de 32 bytes para cada Round, agrupada cada 24 horas en una sola transacción de TON:

struct RoundBatch {
    uint64 batch_id;
    bytes32[] round_roots;   // hasta 1440 raíces por lote (60s × 1440 = 24h)
    uint64 first_round_id;
}

Cualquier usuario puede enviar:

• ID de Round r
• Ruta de prueba de Merkle p
• Resultado reclamado (participant, commit, reveal, weight)

El contrato verifica la prueba de Merkle contra la raíz en cadena. Si es válida, el resultado se reconoce; si no, el usuario puede abrir una disputa.

Dispute Resolver (Resolvedor de Disputas)

Ante una disputa válida:

• El Round se marca como nulo.
• El operador pierde 1000 $POP de un stake (apuesta) vinculado, que se transfiere al Treasury.
• Los usuarios afectados reciben un reembolso del Prize Pool (fondo de premios) del Round.
• El Round se vuelve a liquidar a partir de los registros canónicos del Engine.

Contratos de Gobernanza

Tres contratos:

• Proposal_Registry: almacena propuestas, rastrea el ciclo de vida.
• Vote_Tallying: recuento de votos cuadráticos con ponderación por reputación.
• Execution_Module: ejecuta propuestas aprobadas (cambios de parámetros, desembolsos del Treasury).

Consulte Gobernanza para conocer el ciclo de vida completo.

Plan de auditoría

• Revisión interna: continua, por el equipo del protocolo + asesores externos.
• Auditoría externa 1: dirigida a Trail of Bits, Q3 2026.
• Auditoría externa 2: dirigida a OtterSec, Q4 2026.
• Bug bounty: lanzado en el TGE con una asignación del Treasury de hasta $500 000 por hallazgo crítico.

Los contratos no se implementarán en mainnet sin dos auditorías externas limpias.