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>
davidherranandClaude Opus 4.8
2d44042bd6