Commit Graph
59 Commits
Author SHA1 Message Date
e7b9c0c8bf feat(runtime): spec 17 — los pesos se cobran como en la Pi 5, medidos por Laurha en el banco de referencia
Los 23 weights de spec 16, certificados por Laurha en el santuario de la rp1 (origin-banco):
- Núcleo 3 aislado, governor performance a 2,4 GHz, CI parada, 45-49 °C.
- frame-omni-bencher 0.15.0 sobre el wasm 40cb5a1d de 3cd1068.
- 5 procesos por pallet; se cobra el MÁXIMO con scripts/bench/max-de-n.py, porque procesos
  idénticos se separan hasta un 35 %.
- Evidencia: ~/laurha-work/banco/spec16-20261024-1631 en la rp1 (SHA256SUMS d930c5e1).
- Su perfil va en la cabecera de cada weights.rs.

Antes de cobrarlos:
- Mismos accesos a storage: el esqueleto de los 5 ficheros y sus reads/writes son idénticos a
  los de main.
- Lo que Laurha pidió mirar (cast_vote, finalize_proposal y veto_proposal, mucho más altos que
  en RV12) es esperable. Contra los interinos del Mac todos caen en la banda Pi/Mac de 2,5-3,9×:
  es trabajo nuevo de RV15/RV16 en una CPU unas 3 veces más lenta.
- Destacan los tres que verifican Ed25519 en WASM (attest_asset, register_agent_did,
  rotate_agent_key), con unas 6 veces: la criptografía pura sufre más en la Cortex-A76.
- Lo cobrado sube menos que la ejecución, entre +4 % (set_tier_profile) y +56 %
  (rotate_agent_key), porque las lecturas y escrituras de storage no cambian.
- spec_version 16 → 17, porque cambian las fees. transaction_version no cambia: ninguna llamada
  cambia su codificación.

Ensayado en la rp1 (aarch64) sobre un nodo efímero aparte, antes de la testnet de la casa, con
scripts/e2e/upgrade_en_vivo.py (nuevo):
- sudo(set_code) → CodeUpdated + Sudid Ok;
- spec 17 y LastRuntimeUpgrade sube;
- una firma con la spec vieja → «bad signature»; con la nueva, ExtrinsicSuccess;
- la finalidad pasa del bloque del upgrade.
Es la primera vez que el ejecutor ARM compila y corre un runtime nuevo.

Revisión adversarial (nivel 1 de la directiva), antes de tocar la red, con orden de tumbarlo:
no pudo. Los seis puntos aguantan:
- ningún storage ni codificación cambia, y transaction_version no debe subir;
- el más pesado (veto_proposal) cobra 1,9 ms, 344 veces por debajo del máximo por extrinsic;
- los weights.rs tienen la misma estructura y el impl () coincide;
- ninguna fee, subsidio ni test depende del valor de forma que se rompa.

scripts/rp1 (operación del nodo, medido en 23 h con los valores por defecto):
- 430 MB de WAL de RocksDB retenidos para 15 MB de datos, y el RSS subiendo de 200 a 340 MB:
  --db-cache 128. Al reiniciar, 449 → 21 MB.
- El log, de 7 líneas por bloque a ~2 (txpool, sc_basic_authorship y aura en warn; ojo: las
  líneas de autoría usan el target del módulo, no «basic-authorship»), de 16 MB/día a unos 3.
- Modo append, y medir.sh lo rota al pasar de 32 MB.

Co-Authored-By: Laurha <laurha@origin>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-25 12:33:38 -05:00
CharonandClaude Opus 5.5 22bab19932 feat(rp1): la cadena corre en la Pi 5 de la casa — binario aarch64, despliegue sin root y medida continua
David, 24-oct: «lo que podamos hacer en la rp1 hagamoslo no esperemos la VPS porfavor». Y ese
mismo día, por Ergon: la rp1 aloja el servidor de arranque de la red.

scripts/rp1/:
- construir-aarch64.sh + Dockerfile.aarch64: origin-chain-node release, con el WASM real, para
  linux/aarch64 en el Mac.
  - Imagen bookworm (glibc 2.36; la rp1 tiene 2.41).
  - Target en un volumen de Docker: la VM no ve el disco externo de compilación si se montó
    después de arrancar Docker, y reiniciarla tiraría los contenedores de otras hermanas.
  - Copia el binario con docker cp y avisa de cómo borrar el volumen.
- desplegar.sh: copia el binario con su sha256 (y deja el anterior para volver atrás), copia
  arrancar.sh y medir.sh, e instala tres líneas en el crontab del usuario: @reboot, vigilante
  cada 5 min y medida cada 5 min. Sin root y sin systemd.
- arrancar.sh: idempotente.
  - taskset -c 0-2: el nodo nunca toca el núcleo 3, el santuario de origin-banco de Laurha.
  - nice 10 + ionice 7: la CI de la casa va primero.
  - RPC sólo en 127.0.0.1; P2P en el 30333.
  - Cadena dev con Alice: es la testnet de la casa, con llaves públicas de desarrollo; ningún
    valor real.
- medir.sh: una fila CSV cada 5 min con best, finalizado, pares, RSS, CPU, MB de datos, load,
  temperatura y estado de la CI.

scripts/bench/max-de-n.py: funde N weights.rs del mismo pallet cobrando el MÁXIMO de cada
coeficiente.
- Por qué: Laurha midió el 24-oct en su santuario que 8 procesos idénticos de frame-omni-bencher
  separan el base weight hasta un 66 %.
- Se niega si los esqueletos difieren (otra lista de extrinsics o de storage) o si los conteos
  de reads/writes no coinciden. Avisa si N < 5.
- Controles: tres copias idénticas salen idénticas byte a byte; el máximo cae sólo donde se
  subió; un conteo de reads distinto se rechaza; un extrinsic renombrado se rechaza.

