#shareyouropinion
shareyouropinion
9,039 visualizaciones
35 participa(n) en el debate
Populares
Novedades
Con verificación
Encontré anoche un informe de transparencia anterior que no había leído antes y cambió la forma en que entiendo qué es realmente Newton. Newton en realidad no fue diseñado originalmente como un motor de cumplimiento.
La divulgación de octubre de 2025 describe el diseño original como un rollup de almacén de claves (keystore) construido para la gestión de claves, con un enfoque específicamente en la automatización verificable y la autorización delegada para agentes de IA.
La idea central era permitir que los agentes ejecutaran acciones onchain a través de permisos controlados y criptográficamente verificados, vinculados a la infraestructura de gestión de claves.
El giro ocurrió cuando el equipo se dio cuenta de que las mismas primitivas subyacentes de automatización verificable y autorización delegada podían extenderse mucho más allá de la gestión de claves de los agentes, hacia un marco general para el cumplimiento de políticas en stablecoins, RWAs y el mercado de activos en general.
El rollup de keystore se convirtió en la base de algo mucho más amplio: un motor de políticas que gobierna qué acciones pueden ocurrir, bajo qué condiciones y con qué atestaciones.
Esa es una premisa de partida significativamente distinta a la que sugería el whitepaper que leí originalmente.
En realidad, creo que esta historia importa para entender las decisiones de arquitectura de Newton: el modelo de atestación BLS, el diseño del quórum de operadores, el énfasis en el comercio de agentes como caso de uso; no son decisiones de diseño pensadas primero para el cumplimiento. Son decisiones de gestión de claves y de diseño de autorización de agentes que luego se generalizaron a casos de uso de cumplimiento.
Lo que aún no he resuelto es cuánto de la arquitectura actual sigue conservando supuestos del diseño original del rollup de keystore que podrían no ser óptimos para un motor de políticas orientado al cumplimiento; si el giro fue un rediseño limpio o una extensión de la base técnica original.
#ShareYourOpinion
$EVAA $LAB
¿Cómo crees que evolucionó la arquitectura de Newton?
@NewtonProtocol $NEWT #Newt
La divulgación de octubre de 2025 describe el diseño original como un rollup de almacén de claves (keystore) construido para la gestión de claves, con un enfoque específicamente en la automatización verificable y la autorización delegada para agentes de IA.
La idea central era permitir que los agentes ejecutaran acciones onchain a través de permisos controlados y criptográficamente verificados, vinculados a la infraestructura de gestión de claves.
El giro ocurrió cuando el equipo se dio cuenta de que las mismas primitivas subyacentes de automatización verificable y autorización delegada podían extenderse mucho más allá de la gestión de claves de los agentes, hacia un marco general para el cumplimiento de políticas en stablecoins, RWAs y el mercado de activos en general.
El rollup de keystore se convirtió en la base de algo mucho más amplio: un motor de políticas que gobierna qué acciones pueden ocurrir, bajo qué condiciones y con qué atestaciones.
Esa es una premisa de partida significativamente distinta a la que sugería el whitepaper que leí originalmente.
En realidad, creo que esta historia importa para entender las decisiones de arquitectura de Newton: el modelo de atestación BLS, el diseño del quórum de operadores, el énfasis en el comercio de agentes como caso de uso; no son decisiones de diseño pensadas primero para el cumplimiento. Son decisiones de gestión de claves y de diseño de autorización de agentes que luego se generalizaron a casos de uso de cumplimiento.
Lo que aún no he resuelto es cuánto de la arquitectura actual sigue conservando supuestos del diseño original del rollup de keystore que podrían no ser óptimos para un motor de políticas orientado al cumplimiento; si el giro fue un rediseño limpio o una extensión de la base técnica original.
#ShareYourOpinion
$EVAA $LAB
¿Cómo crees que evolucionó la arquitectura de Newton?
@NewtonProtocol $NEWT #Newt
Original design mostly remaine
0%
Major redesign after the pivot
0%
A blend of both approaches
33%
Not enough information yet
67%
3 Votos • Votación cerrada
Realidad operativa tradicional de KYC/AML frente a la brecha de responsabilidad del modelo de credenciales de Newton
Puse a prueba el modelo de identidad de Newton con un amigo oficial de cumplimiento la semana pasada, alguien que dirige programas de KYC en una firma regulada, y la brecha entre lo que Newton describe y lo que los equipos de cumplimiento hacen operativamente fue mayor de lo que esperaba.
KYC/AML tradicional: el usuario a bordo recopila documentos; se cotejan contra bases de datos de sanciones; se puntúa el riesgo; se almacena el registro. Transacción marcada a posteriori: se extrae el expediente; se revisa el historial; se redacta el informe; se presenta el SAR.
La auditoría acepta el rastro manual de documentos en papel. El banco es responsable. Fue el que hizo la comprobación. Y, por tanto, posee el resultado.
El modelo de Newton: la credencial es emitida por un tercero proveedor de KYC, es retenida por el usuario; los operadores la evalúan en un entorno seguro TEE según la política en segundos. El recibo de cumplimiento es el rastro de auditoría.
La velocidad y la automatización son reales. La primera pregunta que me hizo mi amigo de cumplimiento fue quién es responsable cuando Newton dice que la credencial es válida pero los datos del emisor estaban equivocados. En el modelo de Newton, el emisor la emitió; los operadores la evaluaron; el contrato inteligente la hizo cumplir. La cadena de responsabilidad es más larga y menos clara.
En realidad, pienso que la distribución de la responsabilidad civil es la pregunta de diseño más importante en la adopción institucional, no la capacidad técnica, sino quién asume la responsabilidad cuando una transacción que Newton atestigua resulta no conforme.
Lo que no he resuelto es si los recibos de cumplimiento de Newton satisfacen los requisitos regulatorios de responsabilidad o si solo documentan que se ejecutó una verificación, y si ambas cosas son lo mismo.
$LAB $HMSTR #shareyouropinion
@NewtonProtocol $NEWT #Newt
Puse a prueba el modelo de identidad de Newton con un amigo oficial de cumplimiento la semana pasada, alguien que dirige programas de KYC en una firma regulada, y la brecha entre lo que Newton describe y lo que los equipos de cumplimiento hacen operativamente fue mayor de lo que esperaba.
KYC/AML tradicional: el usuario a bordo recopila documentos; se cotejan contra bases de datos de sanciones; se puntúa el riesgo; se almacena el registro. Transacción marcada a posteriori: se extrae el expediente; se revisa el historial; se redacta el informe; se presenta el SAR.
La auditoría acepta el rastro manual de documentos en papel. El banco es responsable. Fue el que hizo la comprobación. Y, por tanto, posee el resultado.
El modelo de Newton: la credencial es emitida por un tercero proveedor de KYC, es retenida por el usuario; los operadores la evalúan en un entorno seguro TEE según la política en segundos. El recibo de cumplimiento es el rastro de auditoría.
La velocidad y la automatización son reales. La primera pregunta que me hizo mi amigo de cumplimiento fue quién es responsable cuando Newton dice que la credencial es válida pero los datos del emisor estaban equivocados. En el modelo de Newton, el emisor la emitió; los operadores la evaluaron; el contrato inteligente la hizo cumplir. La cadena de responsabilidad es más larga y menos clara.
En realidad, pienso que la distribución de la responsabilidad civil es la pregunta de diseño más importante en la adopción institucional, no la capacidad técnica, sino quién asume la responsabilidad cuando una transacción que Newton atestigua resulta no conforme.
Lo que no he resuelto es si los recibos de cumplimiento de Newton satisfacen los requisitos regulatorios de responsabilidad o si solo documentan que se ejecutó una verificación, y si ambas cosas son lo mismo.
$LAB $HMSTR #shareyouropinion
@NewtonProtocol $NEWT #Newt
los programas de puntos y recompensas en DeFi crean casos límite de cumplimiento. la identidad de newton y los dominios de cumplimiento no están claramente diseñados para abordarlos.
un programa de puntos distribuye créditos o tokens a wallets según la actividad del protocolo.
en ambos casos, la cuestión de cumplimiento es si la wallet receptora es elegible para recibir el valor que se distribuye.
el cumplimiento de sanciones se aplica a las distribuciones de recompensas de la misma manera que a cualquier otra transferencia de valor.
no está claramente descrito en la documentación si el dominio de cumplimiento de newton puede hacer cumplir una verificación de sanciones en transacciones de distribución de recompensas, específicamente en la transferencia saliente de recompensas desde un protocolo hacia una wallet.
la direccionalidad importa.
la mayoría de los casos de uso de newton implican comprobar una wallet antes de que envíe una transacción a un protocolo.
un airdrop de recompensas funciona en la dirección opuesta.
si el modelo de aplicación se aplica a las transferencias salientes iniciadas por el protocolo es una cuestión estructural sobre cómo se activa la comprobación de la política.
no hay respuesta para esto en la documentación actual. el caso límite es lo bastante real como para importar a cualquier protocolo DeFi que ejecute programas de recompensas activas.
@NewtonProtocol $NEWT $LAB $HMSTR #ShareYourOpinion
#Newt #NEWT
¿Se necesitan verificaciones para las recompensas?
un programa de puntos distribuye créditos o tokens a wallets según la actividad del protocolo.
en ambos casos, la cuestión de cumplimiento es si la wallet receptora es elegible para recibir el valor que se distribuye.
el cumplimiento de sanciones se aplica a las distribuciones de recompensas de la misma manera que a cualquier otra transferencia de valor.
no está claramente descrito en la documentación si el dominio de cumplimiento de newton puede hacer cumplir una verificación de sanciones en transacciones de distribución de recompensas, específicamente en la transferencia saliente de recompensas desde un protocolo hacia una wallet.
la direccionalidad importa.
la mayoría de los casos de uso de newton implican comprobar una wallet antes de que envíe una transacción a un protocolo.
un airdrop de recompensas funciona en la dirección opuesta.
si el modelo de aplicación se aplica a las transferencias salientes iniciadas por el protocolo es una cuestión estructural sobre cómo se activa la comprobación de la política.
no hay respuesta para esto en la documentación actual. el caso límite es lo bastante real como para importar a cualquier protocolo DeFi que ejecute programas de recompensas activas.
@NewtonProtocol $NEWT $LAB $HMSTR #ShareYourOpinion
#Newt #NEWT
¿Se necesitan verificaciones para las recompensas?
🔘 Always
67%
🔘 High-value only
33%
🔘 Never
0%
🔘 Depends on rules
0%
6 Votos • Votación cerrada
Lee de nuevo el documento de gobernanza anoche porque puedo asumir que la gobernanza significaba algo que ya estaba en funcionamiento. Significa algo que está siendo diseñado.
El ciclo de vida de la propuesta que describe Newton tiene cinco etapas. Idea: discusión informal sin proceso formal. RFC: solicitud de comentarios, un documento estructurado que propone un cambio. NIP: Newton Improvement Proposal, la versión formalizada de un RFC que ya está lista para su consideración.
Discusión comunitaria: un periodo abierto para recibir comentarios antes de una votación. Votación de Token House: se realiza fuera de la cadena mediante Snapshot, donde los titulares de NEWT votan sobre el NIP.
Ese es el pipeline completo tal como fue diseñado.
Lo que se me pasó en mi primera lectura es que este pipeline existe en el documento, pero que Token House en sí, el organismo que realmente vota, aún no existe como una estructura operativa. Ahora mismo, en lo que el documento llama Fase 0, la Junta de la Fundación toma decisiones. El ciclo de vida de la propuesta es el estado objetivo, no el actual.
Ese detalle cambia cómo leo cada afirmación de gobernanza en los materiales de Newton.
En realidad me gusta que el documento sea explícito con esta distinción: lenguaje de Fase 0, no vago, marketing gobernado por la comunidad. Es raro ver que un nombre de proyecto incluya directamente su propia etapa centralizada actual.
Lo que no tengo claro es qué es lo que específicamente detona una transición de la Fase 0 a la Fase 1: si es un cronograma fijo, una métrica de descentralización o totalmente a discreción de la Junta de la Fundación.
$TAC $LAB #ShareYourOpinion
@NewtonProtocol $NEWT #Newt
El ciclo de vida de la propuesta que describe Newton tiene cinco etapas. Idea: discusión informal sin proceso formal. RFC: solicitud de comentarios, un documento estructurado que propone un cambio. NIP: Newton Improvement Proposal, la versión formalizada de un RFC que ya está lista para su consideración.
Discusión comunitaria: un periodo abierto para recibir comentarios antes de una votación. Votación de Token House: se realiza fuera de la cadena mediante Snapshot, donde los titulares de NEWT votan sobre el NIP.
Ese es el pipeline completo tal como fue diseñado.
Lo que se me pasó en mi primera lectura es que este pipeline existe en el documento, pero que Token House en sí, el organismo que realmente vota, aún no existe como una estructura operativa. Ahora mismo, en lo que el documento llama Fase 0, la Junta de la Fundación toma decisiones. El ciclo de vida de la propuesta es el estado objetivo, no el actual.
Ese detalle cambia cómo leo cada afirmación de gobernanza en los materiales de Newton.
En realidad me gusta que el documento sea explícito con esta distinción: lenguaje de Fase 0, no vago, marketing gobernado por la comunidad. Es raro ver que un nombre de proyecto incluya directamente su propia etapa centralizada actual.
Lo que no tengo claro es qué es lo que específicamente detona una transición de la Fase 0 a la Fase 1: si es un cronograma fijo, una métrica de descentralización o totalmente a discreción de la Junta de la Fundación.
$TAC $LAB #ShareYourOpinion
@NewtonProtocol $NEWT #Newt
empieza pequeño. los agentes de IA que generan operaciones en DeFi nunca equivalen a la negociación algorítmica en la banca financiera tradicional y la infraestructura de cumplimiento a su alrededor está significativamente menos desarrollada.
amplía la vista: la capa de políticas de Newton aborda la cuestión de cumplimiento a nivel de transacción. ¿esta transacción específica cumple las reglas definidas? esa es una capa de lo que requiere el cumplimiento de la negociación algorítmica tradicional.
#NEWT
las capas de arriba son diferentes. el cumplimiento de la negociación algorítmica tradicional requiere documentación del modelo, auditorías y registros que conecten las operaciones ejecutadas con decisiones específicas del modelo, además de la capacidad de kill switch para la intervención humana cuando el modelo se comporte de forma inesperada.
#newt
ninguna de esas cuestiones se aborda con la aplicación previa al plazo (pre settlement) para hacer cumplir transacciones individuales.
amplía la vista aún más: si el trading de agentes de IA en DeFi escala, los reguladores aplicarán requisitos similares a los que rigen la negociación algorítmica en mercados tradicionales. la infraestructura de Newton es un componente necesario de esa pila de cumplimiento. considerarla suficiente por sí sola sería una brecha significativa para cualquier entidad regulada que use agentes de IA en DeFi.
#ShareYourOpinion $LAB $HMSTR
@NewtonProtocol $NEWT #Newt
amplía la vista: la capa de políticas de Newton aborda la cuestión de cumplimiento a nivel de transacción. ¿esta transacción específica cumple las reglas definidas? esa es una capa de lo que requiere el cumplimiento de la negociación algorítmica tradicional.
#NEWT
las capas de arriba son diferentes. el cumplimiento de la negociación algorítmica tradicional requiere documentación del modelo, auditorías y registros que conecten las operaciones ejecutadas con decisiones específicas del modelo, además de la capacidad de kill switch para la intervención humana cuando el modelo se comporte de forma inesperada.
#newt
ninguna de esas cuestiones se aborda con la aplicación previa al plazo (pre settlement) para hacer cumplir transacciones individuales.
amplía la vista aún más: si el trading de agentes de IA en DeFi escala, los reguladores aplicarán requisitos similares a los que rigen la negociación algorítmica en mercados tradicionales. la infraestructura de Newton es un componente necesario de esa pila de cumplimiento. considerarla suficiente por sí sola sería una brecha significativa para cualquier entidad regulada que use agentes de IA en DeFi.
#ShareYourOpinion $LAB $HMSTR
@NewtonProtocol $NEWT #Newt
Con verificación
El documento blanco de las bóvedas de Bitcoin sin confianza (TBV) hace algo que vale la pena resaltar en la Sección 5: enumera la Participación Abierta como un beneficio declarado y especifica liquidadores en lista blanca como el mecanismo real en la misma sección.@BabylonLabs_io
El punto del beneficio es explícito sobre a quién cubre la participación abierta: liquidadores, prestatarios y desarrolladores; todos se supone que se conectan al protocolo con un onboarding mínimo. El flujo de liquidación, unas páginas antes, también es igualmente explícito: las liquidaciones se ejecutan mediante liquidadores en lista blanca, un conjunto definido y con permisos, y no cualquiera que quiera cerrar una posición subcolateralizada.$BABY
No es que enlista a liquidadores sea irrazonable. La liquidación significa mantener y mover capital real con rapidez, y evaluar a los participantes para ese rol es una práctica estándar en protocolos de préstamos, onchain o off.
Tampoco es que las dos afirmaciones estén cómodamente juntas. El beneficio nombra a los liquidadores como participantes abiertos: el mecanismo los restringe. Ambas cosas no pueden ser totalmente ciertas al mismo tiempo; «abierto» pesa más en ese punto que lo que respalda la lista blanca. #baby
Podría haber una resolución si la lista blanca en sí es fácil de integrar: los conjuntos de cofirmas k-de-n en los que cualquiera puede entrar; entonces el onboarding mínimo y lo «en lista blanca» podrían ser lo mismo visto desde dos ángulos. Pero el documento blanco nunca dice cómo un liquidado se vuelve en lista blanca.
Entonces, ¿cualquiera puede convertirse en liquidador o la participación abierta termina en la lista blanca? La Sección 5 nombra el beneficio y la barrera en la misma página, y nunca los conecta.
$UAI $BANK
#ShareYourOpinion
#ShareYourVote
El punto del beneficio es explícito sobre a quién cubre la participación abierta: liquidadores, prestatarios y desarrolladores; todos se supone que se conectan al protocolo con un onboarding mínimo. El flujo de liquidación, unas páginas antes, también es igualmente explícito: las liquidaciones se ejecutan mediante liquidadores en lista blanca, un conjunto definido y con permisos, y no cualquiera que quiera cerrar una posición subcolateralizada.$BABY
No es que enlista a liquidadores sea irrazonable. La liquidación significa mantener y mover capital real con rapidez, y evaluar a los participantes para ese rol es una práctica estándar en protocolos de préstamos, onchain o off.
Tampoco es que las dos afirmaciones estén cómodamente juntas. El beneficio nombra a los liquidadores como participantes abiertos: el mecanismo los restringe. Ambas cosas no pueden ser totalmente ciertas al mismo tiempo; «abierto» pesa más en ese punto que lo que respalda la lista blanca. #baby
Podría haber una resolución si la lista blanca en sí es fácil de integrar: los conjuntos de cofirmas k-de-n en los que cualquiera puede entrar; entonces el onboarding mínimo y lo «en lista blanca» podrían ser lo mismo visto desde dos ángulos. Pero el documento blanco nunca dice cómo un liquidado se vuelve en lista blanca.
Entonces, ¿cualquiera puede convertirse en liquidador o la participación abierta termina en la lista blanca? La Sección 5 nombra el beneficio y la barrera en la misma página, y nunca los conecta.
$UAI $BANK
#ShareYourOpinion
#ShareYourVote
Anyone can liquidate
60%
Whitelist is required
20%
Needs clarification
20%
5 Votos • Votación cerrada
Volví y en realidad recorrí el flujo de la testnet este fin de semana en vez de solo leer sobre ello de segunda mano. Podría creerse que con ver el video guía bastaría para entender la mecánica. Pero no fue así.
La testnet pública para el préstamo nativo respaldado por Bitcoin a través de Aave v4 impulsado por Trustless Bitcoin Vaults (TBV) te permite depositar test BTC en una bóveda, ver que se verifica onchain y pedir prestado en tu contra de la misma manera que lo describe el whitepaper: la acuñación de collBTC y el lending. Reclamar los tokens de prueba del faucet primero y luego seguir el depósito mediante el explorador hizo que la descripción abstracta de “la bóveda se verifica, collBTC se acuña” que aparece en los documentos pareciera una secuencia real de pasos, en lugar de un diagrama.
Lo que me quedó claro fue solo después de hacerlo: el paso de verificación del light client no es instantáneo como se siente una transferencia normal de tokens. Hay una espera real entre el depósito y que el collBTC aparezca y sea utilizable.
De verdad creo que hacerlo tú mismo cambia la forma en que lees más adelante secciones de los whitepapers: los flujos de settlement y liquidación dejan de ser diagramas abstractos cuando ya has visto un depósito moverse por los mismos pasos.
Lo que no he resuelto es si los tiempos de las testnets coinciden con lo que realmente se sentirá en mainnet, o si la infraestructura de testnet funciona más rápido o más lento que lo que tendría un despliegue en vivo.
Hay un formulario de feedback vinculado junto a la app de la testnet; vale la pena usarlo si sigues el flujo tú mismo, especialmente si notas algo que no coincide con los documentos.
$EUL $ON #shareyouropinion
@BabylonLabs_io $BABY #baby
La testnet pública para el préstamo nativo respaldado por Bitcoin a través de Aave v4 impulsado por Trustless Bitcoin Vaults (TBV) te permite depositar test BTC en una bóveda, ver que se verifica onchain y pedir prestado en tu contra de la misma manera que lo describe el whitepaper: la acuñación de collBTC y el lending. Reclamar los tokens de prueba del faucet primero y luego seguir el depósito mediante el explorador hizo que la descripción abstracta de “la bóveda se verifica, collBTC se acuña” que aparece en los documentos pareciera una secuencia real de pasos, en lugar de un diagrama.
Lo que me quedó claro fue solo después de hacerlo: el paso de verificación del light client no es instantáneo como se siente una transferencia normal de tokens. Hay una espera real entre el depósito y que el collBTC aparezca y sea utilizable.
De verdad creo que hacerlo tú mismo cambia la forma en que lees más adelante secciones de los whitepapers: los flujos de settlement y liquidación dejan de ser diagramas abstractos cuando ya has visto un depósito moverse por los mismos pasos.
Lo que no he resuelto es si los tiempos de las testnets coinciden con lo que realmente se sentirá en mainnet, o si la infraestructura de testnet funciona más rápido o más lento que lo que tendría un despliegue en vivo.
Hay un formulario de feedback vinculado junto a la app de la testnet; vale la pena usarlo si sigues el flujo tú mismo, especialmente si notas algo que no coincide con los documentos.
$EUL $ON #shareyouropinion
@BabylonLabs_io $BABY #baby
Dinámicas de poder en la gobernanza: quién controla los umbrales de quórum, la división de comisiones y la admisión de operadores
La parte que nadie pregunta sobre la gobernanza de Newton es quién controla realmente los parámetros que más importan.
Tres líneas de gobernanza: estándares de políticas, admisión de operadores y actualizaciones de protocolo. Lo que falta en la discusión es qué gobiernan en realidad esas líneas.
Umbrales de quórum: configurables por tarea, establecidos por la gobernanza, determinan la seguridad económica de cada atestación en la red.
Reparto de comisiones: configurable, establecido por la gobernanza, determina la economía del operador.
Admisión de operadores: regida por el marco de gobernanza del protocolo, determina quién obtiene comisiones en absoluto.
Ahora mira quién tiene NEWT.
Los operadores apuestan NEWT. Los operadores ganan comisiones. Los operadores deben mantener NEWT para participar. Si los operadores tienen participaciones de NEWT desproporcionadas en relación con otros tenedores de tokens, tienen una influencia desproporcionada sobre los votos de gobernanza que establecen sus propios umbrales de quórum y la división de comisiones.
No digo que sea inusual: la mayoría de la gobernanza en prueba de participación tiene alguna versión de este problema. Los validadores en otras redes votan sobre parámetros que afectan la economía de los validadores.
#newt
No digo que sea un fallo tampoco: que los operadores tengan participación en el juego mediante tenencias de NEWT podría alinear sus intereses con la salud a largo plazo de la red, en lugar de la extracción a corto plazo.
#NEWT
Lo que aún no he resuelto es si Newton ha diseñado algún mecanismo específico para evitar que los operadores voten colectivamente para reducir los umbrales de quórum, disminuyendo su propia carga operativa de maneras que degradan silenciosamente la seguridad de la red.
#shareyouropinion $HMSTR $LAB
@NewtonProtocol $NEWT #Newt
La parte que nadie pregunta sobre la gobernanza de Newton es quién controla realmente los parámetros que más importan.
Tres líneas de gobernanza: estándares de políticas, admisión de operadores y actualizaciones de protocolo. Lo que falta en la discusión es qué gobiernan en realidad esas líneas.
Umbrales de quórum: configurables por tarea, establecidos por la gobernanza, determinan la seguridad económica de cada atestación en la red.
Reparto de comisiones: configurable, establecido por la gobernanza, determina la economía del operador.
Admisión de operadores: regida por el marco de gobernanza del protocolo, determina quién obtiene comisiones en absoluto.
Ahora mira quién tiene NEWT.
Los operadores apuestan NEWT. Los operadores ganan comisiones. Los operadores deben mantener NEWT para participar. Si los operadores tienen participaciones de NEWT desproporcionadas en relación con otros tenedores de tokens, tienen una influencia desproporcionada sobre los votos de gobernanza que establecen sus propios umbrales de quórum y la división de comisiones.
No digo que sea inusual: la mayoría de la gobernanza en prueba de participación tiene alguna versión de este problema. Los validadores en otras redes votan sobre parámetros que afectan la economía de los validadores.
#newt
No digo que sea un fallo tampoco: que los operadores tengan participación en el juego mediante tenencias de NEWT podría alinear sus intereses con la salud a largo plazo de la red, en lugar de la extracción a corto plazo.
#NEWT
Lo que aún no he resuelto es si Newton ha diseñado algún mecanismo específico para evitar que los operadores voten colectivamente para reducir los umbrales de quórum, disminuyendo su propia carga operativa de maneras que degradan silenciosamente la seguridad de la red.
#shareyouropinion $HMSTR $LAB
@NewtonProtocol $NEWT #Newt
Con verificación
Hay un conjunto de datos en el whitepaper que la mayoría de la gente pasa por alto: un estudio de 166 redes blockchain. Dieciséis tienen capacidad de congelación de activos integrada.
Diecinueve más podrían habilitarla con cambios mínimos.
Treinta y cinco redes donde la permisión sin barreras es condicional.
Newton usa esto para plantear un problema central: los controles a nivel de interfaz son insuficientes, pero también lo es la suposición de que las vías (rails) de blockchain son neutrales.
Una red con capacidad de congelación puede hacer cumplir el cumplimiento de maneras opacas y controladas por quien tenga la autoridad de congelación, sin rendición de cuentas criptográfica.
La respuesta de Newton hace cumplir en la capa de políticas, no en la capa de protocolo. La lógica de autorización es auditable en Rego. El conjunto de operadores es descentralizado. Recibos de cumplimiento onchain. Esto no impide que una red congela Activos, pero separa las decisiones de cumplimiento del protocolo para que sean auditables, incluso cuando la cadena no sea neutral.
No es una solución completa. Es una capa distinta de rendición de cuentas encima del problema.
#NEWT
En realidad, creo que los datos sobre congelación replantean lo que Newton está resolviendo: menos agregar cumplimiento a vías permisionless y más hacer el cumplimiento transparente cuando las vías mismas podrían no serlo.
#newt
La cuestión es si la capa de políticas de Newton proporciona una rendición de cuentas significativa cuando la cadena subyacente conserva la autoridad unilateral de congelación, o si un recibo de cumplimiento se vuelve irrelevante si los activos pueden congelarse de todos modos.
#ShareYourOpinion
@NewtonProtocol $NEWT #Newt
$LAB $HMSTR
Diecinueve más podrían habilitarla con cambios mínimos.
Treinta y cinco redes donde la permisión sin barreras es condicional.
Newton usa esto para plantear un problema central: los controles a nivel de interfaz son insuficientes, pero también lo es la suposición de que las vías (rails) de blockchain son neutrales.
Una red con capacidad de congelación puede hacer cumplir el cumplimiento de maneras opacas y controladas por quien tenga la autoridad de congelación, sin rendición de cuentas criptográfica.
La respuesta de Newton hace cumplir en la capa de políticas, no en la capa de protocolo. La lógica de autorización es auditable en Rego. El conjunto de operadores es descentralizado. Recibos de cumplimiento onchain. Esto no impide que una red congela Activos, pero separa las decisiones de cumplimiento del protocolo para que sean auditables, incluso cuando la cadena no sea neutral.
No es una solución completa. Es una capa distinta de rendición de cuentas encima del problema.
#NEWT
En realidad, creo que los datos sobre congelación replantean lo que Newton está resolviendo: menos agregar cumplimiento a vías permisionless y más hacer el cumplimiento transparente cuando las vías mismas podrían no serlo.
#newt
La cuestión es si la capa de políticas de Newton proporciona una rendición de cuentas significativa cuando la cadena subyacente conserva la autoridad unilateral de congelación, o si un recibo de cumplimiento se vuelve irrelevante si los activos pueden congelarse de todos modos.
#ShareYourOpinion
@NewtonProtocol $NEWT #Newt
$LAB $HMSTR
Yes — transparency matters
50%
No — freezing wins always
25%
Depends on jurisdiction
25%
Only with independent ops
0%
4 Votos • Votación cerrada
La sección de routing de comisiones de Babilón tiene una línea específica que vale la pena leer dos veces
Subasta automatizada on-chain donde las comisiones denominadas en BTC se subastan por BABY y los postores ganadores que gastan BABY obtienen un programaticamente burn.
Sin discreción de tesorería. Sin comité decidiendo cuánto quemar o cuándo. Solo una subasta mecánica vinculada directamente al uso del Protocolo.
Esa es una elección de diseño específica, no un reclamo genérico de tokenomics deflacionarias. A medida que crece la actividad de Trustless Bitcoin Vaults (TBV), se crean más bóvedas, más préstamos respaldados por BTC y más redenciones; las comisiones generadas en BTC se enrutan a través de esta subasta y BABY se elimina de la oferta como una función directa del uso real en lugar de un calendario de emisión fijo.
No estoy diciendo que esto garantice nada sobre el valor del token. Las quemas vinculadas al uso todavía dependen de que el uso ocurra realmente a una escala significativa, y el whitepaper explica explícitamente que las estructuras de comisiones y las reglas de staking permanecen bajo un diseño activo y sujetas a la aprobación de la gobernanza.
Tampoco estoy diciendo que sea un detalle menor. Vincular la mecánica de quema del token al uso del protocolo demostrado, en lugar de a una promesa de marketing o a un calendario fijo, es una señal más honesta para monitorear que la mayoría de los reclamos de tokenomics en este sector.
Lo que no he resuelto es si este mecanismo de subasta ya se ha activado en algún despliegue en vivo o si sigue siendo una de las propuestas aún bajo discusión de diseño junto con el resto del marco de enrutamiento de comisiones.
@BabylonLabs_io $BABY #baby
#ShareYourOpinion
$BANK
$DEXE
Subasta automatizada on-chain donde las comisiones denominadas en BTC se subastan por BABY y los postores ganadores que gastan BABY obtienen un programaticamente burn.
Sin discreción de tesorería. Sin comité decidiendo cuánto quemar o cuándo. Solo una subasta mecánica vinculada directamente al uso del Protocolo.
Esa es una elección de diseño específica, no un reclamo genérico de tokenomics deflacionarias. A medida que crece la actividad de Trustless Bitcoin Vaults (TBV), se crean más bóvedas, más préstamos respaldados por BTC y más redenciones; las comisiones generadas en BTC se enrutan a través de esta subasta y BABY se elimina de la oferta como una función directa del uso real en lugar de un calendario de emisión fijo.
No estoy diciendo que esto garantice nada sobre el valor del token. Las quemas vinculadas al uso todavía dependen de que el uso ocurra realmente a una escala significativa, y el whitepaper explica explícitamente que las estructuras de comisiones y las reglas de staking permanecen bajo un diseño activo y sujetas a la aprobación de la gobernanza.
Tampoco estoy diciendo que sea un detalle menor. Vincular la mecánica de quema del token al uso del protocolo demostrado, en lugar de a una promesa de marketing o a un calendario fijo, es una señal más honesta para monitorear que la mayoría de los reclamos de tokenomics en este sector.
Lo que no he resuelto es si este mecanismo de subasta ya se ha activado en algún despliegue en vivo o si sigue siendo una de las propuestas aún bajo discusión de diseño junto con el resto del marco de enrutamiento de comisiones.
@BabylonLabs_io $BABY #baby
#ShareYourOpinion
$BANK
$DEXE
Inicia sesión para explorar más contenidos