Lo que me llama la atención del contrato de transferencia de Dusk no es la transferencia en sí, sino que la misma infraestructura que cobra por el trabajo que provoca una transacción es la que fija sus precios. Las tarifas no son un peaje fijo añadido a la ejecución; son gas_used por gas_price, pagadas en DUSK y valoradas en LUX. Incluso una transacción revertida todavía paga el gas que consumió: el costo refleja el trabajo intentado, no el completado.

Creo que esa es la decisión correcta: tratar la computación como si fuera gratis invita a la congestión. Incluso Dusk filtra las transacciones con fondos insuficientes mediante un límite mínimo de gas antes de que toquen recursos del nodo, en lugar de dejarlas fallar a mitad de la ejecución.

Aquí está la tensión, tal como la veo: cuanto más expresiva se vuelve una transacción, más difícil es predecir su costo; y la previsibilidad es lo que hace que un modelo de tarifas sea entendible para un usuario no técnico.

Lo que sigo notando es que Dusk ya permite que los contratos absorban el gas en nombre de un usuario. Eso no resuelve la tensión; solo la desplaza, de la billetera a la aplicación.
$DUSK @Dusk #dusk
$BMT
$STAR