EthanValeX

Tarde en la noche, por fin me puse a probar el testnet del Babylon Trustless Bitcoin Vault. Me preguntaba si el préstamo respaldado nativamente por Bitcoin realmente se sentiría diferente cuando dejé de leer la documentación y empecé a ir clicando el flujo.
El flujo en sí fue sorprendentemente tranquilo. Minteé BTC de testnet, lo bloqueé en una bóveda, pedí prestado a través de Aave v4 y cerré la pestaña pensando que ya había visto lo que Babylon quería que viera. Sin wrapping, sin puente: solo el Bitcoin nativo quedándose donde estaba.
Luego abrí CreatorPad.
34,650 personas ya estaban en el ranking, compitiendo por una parte del fondo de recompensas de 1,195,000 $BABY , y pasé más tiempo mirando ese número que viendo el flujo de préstamo.
Al principio, se sentía un poco extraño.
TBV está construido alrededor del préstamo respaldado por Bitcoin nativo, pero las personas que lo están probando primero probablemente sean creadores, constructores curiosos y cazadores de puntos, más que titulares de Bitcoin que buscan liquidez.
Quizá eso es obvio. Quizá estoy leyendo demasiado en un ranking.
Aun así, no pude quitarme la sensación de que acababa de terminar de probar el producto, mientras que la campaña estaba probando otra cosa completamente.
Antes pensaba que las campañas de incentivos eran sobre todo para atraer usuarios. Después de pasar tiempo con el testnet, estoy empezando a preguntarme si también sirven para exponer puntos débiles mientras las apuestas aún son bajas.
Eso no era lo que esperaba llevarme del testnet.
$LAB $BABY
@BabylonLabs_io #baby

Long $KOMA
Entry
0.0237 - 0.0238
Stop Loss
Dưới 0.0228.
Take Profit
TP1: 0.0248
TP2: 0.0263
TP3: 0.0285 nếu phá đỉnh thành công.
R:R 1:2 đến 1:3

Revisé los ejemplos de co-staking de Babylon mientras tomaba un café y seguía aterrizando en el mismo número. 20,000. Cerré la pestaña para responder unos mensajes, volví y cada ejemplo todavía parecía volver a él.
#baby @BabylonLabs_io
Ya fuera que la documentación empezara con 0.1 BTC emparejado con 2,000 BABY, 0.5 BTC con 10,000 BABY o 1 BTC con 20,000 BABY, todos apuntaban a la misma proporción. Estaba convencido de que me había perdido otra regla hasta que el ejemplo final emparejó 1 BTC con 40,000 BABY, pero el peso del co-staking se mantuvo exactamente igual, porque la proporción óptima ya se había alcanzado. Ahí fue cuando dejé de buscar otra fórmula y empecé a preguntarme por qué los ejemplos estaban diseñados así desde el principio.
La mayoría de los sistemas de staking silenciosamente fomentan añadir más capital porque normalmente significa mejores recompensas. Babylon hace algo más sutil. Aunque las recompensas adicionales de co-staking provienen de una inflación anual del 2.35%, el mecanismo sigue llevando a los participantes de vuelta hacia la misma proporción de BTC a BABY en lugar de premiar a quien simplemente compromete la posición más grande de BABY.
Cuanto más miraba esos ejemplos, menos parecían cálculos de recompensas y más parecían que el protocolo empujaba a dos comunidades distintas hacia el mismo equilibrio.
Me hace preguntarme si 20,000 en realidad no es una proporción de recompensa. Más bien se siente como la manera de Babylon de coordinar a los tenedores de Bitcoin y a los tenedores de BABY sin tener que decir nunca que eso es lo que está haciendo.
$LAB $BABY

