main
19
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CharonandClaude Opus 5.5
|
b6d05eaf45 |
feat(gobierno): spec 18 (RV17), quorum del voto ordinario y pago del tesoro atado a la propuesta
Gobierno (origin-chain-governance): - El voto ordinario exige un quorum de Aye, el 10 % de PILAR_4 §6.6. Se fija AL CREAR la propuesta (VoteQuorumOf) y se consume al decidirla: un set_code no mueve la meta de un voto abierto. Cuenta solo el Aye: con el Nay, un voto en contra podria aprobar; con la abstencion, el mismo OGC inflaria el quorum de muchas propuestas. - Un override del veto tiene que alcanzar ese quorum y superar el Nay original, las dos condiciones del voto ordinario. Sin ellas, vetar abarataba una aprobacion (dos bloqueantes de las revisiones adversariales). - submit_treasury_proposal (call 16) fija destinatario y monto (TreasuryActions), y treasury_disbursement solo paga exactamente eso, una vez. Rechaza montos bajo el deposito existencial y como destinatario la propia tesoreria o la cuenta-bond. - Sin entrada en VoteQuorumOf no hay quorum: la emergencia (que nunca lleva accion de tesoro) y lo creado antes de RV17, que se abrio y voto sin quorum. Runtime: los dos quorums son el 10 % de la emision VIGENTE, redondeado hacia arriba y nunca por debajo del bond (DiezPorCientoDeLaEmision). Con 100M fijos, en la testnet de la casa (100M emitidos, todos de Alice) nada se habria aprobado nunca; en mainnet sigue siendo ~100M. Spec 18, transaction_version 1: todo lo nuevo es aditivo, sin migracion. Node: pasa a opaque::Block. Decodificaba los extrinsics con tipos nativos y rechazaba en el pool la llamada que anadia el set_code (1040, el mismo error que una llamada inexistente). Los bytes y los hashes no cambian: el binario nuevo sincronizo desde cero los 39 273 bloques de la testnet de la casa con los mismos hashes en 8 alturas. El RPC sirve los extrinsics en hex. Pesos: seis extrinsics cambiaron de codigo y se midieron en la Pi 5 (smoke declarado: 5 procesos limpios, sin CI en ningun segundo, maximo de los 5). Los otros once siguen siendo los certificados por Laurha. Se descarto una medida contaminada: su muestreador no veia los tests de la CI. Pruebas: - 363 tests verdes en el workspace. - 24 contrafactuales, los 24 en rojo. - Ensayo en la rp1 sobre una cadena con el codigo vivo de spec 17: upgrade a 18 y E2E firmando como un wallet (scripts/e2e/rv17_tesoro.py). - Ejemplo firmar_como_wallet con tesoro, pagar, votar, depositar y finalizar; los eventos llevan su fase. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
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>
|
||
|
CharonandClaude Opus 5.5
|
63918f365b |
feat(node): Origin Chain produce su primer bloque — el bloqueo arquitectural era un diagnostico falso
El node nunca habia producido un bloque: service.rs y rpc.rs estaban fuera del build desde v0.0.49 por un «bloqueo arquitectural» que afirmaba que las crates publicadas sc-consensus-aura 0.52.0 y sp-consensus-aura 0.45.0 no tenian standalone::slot_duration_at ni from_timestamp_and_slot_duration. Las dos estan ahi, en crates.io. La nota guio la decision durante meses. Causa real, medida con cargo check (362 errores) y cargo tree: el workspace mezclaba dos releases de polkadot-sdk. Las sc-* del cliente arrastraban sp-runtime 43 y las frame-* del runtime sp-runtime 44: 36 crates del nucleo duplicadas y errores de la forma «Block no satisface Block». Cura: alinear diez versiones del Cargo.toml (sc-cli 0.55, sc-service 0.54, sc-network 0.53, sc-consensus 0.52, sc-consensus-aura 0.53, sc-consensus-grandpa 0.38, sc-offchain 48, sp-blockchain 42, substrate-frame-rpc-system 47, sc-telemetry 30.0.1). El lock solo PIERDE la generacion vieja (1210 -> 1123 entradas); ninguna crate que use el runtime cambia de version. rpc.rs: el client pasa a ser el FullClient concreto. Nuestro node trabaja sobre el Block completo del runtime, que lleva dentro ChainAccountId, una proyeccion (<<MultiSignature as Verify>::Signer as IdentifyAccount>::AccountId) que rustc no normaliza dentro de un where-clause generico: 6 errores de «un bound declarado en la firma no se satisface». Con el generico fallaba, con el concreto compila. main.rs: subcomando run (sc_cli::RunCmd), que arranca new_full con litep2p o libp2p. chain_spec.rs: node_chain_spec construye un GenericChainSpec con el WASM real del runtime (build-spec sigue con su JSON). run --chain mainnet se RECHAZA: sus validadores son placeholder sin llave (gate L-3) y un node con ese genesis no produciria nunca, en silencio. Test con contrafactual: sin el brazo mainnet el id cae en la rama de ruta y falla como «fichero no encontrado»; el test exige la razon, y en rojo lo dijo asi. Medido (build con --features wasm-build, run --dev --tmp): - bloque #1 importado 2026-09-23 20:04:30, uno cada ~6 s (Aura); - GRANDPA finaliza: #7 finalizado con best #9 a los 60 s; - RPC: chain_getHeader, chain_getFinalizedHead, system_accountNextIndex (Alice = 0) y system_properties (OGC, 18 decimales, ss58 42) responden; - «Essential task txpool-background failed» aparece SOLO al SIGINT (0 ocurrencias a los 50 s con RPC servido; 1 al segundo del SIGINT). - cargo test --workspace: 318 passed, 0 failed (igual que RV14) + 1 nuevo. macOS 27: el build necesita DEVELOPER_DIR=/Library/Developer/CommandLineTools mientras la licencia de Xcode 27 no este aceptada (exit 69 en cc y git). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
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> |
||
 davidherranandClaude Opus 4.8
