¿Quién marca el menú de control de riesgos, si es más importante que el menú en sí? Cuando el usuario ve un “banco” con etiquetas como anti-lavado de dinero, verificación de precios y detección de riesgos, su primera reacción es pensar que todos los componentes de seguridad ya están habilitados. Pero en realidad, la persona que administra estos interruptores puede ser solo curator.

Hoy revisé el repo policy-pack de @NewtonProtocol en la lista de tendencias #3 y encontré que esos elementos de verificación como Chainalysis, Hexagate, RedStone, vaults.fyi, Credora y Webacy no están soldados automáticamente dentro del vault, sino que son componentes opcionales en el dashboard. La entrada de precios de RedStone también se conectó realmente hace solo unos días.

Esto trae nuevos riesgos. Antes nos preocupaba que las reglas no fueran ejecutables; ahora que las reglas sí son ejecutables, debemos seguir preguntando de dónde provienen las reglas, quién puede cambiarlas y cuándo se cambian. Si un policy provider está demasiado concentrado, o si el curator modifica en secreto las combinaciones de verificación, lo que el usuario ve como “control de riesgos activado” podría ser solo a medias.

El beneficio de Newton Protocol es que permite incorporar estas reglas en el proceso previo a la transacción. Rego es el verificador de reglas antes de la transacción; si la policy pasa, genera una attestation para permitir el acceso; si no, la rechaza. El operator y los registros de firmas dejarán un camino verificable. Pero la propia prueba también debe explicar qué conjunto de providers y qué versión se usaron.

Por eso $NEWT en Newton Mainnet Beta la prioridad no es qué tan largo sea el menú, sino si las actualizaciones del menú se pueden auditar. #Newt Para ello hay que revisar la combinación de policy provider, los cambios de versión, el audit trail y las razones por las que se rechazaron las transacciones. @NewtonProtocol