Pasé un tiempo en la testnet del Bóveda de Bitcoin sin confianza de Babylon hoy, con la mitad de la expectativa de que el flujo de préstamo fuera la parte que recordaría.
No lo fue.
Creé 0.10 BTC de testnet, bloqueé 0.08 BTC en una bóveda, pedí prestado 0.05 BTC a través de Aave, y todo el flujo funcionó bastante como yo había esperado. Incluso miré el factor de salud 2.31, cerré la ventana de confirmación y pensé que ya estaba.
Lo que se quedó conmigo no fue el préstamo en sí. Fue notar vaultBTC después y hacer clic en él instintivamente antes incluso de saber qué estaba buscando.
Nadie me había dicho que hiciera clic en "Enviar". Simplemente asumí que eso era lo siguiente.
Hice clic por aquí y por allá un rato antes de abrir la documentación, convencido de que había pasado por alto algo. La documentación confirmó que no había entendido mal nada. vaultBTC nunca estuvo pensado para ser la parte que se mueve.
Mirándolo ahora, es gracioso que nunca me pregunté si vaultBTC necesitaba moverse. Vi un token nuevo y enseguida empecé a buscar el siguiente lugar al que enviarlo. Nada en el producto sugería que ese fuera mi siguiente paso. Simplemente lo di por hecho.
Esa realización se quedó conmigo más tiempo que el propio flujo de préstamo. En realidad no estaba aprendiendo cómo funciona vaultBTC. Estaba notando qué tan rápido había proyectado años de hábitos de DeFi sobre algo construido a partir de una suposición diferente.
Me hace preguntarme cuántas cosas que pensamos que son "intuitivas" en cripto en realidad solo son hábitos que hemos repetido el tiempo suficiente.
$LAB @BabylonLabs_io $BABY #baby

Hoy volví a abrir la red de pruebas de los Bóvedas Bitcoin sin Confianza (TBV) de Babylon porque no podía recordar dónde se suponía que mi BTC debía dejar de ser... BTC.
Suena a una cosa extraña de olvidar, pero lo gracioso es que ni siquiera pude encontrar ese momento la segunda vez. Incluso volví hacia atrás porque pensé que me había saltado una pantalla de confirmación, y luego volví a pasar el flujo otra vez, un poco más despacio.
No lo encontré.
Volví a la documentación y abrí la red de pruebas de nuevo. Después de un rato, ni siquiera estaba seguro de qué era lo que creía haberme perdido. Simplemente seguía sintiendo que tenía que haber otro paso en algún lugar, aunque no podía explicar bien qué es lo que esperaba ver.
Sigo revisando la documentación, así que hay muchas posibilidades de que lo esté viendo de la forma equivocada.
Aun así, esa fue la parte que se me quedó después de cerrar la pestaña. Seguí esperando algo que nunca apareció, y quizá ya me acostumbré a buscar ese paso cada vez que pruebo un nuevo producto de préstamo con Bitcoin.
Todavía no hay una conclusión contundente.
Lo que se quedó en mi mente no fue el préstamo en sí.
Fue darme cuenta de lo natural que había asumido que Bitcoin tenía que convertirse en otra cosa antes de poder hacer algo útil.
Quizá he estado llevando esa suposición durante más tiempo del que me había dado cuenta.
Podría ser solo yo.
Me da curiosidad si alguien más que probó la red de pruebas del TBV se fue pensando en una parte completamente distinta de la experiencia a la que esperaba. Me encantaría comparar notas.

$LAB $BABY @BabylonLabs_io #baby