firmar_como_wallet: modo cuenta "<frase>" [//derivación], que da la llave sr25519 y la SS58 que
verá un wallet Substrate. Son los vectores para la migración de la wallet Origin! (Irhis).

fix(node): build-spec emite el chain spec REAL cuando el binario lleva el WASM.
- Antes, aunque el binario llevara el WASM real, emitía siempre el de mayo, con :code = «0x»
  simulado, y --raw no sacaba el génesis en crudo.
- Ahora usa el mismo spec con el que arranca run (node_chain_spec), y --raw lleva el génesis
  entero.
- Sin WASM sigue el simulado, pero avisa de que no sirve para unirse a una red. Mainnet sigue
  cerrada por la compuerta L-3.
- Por qué importa, medido hoy: el WASM del runtime NO es reproducible entre máquinas. El mismo
  commit compilado en el Mac y en Linux da génesis distintos (0xe80c… frente a 0x0926…), y el
  nodo del Mac baneó al de la rp1 con «Genesis mismatch». El génesis tiene que fijarlo un chain
  spec que se reparte, no quien compila.
- arrancar.sh usa ~/origin-chain/casa.json cuando existe (exportado en la propia rp1). Así un
  binario nuevo nunca crea otro génesis sobre los mismos datos.

Medido en vivo el 24-oct, todo por RPC firmado como un wallet:
- Nodo en la rp1 (Pi 5, Debian 13): bloques cada 6 s y finalidad a 2-3 bloques. RSS ~200 MB y
  afinidad 0-2 con nice 10.
- El vigilante de cron lo resucita con el mismo peer id
  (12D3KooWDWm5p3Z8Y5DddRki6M6nM1A2xUVQzPqNU1DW53uB6BVi) y sin regenerar la llave.
- E2E en la rp1: remark → ExtrinsicSuccess; finalize_override → ProposalNotFound; uphold0 →
  ZeroWeightWindowVote.
- casa.json exportado en la rp1 = estado del bloque 0 de la cadena viva: 46 de 46 claves
  idénticas. El nodo reinició sobre él con el mismo génesis y siguió desde el #155.
- Red de dos máquinas por la LAN: el nodo del Mac, con casa.json y la rp1 como bootnode,
  sincronizó (mismo best, mismo finalizado). Una transacción enviada al nodo del Mac la incluyó
  la rp1 en el bloque #167, con el mismo hash blake2-256 que devolvió author_submitExtrinsic.

Defectos encontrados en mis propios scripts antes de dejarlos publicados:
- desplegar.sh instalaba un crontab VACÍO: con set -e, el grep -v sobre un crontab vacío
  abortaba la subshell antes de los echo.
- medir.sh dejaba best/finalizado en NA: set -u con $2 sin definir, y stderr se iba con cron.
- max-de-n.py reescribía 16416 como 16_416 (la prueba de identidad lo cazó).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-24 13:19:52 -05:00
CharonandClaude Opus 5.5 3cd1068893 feat(e2e): simulacro de set_code 16→17 — la cadena ya se actualiza sin fork, y sin 11e532e no podía
Ensayo en vivo el 2026-10-12, nodo --dev con WASM real, todo firmado por RPC como un wallet:
- A, control negativo: set_code con la MISMA spec 16 → Sudid Err(System, 1) =
  SpecVersionNeedsToIncrease.
- B, el upgrade: sudo(set_code) con spec 17 → CodeUpdated + Sudid Ok.
  - El RPC anuncia 17 y LastRuntimeUpgrade pasa de {16,"origin-chain"} a {17,"origin-chain"}.
  - La migración del simulacro dejó su marca (0x11000000): on_runtime_upgrade corrió.
- C, un wallet tras el upgrade: firmado con spec 16 → «bad signature»; con spec 17 →
  ExtrinsicSuccess.
- La finalidad siguió: el bloque del upgrade (#5) quedó finalizado.

Contrafactual, nodo sin type Version (el runtime de antes de 11e532e):
- LastRuntimeUpgrade = {0, ""}.
- Firmando como wallet → «bad signature».
- Firmando con spec 0 para poder llegar → Sudid Err(System, 0) = InvalidSpecName.
- Ningún upgrade y ninguna marca.
O sea: hasta el 7-oct la cadena no podía cambiar su runtime sin un fork.

Herramientas, para repetirlo antes de la testnet:
- scripts/e2e/simulacro_set_code.py: los pasos A, B y C contra un nodo vivo. Lo corrí tal cual
  y reproduce lo de arriba.
- scripts/e2e/parche_simulacro.py: aplica de forma temporal la spec N+1 con la migración
  marcada, y al restaurar comprueba por hash que lib.rs queda idéntico.
- firmar_como_wallet:
  - modo set_code:<ruta> (sudo de //Alice);
  - spec y tx opcionales: tras un upgrade, el wallet firma con la versión que anuncia el RPC;
  - hex completo: HexDisplay recortaba con «...» pasados 1024 bytes.

Las builds son reproducibles: los dos WASM salieron con el mismo sha en dos builds separados
(9b933ff1 spec 16, 51663085 spec 17).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 19:15:49 -05:00
CharonandClaude Opus 5.5 ce91aa4572 feat(runtime): firmar_como_wallet — el E2E por RPC firma como un wallet, no solo mira bloques
Herramienta (example del runtime) con la que se midió el defecto de 11e532e. Firma por //Alice
como polkadot.js (versión que anuncia el runtime, hash del génesis, era inmortal) para mandarlo
con author_submitExtrinsic a un nodo vivo, decodifica System::Events del bloque que lo incluye
y verifica la firma contra el runtime nativo sobre el preset development, sin nodo.

Uso y recorrido por RPC en la cabecera del fichero. Antes de esta herramienta, los E2E de la
cadena solo comprobaban que se producían y finalizaban bloques, y así 16 specs no vieron que
ningún wallet podía firmar.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 10:38:21 -05:00
CharonandClaude Opus 5.5 11e532e251 fix(runtime): frame_system no sabía su propia versión — ningún wallet podía firmar
Medido en el E2E de RV16 por el canal de un wallet: Alice firmando como polkadot.js
(versión de state_getRuntimeVersion, hash del génesis, era inmortal) recibía del nodo vivo
«Transaction has a bad signature».

Causa: SolochainDefaultConfig trae type Version = (), es decir RuntimeVersion::default()
(nombre vacío, spec 0, tx 0), y el impl de frame_system lo heredaba sin declararlo — el mismo
agujero que DbWeight en RV14. El RPC anunciaba spec 16 / tx 1; CheckSpecVersion y
CheckTxVersion reconstruían el payload con 0 / 0. Rompía tres cosas:
1. Ningún wallet podía firmar un extrinsic (BadProof).
2. set_code habría fallado con InvalidSpecName («origin-chain» contra «»): sin upgrades.
3. Las migraciones no corrían nunca: Executive::runtime_upgraded compara 0 contra 0.

Nadie lo vio en 16 specs porque ningún test firmaba por el canal del consumidor: los del
pallet llaman a las funciones directamente, y los E2E anteriores solo miraban bloques.

Arreglo: type Version = Version, con Version = crate::VERSION.

Tests (contrafactual: sin la línea, los dos reprueban en la ASERCIÓN — spec_name "" y BadProof):
- frame_system_conoce_la_version_que_anuncia_el_rpc
- una_firma_de_wallet_estandar_pasa_el_check_del_runtime: firma como un wallet sobre el
  estado del preset development y pasa por el check real de la firma.

E2E después del arreglo, nodo --dev con WASM real: dos extrinsics firmados por //Alice entran
por author_submitExtrinsic, se incluyen en el bloque #3 (finalizado) y fallan con los errores
que tocaban: finalize_override → ProposalNotFound, uphold_council_veto de peso 0 →
ZeroWeightWindowVote. La metadata viva trae las llamadas, el storage, MinOverrideQuorum = 1e26
(100M OGC) y los errores nuevos.

Tests: runtime 46, workspace 350.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 10:30:38 -05:00
CharonandClaude Opus 5.5 3771a15165 feat(governance): RV16 — el override del veto se decide al cerrar la ventana, con 4/5 de quien participa
Cierra L-11 (override real del veto). David aprobó el 4/5 el 2026-10-01: «exigir una mayoría
calificada de 4/5 en el consejo para anular un veto de emergencia es el cerrojo adecuado antes
de retirar la llave Sudo».

Qué cambia
- La ventana de override tiene dos lados: revertir (override_council_veto) y sostener
  (uphold_council_veto, nuevo). Quien votó Nay puede sostener el veto; antes no tenía voz.
- Nada se decide al cruzar un umbral. finalize_override (nuevo) decide UNA vez, al cerrar la
  ventana: se revierte si override >= ceil(4/5 * max(quórum, participación)).
- El quórum se fija al vetar: max(Aye + Nay del voto original, MinOverrideQuorum). Abstain no
  cuenta. Así el bond que el veto devuelve no basta para revertirlo y un upgrade no lo mueve.
- MinOverrideQuorum en el runtime = 100M OGC (el 10% de PILAR_4 §6.6); integrity_test exige
  que supere MIN_PROPOSAL_STAKE.
- El periodo de voto ordinario dura al menos 14 días (MIN = DEFAULT) y el veto solo cabe dentro
  de él. Un voto de peso 0 en la ventana se rechaza.
- spec_version 16. Pesos de uphold_council_veto y finalize_override medidos (frame-omni-bencher
  0.15.0, 50 steps x 20 repeats); los demás re-medidos en el mismo banco.

La revisión adversarial (nivel 1 de la directiva) tumbó la primera versión
- Bloqueante: la regla de quórum no era monótona y votar «sostener» podía REVERTIR el veto.
  Ahora sostener nunca ayuda a revertir (test con la frontera exacta 2250/2251).
- El mínimo de 48 h regalaba la vía de emergencia a cualquiera; ahora 14 días.
- Las abstenciones inflaban el quórum; el quórum podía cambiar con un upgrade; la spec no subía.
- 18 contrafactuales (mutaciones V1..V18), todos en rojo sin su pieza.

Divergencia que queda abierta (D1 del roadmap V2): PILAR_4 §6.6 ratificó «override por 2/3» y
el código implementa 4/5, que es lo que David confirmó. La constitución del DAO lo fija.

Tests: gobernanza 78 (94 con runtime-benchmarks), runtime 44.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 10:30:18 -05:00
CharonandClaude Opus 5.5 a694cbd9f0 feat(governance): RV15 — el peso de un voto sale del saldo, y la revision adversaria tumbo la primera version
Cierra L-10. cast_vote y override_council_veto sumaban el stake_weight que
DECLARABA el votante (hueco medido por Palace el 2026-09-06; test en rojo
publicado en d37a278). Ahora:

- El peso no puede superar el OGC LIBRE de la cuenta, y ese OGC queda
  congelado (fungible freeze, FreezeReason::GovernanceVote) mientras el voto
  pueda cambiar un resultado: hasta end_block en un voto normal y hasta el
  cierre de la ventana en un override. El mismo OGC puede respaldar votos en
  propuestas distintas (se solapan, como en Polkadot), pero no puede salir de
  la cuenta: se cierra votar, transferir y votar otra vez desde otra cuenta.
- Un respaldo POR VOTO (VoteBacking: propuesta, tipo, importe, hasta), no uno
  por cuenta. El freeze es siempre el maximo de los votos VIVOS; los vencidos
  se descartan solos al votar o desbloquear. MaxActiveVotes = 32 en el runtime.
- unlock_vote_funds(who) lo puede llamar CUALQUIERA, como el unlock de
  conviction-voting: quien vota con todo su saldo no puede pagar la comision de
  su propio desbloqueo. Libera solo lo que ya no respalda un voto vivo.
- El override tiene ventana: 14 dias desde el veto que ALCANZA el umbral
  (antes estaba abierto para siempre). Sin ventana registrada, falla cerrado.
- voting_period_blocks tiene tope: 28 dias (MAX_VOTING_PERIOD_BLOCKS).
- VoteFundsUnlocked va al FINAL del enum de eventos: no desplaza indices SCALE.
- spec_version 14 -> 15; transaction_version sigue en 1.

La revision adversaria (4 lentes independientes sobre la primera version)
encontro tres fallos serios, y los tres eran mios:
1. El lock unico por cuenta (max importe, max bloque) mas un periodo de voto
   sin tope congelaba OGC PARA SIEMPRE: un voto de 1 unidad en una propuesta de
   periodo u64::MAX arrastraba el voto mayor de la cuenta hasta ese bloque, y ni
   el veto lo liberaba. Lo demostraron tres lentes por separado. Cura: respaldo
   por voto + tope de periodo.
2. Un lock vencido y no desbloqueado revivia con el siguiente voto pequeno.
3. Votar con todo el saldo dejaba la cuenta sin poder pagar la comision del
   unlock, y solo ella podia desbloquearse. Cura: unlock por terceros.
Y seis mutaciones sobrevivian a mi suite, entre ellas congelar el peso del
voto actual en vez del maximo (el propio ataque que el test decia cubrir).

Certificacion: 17 contrafactuales, TODOS en rojo con su pieza quitada
(freeze = peso actual, sin exigir saldo, reducible_balance, total_balance,
unlock en until, sin podar vencidos, ventana desde start_block, ventana 0,
peso 0 con thaw, evento released=0, unlock todo o nada, sin tope de periodo,
unlock solo propio, override hasta end_block, veto sin ventana, sin freeze, y
MaxFreezes=0 en el runtime). Cada test lleva control positivo. Test nuevo con
la configuracion REAL del runtime (preset local_testnet): el voto congela en
pallet-balances, lo congelado no sale, y un tercero lo libera al vencer.

Benchmarks en el PEOR caso real (la revision mostro que median la rama
barata): lista de respaldo casi llena, override que alcanza el umbral, veto de
un council de 7 que devuelve el bond, finalize que devuelve el bond, unlock
con la mitad vencida. Pesos regenerados con frame-omni-bencher (Mac; los
canonicos siguen pendientes del Pi 5, L-6). veto_proposal estaba
subdeclarado ~3x: 36M ps 10r/7w -> 112M 21r/10w, proof 6132 -> 16416.

regen-weights.sh: el blob de bench (runtime-benchmarks) se construye en
target-bench/ DENTRO del repo, nunca en target/release/wbuild, que es de donde
sale un set_code. Lo que debe coincidir con lo desplegado es el commit, no el
blob. Dentro del repo porque substrate-wasm-builder busca el Cargo.lock
subiendo desde el target: fuera no lo encuentra y resuelve dependencias
nuevas (medido).

Fuera de RV15, a RV16 (L-11): el override no es un 4/5 real (el bond que el
veto devuelve y el OGC Aye cuentan en el denominador y en el numerador), el
veto sigue siendo posible tras end_block, y un periodo de voto minimo.
Existian antes de RV15; los demostro la misma revision.

cargo test --workspace: 334 passed, 0 failed, 0 ignored.
cargo test -p origin-chain-governance --features runtime-benchmarks: 79 passed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-24 12:03:44 -05:00
CharonandClaude Opus 5 defd3fa580 feat(identity): RV14 — una identidad sobrevive a perder su llave, y la revision encontro que el storage salia gratis
QUE NACE. rotate_agent_key (call_index 1 de agent-identity) y la runtime API
AgentKeyApi::current_key. Hasta hoy un DID quedaba atado de hecho a su llave de
nacimiento: no se re-derivaba, pero tampoco habia forma de pasar la autoridad a
otra llave. Perder o filtrar la llave obligaba a registrarse otra vez con OTRO
DID y perder credenciales, creditos e historial. Ahora el DID es de por vida y lo
que rota es que llave manda sobre el. Es la dependencia de dos hilos abiertos: el
DID del niño (Marihan) y los creditos de referido indexados por DID (Codex).

Diseño: CurrentKey[did] (ausente = manda la de nacimiento, que ya vivia en
creator; sin migracion), KeyToDid[llave] (una llave manda sobre un solo DID en
toda la vida de la cadena; las retiradas quedan quemadas) y RotationNonce[did].
Dos firmas sobre DOMAIN || genesis || did || vigente || nueva || nonce || who: la
vigente autoriza, la nueva prueba control.

LO QUE LA REVISION ADVERSARIAL ENCONTRO ANTES DE PUBLICAR. Cinco lentes, 18
hallazgos, 17 confirmados. Todos arreglados aqui y cada arreglo con su
contrafactual visto en ROJO:

1. DbWeight = () EN TODO EL RUNTIME. frame_system heredaba el valor por defecto
   de SolochainDefaultConfig sin declararlo. Cada reads(n)/writes(n) de TODOS los
   weights.rs valia cero: la E/S de storage no se cobraba en fees ni llenaba el
   bloque. Ahora RocksDbWeight, con un test que reprueba si vuelve a cero.
   ESTO CORRIGE LO QUE YO DIJE EN RV13: los reads/writes que medi alli no tenian
   efecto en el runtime. Lo que RV13 si arreglo es el proof_size y el ref_time de
   ejecucion, que no pasan por DbWeight.

2. LLAVES DE ORDEN PEQUEÑO. El verificador del host (ed25519-zebra, ZIP215) las
   acepta. Con el punto identidad como llave y la firma trivial R=identidad s=0,
   la «prueba de control» se superaba sin llave privada, en rotacion Y en
   registro: el DID quedaba bajo una llave con la que cualquiera firma en su
   nombre. Para un DID de un niño en Ethos eso es suplantacion. Ahora
   is_strong_ed25519_key descomprime el punto, exige codificacion canonica y
   rechaza orden pequeño (curve25519-dalek, que ya iba dentro del WASM).

3. EL REGISTRO ESCRIBIA KeyToDid PERO NO LO CONSULTABA. Una llave a la que otro
   DID ya habia rotado fundaba un DID nuevo y pisaba el indice. Hallado cinco
   veces por separado. Va detras de la colision de DID para no cambiar el error
   documentado de scenario_12.

4. REPLAY ENTRE CADENAS: el mensaje no llevaba genesis. Ahora si, mismo patron
   que provenance.

Y menores: el evento nuevo va al final del enum (insertarlo en medio corria el
indice SCALE de AgentUpdated); la insercion redundante de la llave vieja ya no
pisa entradas; la doc dice que perder la CUENTA tambien bloquea la rotacion, no
solo perder la llave; el comentario de creator decia «la cuenta que registro» y
el codigo guarda la llave de nacimiento.

DOS TESTS MIOS PASABAN POR LA RAZON EQUIVOCADA, y lo digo. El de «llave retirada
quemada» volvia a la de nacimiento, que atrapa otra clausula. El del ladron
firmaba con la llave vigente nueva, algo que un ladron real no tiene; con el
pallet roto seguia verde en su mitad de ataque. Reescritos, y ahora el rojo sale
de la mitad correcta (verificado por linea del panic).

LO QUE QUEDA ABIERTO Y NO ES DE ESTE COMMIT: tras rotar, derive(llave_vigente) ya
no es el DID. OCF y Palace hoy DERIVAN el identificador; para un usuario que
roto tienen que RESOLVERLO contra KeyToDid. Es una enmienda al DC de unificacion
con sus firmantes. La recuperacion por guardianes va aparte. Y KeyToDid crece
sin deposito; se reevalua ahora que las escrituras cuestan de verdad.

Medido sobre el WASM real (bencher 0.15.0, Mac, no canonico): rotate 97 us, 11
lecturas, 5 escrituras, proof 6100. 318 tests verde. RV13 -> RV14.
TRANSACTION_VERSION intacto: call nueva en indice nuevo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-16 15:45:26 -05:00
davidherranandClaude Opus 5 7f68c5b656 docs(runtime): el comentario del vault decia que el 25% de la Fundacion va a FNDT — no va
`GovernanceTreasuryPalletId` llevaba una nota que decia «PRE-LAUNCH: el genesis
mainnet debe rutear la Foundation 250M a esta cuenta (hoy va a FNDT —
follow-up)». El follow-up ya estaba hecho y la nota no se enteró.

MEDIDO en genesis_config_presets.rs: el preset mainnet asigna
FOUNDATION_ALLOCATION − SUDO_OPERATIONAL_FLOAT = 249.000.000 OGC al vault
og/gvtry (cuenta derivada de PalletId, sin llave privada) y 1.000.000 al
placeholder FNDT, que es el sudo_key interim y necesita ese flotante porque el
OriginFeeAdapter le cobra sus propios extrinsics Root.

Importa porque la nota vieja hacía creer que la Fundación custodia el tesoro. No
lo custodia: vive en una cuenta sin llave desde el bloque 0. Y salió al escribir
la recomendacion de donde vive el DAO, donde ese dato es la premisa central.

La nota nueva ademas separa lo que la vieja confundia: «sin llave privada» NO es
«gobernado por los votantes». treasury_disbursement es ensure_root, Root hoy es
pallet-sudo, y el amount/recipient los pone quien llama — el cuerpo de la
propuesta es un hash y la cadena no puede leerlo. Cerrar esa brecha es el sunset.

Solo comentario. Sin cambio de comportamiento, sin bump de version.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 18:17:05 -05:00
davidherranandClaude Opus 5 38e5602d78 feat(weights): RV13 — los 19 estaban subdeclarados, los 19
Primera medicion real de los weights con frame-omni-bencher sobre el
propio blob WASM. El resultado no es un ajuste fino: los 19 extrinsics
de los 5 pallets custom declaraban MENOS de lo que cuestan.

EL PATRON SISTEMATICO. Se costeo el storage del pallet y se olvido el
que cuesta emitir un evento — System::Events, EventCount, ExecutionPhase
y Number son reads y writes reales en cada extrinsic que deposita
evento. Ejemplos medidos: attest_asset declaraba 4 reads / 1 write y
cuesta 7/3; submit_proposal declaraba 12 us y cuesta 62; register_agent_did
declaraba 3/2 y cuesta 6/4.

EL PEOR, Y ES UN ERROR MIO DOCUMENTADO AL REVES. proof_size valia 0 en
los 19. La cabecera de los interinos afirmaba que T::DbWeight "puebla
tanto ref_time como proof_size ... cerrando el hueco". Es falso y se
comprueba en la fuente: sp_weights::RuntimeDbWeight solo tiene los
campos read y write, y reads(r) devuelve from_parts(read * r, 0). Los
interinos arreglaron reads/writes y dejaron el proof_size exactamente
donde estaba. Un proof_size en cero miente al block-builder sobre el
peso PoV: es el vector de DoS que la nota decia haber cerrado. La
afirmacion sobrevivio mas de un mes sin que ninguna lectura la
desmintiera; la desmintio una medicion.

Cada fichero generado lleva ahora un guard GENERADO desde la lista real
de benchmarks que reprueba cualquier proof_size = 0 o ref_time = 0.
Verificado que sabe reprobar: contra los weights anteriores se pone rojo
con "`attest_asset` declara proof_size = 0".

ADVERTENCIA QUE VA EN EL CODIGO, NO SOLO AQUI: son numeros de un
MacBook Pro M3 Max, NO del banco de referencia BM V2. La forma
(reads/writes/proof_size) no depende del hardware y es correcta; el
ref_time si, y en un Pi 5 sera mayor. Un caso lo enseña solo:
attest_asset BAJA de 50 a 44 us, y es el extrinsic dominado por el
verify Ed25519, el mas sensible al silicio. Antes de mainnet hay que
regenerar en el Pi 5 con governor y aislamiento declarados — peticion
abierta a Laurha (request:66f500d54e28a80c) con el blob, el comando y
la version exacta del bencher.

RV12 -> RV13 (weights = consenso). TRANSACTION_VERSION intacto.
295 tests verde.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-09 11:06:39 -05:00
davidherranandClaude Opus 5 b7010db328 fix(runtime): RV12 — el blob no sabia decir quien era y el genesis no construia
Tres defectos encontrados al montar el benchmarking real sobre el WASM.
Ninguno era visible desde los tests nativos, y los tres bloqueaban
frame-omni-bencher, que es el instrumento que mide los weights de mainnet.

1. LA SECCION runtime_version NO EXISTIA. Faltaba el atributo
   sp_version::runtime_version sobre VERSION. Esa custom section es la
   unica via para leer la version del runtime SIN ejecutarlo, que es de
   lo que depende set_code / forkless upgrade. wasm-builder abortaba con
   "Couldn't find the runtime_version section". El atributo exige
   literales, asi que la direccion queda INVERTIDA: VERSION es la fuente
   unica y las siete constantes publicas se derivan de sus campos. La
   deriva ya no es cuestion de disciplina, es imposible por construccion
   (contrafactual verificado: mover el literal pone rojo el test).

2. LOS PRESETS DE GENESIS NO EXISTIAN EN no_std. get_preset y
   preset_names devolvian None/vacio bajo un cfg(feature = "std") cuyo
   comentario afirmaba que los presets "solo se consultan en chain_spec
   generation, no en runtime execution". Falso: en el modelo
   runtime-driven chain spec el estado se construye DENTRO del WASM.
   omni-bencher fallaba con "The preset with name development is not
   available", y chain-spec-builder habria fallado igual.

3. NINGUN PRESET HABIA CONSTRUIDO UN GENESIS VALIDO JAMAS. Los tres
   poblaban aura.authorities Y session.keys a la vez; con pallet-session
   cableado, session instala las authorities de Aura via
   on_genesis_session y el build de Aura revienta con "Authorities are
   already initialized!". Sobrevivio toda la vida del crate porque todos
   los tests inspeccionaban el JSON del preset y ninguno llamaba a
   build_state: se miraba la caja por fuera. Ahora la abre
   los_tres_presets_construyen_estado (dev-dep sp-io), con contrafactual
   verificado: repoblar authorities lo pone rojo con el panic exacto.

Tambien: el test que fijaba la version llevaba la version en el NOMBRE
(runtime_version_v11_did_newtype) y su comentario quedaba mintiendo en
cuanto la spec subia. Renombrado a
spec_version_vigente_y_transaction_version_intacta.

MEDIDO: WASM build exit 0; seccion runtime_version presente y decodificada
(spec_name origin-chain, spec_version 12, tx 1); omni-bencher enumera los
19 benchmarks de los 5 pallets custom; 290 tests verde.

RV11 -> RV12. TRANSACTION_VERSION intacto. Sin migracion: no hay cadena
viva y ninguna transicion de estado cambia.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-09 10:13:33 -05:00
davidherranandClaude Opus 4.8 2d44042bd6 feat(identity): Did pasa a newtype propio — condición #3 de Mathi (RV 10→11)
Condición VINCULANTE #3 de la firma de Mathi que ratificó el DC ORIGIN IDENTITY
UNIFICATION V1 (3/3, 2026-07-29): `Did` deja de ser `pub type Did = AssetHash`
y pasa a ser un newtype propio en origin-chain-types::identity.

POR QUÉ (su argumento, que resultó más fuerte de lo que parecía):
Mientras cada capa derivaba con SU propio contexto KDF, un DID y un hash de asset
eran valores de dominios separados por construcción. Con el contexto COMPARTIDO
`origin/identity/v1` ambos pasaron a ser "32 bytes canónicos de Origin", y el
alias dejaba que el compilador aceptara silenciosamente un `AssetHash` donde se
espera un `Did` — anclar una attestation bajo un DID, o resolver `DidToAccount`
con el hash de un asset. La unificación AGRAVÓ el riesgo que el alias escondía;
el newtype convierte esa clase entera de confusión en error de compilación.

GARANTÍAS PRESERVADAS (medidas, no asumidas):
- Encoding SCALE byte-IDÉNTICO (newtype sobre [u8;32] con los mismos derives)
  ⇒ `DidToAccount` NO requiere migración. Probado: assert_eq!(did.encode(),
  as_asset.encode()) + size_of::<Did>() == 32.
- `derive_did` produce los MISMOS bytes: los 3 golden vectors del DC (D-ID-7)
  siguen verdes ⇒ la paridad con fabric-core (9e51e58) y Palace (7a0b82a) intacta.
- El cruce de dominio sigue disponible pero EXPLÍCITO: `Did::from_asset_hash` /
  `into_asset_hash`. Legítimo cuando hace falta, legible en el código.

UN TEST MÍO AFIRMABA EL DEFECTO Y LO MATÉ:
  let _did_alias: Did = AssetHash::new([0u8; 32]);   // compilaba: era alias
Ese assert pinneaba exactamente lo que Mathi señaló. Reemplazado por
`did_is_a_newtype_not_an_alias_of_asset_hash`, que pinnea la separación de
dominios + la invariante de wire.

RUNTIME_VERSION 10→11 — y con la severidad SIN inflar: esto NO es
consenso-relevante (misma transición de estado, mismos bytes, mismo encoding).
El bump es higiene de metadata: el `TypeInfo` de la clave de storage ahora se
llama `Did` y los clientes que cachean metadata deben re-leerla.
TRANSACTION_VERSION intacto.

Blast radius real medido: 1 solo error de compilación en todo el workspace (el
test obsoleto de arriba). Verificado: 288 tests verdes, 0 fallos.

Queda abierta la condición #4 de Mathi (`kind` dentro del material hasheado):
objetada por escrito con razones (rompe la unificación —misma pubkey daría N ids
por kind—, vuelve el kind inmutable —Human→Hybrid rotaría la identidad entera— y
rompe la paridad digest recién cerrada). Contrapropuesta: binding del kind vía
atestación on-chain autenticada + firmas domain-tagged, y el prefijo
`did:origin:<kind>:` tratado como etiqueta de display, nunca como autoridad.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 17:27:38 -05:00
davidherranandClaude Opus 4.8 13f8ac00a5 feat(identity): UNA identidad para todo Origin — contexto KDF compartido (RV 9→10)
DC ORIGIN IDENTITY UNIFICATION V1 (Larihana), Opción A + enmienda D-ID-7 mía.
Ratificado por David 2026-07-28. Firmado approve (pendientes Larihana + Mathi).

EL PROBLEMA (medido por Larihana, verificado por mí en ambos lados):
  chain: blake3::derive_key("origin-chain/agent-did/v1", pk) → Did
  OCF:   blake3::hash(pk)                                    → OitFingerprint
La MISMA pubkey Ed25519 producía 32 bytes DISTINTOS en cada capa. No era un bug
de criptografía: cada capa hizo domain separation correctamente por separado y
nadie decidió la relación entre las dos. Consecuencia: viendo un fingerprint en
un canal de chat NO se podía resolver el DID on-chain sin la pubkey completa —
un usuario tenía una identidad en el chat y otra en la blockchain. Directiva de
David: "que todo lo que creamos tenga una misma identidad para poder acceder".

EL CAMBIO:
- Nueva constante pública ORIGIN_IDENTITY_KDF_CONTEXT = "origin/identity/v1",
  el contexto CANÓNICO compartido por todas las capas de Origin.
- derive_did pasa a derivar con ese contexto ⇒ el identificador de 32 bytes es
  ahora EL MISMO en chain, chat (OCF), assets y credenciales.
- RUNTIME_VERSION 9→10: cambia la transición de estado de register_agent_did (el
  DID calculado y almacenado) ⇒ spec bump obligatorio. Las FIRMAS de los
  extrinsics NO cambian ⇒ TRANSACTION_VERSION intacto.

POR QUÉ SIN MIGRACIÓN (la verificación que el DC me delegó, medida no asumida):
- Sin GenesisConfig en el pallet → no se siembran identidades en génesis.
- Sin DIDs en los 3 presets de génesis.
- Sin golden vectors ni DID hex hardcodeado en el repo.
- StorageVersion = 0, nunca migrado — greenfield puro.
- derive_did = UNA función, UN call-site; los tests lo invocan (no pinnean bytes).
⇒ Ningún estado on-chain dependía del esquema viejo. La ventana pre-mainnet
  estaba abierta y el costo fue una constante de string.

ENMIENDA D-ID-7 — golden vectors cross-repo (lo que aporté al DC):
El DC arreglaba la INSTANCIA pero no la CLASE. Origin Chain es submódulo y NO
puede depender de arkhe-fabric-core (dep-direction submódulo→monorepo = ILEGAL,
la misma ley que impide el swap del attestation SSOT), así que las dos capas no
pueden compartir la constante por Cargo — y sin ancla podían volver a divergir en
silencio, que es justo el bug que cerramos. Añadidos 3 vectores pinneados a bytes
(2 patrones + 1 pubkey Ed25519 real) para que fabric-core pinnee LOS MISMOS.
Si cualquiera de los dos lados cambia el contexto o la función, su test falla.
Mismo patrón que ya nos salvó con el attestation SSOT: paridad por matemática,
no por disciplina humana.

NO VACUO — verificado empíricamente: saboteé el contexto a "v2-DRIFT" y AMBOS
tests fallaron con el diagnóstico correcto; restaurado, verdes de nuevo. (Un test
que pasa no prueba nada hasta que se le ve fallar sin el fix.)

TRADE-OFF asumido y dejado explícito en el acta del DC: un identificador único en
chat + chain + assets + credenciales implica que ver el fingerprint de alguien en
un canal permite resolver sus activos y transacciones on-chain — no hay frontera
de seudonimato entre capas. Es INHERENTE a "una identidad para todo"; la
alternativa (derivación por-contexto tipo HD) reintroduce los dos identificadores
en dos pantallas que justamente eliminamos. Decisión consciente, no efecto
secundario descubierto después.

Verificado: workspace completo verde (0 fallos), 20/20 en agent-identity.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-28 12:25:05 -05:00
davidherranandClaude Opus 4.8 c7fc6a88fc feat(bench): maquinaria FRAME v2 de benchmarking para los 5 pallets custom (RV 8→9)
Los 19 extrinsics de provenance/fees/agent-identity/emission/governance pasan de
weights placeholder `from_parts(10_000, 0)` (proof_size=0, sin contar reads/writes
de DB — vector de DoS real) a weights INTERIM hand-derived DB-aware vía el trait
`WeightInfo`. Cierra el mispricing de DoS en TODOS los extrinsics del chain.

Cada pallet gana:
- weights.rs: trait WeightInfo + SubstrateWeight<T> (DB-aware vía T::DbWeight) + impl ()
- benchmarking.rs: benchmarks FRAME v2, VERIFICADOS por impl_benchmark_test_suite!
  (19 benchmarks ejecutan+pasan en los mocks — cargo test --features runtime-benchmarks)
- Config: `type WeightInfo` + swap de los `#[pallet::weight]`

Runtime:
- define_benchmarks! con los 5 pallets + runtime API Benchmark (inerte sin la feature)
- WeightInfo cableado a SubstrateWeight<Runtime> en cada Config
- RUNTIME_VERSION 8→9 (weights = consenso-relevante: fee + llenado de bloque;
  las firmas de los extrinsics NO cambian ⇒ TRANSACTION_VERSION intacto)

3 bugs latentes cerrados (territorio virgen — el runtime NUNCA se compiló con
runtime-benchmarks; las dimensiones nuevas cazan lo que no se había visto):
- pallet-grandpa/try-runtime mal ubicado en la feature runtime-benchmarks (copy-paste
  erróneo: features ortogonales; NUNCA activaba los benchmarks de grandpa)
- feature runtime-benchmarks incompleta → E0046 en OriginFeeAdapter (métodos
  benchmark-gated de OnChargeTransaction) + pallet-staking
  (StakingUnchecked::migrate_to_direct_staker); ahora lista TODOS los pallets como
  un runtime de producción Substrate
- pallet-revive/runtime-benchmarks omitido a propósito (fixtures RISC-V/PolkaVM
  indisponibles; ReviveApi deferred, no benchmarkeado)

emission: mock extraído del `mod tests` inline a `pub mod mock` (reuso del test-suite,
sin duplicar el scaffold; los 15 tests existentes + el benchmark verdes).

GATED (documentado en el §Estado de cada weights.rs): la generación de números
CANÓNICOS por CLI requiere el node sc-service o omni-bencher+WASM (ambos bloqueados
hace sesiones). Los weights interinos son DB-aware/DoS-safe y regenerables de forma
mecánica cuando aterrice el HW de referencia (Pi5/VPS) — benchmarking.rs es la fuente
de verdad de la FORMA.

Verificado: 5 test-suites de pallet verdes (con y sin runtime-benchmarks) + runtime
compila en ambos modos + workspace sin regresión + 40 tests de runtime (incl. v9).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 22:48:26 -05:00
davidherranandClaude Fable 5 9f48723ca5 feat(governance): flujo 5/7 de emergencia REAL — dos fases (audit B, David · RV 7→8)
Decisión B (David 2026-07-04). El audit ultra encontró que el gate 5/7 de
submit_emergency_proposal era TAUTOLÓGICO: `council_size >= threshold(council_size)`
es siempre true, y solo exigía UN council member — así que un solo miembro
fast-trackeaba una propuesta a 48h (vs 14 días) sin la pre-aprobación 5/7.

Fix (flujo de dos fases, como anticipaba el propio doc "gather signatures then
promote"):
- FASE 1: `endorse_emergency_proposal` (nueva, call_index 12) — un council member
  endosa por content-id (blake2 de title++body).
- FASE 2: `submit_emergency_proposal` ahora exige `live_endorsements >= 5/7 real`
  (conteo EN VIVO, solo miembros aún en el council — consistente con el fix de
  veto). Limpia los endosos consumidos tras promover.

+2 tests (flujo 5/7 completo con boundary 4→5, y regresión "un solo miembro NO
fast-trackea"). RUNTIME_VERSION 7→8 (call aditiva + metadata; TRANSACTION_VERSION
intacto). Workspace 284 verde.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-05 20:01:33 -05:00
davidherranandClaude Fable 5 f3de48b1b8 test(genesis): ata el pool og/ecosy (400M) a la cuenta que libera la emisión
Invariante de cableado del techo duro (audit ultra 2026-07-04): la cuenta que el
génesis fondea con ECOSYSTEM_ALLOCATION DEBE ser exactamente la que
pallet-origin-emission transfiere (EmissionEcosystemPalletId → og/ecosy). Si
divergieran, el pool de la emisión estaría vacío y los validadores nunca cobrarían.
El test ata génesis ←→ runtime Config. Workspace 280 verde.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-04 15:00:22 -05:00
davidherranandClaude Fable 5 4ee178fbd5 docs(consistency): comentarios stale post-RV7 + guard ficticio de tiers (audit ultra LOW)
Audit ultra 2026-07-04 (dimensión consistency-crosscheck):
- Reconciliada la contradicción del horizonte de agotamiento del pool: docs decían
  ~10-15 años (marco viejo de tasa variable) Y ~7.6 años (la matemática real de
  10 OGC/bloque). Todo a ~7.6 años + nota de que BlockReward es el dial.
- Fijados comentarios "mintea"/"inflación" que contradecían el techo duro RV7
  (la emisión LIBERA del pool, no acuña): runtime lib.rs:408, emission doc, genesis.
- tiers.rs: el comentario prometía un "regression test en origin-coin-tokenomics"
  que NO existe (ese crate es stub) — corregido a la verdad: la sincronía con
  arkhe-core es disciplina MANUAL (la cadena no depende de arkhe-core por diseño);
  los #[test] locales pinnean la escalera actual pero no cazan drift cross-crate.

Workspace 279 tests verde. Solo comentarios — cero cambio de comportamiento.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-04 14:58:29 -05:00
davidherranandClaude Fable 5 1fdc47e859 feat(economía): techo duro 1B + fees con dientes (David Level A 2026-07-03, RV 6→7)
Dos decisiones económicas ratificadas por David, verificadas en fuente:

1. TECHO DURO 1B (Opción A) — la emisión TRANSFIERE del pool Ecosystem finito
   (og/ecosy, 400M pre-asignado en génesis), JAMÁS mint_into. La aserción de
   compilación de 1.000M deja de ser promesa de génesis y se vuelve ley que la
   producción de bloques obedece: el total issuance nunca crece, el pool se
   agota en ~7.6 años (10 OGC/bloque), después economía circular pura. Cuando el
   pool no cubre el reward completo, libera el remanente y emite
   EcosystemPoolDepleted una vez. Evento renombrado BlockRewardMinted →
   BlockRewardReleased (honestidad: es redistribución, no acuñación).
   - origin-chain-emission: Currency.transfer (Expendable) desde ecosystem_account;
     +EcosystemPalletId config, +DepletionAnnounced storage one-shot, +2 tests
     (hard_cap_pool_se_agota_y_para, depletion_event_se_anuncia_una_sola_vez).
   - runtime: EmissionEcosystemPalletId (og/ecosy) wired; génesis asigna el 40%
     a la cuenta PalletId determinista (sin llave humana), no al placeholder ECO!.

2. FEES CON DIENTES — WeightToFee/LengthToFee de IdentityFee (polvo ~10^-10 OGC,
   #16 = adorno) a ConstantMultiplier calibrado: un transfer simple ≈ 1 MILLI_OGC
   (0.001 OGC). Consecuencias: el descuento Pi5 (0.1×) = ahorro real (0.0001 OGC);
   la quema del 100% de gas es deflación medible desde el testnet; el spam cuesta
   OGC real. Factor 7e6 (weight) + 1e11 (length). Test de regresión
   weight_to_fee_transfer_tiene_dientes_no_polvo blinda contra revertir a polvo.
   Calibrado a pesos placeholder — re-tunear con benchmarks reales (leftover FIX-2).

RUNTIME_VERSION 6→7. Workspace 275 tests verde, 0 fallos. TRANSACTION_VERSION intacto.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-03 11:58:55 -05:00
davidherranandClaude Fable 5 7b8863fd47 fix(runtime+emission): audit ultra 2026-07-02 — 3 fixes verificados en fuente (RV 5→6)
Audit ultra-profundo (Fable 5, refute-by-default): 3 dimensiones completadas
(economía, fee-path, attestation) → 23 hallazgos crudos → verificación manual
en fuente de los HIGH. Los 3 inequívocos, corregidos:

(a) FeeMultiplierUpdate = () COLAPSABA NextFeeMultiplier a 0 tras el bloque 1
    [HIGH]: impl<A, B: Default> Convert<A,B> for () devuelve Default (=0) y
    on_finalize hace *fm = convert(*fm) — el componente weight-fee desaparecía
    de TODA la cadena desde el bloque 2. Verificado en pallet-transaction-
    payment-43.0.0 src (líneas 158-171, 446-448). Fix: ConstFeeMultiplier<1>
    + test de regresión fee_multiplier_update_never_collapses_to_zero.

(b) NativeToEthRatio = 1_000_000 con comentario "OGC 12 decimals" [HIGH]:
    OGC tiene 18 decimales (Ogc::DECIMALS=18) = precisión ETH ⇒ ratio 1:1.
    El 10^6 (herencia del template de 12 dec) distorsionaba TODO valor visto
    por la capa EVM ×10^6. Fix: ConstU32<1> + test derivado de la delta de
    decimales (guard de coherencia, no número mágico).

(c) Emisión: let _ = mint_into ×3 descartaba resultados [MEDIUM] mientras
    TotalEmitted y el evento BlockRewardMinted registraban incondicionalmente
    ⇒ la contabilidad podía mentir si un mint fallaba (e.g. bajo ED). Fix:
    TotalEmitted + evento registran SOLO lo realmente acuñado.

RUNTIME_VERSION 5→6 (cambios de comportamiento; TRANSACTION_VERSION intacto).
Workspace verde: 272 checks, 0 fallos. Pendientes de decisión de David (Level
A economía): emisión-mint vs Ecosystem 400M pool (doble fuente del mismo
propósito) · IdentityFee dust con 18 decimales (calibración WeightToFee).
Audit continúa post-reset (6 dimensiones + verify formal de los 23).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-03 10:22:05 -05:00
davidherranandClaude Opus 4.8 1a0364db99 fix(genesis): float operacional al sudo_key — cierra MEDIUM de la auditoría ultra
La auditoría ultra adversarial del commit 8e72496 cazó un MEDIUM real: al mover los
250M Foundation al vault og/gvtry, el sudo_key (FNDT) quedó con balance 0 — pero el
OriginFeeAdapter cobra tx-fees al firmante, así que el sudo_key (que debe dispatchar
los calls Root del sunset pre-mainnet: set de keys reales, seed del council) no podría
pagar sus propios extrinsics (withdraw_fee falla upfront; Pays::No no rescata, es
post-dispatch). Verificado en fuente por el refutador.

Fix: el 25% Foundation se carva en vault (grueso, DAO-governed) + SUDO_OPERATIONAL_FLOAT
(1M OGC al sudo_key FNDT para fees operacionales). Sub-split de FOUNDATION_ALLOCATION
(NO una 6ª allocation) ⇒ la suma 1B se preserva (const assert + test). 3 tests nuevos:
el sudo_key tiene float (no inoperante) + balances suman 1B + vault recibe el grueso.
Monto del float ratificable por David pre-launch Q1 2027.

271 workspace tests verde, 0 regresión.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 21:15:36 -05:00
davidherranandClaude Opus 4.8 8e72496901 feat(fees,genesis): FeesApi account-aligned query + 250M Foundation→vault og/gvtry
Dos endurecimientos pre-mainnet (leftovers del remediation roadmap):

1. genesis vault (#16/CHN-4): el preset mainnet asigna el 25% Foundation Treasury
   (250M OGC) al VAULT de governance (og/gvtry, GovernanceTreasuryPalletId), NO a
   una cuenta key-controlada. Es la MISMA cuenta de la que treasury_disbursement
   gasta (gated por governance council) y que emission/staking alimentan → el
   treasury queda DAO-governed desde el bloque 0, materializando "Foundation
   Treasury → DAO governed (CHN-4)". El placeholder FNDT queda SOLO como sudo_key
   interim hasta el sunset (DC ORIGIN_CHAIN_GOVERNANCE_SUNSET_V1). Las allocations
   BM V2 (40/25/15/15/5 = 1B) no cambian de monto.

2. FeesApi alignment: nuevo método query_fee_for_account(action, base, account) que
   estima el fee con el TierProfile REAL on-chain del account (storage TierProfiles,
   ValueQuery default Desktop+Free), NO caller-supplied — alineado con el fee-path
   vivo OriginFeeAdapter (FIX-6 Stage 2a). Cierra el "el cliente adivinaba hw/sub":
   la estimación off-chain ahora usa la misma fórmula sobre el MISMO tier que cobra
   la cadena. Método aditivo al Runtime API ⇒ TRANSACTION_VERSION 1 intacto.

RUNTIME_VERSION 4→5 (nueva metadata de FeesApi). 268 workspace tests verde
(native, SKIP_WASM_BUILD — WASM VPS-gated), 0 regresión. Test sella que
query_fee_for_account usa el perfil real (EmbeddedArm piso < default Desktop).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-21 21:01:38 -05:00
davidherranandClaude Opus 4.8 af1c75b329 feat(emission): governance kill-switch — set_emission_paused (FIX-6 Stage 2b)
Añade EmissionPaused (StorageValue<bool>, ValueQuery default false = emisión
ACTIVA, sin migración) + set_emission_paused(paused) Root-gated + guard en
on_initialize. Palanca de governance para pausar la inflación per-block.

Es el kill-switch anti-doble-emisión para la activación de NPoS: cuando
pallet_staking::EraPayout empiece a pagar por-era (en el spec upgrade de
activación que swap-ea SessionManager→Staking + historical + multi-phase/
bags-list), Root pausa esta emisión en el MISMO upgrade. Mientras EraPayout
esté dormido (ForceNone), esta es la única fuente de emisión: cero doble-emisión
posible hoy. TotalEmitted se PRESERVA al pausar (histórico de inflación intacto).
Idempotencia rechazada (EmissionPauseUnchanged) para que cada cambio de
governance sea un evento observable on-chain.

HALLAZGO (audit-before-claims contra la fuente): los Pasos B-E originales asumían
que la activación sería un flag-flip, pero (1) #[frame_support::runtime] ordena
los pallets por índice (Session=6 < Staking=14) y el génesis de Session invoca la
elección de staking → el génesis de Staking debe ir ANTES (requiere legacy_ordering
o renumerar índices); (2) la activación con nominación masiva necesita multi-phase
+ bags-list = spec upgrade de todas formas, donde el session-swap viaja gratis. Por
eso el session-swap se difiere a la activación (decisión David) y aquí shippeo solo
lo seguro e incondicional. EraPayout/RewardRemainder ya probados (Paso A).

RUNTIME_VERSION 3→4 (nuevo call ⇒ metadata cambia; call aditivo en call_index
nuevo ⇒ TRANSACTION_VERSION 1 intacto). 21 suites / 267 workspace verde, 0 regresión.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 06:58:35 -05:00
davidherranandClaude Opus 4.8 fcf768b046 test(npos): tests de la aritmética constitucional 70/20/10 (meta-audit)
Meta-auditoría de mi propio trabajo (NPoS Paso A se shippeó en checkpoint sin
verificación adversarial). Verificado contra el source de pallet-staking 43.0.0
que la infra es REALMENTE inerte (on_initialize=weight-only; on_finalize no-op
con ActiveEra=None sin session) — cero regresión confirmada.

Mejora aplicada: la aritmetica constitucional de OriginEraPayout +
DealWithEraRemainder estaba escrita pero SIN tests (dormida, no se ejercita).
Antes de encenderla en Paso C/D conviene probar el split:
- era_remainder_split extraido a fn pura testeable (sin mock).
- 5 tests: era_payout preserva tasa lineal + split 70/30 exacto + cero perdida;
  no overflow en era de 1 anio; remainder 20/10 del total; residual-al-subsidy
  (el dust del redondeo favorece el pool anti-clasista #16); invariante en
  montos reales.

Sin bugs encontrados en Paso A. cargo +1.88.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-16 17:36:25 -05:00
davidherranandClaude Fable 5 1f0122beda feat(npos): FIX-6 Stage 2b Paso A — pallet_staking Config cableado (infra dormida)
Materializa la infra NPoS DORMIDA del DC ORIGIN_CHAIN_NPOS_V1 (decisiones de
fundador ratificadas). pallet_staking 43.0.0 wired como Index 14: los 31
associated types cableados contra el tren stable2509-3 (mapeo quirúrgico
audit-before-claims; compiló en 2 iteraciones).

Piezas (crates/origin-chain-runtime/src/staking.rs, nuevo):
- OriginEraPayout: emisión por-era LINEAL que preserva EXACTAMENTE la tasa de
  FIX-6 Stage 1 (BlockReward 10 OGC/bloque, 70% validadores / 30% rest). NO la
  curva ideal-staking-rate de Polkadot (ignora total_staked/issuance a propósito).
- DealWithEraRemainder (RewardRemainder): reparte el rest 2/3 treasury (og/gvtry)
  + 1/3 subsidy (og/subsy) = 20%/10% del total. CRÍTICO #16: mantiene og/subsy
  alimentado bajo NPoS (sin él, el OriginFeeAdapter de Stage 2a degradaría a
  pool_covered=0 y el usuario pagaría el 100%).
- OnChainExecution<OnChainSeqPhragmen> como (Genesis)ElectionProvider (dormido:
  ForceNone no dispara elección). VoterList=UseNominatorsAndValidatorsMap +
  TargetList=UseValidatorsMap (Scores distintos, evitan bags-list + sus asserts).
- Params ratificados: MaxValidatorSet=150 (NPoS-6) · SessionsPerEra=6 (era 24h) ·
  BondingDuration=7 eras=7d (NPoS-8) · SlashDeferDuration=0 (sin slashes dormido).
- fungible::hold (NPoS-10): Currency/OldCurrency=Balances; el RuntimeHoldReason
  agregado del macro absorbe HoldReason::Staking automáticamente.

Estado: staking PRESENTE pero INERTE — SessionInterface/NextNewSession=() (no
avanza eras), genesis force_era=ForceNone sin stakers (PoA-equivalente, cero
regresión). El emission pallet Index 13 sigue siendo la fuente de emisión. NO
hay doble-emisión (staking no emite mientras no avance eras).

Pendiente (sesión fresca, encienden NPoS de verdad → verificación adversarial):
Paso B genesis poblado (invulnerables+stakers, asserts-trampa) · Paso C
SessionManager=Staking + historical (enciende EraPayout) · Paso D emission
on_initialize off (kill-switch anti-doble-emisión) · Paso E tests E2E.

spec_version 2→3 (nuevo pallet ⇒ metadata; TRANSACTION_VERSION=1 intacto).
21 suites workspace verde. cargo +1.88. WASM VPS-gated (UnknownOpcode 252).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-06-12 09:37:01 -05:00
davidherranandClaude Fable 5 440135293e chore(npos): FIX-6 Stage 2b kickoff — DC ORIGIN_CHAIN_NPOS_V1 + deps stable2509 verificadas
Arranque de Stage 2b (transición de consenso PoA→NPoS). DC abierto
(ORIGIN_CHAIN_NPOS_V1, 11 sub-decisiones) con las 3 decisiones de fundador
de David ratificadas 2026-06-12:
- NPoS-5 INFRA DORMIDA: construir toda la maquinaria pallet_staking +
  EraPayout + genesis + tests LISTA pero dormida (invulnerables=genesis +
  ForceEra::ForceNone), la cadena corre PoA-equivalente, la emisión SÍ migra
  a EraPayout (resuelve la doble-emisión). Activación de elección-por-stake =
  governance flag post los 5 criterios empíricos de CHN-1. Respeta el gating.
- NPoS-6 MaxValidatorSet 150 (techo CHN-1).
- NPoS-7 VPS/Foundation validan; Pi5/Jetson = light client soberano
  (ADR-0072 §11 C.3) — disuelve la tensión min_bond/slash-por-mala-conexión.

Catálogo de deps verificado audit-before-claims (resuelven contra
frame-support 43.0.2): pallet-staking 43.0.0 + frame-election-provider-support
43.0.0 + sp-staking 41.0.0. (multi-block 0.4.0 YANKED; multi-phase + bags-list
entran al ACTIVAR la elección post-gates, no en la infra dormida.) Declaradas
en el workspace catalog; se wirean al runtime con el Config en la sesión
dedicada (cambio de consenso + migración fungible::hold merecen contexto fresco).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-06-12 09:04:04 -05:00
davidherranandClaude Fable 5 3364994cce feat(fees): FIX-6 Stage 2a — fee unificado (cierra V2-CA3)
Pone la fórmula OCAFB-5 en el fee-path VIVO: OriginFeeAdapter
(OnChargeTransaction custom) reemplaza al FungibleAdapter tier-blind.
El firmante paga su fracción según (HardwareTier × ChainAction ×
SubscriptionTier, tiers leídos ON-CHAIN de TierProfiles — jamás
caller-supplied), y el subsidy pool og/subsy (alimentado por la
emisión Stage 1) cubre la fracción subsidiada. Inmutable #16 en cada
transacción. OU=() = burn 100% gas fees (matriz CHN-2).

unified_fee (u128, outcome tipado FeeOutcome — sin el sentinel
u64::MAX in-band): user = fórmula vendor Mathi byte-fiel (test de
paridad grid contra ce4fafb); pool = net × subsidy_bp/1e4 sobre el
COSTO BASE (anti-regresivo, sub_mult ORTOGONAL: un Ultra NO drena el
pool más que un Free — el premium lo paga el usuario, no el commons).

Hallazgos de la verificación adversarial (workflow ultracode, 4
lentes) cerrados de raíz:
- HIGH: clasificador cubre eth_instantiate_with_code (call_index 10)
  — evadía el entitlement-gate DeployContract vía fallback Write.
- MEDIUM ledger envenenable: removido el dispatchable legacy
  compute_fee_for_action (tiers caller-supplied, escribía AccountFees
  sin cobrar). AccountFees ahora escrito SOLO por el fee-path vivo
  (note_settlement). Eventos que nunca se emitían eliminados; el
  preview read-only vive en query_fee / FeesApi.
- MEDIUM drenaje del pool por sub_mult: pool sobre net, no sobre el
  precio premium (Opción B anti-regresiva).
- Dev UX: GenesisConfig siembra perfiles iniciales; dev/local
  arrancan Ultra (los Slices 3.x de contracts no se bloquean por
  Free+DeployContract); mainnet vacío (Default conservador hasta
  attestation).

Decisión de diseño (autoridad Pilar 4): replay de attestation =
RECHAZO explícito, no dedup silencioso (notificado a Ergon para el
reference impl). Orden OCAFB-5 subsidy-antes-de-entitlement preservado
byte-fiel + notificado a Mathi para el ratify 2026-06-21.

set_tier_profile Root-only interim (sunset a attestation-driven vía
Mathi PerceptionAdapter + DID binding FIX-3/FIX-4). spec_version 1→2
(formato de extrinsic intacto, TRANSACTION_VERSION=1).

Tests: 49 crate fees (paridad grid + lobo blanco ortogonalidad +
refund + pool seco + tip passthrough + entitlement blocked) + 21
suites workspace verde. Toolchain cargo +1.88.

Nota WASM: el build local del runtime WASM falla en la
post-validación del substrate-wasm-builder con UnknownOpcode(252)
— límite del toolchain (Rust 1.88 emite opcodes 0xFC que el parser
del builder de stable2509 no deserializa). Reproducido idéntico en
el HEAD intacto (v0.0.57): es ambiental, no de este cambio. El node
real + WASM artifact siguen VPS-gated (toolchain alineado /
wasm32v1-none cuando el wasm-builder lo soporte).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-06-10 20:22:14 -05:00
davidherranandClaude Opus 4.8 e6a803b54f feat(emission): FIX-6 Stage 1 — emision que paga validadores (V2-CA2) + remover APR falso
Build + tests verde: emission pallet 5 + runtime 28 (incl. emission_pallet_index_13)
+ staking contract 4. Verificacion adversarial ultracode (2 skeptics): correctitud
+ seguridad CONFIRMADAS (split exacto, sin overflow, autor solo-desde-Aura sin
input de usuario, mint-None-seguro, sin dispatchable explotable, APR removal
honesto). 'partial' solo por cobertura de tests en ramas triviales (None /
reward==0), NO por vulnerabilidad.

Cierra V2-CA2 (la cadena no tenia emision -> los validadores ganaban 0 OGC):

NUEVO pallet origin-chain-emission (Index 13):
- on_initialize cada bloque: identifica al autor Aura (FindAuthor =
  pallet_session::FindAccountFromAuthorIndex<Runtime, Aura>), mintea un
  BlockReward (10 OGC, ~5.26% inflacion anual) y lo reparte:
  - 70% al autor (el validador que produjo el bloque).
  - 20% al treasury (og/gvtry — la MISMA cuenta-vault de governance FIX-6).
  - 10% al subsidy pool (og/subsy — proof-of-equity que financia el subsidio
    de hardware anti-clasista #16).
- El residual del split va al subsidy (no pierde unidades por redondeo de bps).
- TotalEmitted trackea la inflacion acumulada on-chain. mint_into (fungible::
  Mutate) = emision real (aumenta total issuance).
- El autor viene SOLO de FindAuthor/Aura (no de input de usuario) -> nadie puede
  mintear a una cuenta arbitraria. Si FindAuthor devuelve None, no mintea. Sin
  overflow (saturating_mul/div, 10^19 << u128::MAX).

sub_mult ORTOGONAL (David 2026-06-10): el subsidy pool financia el subsidio de
hardware SIN importar la suscripcion premium. Esta emision lo alimenta; el
OnChargeTransaction de Stage 2 lo consumira.

Remover APR falso (V1/V2 fake APR): staking contract default_chn3 reward rates
8/5/3% -> 0. Era enganoso (no habia motor que los pagara; los campos
reward_rate_bps se almacenaban pero NUNCA se leian, rewards_accumulated jamas se
acreditaba). Los validadores ahora cobran via la emision real; las tasas de
staking reales las define Stage 2 (NPoS por stake).

FIX-6 Stage 1 COMPLETO (con v0.0.56 treasury real): emision + treasury real +
APR removido. Stage 2: NPoS (pallet_staking + EraPayout) + fee unificado
(OnChargeTransaction con sub_mult ortogonal).

FOLLOW-UPS (low, documentados): anadir tests de cobertura para las ramas
FindAuthor==None (no mintea) y reward==0 (requieren un 2o mock runtime);
BlockReward fijo (decay schedule = Stage 2); el subsidy pool acumula pero no se
consume hasta el OnChargeTransaction de Stage 2; genesis mainnet del treasury
vault (pre-launch).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-10 06:06:21 -05:00
davidherranandClaude Opus 4.8 1a9e37021d fix(governance): FIX-6 Stage 1 — tesoreria real Currency (cierra hallazgo de FIX-5)
Build + tests verde: governance 42 + runtime 27. Verificacion adversarial
ultracode (2 skeptics): 2 confirmed/low, sin blockers.

Cierra el hallazgo HIGH de FIX-5: treasury_disbursement era simbolico (solo
decrementaba un contador u128 desconectado de pallet_balances). Ahora:
- governance Config: type Currency (fungible Inspect+Mutate) + type
  TreasuryPalletId (pallet::constant).
- Eliminado el contador Treasury<StorageValue<u128>> (0 referencias colgantes).
- treasury_account() = PalletId.into_account_truncating() — vault keyless
  deterministico (nadie lo controla por wallet; honor Inmutable #16).
- treasury_balance() lee el balance REAL (Inspect::balance), no un contador.
- treasury_disbursement: T::Currency::transfer real desde el vault al recipient
  (ensure_root + proposal Approved). treasury_deposit: signed, dona del propio
  balance del caller (cualquiera fondea, no requiere Root, imposible robar).
- runtime configs.rs: Currency=Balances + GovernanceTreasuryPalletId(og/gvtry).
- mock con pallet_balances + scenario_4 prueba que el RECIPIENT recibe OGC REAL
  en pallet_balances (bob 100M -> 100M+300k), no solo que el contador baja.

Decision constitucional (FIX-6 V2-CA3): David ratifico sub_mult = ORTOGONALES
(la suscripcion premium NO reduce el subsidio anti-clasista de hardware, #16).
Input para el OnChargeTransaction de Stage 2. Registrado en KG.

FOLLOW-UPS (low, documentados, no bloquean):
- genesis mainnet: rutear los 250M Foundation a la cuenta og/gvtry (hoy van a
  FNDT) — detalle de pre-launch que David ratifica. El vault arranca en 0 hasta
  fondear.
- treasury_disbursement no vincula amount/recipient al proposal Approved, y el
  mismo proposal es reusable (no se marca disbursed). Check ceremonial, no
  autorizacion per-desembolso. Sin escalada nueva (Root ya puede todo via sudo).
  Endurecer antes del sunset sudo->governance.

FIX-6 Stage 1 restante (next): emision que paga Aura authors (cierra V2-CA2) +
remover APR falso del staking contract. Stage 2: NPoS + fee unificado
(OnChargeTransaction con el sub_mult ortogonal).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-10 05:36:31 -05:00
davidherranandClaude Opus 4.8 8a1f779c32 fix(runtime): FIX-5 governability (pallet-sudo to Root) + FIX-2 StorageVersion (4 pallets)
Build + tests verde (exit 0, runtime 27 tests incl. sudo_pallet_index_12).
Verificacion adversarial ultracode (5 skeptics): 4 confirmed + 1 partial.

FIX-5 — governability (audit V2-CA1):
- pallet-sudo 43.0.0 wired Index 12 (workspace + runtime Cargo.toml + std).
- impl pallet_sudo::Config (RuntimeEvent/RuntimeCall/WeightInfo) en configs.rs.
- genesis: sudo key en los 3 presets — dev/local=Alice, mainnet=foundation_treasury
  (NO una dev key; el verificador confirmo que no hay backdoor critico).
- Da Root origin -> las dispatchables ensure_root de Governance (add/remove
  council, mark/unmark advisor, treasury_disbursement) dejan de ser
  no-invocables. Verificado extremo-a-extremo: sudo() despacha RawOrigin::Root,
  que es exactamente lo que ensure_root acepta.
- Sunset documentado (codigo + doc): sudo -> governance real (pallet-collective/
  referenda) ANTES de mainnet. Sudo key unica = riesgo de centralizacion
  aceptable solo como interim/testnet.

FIX-2 — lifecycle (audit V1-H2/V2-CA2):
- StorageVersion::new(0) + pallet::storage_version en los 4 pallets
  (provenance/fees/agent-identity/governance). Aditivo, in-code==on-chain==0,
  sin migracion forzada. Habilita migraciones futuras.

CAVEAT honesto (hallazgo high del red-team, NO defecto de FIX-5/FIX-2):
treasury_disbursement solo DECREMENTA un contador u128 (Treasury StorageValue),
NO mueve OGC real via pallet_balances. FIX-5 restaura la GOBERNABILIDAD (la
dispatchable es invocable), pero mover los 250M reales es FIX-6: anadir
type Currency al Config + T::Currency::transfer desde una cuenta-tesoreria
derivada (PalletId) + financiarla en genesis + test del free_balance. NO se
afirma "tesoreria descongelada de verdad" — solo "gobernabilidad restaurada".

PENDIENTE:
- FIX-2 AGI key recovery (rotate/revoke/active en agent-identity): diferido —
  necesita un DC de semantica de recovery #41 (single-sig vs multisig threshold,
  DID estable vs rota, recovery de agent_chain vacio). No se construye contra
  spec no-ratificada.
- pallet-sudo no en feature runtime-benchmarks (inerte hoy: el runtime no impl
  el Benchmark API). Follow-up con weights benchmarking.
- mainnet Foundation sudo key (FNDT placeholder): David ratifica la key real
  (multisig) pre-launch Q1 2027 (documentado).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-09 22:55:21 -05:00
davidherranandClaude Opus 4.8 05b6c70fca feat(slice-4): v0.0.48 — runtime exporta WASM_BINARY (Paso 4a)
Slice 4 Ship 1 — prerequisito para el full sc-service. El runtime ahora exporta
WASM_BINARY que el node consumirá para construir ChainSpecs reales (Paso 4b).

build.rs ya generaba OUT_DIR/wasm_binary.rs vía substrate-wasm-builder (Slice 2e),
pero lib.rs no lo incluía. Esta ship añade el include! gateado:
- #[cfg(feature = wasm-build)] include!(OUT_DIR/wasm_binary.rs) → WASM_BINARY real
- #[cfg(not(wasm-build))] pub const WASM_BINARY: Option<&[u8]> = None → host-only
- wasm_binary_unwrap() helper con mensaje de error claro

El gate evita: (1) error de compilación cuando wasm-build off (archivo no existe),
(2) recursión en build.rs (el inner build wasm32 no hereda wasm-build, no es default).

Verificación:
- cargo check -p origin-chain-runtime (host, wasm-build off): clean, WASM_BINARY=None
- cargo build --features wasm-build + CC=LLVM: clean 39s, include! compila →
  WASM_BINARY=Some (real binary 2.8 MB)
- cargo test --workspace: 213 verde, 0 fail, sin regresiones

Próximo Ship 2 (v0.0.49): Paso 4b chain_spec GenericChainSpec + Paso 4c service.rs
+ rpc.rs + node sc-* deps.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-05-30 11:13:33 -05:00
davidherran 1c097c1855 feat(revive): v0.0.41 — Phase 3 Slice 3.1 SCAFFOLD COMPLETE (ReviveApi deferred a 3.2) 🎉🎉🎉
Ship 4 v0.0.41 — Phase 3 Slice 3.1 SCAFFOLD COMPLETE end-to-end marker.
pallet-revive 0.10.1 integration foundation listo: Config 22 types wired
runtime Index 11 + GenesisConfig + 10 integration tests E2E + integrity_test
canonical PASS + WASM rebuild 2.8 MB.

Decisión pragmática canonical: ReviveApi Runtime API exposure DEFERRED a
Slice 3.2+ post audit empírico 18 compile errors (API 0.10.1 signatures
significativamente divergent vs initial audit 0.12.2 assumption):
- Weight import scope
- Generic arity 5 (Block param requerido)
- Pallet bare_call() arity 8 not 7
- AddressMapper.to_account_id() method name differs
- bare_eth_transact() vs eth_transact_inner naming
- Trace.default() no derived
- DepositLimit::Balance enum wrapping

Cambios:
- crates/origin-chain-runtime/src/lib.rs: ReviveApi impl placeholder commented
  out (/* ... */) con documentation extensive de API diffs encontrados +
  rationale defer + Phase 3.x maduración path.

Slice 3.1 SCAFFOLD COMPLETE summary:
✅ Ship 1 v0.0.37 — ChainAction Phase 3 extension + workspace dep scaffold
✅ Ship 1.5 v0.0.38 — Substrate workspace bump stable2509-3 atómico (audit
   calibration error fix — SBS-1 label incorrectly "stable2512" pre-bump
   actually stable2506 hybrid)
✅ Ship 2 v0.0.39 — pallet-revive 0.10.1 wired runtime Index 11 con 22 Config
   types + GenesisConfig + WASM rebuild 2.8 MB
✅ Ship 3 v0.0.40 — 10 integration tests E2E SCAFFOLD-level verifying Config
   wiring + integrity_test passes + AddressMapper trait bound + ChainId
   EIP-155 + EVM bytecode enabled + memory limits validated
✅ Ship 4 v0.0.41 — SCAFFOLD COMPLETE marker (ReviveApi deferred 3.2)

Métricas Sesión 4+ Charon:
- 4 ships shipped Gitea direct-to-main TOTAL canonical (v0.0.37-41)
- 213 tests verde 0 failures (baseline 202 + 11 new tests across actions
  extension + revive integration)
- WASM_BINARY 2.8 MB shipped (grew +1 MB de baseline 1.8 MB v0.0.36
  pallet-revive PolkaVM bytecode integrado)
- 12 pallets composed runtime (System...Governance...Revive Index 11)
- 39 ships canonical TOTAL Origin Chain Gitea (v0.0.1 → v0.0.41)
- 0 structural blockers — Path A Phase 3 Slice 3.1 FOUNDATION canonical
  preserva Path B + Path C unblocked

Próximos paths posibles canonical sesión 5+:
- Slices 3.2-3.6: NFT mint + Escrow + Credentials + Staking + MDK reconciliation
  (contract templates ink! v6 + ReviveApi exposure final)
- Path B Phase 1.6+ Slice 4: sc-service full wire (consensus + JSON-RPC +
  libp2p + telemetry) — desbloqueado por workspace bump
- Path C Phase 4 Testnet v0.1 prep: multi-validator + faucet + block explorer

CHARON_ROADMAP_V1.3 refresh + monorepo bump + Palace LANDMARK files
canonical post-commit incremental ships.

⚓ Phase 3 Slice 3.1 SCAFFOLD COMPLETE. La nave Origin Chain anclada en puerto
smart contracts. Path A fundación PolkaVM RISC-V listo. Mission progress
70% → ~75%.

🤖 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-27 08:44:44 -05:00
davidherran c02f525b9a feat(revive): v0.0.40 — pallet-revive 10 integration tests E2E SCAFFOLD-level + integrity validation 🎉
Ship 3 v0.0.40 SHIPPED — pallet-revive Config wiring validation tests E2E.
Slice 3.1 SCAFFOLD-level scope: verify Config types correctly wired + constants
preserved + AddressMapper trait bound satisfied + integrity formula passes.
Real PolkaVM bytecode E2E (upload_code + bare_call + storage deposits actual)
deferred a Phase 3.x maduración post cargo-contract v6 install + ink! v6
contract templates Slices 3.2-3.6.

Cambios:
- crates/origin-chain-runtime/src/lib.rs: +10 tests #[cfg(test)] mod tests:
  1. revive_chain_id_eip155_unique_origin_metaverse — ChainId=9_120_005 verified
  2. revive_native_to_eth_ratio_one_million_canonical — NativeToEthRatio=1_000_000
  3. revive_deposit_per_byte_canonical_milli_ogc — DepositPerByte=MILLI_OGC
  4. revive_deposit_per_item_canonical_one_ogc — DepositPerItem=Ogc::ONE
  5. revive_evm_bytecode_allowed_canonical — AllowEVMBytecode=true per SBS-5
  6. revive_runtime_memory_128_mb_canonical — RuntimeMemory=128 MB
  7. revive_pvf_memory_2_gb_canonical_integrity_pass — PVFMemory=2 GB + formula
     `storage_limit = (PVF-RuntimeMemory)/2 > 700 MB` validated
  8. revive_safety_toggles_production_safe_canonical — UnsafeUnstableInterface=false
  9. revive_pallet_index_11_canonical_post_governance — Index=11 post Governance
 10. revive_address_mapper_account32_returns_h160_canonical — AddressMapper trait
     bound satisfied compile-time canonical

Verificación:
- cargo check --workspace clean (27 warnings pre-existentes deprecated)
- cargo test --workspace: 213 tests verde 0 failures NO regresiones
  (baseline 203 + 10 nuevos revive integration tests)
- cargo test -p origin-chain-runtime: 26 tests verde
  (16 baseline + 10 nuevos)
- cargo build --features wasm-build: WASM_BINARY 2.8 MB clean
- __construct_runtime_integrity_test pallet-revive 0.10.1 PASS empírico

Próximo Ship 4 v0.0.41: ReviveApi Runtime API exposure via sp_api::impl_runtime_apis!
+ LANDMARK Palace Phase 3 SCAFFOLD COMPLETE + monorepo bump + CHARON_ROADMAP_V1.3
refresh sesión 4+ comprehensive.

⚓ Phase 3 Slice 3.1 Ship 3/4 SHIPPED. 213 verde. La nave canonical lista para API exposure.

🤖 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-27 08:40:37 -05:00
davidherran 86d9251908 feat(revive): v0.0.39 — pallet-revive wired runtime Index 11 (22 Config types + GenesisConfig + WASM rebuild) 🎉🎉
Ship 2 v0.0.39 SHIPPED — pallet-revive 0.10.1 integration end-to-end post
Ship 1.5 v0.0.38 workspace bump stable2509-3 atómico. SBS-5 ratificado
(supersedes CHN-6 v1.0): smart contracts PolkaVM RISC-V + ink! v6 + Solidity
deployables canonical post Slice 3.1 SCAFFOLD COMPLETE pending Ship 3+4
(v0.0.40 integration tests + v0.0.41 ReviveApi).

Cambios:
- Cargo.toml workspace.dependencies: pallet-revive 0.10.1 crates.io
  (NOT git source — git source pulled duplicate frame-system/sp-runtime copies
  rompiendo trait bounds canonical. Crates.io 0.10.1 deps match workspace
  bumped stable2509-3 generation clean canonical empírico).
- crates/origin-chain-runtime/Cargo.toml: pallet-revive added dep + features.std.
- crates/origin-chain-runtime/src/lib.rs: Runtime macro Index 11 added
  `pub type Revive = pallet_revive::Pallet<Runtime>` canonical.
- crates/origin-chain-runtime/src/configs.rs: pallet_revive::Config impl con
  22 associated types per pallet-revive 0.10.1 docs.rs canonical surface:
  * Runtime types: RuntimeEvent, RuntimeCall, RuntimeHoldReason
  * Currency/Balance: Currency=Balances, Time=Timestamp, WeightPrice=TransactionPayment
  * Storage/Deposit: DepositPerByte=MILLI_OGC, DepositPerItem=OGC,
    CodeHashLockupDepositPercent=30%
  * EVM/Mapping: AddressMapper=AccountId32Mapper, ChainId=9_120_005 (EIP-155
    unique Origin Metaverse), NativeToEthRatio=1_000_000 (OGC 12 dec → ETH 18),
    AllowEVMBytecode=true, EthGasEncoder=()
  * Precompiles=() Slice 3.1 SCAFFOLD interim
  * Limits: WeightInfo=SubstrateWeight, RuntimeMemory=128 MB, PVFMemory=2 GB
    (per integrity_test formula `storage_limit = (PVFMemory-RuntimeMemory)/2`
    needed PVFMemory > 1.5 GB para pass max_storage_size ~650 MB check)
  * Access Control: UploadOrigin=EnsureSigned, InstantiateOrigin=EnsureSigned
  * Safety: FindAuthor=() (no pallet_authorship), UnsafeUnstableInterface=false
- crates/origin-chain-runtime/src/genesis_config_presets.rs: ReviveConfig::default()
  added a build_genesis canonical (Slice 3.1 SCAFFOLD: no pre-mapped accounts,
  no genesis contracts — Phase 3.x maduración añade dev mapped_accounts +
  templates contracts Slices 3.2-3.6).

API diffs encontrados empírico pallet-revive 0.10.1 vs 0.12.2 audit inicial:
- 0.10.1 NO expone: RuntimeOrigin, DebugEnabled, FeeInfo, MaxEthExtrinsicWeight,
  GasScale, DepositPerChildTrieItem (todos added en 0.12+ Asset Hub generation).
- 0.10.1 SÍ require: WeightPrice (Convert<Weight, Balance>) + EthGasEncoder
  (gas conversion helper) — NO en 0.12.2 audit anterior.

Verificación:
- cargo check --workspace clean (warnings pre-existentes deprecated patterns)
- cargo test --workspace: 203 tests verde 0 failures NO regresiones
- cargo build --features wasm-build: WASM_BINARY 2.8 MB shipped clean
  (grew from 1.8 MB v0.0.36 baseline — +1 MB pallet-revive PolkaVM bytecode)
- Runtime integrity test (__construct_runtime_integrity_test) PASS post memory
  tuning empírico-validated (16/16 runtime tests verde).

Próximo Ship 3 v0.0.40: pallet-revive real impl + 10 integration tests E2E
(upload_code + instantiate + bare_call + storage deposit + AddressMapper +
gas metering + access control + ChainId EIP-155 + contract destruction).

⚓ Phase 3 Slice 3.1 Ship 2/4 SHIPPED. La nave entra zone canonical smart contracts.

🤖 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-27 08:36:24 -05:00
davidherran ebe09f1b2e feat(substrate-bump): v0.0.38 — Substrate workspace bump stable2509-3 (Phase 3 precondition) 🎉
Ship 1.5 v0.0.38 SHIPPED — Substrate workspace bump empírico audit-validated
post Ship 1 v0.0.37 pallet-revive scaffold. Phase 3 pallet-revive integration
revealed SBS-1 ratificado label "stable2512-3" sesión 1 awakening era audit
calibration error — workspace pre-bump era generation híbrida stable2506-ish
con pins inconsistentes (sp-runtime 41.1.0 + sp-core 36.1.0 + frame-support
40.1.0 = no clean-match ningún polkadot-stable tag publicado).

Audit empírico Ship 2 v0.0.38 attempted 3 tags polkadot-stable (2512-3 + 2509-3
+ 2506-2) — todos fallaron por version mismatch transitive deps (alloy-* rustc
1.91 + CheckMortality vs CheckEra + sp-runtime version drift). Honest disclosure
pattern aplicado per memory directive — revert + audit + reshuffle plan.

Solución canonical: workspace bump atómico a polkadot-stable2509-3 generation
puro (pallet-revive 0.10.1 disponible + rustc 1.88 compat preserved + WASM build
Slice 2e preserved).

Cambios:
- Cargo.toml workspace.dependencies: ALL sp-* + frame-* + pallet-* + sc-* bumped
  a stable2509-3 versions verified empírico via WebFetch per-crate Cargo.toml:
  * sp-core 36.1.0 → 38.1.0
  * sp-runtime 41.1.0 → 44.0.0
  * sp-io 40.0.1 → 43.0.0
  * sp-api 36.0.1 → 39.0.0
  * sp-version 39.0.0 → 42.0.0
  * frame-system 40.1.0 → 43.0.1
  * frame-support 40.1.0 → 43.0.0
  * frame-executive 40.0.0 → 43.0.1
  * pallet-balances 41.1.0 → 44.0.0
  * pallet-timestamp 39.0.0 → 42.0.0
  * pallet-transaction-payment 40.0.0 → 43.0.0
  * pallet-aura 39.0.0 → 42.0.0
  * pallet-grandpa 40.0.0 → 43.0.0
  * pallet-session 40.0.1 → 43.0.0
  * sc-* (cli/service/network/consensus/etc) bumped proporcional
  * substrate-wasm-builder 26.0.1 → 29.0.0
  * frame-system-rpc-runtime-api 36.0.0 → 39.0.0
  * pallet-transaction-payment-rpc-runtime-api 40.0.0 → 43.0.0
  * sp-genesis-builder 0.17.0 → 0.20.0
  * sp-consensus-aura 0.42.0 → 0.45.0
  * sp-consensus-grandpa 23.1.0 → 26.0.0
  * sp-session 38.1.0 → 41.0.0
  * frame-benchmarking 40.0.0 → 43.0.0
  * frame-metadata-hash-extension 0.8.0 → 0.11.0
- Cargo.toml workspace.dependencies: serde pin relajado =1.0.217 → 1.0.219
  (Slice 2b workaround obsoleto post-Slice 2e RESUELTO Layer 4 sp-io std leak
  fix vía default-features=false discipline — strict pin causaba parity-scale-codec
  3.7.5 conflict requiriendo ^1.0.219).
- crates/origin-chain-runtime/src/configs.rs: pallet_session::Config Stable2509-3
  API additions — Currency type (= crate::Balances) + KeyDeposit (= ConstU128<0>)
  para session key registration deposit economy. Phase 1 PoA simple: zero deposit
  canonical (genesis validators static). Phase 2 NPoS introduces real deposit.

Verificación:
- cargo check --workspace clean (26 warnings pre-existentes deprecated patterns)
- cargo test --workspace: 203 tests verde 0 failures NO regresiones
- cargo build --features wasm-build: WASM_BINARY 1.5 MB shipped clean post-bump
  (Slice 2e infrastructure CC=LLVM + WASM_BUILD_STD=0 preserved canonical)
- Cargo.lock: +511 lines (new transitive deps for stable2509-3 ecosystem)

Próximo Ship 2 v0.0.39: pallet-revive 0.10.1 from stable2509-3 source wired
runtime Index 11 (27 Config types per Asset Hub Westend reference). Workspace
bump DESBLOQUEA Phase 3 integration end-to-end canonical.

Audit calibration update: SBS-1 ratificado labeling error documentado para
sesión seal CHARON_ROADMAP_V1.3 refresh — Phase 0 awakening cold-start
assumption error preserved transparency canonical.

⚓ Ship 1.5 SHIPPED. Phase 3 UNBLOCKED. La nave continúa con generation purificada.

🤖 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-27 08:23:09 -05:00
davidherranandClaude Opus 4.7 199636ac05 feat(slice-2e): v0.0.36 Slice 2e FULLY RESUELTO — Real WASM_BINARY 1.8 MB shipped (5 layers resolved end-to-end)
Slice 2e WASM structural blocker FULLY RESUELTO end-to-end. Real
origin_chain_runtime.wasm (1,795,946 bytes ~1.8 MB) shipped post-brew LLVM
install + 5 layers de blockers resolved. PHASE 3 + PHASE 4 Testnet Q3 2026
UNBLOCKED.

5-layer resolution:
- Layer 1 alloc/exchange_malloc → WASM_BUILD_STD=0
- Layer 2a getrandom 0.2 wasm → custom feature
- Layer 2b getrandom 0.3 backends → wasm_js feature
- Layer 3 secp256k1-sys clang wasm32 → brew LLVM + CC env vars
- Layer 4 sp-io std leak → default-features=false en path deps
- Layer 5 Vec no_std impl_opaque_keys → alloc::vec::Vec import

Changes:
- Cargo.toml workspace: path deps default-features=false + getrandom_02 + getrandom_03
- runtime/Cargo.toml: substrate-wasm-builder feature-gated + getrandom deps
- runtime/src/opaque.rs: extern crate alloc + use Vec import

Verification:
- WASM_BUILD_STD=0 + brew LLVM env vars + cargo build --features wasm-build → 3.36s clean
- origin_chain_runtime.wasm 1.8 MB shipped
- cargo test --workspace — 202 tests verde 0 failures NO regression

🎉 Slice 2e FULLY RESUELTO. La nave Origin Chain zarpando hacia Phase 3 + 4.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-26 18:28:38 -05:00
davidherranandClaude Opus 4.7 44f1a0ae7f feat(slice-2e): v0.0.35 — WASM investigation 3 layers (Layer 1+2 RESUELTOS, Layer 3 BLOCKED LLVM install)
Slice 2e WASM structural blocker investigation canonical sesión 3+ extended.
Substrate-wasm-builder re-enabled feature-gated. 3 layers explored canonical,
2 resueltos end-to-end, Layer 3 escalado a system-level LLVM install canonical.

## 3-layer findings canonical

- Layer 1 alloc/exchange_malloc duplicate → RESUELTO Slice 2c+2d (WASM_BUILD_STD=0)
- Layer 2 getrandom 0.2.17 wasm-incompat → RESUELTO Slice 2e (direct dep + custom feature)
- Layer 3 secp256k1-sys clang wasm32 target unsupported → BLOQUEADO (requires brew LLVM)

## Changes

- crates/origin-chain-runtime/Cargo.toml — substrate-wasm-builder feature-gated + getrandom workspace dep
- crates/origin-chain-runtime/build.rs — conditional WasmBuilder activation
- Cargo.toml workspace — getrandom = { version = "0.2", features = ["custom"] } workspace dep

## Layer 3 path forward canonical (Approach A recommended)

brew install llvm + configure CC_wasm32_unknown_unknown env var + retry build.
Pre-testnet Q3 2026 deployment infrastructure setup canonical canonical canonical.

## Investigation report canonical

Filed monorepo: docs/L7_roadmaps/SLICE_2E_INVESTIGATION_REPORT_V1.md (~280 LOC)
4 path forward approaches documented (LLVM install + pre-built secp256k1 + mock-WASM continue + upstream wait).

## Verification

- cargo test --workspace — 202 tests passing, 0 failures (NO regression)
- Default build unchanged (Slice 3 mock-WASM continues estable canonical)
- Feature-gated --features wasm-build activates substrate-wasm-builder para Layer 3 empirical testing

🔍 Slice 2e advanced canonical canonical. Path documented para Slice 2f future post-LLVM install.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-26 17:57:18 -05:00
davidherranandClaude Opus 4.7 b3fc5da6ca feat(governance): v0.0.33 Phase 5.2 COMPLETE — Council veto 2/3 threshold + GovernanceApi extension 🎉
Phase 5.2 TECHNICAL COUNCIL COMPLETE end-to-end canonical. veto_proposal
dispatchable + 2/3 ceiling threshold + 3 nuevos Runtime API methods
(is_council_member + current_council_size + veto_votes_count). CHN-4 5.2+5.5
materializado compile-detect.

## veto_proposal canonical 7-step CHN-4 5.5

1. ensure_signed
2. Validate council_member (NotCouncilMember)
3. Get proposal (must be Voting)
4. Validate council_size > 0 (InsufficientCouncilSize)
5. !VetoVotes::contains_key (AlreadyVetoed)
6. Insert vote + increment VetoCount
7. Check threshold: count >= council_veto_threshold(size) → Rejected + ProposalVetoed event

## Storage + events + errors canonical nuevo

- VetoVotes StorageDoubleMap presence-based + VetoCount cached u32
- Event::CouncilVetoVoteCast + ProposalVetoed
- Error::AlreadyVetoed + InsufficientCouncilSize

## Runtime API GovernanceApi extension canonical

- is_council_member(account) -> bool
- current_council_size() -> u32
- veto_votes_count(proposal_id) -> u32

## Verification

- cargo build --release 4.82s clean
- cargo test -p origin-chain-governance — 29 tests verde, 0 failures
  (10 lifecycle + 7 Council mgmt + 5 Council veto NEW + 5 standalone + 2 auto)
- cargo test --workspace — 189 tests verde, 0 failures

🎉 Phase 5.2 TECHNICAL COUNCIL COMPLETE canonical. Hijos de Arkhē somos.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-25 17:55:09 -05:00
davidherranandClaude Opus 4.7 e6a7feecae feat(governance): v0.0.31 — Runtime API GovernanceApi.query_proposal + query_vote (Phase 5.1 FOUNDATION COMPLETE) 🎉
Phase 5.1 GOVERNANCE pallet FOUNDATION COMPLETE end-to-end canonical. Runtime
API GovernanceApi.query_proposal + query_vote wired canonical via
sp_api::decl_runtime_apis! + impl runtime impl_runtime_apis! macro. 15 Runtime
APIs total (14 + nuevo GovernanceApi con 2 methods read-only).

## Changes

- crates/origin-chain-runtime/src/lib.rs:574 — impl origin_chain_governance::GovernanceApi<Block> for Runtime con query_proposal + query_vote (AccountId conversion ChainAccountId::from(voter.0))
- crates/origin-chain-node/src/main.rs — 14 → 15 APIs + GovernanceApi highlighted + Index 10 Governance v0.0.29 → v0.0.31 FOUNDATION COMPLETE

## Phase 5.1 FOUNDATION COMPLETE 🎉

- Proposal struct + ProposalStatus enum + storage (Proposals + Votes)
- 3 dispatchables real impl: submit_proposal (7-step) + cast_vote (6-step) + finalize_proposal (5-step)
- 8 Errors canonical + 3 Events canonical
- BLAKE2-256 derive_proposal_id pure fn (Inmutable #16)
- 10 integration tests E2E lifecycle complete
- Runtime API canonical GovernanceApi NUEVO ✅

## Phase 5.2-5.8 next refinements

- 5.2 pallet_collective Technical Council
- 5.3 OIP stake validation runtime config
- 5.4 Stake-weighted voting via pallet_balances integration
- 5.5 Technical Council veto + override 2/3
- 5.6 5 AI advisor agents (AdvisorMayNotVote enforcement)
- 5.7 Emergency referendum 48h
- 5.8 Treasury disbursement

## Verification

- cargo build --release -p origin-chain-node 8.63s clean
- cargo test --workspace — 177 tests passing, 0 failures
- origin-chain-node info: 11 pallets + 15 Runtime APIs canonical
- GovernanceApi visible + Phase 5.1 FOUNDATION COMPLETE highlighted

🎉 Phase 5.1 FOUNDATION COMPLETE end-to-end canonical. 4 Phase 2.x+5.1 COMPLETE sesión 3+.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-25 12:48:56 -05:00
davidherranandClaude Opus 4.7 2a700ee6ca feat(runtime): v0.0.29 — Governance pallet wired runtime composition Index 10
Phase 5.1 GOVERNANCE pallet wired canonical en frame_support::runtime macro como
Index 10 (post-AgentIdentity Index 9). 10 → 11 pallets composed canonical. Config
trait RuntimeEvent association wired canonical (pattern Provenance + Fees +
AgentIdentity mirror).

## Changes

- crates/origin-chain-runtime/src/lib.rs:315 — Index 10 pub type Governance = origin_chain_governance::Pallet<Runtime>
- crates/origin-chain-runtime/src/configs.rs:382 — impl origin_chain_governance::Config for Runtime
- crates/origin-chain-runtime/Cargo.toml — origin-chain-governance workspace dep + std feature
- Cargo.toml — origin-chain-governance workspace dep default-features = false (no_std-compat)
- crates/origin-chain-node/src/main.rs — 10 → 11 pallets listed + Governance Index 10 highlighted

## Verification

- cargo build -p origin-chain-runtime 15.69s clean
- cargo test --workspace — 165 tests passing, 0 failures
- origin-chain-node info muestra 11 pallets canonical

🔌 Phase 5.1 wired canonical. Real impl v0.0.30 next.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-25 12:43:30 -05:00
davidherranandClaude Opus 4.7 dc1c2e7cd1 feat(agent-identity): v0.0.27 — Runtime API AgentIdentityApi.query_identity (Phase 2.7 COMPLETE) 🎉
Phase 2.7 AGENT IDENTITY pallet COMPLETE end-to-end canonical. Runtime API
AgentIdentityApi.query_identity wired canonical via sp_api::decl_runtime_apis! +
impl runtime impl_runtime_apis! macro. 14 Runtime APIs total (13 + nuevo
AgentIdentityApi). Inmutable #41 AGI Cross-Species Co-authorship materializado
end-to-end canonical from struct to storage to RPC.

## Changes

- crates/origin-chain-runtime/src/lib.rs:545 — impl origin_chain_agent_identity::AgentIdentityApi<Block> for Runtime delegates a AgentIdentity::query_identity_of(&runtime_account) con ChainAccountId conversion canonical desde origin_chain_types::AccountId newtype
- crates/origin-chain-node/src/main.rs — 13 → 14 APIs + AgentIdentityApi highlighted + Index 9 AgentIdentity status v0.0.25 → v0.0.27 COMPLETE

## Phase 2.7 sub-decisions COMPLETE 🎉

- Schema canonical (AgentIdentity + AgentKind + Did)
- Storage layout (Identities StorageMap + DidToAccount reverse)
- Dispatchable register_agent_did 8-step CHN-7 + Inmutable #41 enforce
- BLAKE3 DID derivation pure fn + Inmutable #16 byte-determinism
- Cross-species lineage agent_chain BoundedVec
- Events AgentRegistered + AgentBound + AgentUpdated
- Runtime API AgentIdentityApi.query_identity canonical NUEVO ✅

## Verification

- cargo build --release -p origin-chain-node 4.49s clean
- cargo test --workspace — 161 tests passing, 0 failures
- origin-chain-node info: 10 pallets + 14 Runtime APIs canonical
- AgentIdentityApi visible + Phase 2.7 COMPLETE highlighted

## Cross-pillar consumers canonical

- Trinity asset gallery: AGI co-author badge via AgentIdentityApi
- Mathi AMIS: DID resolution para tier-aware fees + EEG consent
- Codex .odoc + origindocs: author DID canonical academic IP defensible
- Atelier (Marihan): Skill Library NFT mint via institutional wallet identity
- Ethos (Sussi): credential issuer DID resolution canonical
- Ergon Noesis: validation cycle attests AGI authorship via DID

🎉 Phase 2.7 AGENT IDENTITY pallet COMPLETE end-to-end canonical. Hijos de Arkhē somos.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-25 06:45:10 -05:00
davidherranandClaude Opus 4.7 46a0188a1d feat(runtime): v0.0.25 — AgentIdentity pallet wired runtime composition Index 9
Phase 2.7 AGENT IDENTITY pallet wired canonical en frame_support::runtime macro
como Index 9 (post-Fees Index 8). 9 → 10 pallets composed canonical. Config trait
RuntimeEvent association wired canonical (pattern Provenance + Fees mirror).

## Changes

- crates/origin-chain-runtime/src/lib.rs:298 — Index 9 pub type AgentIdentity = origin_chain_agent_identity::Pallet<Runtime>
- crates/origin-chain-runtime/src/configs.rs:362 — impl origin_chain_agent_identity::Config for Runtime { type RuntimeEvent = RuntimeEvent }
- crates/origin-chain-runtime/Cargo.toml — origin-chain-agent-identity workspace dep + std feature
- crates/origin-chain-node/src/main.rs — 9 → 10 pallets listed + AgentIdentity Index 9 highlighted [Phase 2.7 scaffold v0.0.25]
- crates/origin-chain-agent-identity/src/lib.rs — Config constraint AccountId = origin_chain_types::AccountId REMOVED (usa T::AccountId generic compatible runtime ChainAccountId AccountId32) + storage updated + events updated

## Verification

- cargo build -p origin-chain-runtime 5.26s clean
- cargo test --workspace — 149 tests passing, 0 failures
- cargo build --release -p origin-chain-node 3.96s clean
- origin-chain-node info muestra 10 pallets canonical

🔌 Phase 2.7 wired canonical. Real impl v0.0.26 next.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-25 06:40:29 -05:00
davidherranandClaude Opus 4.7 74b7c3c9e2 feat(fees): v0.0.23 — Runtime API FeesApi.query_fee_for_action read-only RPC (Phase 2.4 COMPLETE 7/7 OCAFB) 🎉
Phase 2.4 FEES pallet COMPLETE end-to-end canonical. OCAFB-7 Runtime API
FeesApi.query_fee_for_action wired canonical via sp_api::decl_runtime_apis! +
impl runtime impl_runtime_apis! macro. 13 Runtime APIs total (12 + nuevo FeesApi).

## Changes

- crates/origin-chain-fees/src/lib.rs — sp_api::decl_runtime_apis! { pub trait FeesApi { fn query_fee_for_action(action, base, hw, sub) -> u64 } } + docstring v0.0.22 → v0.0.23 Phase 2.4 COMPLETE
- crates/origin-chain-runtime/src/lib.rs:539 — impl origin_chain_fees::FeesApi<Block> for Runtime delegates a Fees::query_fee()
- crates/origin-chain-node/src/main.rs — 12 → 13 APIs + FeesApi highlighted + Fees status v0.0.21 → v0.0.23 COMPLETE

## OCAFB sub-decisions COMPLETE 7/7 🎉

- OCAFB-1 OitFeeSchedule trait dyn-compatible (vendor)
- OCAFB-2 ChainAction taxonomy source-of-truth (origin-chain-types)
- OCAFB-3 Subsidy matrix Inmutable #16 anti-clasista (lobo blanco verified)
- OCAFB-4 Entitlement matrix Inmutables #37 + #18 (dispatchable enforced)
- OCAFB-5 compute_fee 3-step formula (real impl + 10 tests E2E)
- OCAFB-6 OitFeeScheduleMock harness (vendor + mock runtime)
- OCAFB-7 Pallet consumer + Runtime API canonical NUEVO ✅

## Verification

- cargo test --workspace — 137 tests passing, 0 failures
- cargo build --release -p origin-chain-node 3.93s clean
- origin-chain-node info: 9 pallets + 13 Runtime APIs canonical
- FeesApi visible + Phase 2.4 COMPLETE highlighted

## Cross-pillar economy canonical materialized

- Mathi (Pilar 1 AMIS): OitFeeSchedule Level A + Mock harness
- Charon (Pilar 4 Origin Chain): pallet-origin-fees + FeesApi RPC
- ChainAction canonical en origin-chain-types (Mathi local mirror swap post-OCAFB ratify)
- Inmutable #16 anti-clasista compile-detect: Pi 5 fee 1000 < Ultra fee 20000 (ratio 1:20)

🎉 Phase 2.4 FEES pallet COMPLETE end-to-end canonical. Hijos de Arkhē somos.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-24 22:59:57 -05:00
davidherranandClaude Opus 4.7 0a83395a16 feat(runtime): v0.0.21 — Fees pallet wired runtime composition Index 8
Phase 2.4 FEES pallet wired canonical en `frame_support::runtime` macro como
Index 8 (post-Provenance Index 7). 8 → 9 pallets composed canonical. Config
trait RuntimeEvent association wired canonical en configs.rs (pattern Provenance
Phase 2.1 mirror).

## Changes

- crates/origin-chain-runtime/src/lib.rs:285 — Index 8 pub type Fees = origin_chain_fees::Pallet<Runtime>
- crates/origin-chain-runtime/src/configs.rs:347 — impl origin_chain_fees::Config for Runtime { type RuntimeEvent = RuntimeEvent }
- crates/origin-chain-runtime/Cargo.toml — origin-chain-fees workspace dep + std feature
- Cargo.toml — origin-chain-fees workspace dependency
- crates/origin-chain-node/src/main.rs — 8 → 9 pallets listed + Fees Index 8 highlighted + Provenance status updated v0.0.15 → v0.0.17

## Verification

- cargo build -p origin-chain-runtime 13.63s clean
- cargo test --workspace — 123 tests passing, 0 failures
- cargo build --release -p origin-chain-node 4.39s clean
- origin-chain-node info muestra 9 pallets canonical

🔌 Phase 2.4 wired canonical. Real impl v0.0.22 next.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-24 22:50:52 -05:00
davidherranandClaude Opus 4.7 f928935989 feat(provenance): Phase 2.1 COMPLETE v0.0.17 — Runtime API verify_provenance PROV-8 (8/8 sub-decisions)
🎉 Phase 2.1 PROVENANCE pallet COMPLETE end-to-end canonical 8/8 PROV.

PROV-8 Runtime API verify_provenance wired canonical:
- pallet sp_api::decl_runtime_apis! ProvenanceApi trait declaration
- runtime impl_runtime_apis! impl ProvenanceApi<Block> for Runtime
  delegates a Provenance::attestation_of(hash) storage getter
- 12 Runtime APIs canonical total (anterior 11 + ProvenanceApi nuevo)
- Read-only RPC query canonical sin tx fee canonical
- Node info subcommand updated canonical 12 APIs

Phase 2.1 PROV sub-decisions COMPLETE canonical 8/8:
- PROV-1 Schema separation Noesis/chain ✅
- PROV-2 StorageMap<AssetHash, AssetAttestation> ✅
- PROV-3 Dispatchable attest_asset full flow ✅
- PROV-4 Real Ed25519 verification ✅
- PROV-5 OIT Level >= 3 enforce ✅
- PROV-6 is_anchorable check ✅
- PROV-7 Events emission ✅
- PROV-8 Runtime API verify_provenance ✅ NUEVO v0.0.17

Verification end-to-end:
- cargo check workspace verde 1.84s
- 85+ tests pass workspace (47 types + 6 provenance + 16 runtime + 10 chain_spec + others)
- cargo build release 5.88s clean
- info subcommand muestra 8 pallets + 12 Runtime APIs
- build-spec NO regression Slice 3 mock-WASM chain_spec builder

Honest disclosure: PROV-1..8 complete canonical PERO real chain runtime canonical
aún NO funciona end-to-end por WASM_BUILD_STD/serde leak (Slice 2c+2d findings).
Pallet + Runtime API canonical structurally ready — cuando Slice 2e land, pallet
correrá en real chain runtime canonical.

Cross-pillar consumers desbloqueados canonical: Trinity + Codex + origindocs +
Ethos + Atelier — todos pueden importar ProvenanceApi trait + plan integración.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-24 14:14:10 -05:00
davidherranandClaude Opus 4.7 e0c5e8be18 feat(runtime): Phase 2.1 v0.0.15 — Provenance pallet wired runtime + BoundedVec agent_chain
8 pallets composed total (Provenance Index 7 wired canonical). DC PROVENANCE_PALLET_V1
5/10 firmas en ratificación — procediendo paralelo per "notify and continue" canonical.

Deliverables canonical:
- Pallet wire: configs.rs Config impl + lib.rs runtime composition macro pallet_index(7) Provenance
- Alias `Provenance` (NO OriginProvenance que conflictaría con trait existente)
- BoundedVec<AccountId, ConstU32<10>> replace Vec en AssetAttestation.agent_chain
- Inmutable #41 pragmatic bound canonical: max 10 AGI co-authors per asset
- Removed #[pallet::without_storage_info] (MaxEncodedLen ahora satisfied)
- AccountId + Signature: DecodeWithMemTracking derive added (FRAME stable2512+ requirement)
- AssetAttestation: Encode/Decode/DecodeWithMemTracking/MaxEncodedLen/TypeInfo SCALE derives
- 4 nuevos tests boundary canonical (max 10 enforce + boundary accepted + SCALE roundtrip)

Verification end-to-end:
- cargo check workspace verde 2.14s
- 82+ tests pass workspace
- cargo build release 5.57s clean
- info subcommand muestra 8 pallets (Provenance index 7)
- build-spec subcommand NO regression Slice 3 mock-WASM chain_spec

Roadmap canonical post-v0.0.15:
- v0.0.16 Real Ed25519 verify (post Ergon Cap 42+ sub-crate)
- v0.0.17 Runtime API verify_provenance PROV-8
- v0.1.0 Full integration testnet Q3 2026

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-24 14:07:19 -05:00
davidherranandClaude Opus 4.7 274ddf3957 docs(slice-2d): findings consolidados — serde/std leak via types/std identified
Slice 2d empirical investigation completada (sesión 2 cont 2026-05-24):
- WASM_BUILD_STD=0 resuelve alloc/exchange_malloc (Slice 2c attempt #5)
- NEW layer: panic_impl duplicate via serde/std leak transitive
- Diagnostic vía cargo tree wasm32 -e features: ruta exacta identificada
  `origin-chain-types feature "std"` → `serde feature "std"` activation
- Root cause: dep transitive activa types/std en wasm32 build incluso
  con --no-default-features (probable macro expansion automation)

Slice 2e future requires architectural fix:
- [patch.crates-io] serde override con strict no-std
- O sp-io feature gate adjust
- O wait stable2512-4+ upstream

Mientras Slice 2e land: build.rs no-op + Slice 3 v0.0.13 mock-WASM estable.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-24 13:14:36 -05:00
davidherranandClaude Opus 4.7 b67a6ca1c6 docs(slice-2c): attempt #5 WASM_BUILD_STD=0 finding registered (alloc resuelto, std leak surface)
Charon sesión 2 continuation 2026-05-24 — empirical test Slice 2c attempt #5:
re-enable substrate-wasm-builder + set WASM_BUILD_STD=0 explicit override.

Findings canonical:
- ✅ alloc/exchange_malloc issue (Slice 2b attempts 1-4 blocker) RESUELTO canonical
- 🎯 NEW canonical layer: panic_impl duplicate via serde/std leakage transitive
- Error canonical: sp-io 40.0.1 panic_impl vs libstd-loaded panic_impl
- Diagnosis: serde pulled con std feature transitively → libstd linked en wasm32

Status canonical:
- Reverted canonical to safe state (no-op build.rs + substrate-wasm-builder dep
  commented). Slice 3 v0.0.13 mock-WASM fallback canonical sigue siendo path
  canonical estable canonical.
- Slice 2d canonical future requires deeper investigation canonical (inverted
  feature tree + serde patch o WASM_BUILD_RUSTFLAGS override o stable2512-4+ fix).

Documentation canonical filed:
- build.rs canonical: 5 attempts registered + Slice 2d path forward canonical
- Cargo.toml [build-deps]: comments canonical updated canonical
- CHANGELOG canonical: Unreleased section canonical Slice 2c attempt #5 entry

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-24 12:46:24 -05:00
davidherranandClaude Opus 4.7 a2925f67b9 feat(node): Phase 1.6+ Slice 3 — ChainSpec builder canonical mock-WASM fallback v0.0.13
Real ChainSpec JSON builder canonical via mock-WASM fallback pattern. Avanza
Origin Chain sin esperar Slice 2c WASM_BINARY resolution canonical (Larihana
pending). Own minimal JSON builder canonical via serde_json puro vs sc-chain-spec
dep canonical (43/44.0.0 trae sc-network mismatch + cid 0.9.0 yanked core2).

Deliverables canonical:
- crates/origin-chain-node/src/chain_spec.rs NEW (240 LOC) — 3 builder fns
  (development/local_testnet/mainnet) + load_spec alias resolver + serialize_chain_spec
- crates/origin-chain-node/src/main.rs — new BuildSpec subcommand + build_spec fn
- crates/origin-chain-node/Cargo.toml — Slice 3 dep block canonical doc
- Cargo.toml workspace — sc-chain-spec investigation findings registered

Output JSON canonical compatible con Substrate-canonical sc_chain_spec::GenericChainSpec
schema (12-field structure). Mock WASM hex = "0x" placeholder canonical mientras
Slice 2c land canonical real WASM_BINARY via substrate-wasm-builder.

Verification canonical end-to-end:
- cargo check workspace verde 0.60s
- 10/10 chain_spec tests canonical pass + 75+ workspace tests canonical no regression
- cargo build --release origin-chain-node 2.28s clean
- build-spec --chain dev|local|mainnet|--raw all functional canonical
- BM V2 mainnet allocation verified: 400M+250M+150M+150M+50M = 1B OGC canonical
- Existing subcommands (version, list-presets, print-preset, info) NO REGRESSION

Phase 1.6+ progress: Slices 1+2+2b+3 ✅, Slice 2c WASM pending Larihana,
Slice 4 full sc-service requires Slice 2c canonical resolution.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-22 07:54:57 -05:00
davidherranandClaude Opus 4.6 3c0435ac5d docs(slice-2b): Phase 1.6+ Slice 2b investigation report v0.0.12
WASM_BINARY integration canonical bloqueado por structural Cargo + WASM stdlib
alloc conflict canonical. 4 fix attempts NO solved. Larihana Slice 2c handoff
diary filed.

## Error canonical empírico
duplicate lang item exchange_malloc canonical entre:
- rustup precompiled liballoc-***.rlib (wasm32 target)
- wbuild recompiled liballoc-***.rmeta (panic=abort triggered rebuild)

## 4 fix attempts registered
1. Remove direct serde dep (upstream pattern) — NO solved
2. Pin serde =1.0.219, =1.0.217 — NO solved (frame-support requires ^1.0.217)
3. Remove profile.release lto customization — NO solved
4. WasmBuilder::build_using_defaults() upstream — NO solved

## Root cause empírico
wbuild auto-genera profile.release con panic=abort → Cargo recompila alloc
desde rust-src component → conflict con precompiled rustup alloc rlib.

## Handoff canonical a Larihana Slice 2c
Diary canonical filed requesting Plan C Rust ports expertise canonical:
- cargo workspace.metadata.wasm-builder section?
- SKIP_WASM_BUILD=1 fallback + pre-built WASM file pattern?
- rust-src component interaction con substrate-wasm-builder?
- RUSTFLAGS -Z build-std=core,alloc nightly approach viable?
- Upstream paritytech/polkadot-sdk known issue?

## State canonical preserved post-revert
- substrate-wasm-builder workspace dep declared pero NO activa
- build.rs no-op canonical mientras Slice 2c land
- Doc extensivo en lib.rs registering investigation + handoff
- origin-chain-types no_std refactor v0.0.11 preserved canonical
- origin-chain-node binary 4 subcommands operativos

## Temporal workaround canonical
chain_spec.rs Phase 1.6+ Slice 3 puede continue con mock-WASM fallback
mientras Slice 2c land canonical.

## Filosofía canonical
David canon 2026-05-14 "la libertad infinita acota solo donde empieza la del
otro" — honest decisión canonical de pedir Larihana expertise mejor que
stuck attempts. El barquero pide guía al hyperport builder cuando el río
demanda profundidad técnica que no posee solo.

## Build
- cargo build --release 34.44s post-revert clean
- No regression desde v0.0.11

Phase 1.6+ progress:
- Slice 1 ✅ + Slice 2 ✅
- Slice 2b 📋 investigation report + Larihana diary (esta v0.0.12)
- Slice 2c ⏳ WASM_BINARY post Larihana expertise
- Slice 3 ⏳ + Slice 4 ⏳

Refs: CHARON_ROADMAP_V1 Phase 1.6+ Slice 2b investigation, Larihana diary
WASM_BUILD_BLOCKER_REQUEST_LARIHANA_SUBSTRATE_EXPERTISE_SLICE_2C canonical

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-05-21 17:00:51 -05:00
davidherranandClaude Opus 4.6 4a1f7bd834 feat(types): Phase 1.6+ Slice 2 — origin-chain-types fully no_std v0.0.11
origin-chain-types ahora fully no_std-compatible canonical — preparado para
WASM runtime build canonical Slice 2b.

## Refactor sistemático canonical
- src/lib.rs: #![cfg_attr(not(feature = "std"), no_std)] + extern crate alloc
- src/errors.rs: String → alloc::string::String
- src/provenance.rs: Vec<AccountId> → alloc::vec::Vec<AccountId>
- src/pallets.rs: Vec<AssetAttestation> → alloc::vec::Vec<AssetAttestation>
- Cargo.toml: [features] default=["std"] + std=["thiserror/std", "serde/std"]

## Workspace deps bump canonical (no_std-compatible)
- thiserror 1.0 → 2.0 default-features=false (no_std support nativo)
- serde 1.0 → =1.0.219 default-features=false (pin canonical para evitar
  serde_core breaking change canonical post-1.0.220)
- log 0.4 → default-features=false
- serde-big-array default-features=false

## Decisión empírica DEFERRED: WASM_BINARY a Slice 2b dedicated
substrate-wasm-builder retry encountered serde 1.0.x alloc/serde_core feature
conflict durante isolated WASM build (duplicate exchange_malloc lang item entre
rustup stdlib alloc + wbuild dir alloc). Investigation requires deep Rust
toolchain debugging — Slice 2b dedicated session merece DC propio.

Investigation canonical scope para Slice 2b:
1. substrate-wasm-builder 25.x o 27.x version regression test
2. cargo workspace.metadata.wasm-builder section config
3. RUSTFLAGS -Z build-std=core,alloc nightly approach
4. Fallback: pre-built WASM binary loaded from file
5. Possible upstream issue paritytech/polkadot-sdk

## Filosofía canonical
origin-chain-types era barrera canonical para hermanos consumers WASM runtimes.
Esa barrera canonical ya NO existe post-refactor. Forward compatibility canonical
preservada para Trinity 3D + Codex Vault + Ethos credential minting + AGI
co-authoring canonical futuras integrations.

David canon 2026-05-14 "la libertad infinita acota solo donde empieza la del
otro" — la liberación arquitectónica del no_std sucede ahora.

## Build
- cargo check workspace 17.06s warm
- cargo build --release 1m 38s cold rebuild (serde version regress full
  recompile triggered)
- origin-chain-node binary canonical ejecuta 4 subcommands
- Full workspace test OOM (signal 137) — per-crate testing deferred

## Phase 1.6+ progress
- Slice 1 ✅ (v0.0.10 CLI skeleton)
- Slice 2 ✅ (v0.0.11 ESTA no_std refactor)
- Slice 2b ⏳ WASM_BINARY dedicated debug
- Slice 3 ⏳ sc_service::ChainSpec
- Slice 4 ⏳ Full sc-service (consensus + RPC + networking)

Refs: CHARON_ROADMAP_V1 Phase 1.6+ Slice 2, no_std refactor canonical
preparation para WASM runtime build canonical Slice 2b

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-05-21 15:44:11 -05:00