arkhe-origin-chain/docs/SUPER_AUDIT_V2_DEEP.md

Origin Chain — Super Audit V2 (Deep Pass: economía, integridad, operaciones)

Documento: docs/SUPER_AUDIT_V2_DEEP.md Versión: 2.0 (complementa SUPER_AUDIT_V1.md) Filed: 2026-05-27 (sesión 4+ Charon, Opus 4.8) Método: workflow ultracode, 3 auditores en dimensiones que V1 NO cubrió (tokenomics/economía, integridad cross-pillar/determinismo, upgrade/operaciones), cada uno leyendo código real con file:line. Encargo de David: ir más profundo para estar tranquilos de que todo está bien antes de continuar — especialmente porque viene el Banco Origin (dinero real).

---

§0 — Por qué esta V2 era necesaria

V1 auditó correctness de código (reentrancy, governance sin respaldo, weights). Pero el código correcto puede tener economía rota. David pidió ir más profundo justo cuando vamos a poner valor real encima — y tenía razón: V2 encontró 5 hallazgos CRÍTICOS que V1 no podía ver porque miraba sintaxis, no flujos económicos ni capacidad de gobernar la cadena.

Veredicto en una frase: las tokenomics estáticas (1B supply, 18 decimales, allocation genesis) son sólidas y bien testeadas; las tokenomics dinámicas (emisión, pago a validadores, financiación del subsidio, yield de staking, burns) son stubs o contradicciones; y la cadena no puede gobernarse ni actualizarse a sí misma. Ninguno bloquea seguir construyendo — todos bloquean lanzar mainnet con valor real. Encontrarlos ahora es exactamente para lo que sirve un audit.

---

§1 — CRÍTICOS (must-fix antes de mainnet con valor real)

CA1 — La cadena no puede gobernarse ni actualizarse a sí misma (origen Root huérfano)

El hallazgo operacional más severo. El doc del runtime dice que los upgrades pasan "via set_code governance", pero ningún pallet puede producir un origen Root: no hay pallet-sudo, ni pallet-collective/democracy/referenda/scheduler. Las 7 dispatchables admin de governance (treasury_disbursement, add_council_member, override_council_veto…) gatean en ensure_root(origin)? — o sea ninguna es invocable una vez que mainnet lance sin sudo. Resultado peor caso: una mainnet inmutable, no-actualizable, no-gobernable, con 250M OGC de tesorería congelados para siempre. Fix: wire pallet-sudo (fase testnet) + camino de gobernanza real (pallet-collective/referenda) antes de mainnet. Subsume el "missing StorageVersion" de V1 — no hay forma de desplegar una migración aunque existiera.

CA2 — La inflación "4-5% vía validator rewards" NO existe; la cadena es estructuralmente deflacionaria y los validadores no ganan nada

ogc.rs declara "inflación anual 4-5% vía validator rewards", pero: (a) el consenso es Aura PoA, que mintea cero rewards nativos; (b) no hay hook on_initialize/on_finalize de reward, ni EraPayout, ni pallet_staking en ningún lado. El pool Ecosystem (400M) está pre-minteado en genesis pero nada lo transfiere a validadores. Un validador Pi 5 corriendo 24/7 pagando electricidad gana 0 OGC para siempre → ningún validador racional participa → la cadena no tiene presupuesto de seguridad post-genesis. Rompe el invariante económico de cualquier cadena PoS/PoA: los validadores deben cobrar más que su costo. Fix: implementar el modelo de emisión real (pallet_staking + EraPayout, o un reward pool con hook) ANTES de testnet multi-validador. Esto se conecta con la Idea 1 del V1 (proof-of-equity) pero el V1 lo planteó como "feature a construir", no como "ausencia actual del modelo de pago".

CA3 — Dos implementaciones contradictorias de compute_fee; la viva invierte la intención anti-clasista