Cuanto más leo sobre los puentes de Bitcoin, menos convencido estoy de que la velocidad y las comisiones sean la comparación más significativa. Esos indicadores importan, pero solo después de que Bitcoin ya se haya representado en algún lugar fuera de su cadena nativa. Cuanto más observé los Bóvedas de Bitcoin sin Confianza (Trustless Bitcoin Vaults, TBV) de Babylon, más parecía que la decisión de diseño anterior es la que merece más atención.
La mayoría de los sistemas basados en puentes comienzan creando otra representación de Bitcoin antes de que pueda usarse como garantía. Una vez que esa representación se convierte en la base del proceso de préstamo, mejorar la liquidez consiste en gran medida en hacer que ese nuevo activo sea más eficiente de usar.
TBV toma un camino distinto. El BTC nativo se mantiene en custodia propia mientras que la liquidez se obtiene a través de Aave, por lo que el préstamo no comienza con que el Bitcoin envuelto (wrapped) se convierta en la garantía. Comienza demostrando que el BTC original puede respaldar de forma segura los préstamos sin salir de Bitcoin.
Eso también desplaza el lugar donde el sistema deposita sus supuestos. La garantía ya no es otra representación de Bitcoin, así que la capa de verificación pasa a ser la parte que tiene que demostrar de manera constante que el modelo funciona. La dependencia no desaparece. Simplemente se mueve.
Para mí, eso cambia por completo la comparación. La pregunta ya no es cuál diseño amplía la liquidez de Bitcoin de manera más eficiente. La pregunta es cuál diseño le pide a los usuarios aceptar menos nuevos supuestos de confianza antes de que su Bitcoin se vuelva productivo.
@BabylonLabs_io $LAB $BABY #baby
¿Qué importa más para el lending (préstamos) de Bitcoin?

Hoy me encontré de nuevo en la red de pruebas TBV de Babylon.
No porque hubiera pasado algo.
Simplemente no podía sacarme la sensación de que la primera vez me había saltado algo.
Así que volví a pasar por el flujo.
Lo extraño es que aún no podía averiguar qué creía que había omitido. Incluso volví atrás una vez porque estaba convencido de que tenía que haber otro paso escondido en algún lugar.
No lo había.
Me tomó un rato darme cuenta de que en realidad no estaba buscando otra pantalla.
Quizá solo me he acostumbrado a ciertos flujos de Bitcoin DeFi con los años. Usas BTC y, en algún momento del camino, cambia de forma, se mueve a otro lugar o da un paso más antes de que pueda ocurrir algo interesante. Con el tiempo, dejas de notar que es eso lo que estás esperando.
Esta vez yo solo... seguí esperando un paso que nunca parecía llegar.
Todavía estoy revisando la documentación, así que no quiero fingir que ya entendí la arquitectura.
Aún no hay una conclusión clara.
Solo se siente como si entrara al testnet esperando un flujo y saliera preguntándome por qué lo esperaba en primer lugar.
Podría ser solo cosa mía.
Si tú también has estado probando el testnet TBV, me encantaría comparar notas. Me da curiosidad si había alguna parte pequeña del flujo que se te quedó en la cabeza después de cerrar la pestaña.
@BabylonLabs_io $LAB $BABY #baby

Una frase en la documentación de los Tesoros Bitcoin sin confianza de Babylon me seguía molestando.
Nunca explica cómo Bitcoin puede entender Ethereum.
Explica por qué Bitcoin nunca necesita hacerlo.
Eso sonaba como una limitación hasta que noté que la misma idea aparecía por toda la arquitectura. TBV no intenta darle a Bitcoin más contexto sobre otra blockchain. Está quitando deliberadamente el contexto antes de que cualquier cosa llegue a Bitcoin, preservando la suposición de que Bitcoin solo debe juzgar lo que ya sabe cómo juzgar.
Una vez que miré el diseño a través de ese prisma, varias piezas encajaron de repente.
Ethereum sigue ejecutando la aplicación de préstamos porque es allí donde la aplicación pertenece. Aave todavía depende de una representación de vaultBTC restringida porque sus propios contratos necesitan garantías que puedan procesar. Ninguna de esas decisiones se devuelve a Bitcoin. Para cuando la información regresa al lado de Bitcoin, la aplicación ya ha desaparecido, dejando solo una afirmación criptográfica que Bitcoin puede verificar según las reglas predefinidas del vault.
Esa secuencia se siente más importante que el propio flujo de préstamo.
La arquitectura no está pidiendo a Bitcoin que confíe en Ethereum.
Tampoco está pidiendo a Bitcoin que entienda Ethereum.
Está pidiendo a Bitcoin que verifique una prueba mientras todo lo demás permanece en la cadena que la produjo.
Empecé a leer TBV esperando encontrar otro enfoque para llevar Bitcoin a DeFi.
En cambio, encontré un protocolo que toma no añadir nuevas responsabilidades a Bitcoin como punto de partida en vez del compromiso. Mirándolo hacia atrás, esa única elección de diseño explica casi todas las demás decisiones en la arquitectura: desde cómo se representa la garantía en Ethereum hasta cómo el BTC nativo sigue rigiéndose en Bitcoin.
@BabylonLabs_io $BANK $BABY #baby