|
4485bb8683 |
fix(slice-4): service.rs/rpc.rs corrected (Block root + verbatim CIDP) + §11 honest finding
Slice 4 checkpoint tras intentar Opción C (David: stack consistente del tag). Build verde, 213 tests, sin regresiones. Node sigue CLI+chain_spec (mods off). === Correcciones a service.rs/rpc.rs (preservadas para wire-in) === - Block root (no opaque::Block): el runtime expone impl_runtime_apis! sobre el Block root con UncheckedExtrinsic, no un opaque block separado. rpc.rs igual. - CIDP verbatim del template restaurado: standalone::slot_duration_at + inherents::InherentDataProvider::from_timestamp_and_slot_duration. AMBOS existen en sp-consensus-aura 0.45.0 PUBLICADO (verificado inherents.rs:61). Mi 'fix' v0.0.49 (Slot::from_timestamp) era incorrecto — revertido. === §11 corrige §10.2 (diagnóstico honesto) === El problema NO era API gap (las APIs existen) ni elegir bien versiones publicadas. Es estructural del ecosistema: polkadot-sdk publica sus ~15 sub-crates sc-* en cadencias distintas → NO existe isla de versiones publicadas internamente consistente que reproduzca el tag. Verificado vía sparse index: - sc-consensus-aura 0.52.0 → sp-consensus-aura ^0.44; 0.53.0/0.53.1 → ^0.45; 0.54.0 → ^0.44 (oscila entre generaciones en patches consecutivos) - sc-service 0.54.1 (versión del tag) NO publicada en crates.io El tag solo es consistente vía su Cargo.lock commiteado en el monorepo git. === Recomendación senior para David (§11.4) === Diferir node service real al setup de infra Phase 4 testnet (que necesita build env con red git de todos modos). NO seguir adivinando versiones publicadas (no convergen). Firmes: WASM export (v0.0.48) + core2 unblock (v0.0.49) + service.rs/rpc.rs correctos. Wire-in ~1 sesión cuando haya env con git fetch O un Cargo.lock del monorepo stable2509-3. Verificación: cargo check -p origin-chain-node verde (mods off) + 213 tests verde. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
e0e0b907b7 |
feat(slice-4): v0.0.49 — core2 yanked unblock + sc-service WIP (crates.io API gap found)
Slice 4 Ship 2 parcial. RESUELVE el blocker real que difirió sc-service 3
sesiones (core2 yanked), pero DESCUBRE un segundo bloqueo arquitectural que
requiere decisión de David. Build verde, 213 tests, sin regresiones.
=== RESUELTO: core2 yanked (el muro de 3 sesiones) ===
sc-network-types 0.16 → cid ^0.9 (0.9.0 yanked) → core2 ^0.4 (0.4.0 yanked,
las no-yanked son 0.3.x que no satisfacen ^0.4). Cargo no auto-selecciona
versiones yanked → resolución fallaba. Era exactamente lo documentado en
chain_spec.rs Slice 3 que difirió sc-service.
Fix: vendorizado el .crate publicado de core2 0.4.0 (yanked pero descargable)
en vendor/core2-0.4.0/ + [patch.crates-io] core2 = { path = ... }. Una path
source es seleccionable independiente del estado yanked. El git source
(technocreatives/core2 master) resultó ser workspace ≤0.3.x, no servía.
=== DESCUBIERTO: crates.io consensus crates ≠ git tag API ===
Las crates sc-/sp- consensus PUBLICADAS (sc-consensus-aura 0.52.0 +
sp-consensus-aura 0.45.0) tienen API DISTINTA al git tag polkadot-stable2509-3
bajo el MISMO número de versión:
- git tag: sc_consensus_aura::standalone::slot_duration_at +
sp_consensus_aura::inherents::InherentDataProvider::from_timestamp_and_slot_duration
- crates.io: slot_duration_at en root + NO existe slot InherentDataProvider
(Slot no implementa el trait; Slot::from_timestamp toma 1 arg)
polkadot-sdk reusa números de versión con cambios git no publicados.
Construir un node service real requiere migrar TODO el stack sc-/sp- consensus
a git sources del tag — la misma cirugía duplicate-crate que golpeó pallet-revive
(Ship 2 v0.0.39). Decisión arquitectural para David.
Cambios:
- Cargo.toml: [patch.crates-io] core2 path vendor + sp-timestamp 39 + sp-blockchain 41
- vendor/core2-0.4.0/: crate vendorizado (yanked artifact original)
- node Cargo.toml: 13 sc-* + sp- consensus deps + jsonrpsee/rpc + core2 unblock dep
- node src/service.rs + rpc.rs: WIP escritos (verbatim stable2509-3 + 2 fixes API
crates.io), NO mod-declarados (preservados para siguiente fase)
- node src/main.rs: finding documentado, mods service/rpc neutralizados
Verificación:
- cargo check -p origin-chain-node: EXIT 0 (deps resuelven vía core2, mods off)
- cargo test --workspace: 213 verde, 0 fail, sin regresiones
- core2 0.4.0 + cid 0.9.0 ahora en Cargo.lock (vía path patch)
Próximo: decisión David — (A) migrar sc-/sp- consensus a git sources tag
stable2509-3 (real node, riesgo duplicate-crate) vs (B) mantener publicadas
(node service diferido a futura generación Substrate). Ver SLICE_4 plan §10.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
davidherranandClaude Opus 4.7
|
10ee1ab7b9 |
feat(governance): v0.0.34 Phase 5 FULLY COMPLETE — 5.3-5.8 refinements consolidated 🎉🎉🎉
Phase 5 GOVERNANCE FULLY COMPLETE end-to-end canonical. 5.3-5.8 refinements consolidated single ship canonical. AI advisor flag system (5.6) + Council veto override 4/5 community supermajority (5.5) + Emergency referendum 48h fast-track (5.7) + Treasury disbursement (5.8) + voting period constants (5.3+5.4). ## Phase 5.3+5.4 constants canonical - DEFAULT_VOTING_PERIOD_BLOCKS = 201,600 (14 days × 24h × 600 blocks/h @ 6s) - EMERGENCY_VOTING_PERIOD_BLOCKS = 28,800 (48h × 600 blocks/h) - council_emergency_threshold ceiling 5/7 ## Phase 5.5 Community override canonical - override_council_veto dispatchable (7-step canonical) - 4/5 supermajority ceiling threshold (override_supermajority_threshold const fn) - OverrideVotes StorageDoubleMap + OverrideStakeTotal cached - Events::CouncilVetoOverridden + Errors::ProposalNotRejected/AlreadyOverrideVoted/OverrideThresholdNotMet ## Phase 5.6 AI advisor system canonical - AdvisorFlags StorageMap presence-based - mark_as_advisor + unmark_as_advisor dispatchables (ensure_root) - cast_vote canonical EXTENDED: AdvisorMayNotVote enforcement (humans-only vote) - Events::AdvisorFlagged + AdvisorUnflagged + Errors::AlreadyAdvisor + NotAdvisor ## Phase 5.7 Emergency referendum canonical - submit_emergency_proposal canonical (council-only + 5/7 council pre-approval) - Fast-track 48h voting period vs 14 days - Events::EmergencyProposalSubmitted + Errors::InsufficientCouncilEmergencyApprovals ## Phase 5.8 Treasury disbursement canonical - Treasury StorageValue<u128> Foundation balance - treasury_deposit (ensure_root helper) + treasury_disbursement (6-step canonical) - Requires ProposalStatus::Approved (governance ratification) - Events::TreasuryDisbursed + Errors::TreasuryInsufficientBalance + ProposalNotApproved ## Phase 5 dispatchables canonical inventory 12 total dispatchables (Index 0-11): submit_proposal + cast_vote + finalize_proposal + Council mgmt (add/remove) + veto + advisor mgmt (mark/unmark) + override + emergency + treasury (disburse/deposit). ## Verification - cargo build --release -p origin-chain-node 5.17s clean - cargo test -p origin-chain-governance — 42 tests verde, 0 failures (10 lifecycle + 7 Council mgmt + 5 Council veto + 3 Advisor + 3 Override + 3 Emergency + 4 Treasury + 5 standalone + 2 auto) - cargo test --workspace — 202 tests verde, 0 failures 🎉🎉🎉 Phase 5 GOVERNANCE FULLY COMPLETE end-to-end canonical. CHN-4 materializado compile-detect. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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> |
||
|
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>
|
||
|
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>
|
||
|
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>
|
||
|
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> |
||
|
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> |
||
|
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> |
||
|
davidherranandClaude Opus 4.6
|
8a24a86ee6 |
feat(node): Phase 1.6+ Slice 1 — origin-chain-node CLI canonical v0.0.10
origin-chain-node binary canonical funcional con 4 sub-comandos: - version (default canonical) - list-presets (3 genesis presets disponibles) - print-preset <id> (JSON-serialized RuntimeGenesisConfig) - info (full runtime metadata canonical) ## Output canonical print-preset development verified Alice SS58 address: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY ✅ matches exactly Substrate well-known canonical — hardcoded bytes son bit-perfect compatible con polkadot-js + subkey ecosystem canonical. ## Decisión empírica documentada: WASM_BINARY DEFERRED a Slice 2 (v0.0.11) substrate-wasm-builder requiere TODAS las deps no_std-compatible. origin- chain-types actualmente usa std::String/Vec directly + thiserror 1.0 sin no_std. Refactor scope substantial (5-10+ files affected) merece DC propio y Slice dedicado canonical. CLI canonical opera correcto sin WASM execution porque genesis presets serializables natively canonical. ## Workspace deps añadidos Phase 1.6+ (most Slice 4 deferred) - substrate-wasm-builder 26.0.1 (Slice 2) - sc-cli 0.51.0, sc-service 0.50.0, sc-executor 0.42.0 (Slice 4) - sc-network 0.49.1, sc-consensus 0.48.0 (Slice 4) - sc-consensus-aura 0.49.0, sc-consensus-grandpa 0.34.0 (Slice 4) - sc-transaction-pool 39.0.0, sc-client-api 39.0.0 (Slice 4) - sc-basic-authorship 0.49.0, sc-telemetry 28.1.0, sc-offchain 44.0.0 (Slice 4) - jsonrpsee 0.24.3, substrate-frame-rpc-system 43.0.0 (Slice 4) - pallet-transaction-payment-rpc 43.0.0 (Slice 4) - clap 4.5.13 (USED v0.0.10 canonical) - futures 0.3.31 (Slice 4) Workspace declarations preparan canonical para Slice 4 sin re-declarar cuando se necesite ramp up canonical. ## Roadmap Phase 1.6+ multi-slice canonical - Slice 1 (v0.0.10 ESTA): CLI skeleton + preset listing ✅ - Slice 2 (v0.0.11): WASM_BINARY canonical + no_std refactor - Slice 3 (v0.0.12): real sc_service::ChainSpec builder canonical - Slice 4 (v0.0.13+): full sc-service (consensus + RPC + networking) ## Build + tests - cargo build --release 8.22s warm cache - cargo test --workspace ~63 tests passing - Binary functional: cargo run --bin origin-chain-node {version|list-presets| print-preset <id>|info} ## Filosofía canonical incorporada Doc main.rs: "el CLI canonical es la primera ventana del barquero al mundo". list-presets canonical = transparency canonical: las 3 distribuciones posibles canonical están a la vista canonical, BM V2 incluida canonical materializando David canon 2026-05-14 "la libertad infinita acota solo donde empieza la del otro". Refs: CHARON_ROADMAP_V1 Phase 1.6+, sub-decisión empírica WASM_BINARY defer to Slice 2, sub-decisión empírica sc-service defer to Slice 4 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.6
|
2f47654418 |
feat(workspace): Phase 1.1 — runtime + node scaffolding v0.0.2
Charon sesión 1 continuación. Phase 0.4 → Phase 1.1 ship canonical. ## origin-chain-runtime crate (Phase 1.1) - Re-exports canonical traits + types desde origin-chain-types (single-crate surface para runtime consumers) - RuntimeConfig marker (será reemplazado por Substrate Config traits Phase 1.2) - RUNTIME_VERSION = 1 constante (bump per Substrate upgrade) - Docs Phase 1 milestones (1.1 → 1.7) + Substrate version pin pending DC ## origin-chain-node binary (Phase 1.6 placeholder) - main() prints scaffold notice + canonical frase Charon - Hardware target documented: Pi 5 + NVMe SSD minimum (CHN-1) - Smoldot light client noted as separate Phase 2+ crate ## Workspace - 8 crates total (was 6): added origin-chain-runtime + origin-chain-node - 44 tests passing workspace-wide - Build release clean - cargo run --bin origin-chain-node verified working ## Notes - Aún sin deps Substrate. Phase 1.2 (pallet_aura + pallet_grandpa) será el primer slice que pulls Substrate framework + bumps rust toolchain. - Polkadot SDK version pin canónica vendrá vía DC complementaria a ORIGIN_CHAIN_FOUNDATION_V1 cuando Phase 1.2 inicie. Refs: Charon Roadmap V1 Phase 1.1, CHN-1, BM V2 §1.1 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |