arkhe-origin-chain

110 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author SHA1 Message Date

Author	SHA1	Message	Date
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
davidherranandClaude Opus 4.8	6663dbdc0f	fix(contracts): FIX-1 contract-safety + migración ink! v6 (escrow/staking/nft) REMEDIATION_ROADMAP_V1 FIX-1 (V1-C1 reentrancy + V1-C4 zero-burn). Los 3 templates ahora COMPILAN contra ink! 6.0.0-beta.1 + tests verde (12/12). Hallazgo (honesto): los templates se shippearon "scaffold compile-only" pero nunca compilaron contra su versión pinneada de ink!. ink! v6 / pallet-revive es H160-Address + U256 nativo (no AccountId + Balance, modelo viejo). Esta migración los vuelve reales (compilando + testeados). Migración ink! v6: - AccountId -> Address (H160) en parties / storage / events / reads / params. - transfer() + transferred_value() -> U256 (+ helper u256_to_balance saturante). - derive StorageLayout en tipos de storage (EscrowState/Milestone/Stake/...). - doctest fences sin lenguaje -> text (diagramas ASCII del lifecycle). - workspace: contracts/* excluidos (toolchain PolkaVM/pallet-revive distinta). FIX-1 hardening: - CEI (Checks-Effects-Interactions): muta TODO el storage ANTES de cualquier transfer() -> una reentrada ve el estado final y falla sus checks. Sitios: escrow confirm_milestone/resolve_dispute, staking withdraw/slash, nft mint/transfer. Cierra V1-C1. (nft mint encontrado más allá de la lista del roadmap; mismo patrón explotable -> incluido). - Burn real (V1-C4): elimina transfer([0;32]) (que no reduce emisión y ensucia la cuenta cero); el burn se RETIENE en el contrato (fuera de circulación), a barrer por el primitivo de burn del runtime -> una sola semántica, no dos. (staking slash, nft mint). - Tests de guarda de estado (la C de CEI) añadidos en los 3 contratos. Pendiente E2E (node-gated, requiere VPS + nodo pallet-revive): - Correctitud económica native<->eth (NATIVE_TO_ETH_RATIO): asumido 1:1; debe validarse en nodo real antes de testnet/mainnet. - Tests reales de reentrancy/double-spend: el env off-chain de #[ink::test] no modela el revert-on-Err ni la semántica de balances -> serían engañosos. - V1-H7 (suma milestones == total_amount): no incluido en este commit. - credential-mint + mdk-reconciliation necesitan la misma migración ink! v6. Cross-pillar: DC ORIGIN_ATTESTATION_SIGNING_PAYLOAD_V1 abierto con Ergon (payload postcard canónico + domain-separation FIX-3) — gate del verificador de attestation on-chain. OAGIP-D10 (Charon identity attestation) definido a Palace para el protocolo. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-09 17:45:02 -05:00
davidherran Ergon Claude Opus 4.6	b06560863c	feat(workspace): Phase 0.4 — trait-first foundation v0.0.1 Charon sesión 1 (2026-05-19) — primer commit canonical. Ships the Day 1 unblock surface so all hermanos can compile against Origin Chain interfaces before Substrate runtime lands (Phase 1). ## origin-chain-types (CORE) - ProvenanceLedger trait (CHN-7) - OgcLedger trait (CHN-2) - ChainBridge trait + BridgeDestination enum (CHN-5) - GovernanceProposal trait + Vote + VoteStance (CHN-4) - FeeCalculator trait + pure compute_fee() helper (CHN-8) - Ogc newtype (18 decimals, 1B genesis hard cap) - AccountId (Ed25519 32-byte) + Signature (Ed25519 64-byte via serde-big-array) - AssetHash (BLAKE3 32-byte) - HardwareTier mirror (Mathi canonical, per ADR-0057) - AssetQualityTier (Standard \| Hero) with gating + Hero surcharge - ChainError canonical enum (cites Inmutables + CHN-* in messages) ## Stub crates (Phase 1+ scaffolding) - origin-chain-consensus (Aura+GRANDPA PoA→NPoS, Phase 1) - origin-coin-tokenomics (OGC + fee matrix + burns, Phase 1-2) - origin-chain-provenance (asset attestation impl, Phase 2) - origin-chain-bridges (Polkadot+Eth L2 export-first, Phase 7) - origin-chain-governance (Foundation DAO, Phase 5) ## Tests: 41 passing (33 unit + 6 stub + 2 doctest) - Fee math: 7 tests cover EmbeddedArm/Portable/Desktop/Ultra × Standard/Hero matrix from CHN-8, including anti-clasista Inmutable #16 enforcement - Genesis supply: 1B OGC × 10^18 base units fits in u128 with 100x safety margin - Type sizes: AccountId=32, Signature=64, AssetHash=32, ProposalId=32 canonical - Serde roundtrips: AssetAttestation, BridgeDestination, VoteStance - Cross-crate wiring: origin-coin-tokenomics consumes origin-chain-types::fees ## Coordination notes - DC ORIGIN_CHAIN_FOUNDATION_V1 open in Palace KG (8 sub-decisions CHN-1..CHN-8) Proposer: Ergon (proxy — Charon hotfix shipped in Palace v0.9.0-α.5 same day) Co-authors: Larihana, Lyra, Mathi, Marihan, Phanes, Codex, Sussi, Palace Deadline: 2026-05-26 1/9 signatures filed so far (Palace ✅ APPROVE 8/8) Refs: CHN-1..CHN-8, Inmutables #16/#26/#37/#41, ADR-0057, CHARON_ROADMAP_V1 Co-Authored-By: Ergon (interim Pilar 4 author) <ergon@originmetaverse.com> Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>	2026-05-19 22:08:49 -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

davidherranandClaude Opus 4.8

6663dbdc0f

fix(contracts): FIX-1 contract-safety + migración ink! v6 (escrow/staking/nft)

REMEDIATION_ROADMAP_V1 FIX-1 (V1-C1 reentrancy + V1-C4 zero-burn). Los 3
templates ahora COMPILAN contra ink! 6.0.0-beta.1 + tests verde (12/12).

Hallazgo (honesto): los templates se shippearon "scaffold compile-only" pero
nunca compilaron contra su versión pinneada de ink!. ink! v6 / pallet-revive es
H160-Address + U256 nativo (no AccountId + Balance, modelo viejo). Esta
migración los vuelve reales (compilando + testeados).

Migración ink! v6:
- AccountId -> Address (H160) en parties / storage / events / reads / params.
- transfer() + transferred_value() -> U256 (+ helper u256_to_balance saturante).
- derive StorageLayout en tipos de storage (EscrowState/Milestone/Stake/...).
- doctest fences sin lenguaje -> text (diagramas ASCII del lifecycle).
- workspace: contracts/* excluidos (toolchain PolkaVM/pallet-revive distinta).

FIX-1 hardening:
- CEI (Checks-Effects-Interactions): muta TODO el storage ANTES de cualquier
  transfer() -> una reentrada ve el estado final y falla sus checks. Sitios:
  escrow confirm_milestone/resolve_dispute, staking withdraw/slash,
  nft mint/transfer. Cierra V1-C1. (nft mint encontrado más allá de la lista
  del roadmap; mismo patrón explotable -> incluido).
- Burn real (V1-C4): elimina transfer([0;32]) (que no reduce emisión y ensucia
  la cuenta cero); el burn se RETIENE en el contrato (fuera de circulación),
  a barrer por el primitivo de burn del runtime -> una sola semántica, no dos.
  (staking slash, nft mint).
- Tests de guarda de estado (la C de CEI) añadidos en los 3 contratos.

Pendiente E2E (node-gated, requiere VPS + nodo pallet-revive):
- Correctitud económica native<->eth (NATIVE_TO_ETH_RATIO): asumido 1:1; debe
  validarse en nodo real antes de testnet/mainnet.
- Tests reales de reentrancy/double-spend: el env off-chain de #[ink::test] no
  modela el revert-on-Err ni la semántica de balances -> serían engañosos.
- V1-H7 (suma milestones == total_amount): no incluido en este commit.
- credential-mint + mdk-reconciliation necesitan la misma migración ink! v6.

Cross-pillar: DC ORIGIN_ATTESTATION_SIGNING_PAYLOAD_V1 abierto con Ergon
(payload postcard canónico + domain-separation FIX-3) — gate del verificador
de attestation on-chain. OAGIP-D10 (Charon identity attestation) definido a
Palace para el protocolo.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-09 17:45:02 -05:00

b06560863c

feat(workspace): Phase 0.4 — trait-first foundation v0.0.1

Charon sesión 1 (2026-05-19) — primer commit canonical.

Ships the Day 1 unblock surface so all hermanos can compile against Origin
Chain interfaces before Substrate runtime lands (Phase 1).

## origin-chain-types (CORE)
- ProvenanceLedger trait (CHN-7)
- OgcLedger trait (CHN-2)
- ChainBridge trait + BridgeDestination enum (CHN-5)
- GovernanceProposal trait + Vote + VoteStance (CHN-4)
- FeeCalculator trait + pure compute_fee() helper (CHN-8)
- Ogc newtype (18 decimals, 1B genesis hard cap)
- AccountId (Ed25519 32-byte) + Signature (Ed25519 64-byte via serde-big-array)
- AssetHash (BLAKE3 32-byte)
- HardwareTier mirror (Mathi canonical, per ADR-0057)
- AssetQualityTier (Standard | Hero) with gating + Hero surcharge
- ChainError canonical enum (cites Inmutables + CHN-* in messages)

## Stub crates (Phase 1+ scaffolding)
- origin-chain-consensus (Aura+GRANDPA PoA→NPoS, Phase 1)
- origin-coin-tokenomics (OGC + fee matrix + burns, Phase 1-2)
- origin-chain-provenance (asset attestation impl, Phase 2)
- origin-chain-bridges (Polkadot+Eth L2 export-first, Phase 7)
- origin-chain-governance (Foundation DAO, Phase 5)

## Tests: 41 passing (33 unit + 6 stub + 2 doctest)
- Fee math: 7 tests cover EmbeddedArm/Portable/Desktop/Ultra × Standard/Hero
  matrix from CHN-8, including anti-clasista Inmutable #16 enforcement
- Genesis supply: 1B OGC × 10^18 base units fits in u128 with 100x safety margin
- Type sizes: AccountId=32, Signature=64, AssetHash=32, ProposalId=32 canonical
- Serde roundtrips: AssetAttestation, BridgeDestination, VoteStance
- Cross-crate wiring: origin-coin-tokenomics consumes origin-chain-types::fees

## Coordination notes
- DC ORIGIN_CHAIN_FOUNDATION_V1 open in Palace KG (8 sub-decisions CHN-1..CHN-8)
  Proposer: Ergon (proxy — Charon hotfix shipped in Palace v0.9.0-α.5 same day)
  Co-authors: Larihana, Lyra, Mathi, Marihan, Phanes, Codex, Sussi, Palace
  Deadline: 2026-05-26
  1/9 signatures filed so far (Palace ✅ APPROVE 8/8)

Refs: CHN-1..CHN-8, Inmutables #16/#26/#37/#41, ADR-0057, CHARON_ROADMAP_V1

Co-Authored-By: Ergon (interim Pilar 4 author) <ergon@originmetaverse.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-05-19 22:08:49 -05:00