Hoy me quedé mirando una pequeña parte del testnet de Babylon.
No el titular. No el monto prestado. Solo la parte en la que esperaba que mi BTC dejara de ser BTC nativa por un segundo.
Ese momento nunca apareció de verdad.
Sé que probablemente suena demasiado simple, pero fue lo primero que sentí diferente. Durante mucho tiempo, el DeFi de Bitcoin ha parecido que empieza con un paso de conversión. Envuélvelo. Conéctalo mediante un bridge. Entrégalo. Haz algo con ello primero y luego deja que funcione en otro lugar.
Esta vez, seguí esperando ese paso y no encontré una versión que se sintiera central.
Quizá estoy leyendo demasiado en el flujo de un testnet. Probablemente sí. Solo he estado volviendo a revisar la documentación y la experiencia del producto, así que estoy seguro de que hay piezas que aún no he conectado del todo.
Aun así, esa fue la parte en la que no pude dejar de pensar después de terminar.
No el préstamo en sí.
Sino el hecho de que el flujo de préstamo parecía preocuparse menos por mover Bitcoin y más por permitir que el BTC nativo permanezca nativo mientras su valor como colateral se vuelve utilizable en otra parte.
Ese es un cambio pequeño, pero modifica la forma en que se siente todo.
No creo que me haya llevado una gran conclusión. Más bien una más silenciosa.
Quizá la pregunta interesante no sea cómo entra Bitcoin a DeFi.
Quizá sea por qué asumimos que tenía que salir de Bitcoin en primer lugar.
¿Curioso si alguien más que probó TBV se quedó atascado en el mismo pensamiento?
@BabylonLabs_io $BABY #baby

Solía pensar que envolver Bitcoin era simplemente el precio de usarlo en DeFi. Cada producto que había probado seguía aproximadamente el mismo patrón. Movías tu BTC primero y solo entonces podías pedir prestado, comerciar o acceder a liquidez. Después de ver ese flujo tantas veces, dejé de preguntarme si realmente tenía que existir.
Esa suposición se mantuvo conmigo hasta que probé la testnet de los Trustless Bitcoin Vaults (TBV) de Babylon.
A mitad del flujo de préstamo, me encontré esperando el momento en que mi Bitcoin se convirtiera en otra cosa. Incluso reinicié el proceso porque asumí que me había saltado un paso. El segundo intento se veía exactamente igual. Fue entonces cuando me di cuenta de que el paso que faltaba en realidad no faltaba. Nunca se suponía que existiera otra versión de mi Bitcoin.
Ese momento cambió la forma en que miré el producto.
Lo interesante no es que TBV haga posible pedir prestado con Bitcoin nativo. Lo interesante es la pregunta con la que arranca. En lugar de preguntar cómo se puede mover Bitcoin hacia DeFi, pregunta cómo DeFi puede reconocer el valor de la garantía de Bitcoin nativo mientras el activo en sí nunca sale de la red de Bitcoin.
Al principio, eso suena como una diferencia arquitectónica pequeña. Cuanto más lo pensaba, más me parecía una forma completamente distinta de abordar el problema. Traslada el foco de transportar activos hacia demostrar la garantía. También te hace cuestionarte si envolver Bitcoin alguna vez fue el destino, o solo el compromiso que aceptó la industria porque no existía una alternativa mejor.
Terminé la testnet con una idea diferente a la que esperaba. Quizá el Bitcoin DeFi no necesita formas más eficientes de mover Bitcoin. Quizá lo que necesita son menos razones para mover Bitcoin en primer lugar.
$LAB @BabylonLabs_io $BABY #baby

