David, 2-nov-2026: «Sí a la súper-mayoría, dos tercios».
- Una propuesta de tesoro se aprueba sólo si su Aye es al menos dos tercios del voto
emitido (Aye + Nay; la abstención no cuenta), además del quórum y de la mayoría simple.
- Se fija al crear la propuesta (storage TreasurySupermajorityOf) y se consume al decidirla.
Las de tesoro abiertas antes de spec 21 conservan la mayoría simple con la que se abrieron.
- Revertir el veto de una propuesta de tesoro exige los dos tercios frente a TODA la
oposición: el Nay original más lo que sostuvo el veto en la ventana. Es el bloqueante de
la revisión adversaria: con Nay 4Q y 2Q sosteniendo, 8Q pagaban cuando el voto ordinario
pedía 12Q.
- Evento nuevo ProposalRejectedForSupermajority, al final del enum. Sin migración y con
transaction_version igual.
- reaches_supermajority: exacta (aye por den >= num por emitido), monótona, sin Aye nunca
aprueba y falla cerrada si desborda. Un const assert exige que la fracción sea mayor que 1/2.
- Pruebas: 18 contrafactuales en rojo (17 en su aserción, 1 en compilación), 114 tests del
pallet y 373 del workspace.
- E2E: pasos 2c (la propuesta nueva guarda 2/3), 2d (la sembrada en spec 18 no) y 2e (la
frontera del upgrade sobre todas las propuestas de tesoro).
Falta antes de main: el certificado de Laurha para los tres pesos que cambian de esqueleto
(submit_treasury_proposal, finalize_proposal, finalize_override), el E2E vivo y el upgrade.
Sigue abierto, desde RV17: el override de una propuesta ORDINARIA no cuenta lo que sostiene.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Decision de David, 2026-10-29: «Si, del 10 % de lo que puede votar».
Que puede votar:
- Es la emision vigente menos el saldo que nadie puede votar ni recuperar: el pool de emision,
el de subsidios y el vault de gobierno (cuentas_sin_llave en configs.rs).
- Los bonds (og/props) y los depositos de pallet-revive NO se restan, porque vuelven enteros a
una cuenta con llave. La revision adversaria de spec 19 lo demostro con sonda: restarlos
dejaba bajar el quorum un 14 % en el genesis de mainnet, aparcando un bond en una propuesta
de relleno y recuperandolo despues.
Efecto:
- En mainnet el quorum pasa de ~100M a ~35,1M OGC (10 % de 351M).
- En la testnet de la casa apenas cambia.
- Las propuestas abiertas conservan el quorum que guardaron al crearse.
Pruebas:
- quorums_del_runtime clasifica cada cuenta de pallet por su nombre.
- aparcar_un_bond_no_baja_el_quorum reproduce la sonda con la configuracion real.
- toda_cuenta_de_pallet_con_saldo_esta_clasificada vigila las cuentas modl del genesis.
- 10 contrafactuales en rojo.
- El E2E (paso 2b) descubre las cuentas de pallet recorriendo el storage, no copia la lista, y
exige el quorum exacto. La comision se quema despues de despachar, y eso se mide en el
BurnedDebt de la propia transaccion.
Pesos: submit_proposal, submit_treasury_proposal y veto_proposal leen 3 cuentas mas. Medidos en
la Pi: 5 procesos limpios, el nucleo calentado 3 s antes de cada uno, a 2,4 GHz.
Operacion de la rp1, arrancar.sh:
- en cada encendido desde el 26-oct el nodo moria al segundo porque la red no estaba; ahora
espera a la ruta por defecto;
- un cerrojo flock impide dos instancias;
- el pid vivo se reconoce por su linea de comandos.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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