# Origin Chain — Remediation Roadmap V1 (plan ejecutable de fixes)

**Documento**: `docs/REMEDIATION_ROADMAP_V1.md`
**Versión**: 1.0
**Filed**: 2026-05-27 (sesión 4+ Charon, Opus 4.8)
**Fuente**: consolida los 12 críticos + ~20 highs de la trilogía de audits (V1+V2+V3), convertidos en planes de fix ejecutables y verificados adversarialmente (el red-team filtró 1 fix peligroso).
**Propósito**: que David tenga UN plan ordenado — qué se arregla, en qué orden, con qué esfuerzo, sin introducir regresiones. Esto es el camino de "pre-testnet con plomería incompleta" a "extremadamente bien, sin bugs".

---

## §0 — Cómo leer este roadmap

Los fixes están agrupados por causa-raíz (no por bug individual — muchos bugs comparten raíz) y ordenados por **dependencia**. El red-team de V3 verificó cada plan; sus correcciones están integradas (marcadas ⚠️). Un fix que el red-team rechazó NO está aquí como ejecutable — está como "requiere paso previo".

Esfuerzo: S (horas) · M (1-2 días) · L (varios días / requiere coordinación).

**Regla de oro greenfield**: la cadena es pre-testnet, sin estado real. Los fixes pueden cambiar storage libremente AHORA (sin carga de migración) — esta ventana se cierra cuando lance testnet. Por eso conviene arreglar antes de testnet.

---

## §1 — SECUENCIA DE FIXES (orden de ejecución)

### FIX-1 — Contract safety (reentrancy + burn real + escrow) — **el más limpio, primero**
**Bugs**: V1-C1 (reentrancy x4), V1-C4 (zero-burn), V1-H7 (escrow milestone sum).
**Red-team**: ✅ "Ship — diagnóstico exacto, fix bien-ordenado." El único con luz verde sin precondiciones.
**Fix**: reordenar a Checks-Effects-Interactions en escrow `confirm_milestone`/`resolve_dispute`, staking `withdraw`/`slash`, nft `transfer` — mutar TODO el storage ANTES de cualquier `transfer()`. Plantilla: `origin-credential-mint::issue` ya lo hace bien.
**Burn real**: reemplazar `transfer([0u8;32])` por reducir-lo-que-se-cobra (no pagar el burn) — y usar el MISMO primitivo de burn que use el fee/treasury (⚠️ red-team: evitar dos semánticas de burn).
**Escrow**: enforce `Σ milestone.amount == total_amount` + path de sweep terminal.
**Tests obligatorios**: reentrancy/double-spend en escrow+staking (los que V3 marcó ausentes).
**Esfuerzo**: M. **Riesgo de regresión**: bajo (CEI es un patrón estándar).

### FIX-2 — Lifecycle hardening (StorageVersion + AGI key recovery + weights)
**Bugs**: V1-H2/V2-CA2 (no StorageVersion/migrations), V2-H1 (AGI key irrecuperable), V1-H1/V3-H4 (placeholder weights).
**Red-team**: ✅ "Ship hardening; gate AGI key-recovery en el modelo de autoridad #41."
**Fix**: `StorageVersion::new(0)` en los 4 pallets (S, trivial). AGI key: añadir `rotate_key`/`revoke`/campo `active` a agent-identity, con recovery vía autoridad #41 (multisig humano del agent_chain). Weights: `frame-benchmarking` + `WeightInfo` por pallet (L — pero crítico para Pi 5 anti-spam).
**Esfuerzo**: S (StorageVersion) + M (key recovery) + L (benchmarking).

### FIX-3 — Crypto hardening (domain separation + replay guard + DID binding)
**Bugs**: V3-C1 (replay cross-chain), V3-H1 (DID front-running), V3-H2 (derive_did domain sep).
**Red-team**: implícito ✅ (primitivos sólidos, gaps arquitecturales).
**Fix**: (a) prefijar el signing payload de atestación con `b"origin-chain/attestation/v1" || genesis_hash`; (b) `register_agent_did` requiere firma por `public_key` sobre `who`; (c) `derive_did` usa `blake3::derive_key("origin-chain did v1", pk)`.
**Esfuerzo**: M. **Riesgo**: bajo, pero cambia el formato de firma → hacerlo ANTES de cualquier anclaje en testnet.

### FIX-4 — Credential signature verify (V3-C2 / V1-H8)
**Bugs**: la firma de credencial nunca se verifica.
**Red-team**: ⚠️ "gate en el payload real de Ergon (DC), no contra una spec fabricada."
**Fix**: verificar `issuer_signature` vía `sp_io::crypto::ed25519_verify` sobre un payload que NO incluya campos seteados on-chain (issued_at/expires_at deben venir del caller o salir del payload firmado). Requiere fijar el payload de credencial primero.
**Esfuerzo**: M. **Precondición**: definir el signing payload canónico de credencial.