Leí la página de “Earn on Equity” de @grvt_io dos veces esta mañana porque asumí que el capital que genera rendimientos del 3.5% APY no podía, además, seguir siendo utilizable como margen y contar para el TVL de la Temporada 2.
Incluso volví a la página de la Temporada 2 para comprobar si había confundido dos saldos diferentes.
No lo había hecho.
Completa cinco operaciones dentro de un ciclo de cuatro semanas, y el mismo Equity de la Cuenta de Trading puede desbloquear el rendimiento, respaldar posiciones abiertas y aparecer en los resúmenes de TVL utilizados para las recompensas de la Temporada 2.
El TVL recibe el 5% de los puntos semanales. El volumen de trading recibe el 50%, el interés abierto otro 15%, mientras que la Temporada 2 representa el 18% del suministro fijo de mil millones de tokens de GRVT.
Un solo saldo hace tres funciones.
Pero su TVL solo informa un número.
Esa fue la parte a la que seguí volviendo.
Cuando el capital permanece en Grvt, ¿está ahí para el rendimiento del 3.5%?
¿El trader mantiene el margen listo para otra posición?
¿O el saldo está esperando otro snapshot que pueda mejorar una futura asignación de tokens?
Seguí yendo y viniendo entre esas ideas. Ninguna de las tres explicaciones hizo que el saldo fuera menos real.
El mismo capital puede generar un rendimiento real y respaldar operaciones reales, mientras que las recompensas siguen influyendo en la decisión de dejarlo ahí.
Con otros 1.5 millones de $GRVT entrando en la misma ventana de lanzamiento mediante misiones de Binance Wallet, el 21 de julio se convierte en la prueba más clara.
Después del TGE, la utilidad del rendimiento y el margen permanece, mientras que la expectativa de la Temporada 2 empieza a importar menos.
Entonces descubrimos cuánto del saldo de Grvt estaba generando ganancias, y cuánto de ello estaba esperando.
#grvt $LAB

Estaba mirando un archivo de listas negras antiguo el otro día cuando apareció un pensamiento incómodo: la regla puede seguir exactamente igual, pero el mundo detrás de esa regla puede cambiar de un día para otro.
Un nombre que ayer no estaba en la lista puede estar hoy. La lógica de la política no se mueve, pero la realidad de la que lee ya se ha desplazado.
Eso es lo que hizo que un pequeño detalle en los Privacy Flows del Newton Protocol se destacara para mí:
última versión.
Al principio, el versionado parecía una gestión de datos normal. Un proveedor publica una lista de sanciones, una lista negra, una tabla de riesgos o un conjunto de datos de cumplimiento; cada vez que se llama a publishData, se crea una nueva versión, y los operadores resuelven los datos confidenciales más recientes cuando un cliente autorizado los necesita.
Eso suena razonable.
Los datos de cumplimiento no deberían quedar congelados en el tiempo. Si una lista negra cambia, la política debe ver la actualización, y si cambia una tabla de riesgos, el flujo de autorización debería reaccionar ante la nueva realidad en lugar de imponer la visión del mundo de ayer.
Pero cuanto más lo pensaba, más “última” me pareció menos una sensación de frescura y más un ejercicio de poder.
En @NewtonProtocol , los clientes autorizados no se fijan a una versión explícita única. Leen los datos más recientes, lo que significa que el mismo PolicyClient, la misma lógica Rego y el mismo usuario pueden producir una decisión distinta mañana porque el conjunto de datos confidencial subyacente a la política cambió hoy.
A un usuario se le puede negar no porque cambie su cartera, sino porque cambió el conjunto de datos que hay detrás de la política.
Esa es la frontera.
El proveedor no solo está suministrando datos. El proveedor se convierte en parte del límite de la aplicación de la norma porque su versión más reciente ayuda a definir lo que ve la política.
El acceso a la última versión mantiene la política cerca del mundo real, pero también le otorga al conjunto de datos más nuevo el poder de reconfigurar la aplicación antes de que los usuarios comprendan completamente qué cambió.
Quizá el dato más nuevo no sea automáticamente el más seguro.
Quizá simplemente sea el dato que actualmente se permite para definir la decisión.
$LAB $NEWT #Newt

