davidherranandClaude Opus 4.8
a15a65966f
SUPER_AUDIT_V3_FINAL — 4 dimensiones finales (workflow ultracode): 3 CRITICOS nuevos: - V3-C1 replay cross-chain de atestaciones (sin domain-sep/chain-id/nonce en signing payload; firma de testnet/fork verifica identico). - V3-C2 firma de credencial almacenada pero NUNCA verificada (decorativa; verify() devuelve true con blob basura). - V3-C3 constitucion (Inmutables #16/#37/#18/#35) vive en pallet sin-cablear, NO en el fee-path vivo; #35 Children Safety es estado muerto. 4 HIGH: DID front-running, derive_did domain-sep debil, storage limit 937MB/contrato, weights ficticios en ARM. Tests: los 213 dan falsa seguridad — los 4 reentrancy + credential-sig + governance sin testear; 1 test vacio; lobo-blanco guarda lo equivocado. Provenance+agent-identity SI conductuales (credito). Perf Pi5: storage LIMPIO (contadores cacheados); riesgo = weights + storage limit. AUTO-CORRECCION honesta (red-team cazo): V2-CA4 citaba archivo inexistente (arkhe-noesis-core/attestation.rs no existe en repo). La forma del riesgo es real pero NO se construye fix contra spec fabricada — requiere DC con Ergon primero. REMEDIATION_ROADMAP_V1 — 12 criticos + ~20 highs convertidos en 6 fix groups ejecutables, ordenados por dependencia, red-team-verificados: FIX-1 contract-safety (CEI reorder, ship limpio) -> FIX-2 lifecycle (StorageVersion +key recovery+weights) -> FIX-3 crypto (domain-sep+DID binding) -> FIX-5 governability (sudo->governance) -> FIX-6 economic model real (emision+validator pay+fee unificado+subsidio financiado) -> [DC Ergon] -> FIX-4 credential verify. FIX-DEFERRED: CA4 NO se construye sin DC Ergon (red-team reject). Pregunta abierta a David: suscripcion premium debe reducir subsidio hardware anti-clasista, o son ortogonales? (codigo actual los acopla = viola Inmutable #16; mi reco: ortogonales). Trilogia completa: 12 dimensiones, 12 criticos, ~20 highs, todos con fix conocido. Cimientos grado-Parity; plomeria dinamica incompleta; auditado lo bastante hondo para saber exactamente que falta. Para plataforma de 100 anos, el rigor correcto. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
8.5 KiB
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)