#dusk $DUSK ¡Me estoy volviendo loco! La cotización cae a la fuerza; la wallet tiene claramente 100.000 DUSK, pero el bot de stop-loss dice: ¡esta parte del dinero por ahora no se puede usar!
En Phoenix, los saldos de privacidad están compuestos por Notas. Después de que se emite una transacción, la wallet retiene las Notas usadas y registra el Nullifier correspondiente. Puedes pensarlo así: este dinero ya se usó para pagar; hasta que no quede claro el asunto, no puedes usarlo de nuevo para pagar una segunda vez.
Pero lo más problemático está en esas dos palabras: “fallida”. Es decir, que un nodo agote el tiempo de espera, no se pueda consultar la transacción temporalmente, o se reciba un resultado de fallo de una vez que aún no esté confirmada de forma final, no puede probar que la transacción original haya quedado completamente anulada. En ese momento, coloco inmediatamente la Nota de vuelta; el robot podría volver a pedir usando el mismo lote de dinero. Luego, la primera operación se confirma más tarde, y el resultado es que dos transacciones compiten por la misma parte de los fondos.
La lógica de Phoenix que ya tiene integrada Dusk Wallet opta por mantener bloqueado primero. En pruebas locales oficiales, enviando dos transacciones en paralelo con el mismo Profile: una tuvo éxito y la otra fue bloqueada de manera segura; cuando el resultado no estaba claro, los Nullifier pendientes continuaron retenidos. Los planes posteriores que están bajo revisión, además, separarán “recibir el resultado de ejecución” y “la decisión final de la transacción”.
Para ser honesto, al principio me pareció bastante molesto: si la transacción ya muestra fallida, ¿por qué sigue ocupando mi dinero?
Pero si vuelvo a trazar la cadena de posiciones, en realidad me atrevo menos a pedirle que la suelte de inmediato. Si lo libera demasiado rápido, el sistema podría asignar el mismo dinero a dos órdenes; si lo retiene demasiado tiempo, la privacidad se llevará una comisión de ocupación de fondos que ni siquiera se ve.
Así que, por fin, entiendo el balance. El saldo total de Phoenix no se puede computar íntegramente como posición disponible:
Liquidez de privacidad efectiva = saldo total de privacidad × tasa de gasto
Tasa de gasto = monto de Notas actualmente disponibles ÷ saldo total de privacidad
La wallet caliente del exchange, los robots de arbitraje y los reajustes de gran volumen deberían configurar sus límites de posición con ese número, y luego observar cuánto tiempo en promedio se ocupan las Notas y cuándo se libera, en el peor caso, el 5% más lento.
Creo que este es el tipo de contabilidad macro que $DUSK merece estudiar más. El crecimiento del saldo de privacidad solo indica que el dinero entra; la tasa de gasto y la velocidad de rotación determinan cuántas transacciones reales y Gas pueden generar esos fondos.
La ruta de fondos con protección de privacidad; la tasa de gasto determina si el dinero puede seguir generando ganancias. En la dimensión de la demanda a largo plazo de $DUSK , me gusta más esta última.
@Dusk
$BTC
En Phoenix, los saldos de privacidad están compuestos por Notas. Después de que se emite una transacción, la wallet retiene las Notas usadas y registra el Nullifier correspondiente. Puedes pensarlo así: este dinero ya se usó para pagar; hasta que no quede claro el asunto, no puedes usarlo de nuevo para pagar una segunda vez.
Pero lo más problemático está en esas dos palabras: “fallida”. Es decir, que un nodo agote el tiempo de espera, no se pueda consultar la transacción temporalmente, o se reciba un resultado de fallo de una vez que aún no esté confirmada de forma final, no puede probar que la transacción original haya quedado completamente anulada. En ese momento, coloco inmediatamente la Nota de vuelta; el robot podría volver a pedir usando el mismo lote de dinero. Luego, la primera operación se confirma más tarde, y el resultado es que dos transacciones compiten por la misma parte de los fondos.
La lógica de Phoenix que ya tiene integrada Dusk Wallet opta por mantener bloqueado primero. En pruebas locales oficiales, enviando dos transacciones en paralelo con el mismo Profile: una tuvo éxito y la otra fue bloqueada de manera segura; cuando el resultado no estaba claro, los Nullifier pendientes continuaron retenidos. Los planes posteriores que están bajo revisión, además, separarán “recibir el resultado de ejecución” y “la decisión final de la transacción”.
Para ser honesto, al principio me pareció bastante molesto: si la transacción ya muestra fallida, ¿por qué sigue ocupando mi dinero?
Pero si vuelvo a trazar la cadena de posiciones, en realidad me atrevo menos a pedirle que la suelte de inmediato. Si lo libera demasiado rápido, el sistema podría asignar el mismo dinero a dos órdenes; si lo retiene demasiado tiempo, la privacidad se llevará una comisión de ocupación de fondos que ni siquiera se ve.
Así que, por fin, entiendo el balance. El saldo total de Phoenix no se puede computar íntegramente como posición disponible:
Liquidez de privacidad efectiva = saldo total de privacidad × tasa de gasto
Tasa de gasto = monto de Notas actualmente disponibles ÷ saldo total de privacidad
La wallet caliente del exchange, los robots de arbitraje y los reajustes de gran volumen deberían configurar sus límites de posición con ese número, y luego observar cuánto tiempo en promedio se ocupan las Notas y cuándo se libera, en el peor caso, el 5% más lento.
Creo que este es el tipo de contabilidad macro que $DUSK merece estudiar más. El crecimiento del saldo de privacidad solo indica que el dinero entra; la tasa de gasto y la velocidad de rotación determinan cuántas transacciones reales y Gas pueden generar esos fondos.
La ruta de fondos con protección de privacidad; la tasa de gasto determina si el dinero puede seguir generando ganancias. En la dimensión de la demanda a largo plazo de $DUSK , me gusta más esta última.
@Dusk
$BTC