"Not your keys, not your coins." Correcto. Pero no es suficiente.
Tú tienes la clave privada. Tú haces self-custody. No confías en un exchange centralizado. Haces todo bien según la filosofía Web3.
Pero cuando un protocolo con el que interactúas es explotado, tu clave sigue estando a salvo, pero tus activos no.
Porque Web3 resuelve el problema de quién custodia las claves. Pero aún no resuelve el problema de la autorización: quién decide si esta transacción tiene permiso para ocurrir.
@NewtonProtocol la primera vez que ponen la respuesta antes de que los fondos se muevan. Rellenan ese espacio colocando verificaciones de autorización antes de la transferencia de fondos (pre-settlement enforcement).
Mainnet Beta verifica cada transacción a través de 4 capas principales:
👉 Compliance (cumplimiento regulatorio, sanciones, jurisdicción).
👉 Identidad (verificación de identidad, KYC/credenciales).
👉 Seguridad (beneficiarios aprobados, límites de gasto, defensa contra prompt injection para agentes).
👉 Riesgo (límites de apalancamiento, concentración, salud de oráculos, depeg, riesgo de contraparte...).
Todas las verificaciones generan un recibo firmado onchain (evidencia que puede verificarse públicamente).
No cambian demasiado el UX porque los usuarios siguen firmando la transacción por su cuenta, pero Newton AVS #Newt lo bloquea si viola la política.
Newton no compite directamente con wallets ni soluciones de custodia (como Magic Labs, con quienes colaboran).
En lugar de eso, agregan una capa de policy y autorización en medio del intent y la ejecución. Es un camino inteligente porque:
⭐ La self-custody está en auge.
⭐ La IA agentic y la automatización están creciendo y necesitan guardrails fuertes.
⭐ El capital institucional exige cumplimiento verificable.
Newton reposiciona su papel de “un protocolo de compliance” al siguiente avance lógico de la filosofía Web3 de “Not your keys” hacia “Not your unauthorized transaction”.
Encaja mucho con su producto real (VaultKit + policy engine en vivo en mainnet beta $NEWT
Tú tienes la clave privada. Tú haces self-custody. No confías en un exchange centralizado. Haces todo bien según la filosofía Web3.
Pero cuando un protocolo con el que interactúas es explotado, tu clave sigue estando a salvo, pero tus activos no.
Porque Web3 resuelve el problema de quién custodia las claves. Pero aún no resuelve el problema de la autorización: quién decide si esta transacción tiene permiso para ocurrir.
@NewtonProtocol la primera vez que ponen la respuesta antes de que los fondos se muevan. Rellenan ese espacio colocando verificaciones de autorización antes de la transferencia de fondos (pre-settlement enforcement).
Mainnet Beta verifica cada transacción a través de 4 capas principales:
👉 Compliance (cumplimiento regulatorio, sanciones, jurisdicción).
👉 Identidad (verificación de identidad, KYC/credenciales).
👉 Seguridad (beneficiarios aprobados, límites de gasto, defensa contra prompt injection para agentes).
👉 Riesgo (límites de apalancamiento, concentración, salud de oráculos, depeg, riesgo de contraparte...).
Todas las verificaciones generan un recibo firmado onchain (evidencia que puede verificarse públicamente).
No cambian demasiado el UX porque los usuarios siguen firmando la transacción por su cuenta, pero Newton AVS #Newt lo bloquea si viola la política.
Newton no compite directamente con wallets ni soluciones de custodia (como Magic Labs, con quienes colaboran).
En lugar de eso, agregan una capa de policy y autorización en medio del intent y la ejecución. Es un camino inteligente porque:
⭐ La self-custody está en auge.
⭐ La IA agentic y la automatización están creciendo y necesitan guardrails fuertes.
⭐ El capital institucional exige cumplimiento verificable.
Newton reposiciona su papel de “un protocolo de compliance” al siguiente avance lógico de la filosofía Web3 de “Not your keys” hacia “Not your unauthorized transaction”.
Encaja mucho con su producto real (VaultKit + policy engine en vivo en mainnet beta $NEWT