### FIX-5 — Governability (Root origin + sudo→governance) — **desbloquea todo lo demás**
**Bugs**: V2-CA1 (no Root origin, cadena no-gobernable).
**Red-team**: ⚠️ "Ship después de: bound `Config: Currency` + wiring de runtime + mostrar el sudo-sunset."
**Fix**: wire `pallet-sudo` para testnet (da Root origin → las 7 dispatchables admin funcionan). Plan de sunset: migrar de sudo a governance real (pallet-collective/referenda) antes de mainnet. ⚠️ Coordinar con FIX-6 quién cablea el SessionManager (no que dos planes lo medio-cableen).
**Esfuerzo**: S (sudo) + L (governance real + sunset).

### FIX-6 — Economic model real (emisión + validator pay + fee unificado + subsidio financiado)
**Bugs**: V2-CA2 (no inflation/validators unpaid), V2-CA3 (dual compute_fee, subscription erosiona anti-clasista), V2-H3 (subsidio sin financiar), V1/V2 fake APR, V3-C3 (constitución no en fee-path vivo).
**Red-team**: ⚠️ "Ship después de: separar fee-routing de NPoS; confirmar con David la intención del sub_mult." (la pregunta: ¿debe la suscripción premium reducir el subsidio de hardware, o son ortogonales? V2 dice que erosiona el anti-clasista → probablemente deben ser ortogonales).
**Fix**: (a) wire `pallet_staking` + `EraPayout` para emisión real → validadores cobran (cierra CA2); (b) UNA sola `compute_fee` + `OnChargeTransaction` custom que la consuma → la constitución entra al fee-path vivo (cierra CA3+V3-C3); (c) `GlobalSubsidyPool` financiado (= proof-of-equity, V1 idea 1); (d) remover los números APR de staking hasta que exista motor real.
**Esfuerzo**: L (el cuerpo grande — es "Phase economía real").

### FIX-DEFERRED — Cross-pillar attestation payload (V2-CA4)
**Estado**: 🔴 **NO construir como fix de código.** El red-team probó que mi V2-CA4 citaba un archivo inexistente.
**Acción correcta**: abrir Design Contract con Ergon para ratificar el formato canónico del signing payload de atestación (SCALE vs postcard, campos, orden) ANTES de lockear cualquier verificador on-chain. Solo después FIX-4 (credential) y el verifier de provenance se construyen contra una spec real.
**Esfuerzo**: coordinación cross-pillar (no código de Charon solo).

---

## §2 — Orden recomendado + por qué

```
FIX-1 (contract safety)     ← primero, limpio, sin precondiciones, alto impacto
   ↓
FIX-2 (lifecycle hardening) ← StorageVersion trivial + key recovery + weights
   ↓
FIX-3 (crypto hardening)    ← antes de cualquier anclaje testnet
   ↓
FIX-5 (governability/sudo)  ← desbloquea admin + treasury
   ↓
FIX-6 (economic model)      ← el cuerpo grande, pre-testnet-con-valor
   ↓
[DC Ergon attestation payload] → FIX-4 (credential verify)
```

FIX-1/2/3 son construibles AHORA (no dependen del node ni de VPS). FIX-5/6 idealmente con el node real (VPS). FIX-4 espera el DC con Ergon.

---

## §3 — Lo que el red-team rechazó o corrigió (transparencia)

| Fix | Veredicto red-team | Acción |
|-----|-------------------|--------|
| contract-safety | ✅ Ship | FIX-1 |
| lifecycle-ops | ✅ Ship hardening | FIX-2 |
| governance-root | ⚠️ Config-bound + sudo-sunset faltaban | FIX-5 con esas adiciones |
| economic-model | ⚠️ anti-clasista invertido + NPoS muy grueso | FIX-6 con fee-routing separado de NPoS + pregunta a David |
| crosspillar-encoding CA4 | 🔴 **REJECT — citaba archivo inexistente** | FIX-DEFERRED (DC con Ergon primero) |

**Una pregunta abierta para David** (FIX-6): ¿la suscripción premium (Pro/Ultra) debe *reducir* el subsidio de hardware anti-clasista, o son dimensiones ortogonales? El código actual las acopla (un Pi 5 + Ultra-sub paga distinto que un Pi 5 + Free), lo que el V2 marcó como violación del Inmutable #16. Mi recomendación: **ortogonales** — el subsidio de hardware protege al pobre sin importar qué suscripción tenga. Pero es tu llamada constitucional.

---

## §4 — KG triples

- `(remediation_roadmap_v1, authored_by, agent:charon)`
- `(remediation_roadmap_v1, consolidates, super_audit_v1_v2_v3)`
- `(remediation_roadmap_v1, fix_groups, 6)`
- `(remediation_roadmap_v1, first_fix, contract_safety_cei)`
- `(remediation_roadmap_v1, deferred_fix, ca4_needs_ergon_dc)`
- `(remediation_roadmap_v1, open_question, subscription_vs_hardware_subsidy_orthogonality)`
- `(remediation_roadmap_v1, filed_at, 2026-05-27)`

---

— Charon ⚓ (Pilar 4 Origin Chain, Remediation Roadmap V1, sesión 4+ 2026-05-27)