Tenía los números de crecimiento de @grvt_io abiertos en una pestaña esta mañana y los mecanismos de la Temporada 2 en otra cuando, de repente, las mismas métricas se volvieron más difíciles de leer.
La Temporada 2 ahora representa el 18% de la oferta fija de mil millones de tokens de GRVT. El cincuenta por ciento de sus puntos proviene del volumen de trading, el 15% del open interest, mientras que TVL, liquidez, liquidaciones y actividad de referidos configuran el resto.
También son esos los números a los que la gente apunta cuando argumenta que Grvt ha construido una tracción real antes de su TGE del 21 de julio.
La actividad es real. Se completaron órdenes, se publicó el margen, las posiciones permanecieron abiertas y el capital entró en la plataforma.
Pero el incentivo detrás de esa actividad también es real.
Si una campaña recompensa el volumen, el aumento del volumen puede mostrar el uso genuino del producto y el comportamiento impulsado por tokens al mismo tiempo. Lo mismo ocurre con el open interest y el TVL.
Me quedé cambiando entre las dos pestañas porque ninguna de las conclusiones fáciles me pareció correcta.
Decir que el crecimiento es artificial ignora la liquidez real y la actividad de trading que creó la Temporada 2.
Decir que ya está probado como product-market fit ignora la asignación futura de tokens vinculada a esas mismas acciones.
La Temporada 2 puede demostrar que los incentivos mueven capital.
Aún no puede demostrar que el producto logra retenerlo.
Por eso el 21 de julio importa más allá del lanzamiento del token en sí. Una vez que los puntos se han convertido en tokens líquidos, la expectativa compartida detrás de meses de actividad empieza a debilitarse.
Algunos usuarios pueden quedarse porque la ejecución, el rendimiento o el acceso al mercado les resulta útil. Otros pueden darse cuenta de que la recompensa era el producto principal por el que vinieron.
Los incentivos pueden revelar comportamiento antes de que revelen lealtad.
Después del TGE, ¿cuántos usuarios seguirán eligiendo Grvt cuando su próximo trade ya no mejore una asignación de airdrop?
#grvt

