En la tabla de parámetros de la última red de pruebas pública vi tres valores iguales de 0,4 BTC. Al comparar, descubrí que los objetos a los que limitan no son los mismos. Un solo bóveda: máximo 0,4 BTC; dentro de una posición de préstamo, la suma de todas las bóvedas también es como máximo 0,4 BTC; y en Aave, el límite máximo de exposición para una misma dirección sigue siendo 0,4 BTC. Los números son iguales, pero las tres reglas no pueden sustituirse entre sí.
Un nivel más arriba, CapPolicy le configura a la aplicación de Aave un límite total de 10 BTC y lo comprueba cuando se activa la bóveda. Dividir 10 entre 0,4, en teoría, permite alojar hasta 25 direcciones “usando su cupo personal”. Ese 25 es solo una conversión de capacidad, no una estimación del número de usuarios. Puede haber quien solo coloque 0,1 BTC y haya más direcciones, pero el total de activaciones acumuladas no puede superar 10 BTC.
Lo fácil de leer mal es entender “no he superado mi cupo” como “esta vez seguro puede activarse”. Supongamos que la aplicación ya tiene 9,8 BTC y un usuario nuevo quiere activar 0,4 BTC: el cupo personal es correcto, pero el total de la aplicación sube a 10,2 BTC y no pasa la comprobación de capacidad. Al contrario, incluso si la aplicación tiene espacio, si una dirección ya tiene 0,3 BTC, no puede añadir otros 0,2 BTC. Hay que cumplir a la vez el umbral personal y el umbral global. Por eso, la forma en que el front-end indica que la capacidad es insuficiente es en sí parte del control de riesgos; de lo contrario, los usuarios pueden interpretar con facilidad que las reglas bloqueadas son un problema de billetera o de red.
@BabylonLabs_io actualmente ha listado esto como configuraciones de Bitcoin Signet y de la red de pruebas de Ethereum, y no se puede extrapolar como parámetros permanentes de la red principal. Creo que su punto clave no es “cuánto puede bloquear”, sino controlar por separado la exposición de un usuario individual y el riesgo total de la aplicación. Los usuarios comunes deberían observar a continuación si el front-end muestra simultáneamente el saldo/cupo restante personal, la capacidad restante de la aplicación y, además, la ruta de reembolso cuando la activación no se completa. $BABY Para ampliar la infraestructura correspondiente, primero hay que evitar que los usuarios malinterpreten que “la cuenta tiene cupo” significa “la aplicación aún tiene capacidad”.
#baby
Un nivel más arriba, CapPolicy le configura a la aplicación de Aave un límite total de 10 BTC y lo comprueba cuando se activa la bóveda. Dividir 10 entre 0,4, en teoría, permite alojar hasta 25 direcciones “usando su cupo personal”. Ese 25 es solo una conversión de capacidad, no una estimación del número de usuarios. Puede haber quien solo coloque 0,1 BTC y haya más direcciones, pero el total de activaciones acumuladas no puede superar 10 BTC.
Lo fácil de leer mal es entender “no he superado mi cupo” como “esta vez seguro puede activarse”. Supongamos que la aplicación ya tiene 9,8 BTC y un usuario nuevo quiere activar 0,4 BTC: el cupo personal es correcto, pero el total de la aplicación sube a 10,2 BTC y no pasa la comprobación de capacidad. Al contrario, incluso si la aplicación tiene espacio, si una dirección ya tiene 0,3 BTC, no puede añadir otros 0,2 BTC. Hay que cumplir a la vez el umbral personal y el umbral global. Por eso, la forma en que el front-end indica que la capacidad es insuficiente es en sí parte del control de riesgos; de lo contrario, los usuarios pueden interpretar con facilidad que las reglas bloqueadas son un problema de billetera o de red.
@BabylonLabs_io actualmente ha listado esto como configuraciones de Bitcoin Signet y de la red de pruebas de Ethereum, y no se puede extrapolar como parámetros permanentes de la red principal. Creo que su punto clave no es “cuánto puede bloquear”, sino controlar por separado la exposición de un usuario individual y el riesgo total de la aplicación. Los usuarios comunes deberían observar a continuación si el front-end muestra simultáneamente el saldo/cupo restante personal, la capacidad restante de la aplicación y, además, la ruta de reembolso cuando la activación no se completa. $BABY Para ampliar la infraestructura correspondiente, primero hay que evitar que los usuarios malinterpreten que “la cuenta tiene cupo” significa “la aplicación aún tiene capacidad”.
#baby