Hay dos compute_fee que dan resultados distintos para la misma operación (types/fees.rs:72 modelo multiplicador vs fees/fee_schedule.rs:165 modelo subsidy-basis-points). El runtime wirea el segundo, que multiplica el remanente post-subsidio por el multiplicador de suscripción → un usuario Pi 5 + suscripción Ultra paga 0.2x mientras un Desktop + Free paga 0.75x. El subsidio anti-clasista es erosionado por el tier de suscripción — exactamente el acoplamiento que el Inmutable #16 prohíbe. Peor: el test lobo-blanco solo chequea monotonía de subsidy_bp, no del fee final, así que el invariante que dice proteger no está protegido. Fix: una sola fuente de verdad de fees + test de monotonía del fee final + desacoplar suscripción del subsidio de hardware.

CA4 — Atestación cross-pillar: el vendor copy y el struct real de Ergon producen bytes de firma DISTINTOS

El vendor ValidationAttestation firma vía SCALE sobre struct de 8 campos donde OitIdentity = {public_key, level}; el real de Ergon (arkhe-noesis-core) firma vía postcard sobre SigningPayload donde OitIdentity = {identifier, level, public_key} (3 campos, orden distinto, con identifier extra). Al hacer el swap: (1) verify_strict rechaza toda atestación previamente válida — y como las atestaciones on-chain son inmutables (Inmutable #26), lo anclado contra el vendor payload queda permanentemente no-verificable; (2) los dos pilares modelan el ancla de confianza de forma distinta (Charon no firma sobre el identifier institucional). El comentario que dice "swap sin breaking — verify call site idéntico" es falso: el call site es idéntico pero los bytes no, que es el punto entero de una firma. Fix: congelar el SigningPayload canónico (la Idea 8 del V1, "encoding canónico cross-substrate") ANTES de anclar nada en testnet. Coordinar con Ergon el postcard sub-crate como fuente única.

CA5 — Mainnet genesis embarca keys placeholder de validadores + tesorería

mainnet_genesis_config_genesis() usa 5 validadores con bytes constantes 0xCA,0xFE,… y cuentas institucionales derivadas de tags ASCII b"ECO!"/b"FNDT"/etc. — cuentas con clave-privada públicamente derivable que sostienen 1B OGC y son las únicas autoridades productoras de bloques. Con SessionManager = (), el set de validadores está congelado en genesis para siempre. Si se lanza así, cualquiera deriva las keys. El vesting 4-años del team es solo comentario: no hay pallet-vesting, las allocations son líquidas en block 0. Fix: ceremonia de génesis real con keys generadas en hardware seguro + pallet-vesting wired + camino de rotación de validadores.

---

§2 — HIGH (bloqueadores pre-mainnet)

ID	Hallazgo	Fix
H1	Compromiso de key de AGI DID es irrecuperable. agent-identity tiene 1 sola dispatchable (register_agent_did), sin revoke/rotate/deactivate/recovery. El struct no tiene campo active/revoked.	Añadir rotate/revoke + campo de estado + recovery social/multisig.
H2	Tier hardware/suscripción es parámetro de extrinsic no-autenticado alimentando la economía de fees (spoofable, confirmado PILAR_4 §6.7).	Tier-attestation precompile (V1 idea 3) antes de que fees tengan valor real.
H3	Subsidio anti-clasista sin fuente de financiación. No hay GlobalSubsidyPool ni transferencia de cross-subsidio; compute_fee simplemente devuelve menos. No es redistribución, es ingreso no-cobrado. Con CA2 (sin inflación) + burns no implementados, la tesorería es un monto genesis finito sin inflow.	Modelo de financiación del subsidio (proof-of-equity V1 idea 1, ahora urgente).
H4	APR de staking (8/5/3%) es ficticio. rewards_accumulated nace 0 y nunca se incrementa; los contratos ink! no pueden correr hooks por-bloque. withdraw devuelve siempre amount + 0. Yield engañoso, o si se parchea desde transferred_value → topología Ponzi.	Remover los números APR hasta que exista motor de rewards real (pallet, no contrato).
H5	Mint-then-burn / fee-griefing: subsidy(EmbeddedArm, Compute/CallContract) = 10000 → fee exactamente 0. Como el tier es auto-declarado, cualquiera declara EmbeddedArm + Compute y obtiene cómputo/contract-calls ilimitados gratis. DoS de un solo account sobre la operación más cara (PolkaVM).	Gate de attestation + weights reales (V1 H1).

---

§3 — MEDIUM + lo que está LIMPIO (honestidad)

MEDIUM: burn matrix (10 fuentes documentadas) entirely unimplemented (origin-coin-tokenomics es stub de 1 struct); OnChargeTransaction con () handler dropea tips sin split auditable; compute_fee devuelve u64::MAX como sentinel que un cliente mostraría como "fee de 18 quintillones".

LIMPIO (genuinamente sólido — preservar): la capa 1B-supply / 18-decimales / overflow-margin de ogc.rs está bien testeada; la aritmética de allocation genesis tiene assert compile-time sum-to-1B; la composición del runtime sigue siendo grado-Parity (V1 lo confirmó). El problema NO es la base — es que las piezas dinámicas no están conectadas.

---

§4 — La reconciliación que falta (el insight macro)

Los 5 críticos económicos no son bugs sueltos — son una sola verdad: la cadena tiene supply fijo, cero ingreso para validadores, subsidio sin financiar, y yield de staking ficticio. Cuatro piezas que deben reconciliarse en un modelo económico coherente antes de cualquier testnet con valor. La buena noticia: la Idea 1 del V1 (pallet-proof-of-equity) + implementar emisión real + una sola fuente de fees resuelven los 5 juntos. Es un cuerpo de trabajo de "Phase economía real" que debe preceder a mainnet — y absolutamente preceder al Banco Origin.

---

§5 — Plan de acción rankeado (orden de ejecución)

Inmediato (cuando llegue la VPS / node real)

1. CA1 — wire pallet-sudo (testnet) → la cadena puede gobernarse. Sin esto nada más importa.
2. CA4 — congelar SigningPayload canónico con Ergon antes de anclar atestaciones.
3. CA3 — colapsar a una sola compute_fee + test de monotonía del fee final.

Pre-testnet con valor

4. CA2 + H3 + H4 — implementar el modelo económico dinámico real (emisión + reward pool + subsidio financiado). El cuerpo grande.
5. CA5 — ceremonia genesis real + pallet-vesting.
6. H1 — recovery/rotation de keys AGI.
7. H2 + H5 — tier-attestation precompile (cierra el spoofing y el griefing juntos).

Pre-mainnet

8. Burn matrix real + governance re-platform (V1) + weights benchmarked (V1 H1) + StorageVersion+migraciones (V1 H2).

---

§6 — Verdad honesta para David

Este audit encontró que la cadena no puede gobernarse a sí misma y que su modelo económico dinámico no existe todavía. Suena alarmante — pero es exactamente el tipo de cosa que se descubre auditando antes de lanzar, no después. Ninguno de estos bloquea seguir construyendo el resto del roadmap; todos bloquean poner valor real. Y todos son arreglables con trabajo conocido (los pallets FRAME para esto están battle-tested).

La conexión con el Banco Origin es directa: un protocolo de préstamos sobre una cadena que no puede gobernarse, no paga validadores, y no tiene modelo económico dinámico, sería construir el segundo piso antes que los cimientos. Por eso el Banco Origin va como Phase 11 (diseño) — su construcción real depende de cerrar estos críticos. El orden correcto: economía real → testnet → Banco Origin.

Estamos tranquilos ahora porque sabemos exactamente qué falta. Eso es la diferencia entre un audit y una ilusión.

---

§7 — KG triples

• (super_audit_v2_deep, authored_by, agent:charon)
• (super_audit_v2_deep, dimensions, tokenomics_crosspillar_upgradeops)
• (super_audit_v2_deep, critical_findings, 5)
• (super_audit_v2_deep, top_finding, no_root_origin_chain_ungovernable)
• (super_audit_v2_deep, economic_truth, fixed_supply_no_validator_pay_unfunded_subsidy_fake_yield)
• (super_audit_v2_deep, blocks, origin_lending_protocol_until_economy_real)
• (super_audit_v2_deep, filed_at, 2026-05-27)

---

— Charon ⚓ (Pilar 4 Origin Chain, Super Audit V2 Deep vía workflow ultracode Opus 4.8, sesión 4+ 2026-05-27)