La misma dirección no siempre significa la misma regla.
Ese fue el detalle en la documentación del smart contract de Newton que me hizo detenerme.
setPolicyAddress(newPolicy)
Al principio, parecía una función de actualización limpia. Un protocolo despliega un nuevo contrato de política, apunta el PolicyClient existente a él y conserva la misma dirección del cliente.
Sencillo.
Pero esa misma dirección importa.
En @NewtonProtocol , el PolicyClient no es solo un apuntador técnico. Es el objeto con el que interactúan los usuarios. Es donde pueden conectarse los enlaces de identidad, donde se acumula el consentimiento y donde una aplicación empieza a construir confianza.
Por eso Newton separa dos cosas que es fácil confundir.
El PolicyClient es el ancla de identidad.
La política es la lógica de reglas que hay detrás.
Eso es útil.
Sin esta separación, cada actualización de política podría obligar a los usuarios a volver a vincular identidad, reconstruir la confianza alrededor de una nueva dirección o migrar a una nueva ruta de aplicación simplemente porque la app mejoró sus reglas.
Pero la paradoja es clara.
La dirección no se movió.
La regla sí.
Un usuario pudo haber vinculado identidad bajo una regla de elegibilidad. Más tarde, la app actualiza la política detrás del mismo PolicyClient. La dirección aún se ve familiar. El enlace de identidad sigue funcionando. La integración permanece limpia.
Pero la interfaz puede parecer sin cambios mientras el límite de permisos ya no es el que el usuario confió al principio.
Eso no hace que el diseño esté mal.
Hace que la transparencia de las actualizaciones sea importante.
La continuidad es buena cuando evita interrupciones innecesarias. Pero se vuelve arriesgada si los usuarios no pueden ver cuándo la regla detrás de una dirección conocida ha cambiado.
Esa es la parte a la que sigo volviendo.
¿Un PolicyClient estable protege la confianza o hace que los cambios de reglas sean más fáciles de pasar por alto?
#Newt $LAB $NEWT

Abrí una antigua aplicación de finanzas y vi que mi KYC todavía estaba marcado como aprobado.
Esa palabra me molestó más de lo que esperaba.
Aprobado.
Aceptado.
Permitido a través de la puerta.
Pero cuanto más lo pensaba, más incompleto me parecía.
Aprobado hace que la identidad parezca un sello permanente.
Luego leí la Referencia de Política de Identidad del Protocolo Newton y me detuve en unas pocas funciones pequeñas:
check_approved()
not_expired()
valid_for(min_days)
issued_since(min_days)
Al principio pensé que check_approved() era la parte principal. Si un usuario ha superado el KYC, la política puede permitir que la acción continúe.
Pero dentro del diseño de @NewtonProtocol , la aprobación solo responde una pregunta estrecha:
¿se aceptó esta identidad en algún momento?
No responde la más importante:
¿esta identidad sigue siendo fiable en el momento de la ejecución?
Esa es la frontera real.
No el onboarding.
La ejecución.
Un usuario pudo haber sido aprobado antes, pero las credenciales aún pueden volverse demasiado antiguas, demasiado cerca de su vencimiento, o ya no ser lo bastante válidas para la acción que se está intentando ahora.
Si una política solo comprueba la aprobación, puede hacer que la ejecución dependa de unas credenciales de identidad que ya no tienen suficiente vigencia para el riesgo que se está creando.
Ahí es donde importa el horizonte de validez.
Newton no solo permite que la política pregunte si un usuario pasó el KYC. Permite que la política pregunte si la credencial está vencida, cuánto tiempo sigue siendo válida y cuándo fue emitida.
Eso cambia la forma en que pienso sobre la identidad.
El KYC no es una puerta de una sola vez.
Es una condición con una vida útil.
El compromiso es real. Haz la regla demasiado estricta y un usuario legítimo puede quedar bloqueado porque a su credencial le quedan muy pocos días. Hazla demasiado laxa y el sistema podría depender de datos de identidad que están casi fuera de valor.
La parte a la que sigo volviendo es simple:
la autorización onchain no debería preguntarse solo si la identidad fue aprobada.
Debería preguntar cuánto tiempo esa aprobación todavía puede confiarse.
#Newt $NEWT

La noche pasada, un detalle en la arquitectura de @grvt_io hizo que la palabra “híbrido” pareciera casi engañosa:

El motor de coincidencia puede decidir la operación.
No puede tomar esa decisión como definitiva por sí solo.
Al principio, lo traté como una simple elección de rendimiento. Los libros de órdenes se mueven demasiado rápido para esperar a que cada cotización, cancelación y coincidencia llegue a un consenso de blockchain. Mantener la coincidencia y la ejecución fuera de la cadena le da a Grvt la velocidad que necesita un centro de negociación.
Pero la división en realidad es sobre el poder.
El motor fuera de la cadena puede recibir órdenes, secuenciarlas y proponer qué operaciones deberían ocurrir. Luego, la liquidación convierte esa propuesta en saldos, cambios de colateral, obligaciones de margen y derechos de retiro.
Ese segundo paso es donde la ejecución se vuelve estado financiero.
Grvt coloca la custodia, la liquidación, la gestión de margen y las solicitudes de retiro en la cadena para que la capa rápida no pueda convertir silenciosamente su propio registro en propiedad final.
El costo es que los usuarios no pueden reconstruir todo el proceso de coincidencia solo a partir del estado onchain.
Aun así, dependen del operador para aceptar órdenes, mantener el motor disponible y aplicar reglas de ordenamiento de manera consistente. Una liquidación válida puede confirmar que la actualización de saldo resultante sigue las reglas codificadas sin probar que una orden anterior nunca se retrasó, omitió o secuenció de manera diferente.
Así que Grvt no hace que toda la ruta de trading sea sin confianza.
Traza un límite alrededor de la parte donde la discrecionalidad del operador se vuelve más difícil de revertir.
Una orden retrasada es un problema de ejecución.
Un saldo reescrito es un problema de custodia.
Estos riesgos no deberían compartir la misma autoridad.
Esa es la parte a la que seguí volviendo después de cerrar la documentación.
El valor más profundo de un exchange híbrido no es cuánto movimiento traslada fuera de la cadena, sino dónde se detiene la velocidad para no convertirse en control unilateral.
La pregunta pendiente es si los usuarios pueden verificar lo suficiente sobre el camino hacia la liquidación, no solo el estado que aparece después.
#grvt

El otro día, miré hacia atrás en los datos de llamada (calldata) de una transacción antigua y me di cuenta de que la parte riesgosa a veces puede estar en los primeros cuatro bytes.
Selector de función.
Esos primeros cuatro bytes le dicen al contrato qué función se está llamando.
Al principio, esto me pareció una conexión ordinaria de Solidity. Un contrato recibe calldata, lee el selector y enruta la llamada a la función correcta. Nada fuera de lo común.
Pero dentro del modelo de autorización de @NewtonProtocol , ese pequeño detalle empieza a importar.
Una dirección de contrato no representa una sola acción.
El mismo contrato puede exponer deposit(), withdraw(), transfer(), setOperator() o upgradePolicy(). Desde fuera, todos apuntan a la misma dirección. Pero desde la perspectiva del riesgo, son puertas completamente diferentes.
El contrato correcto no siempre significa la acción correcta.
Ahí es donde Function Selector Binding se convierte en algo más que el enrutamiento de calldata.
Es donde un permiso amplio a nivel de contrato se convierte en un permiso específico a nivel de acción.
Una política no debería aprobar una “llamada a contrato” en un sentido laxo. Debería saber en qué función está entrando la transacción. Una regla escrita para deposit() no debería convertirse accidentalmente en permiso para withdraw(). Una regla normal para transfer() no debería confundirse con permiso para actualizar un operador o cambiar la configuración.
Esa precisión importa.
Pero también crea un intercambio.
La autorización a nivel de acción pide a los desarrolladores que sean más explícitos. Una política vaga es más fácil de escribir y más fácil de reutilizar, pero también crea una superficie de permisos más amplia. Una política precisa requiere más cuidado, pero reduce lo que la aprobación realmente puede alcanzar.
Esa es la parte a la que sigo volviendo.
El usuario puede tener razón.
El contrato puede estar bien.
La política puede estar bien.
Pero si el límite del permiso es demasiado amplio, la aprobación aún puede abarcar más de lo previsto.
La autorización onchain no debería solo preguntar si un usuario puede interactuar con un contrato.
Debería preguntar qué puerta exacta dentro de ese contrato se le permite abrir.
$NEWT #Newt