El token de gas de DuskEVM es DUSK con 18 decimales; no lo trates como USDC de 6 decimales
día del despliegue del contrato en testnet: escribí según mi memoria muscular de DeFi pasando parámetros transfer(addr, 1000000) para transferir 1 DUSK. Resultado: el nodo respondió “insufficient balance”. Mi wallet tenía 15 DUSK de prueba. Me dio un golpe de realidad en Blockscout: DUSK en la mainnet y en DuskEVM también usa 18 decimales (como ETH), no 6 decimales como USDC, ni los 8 decimales de algunos BEP-20. 1 DUSK = 1000000000000000000 unidades mínimas.
Este tipo de trampa es muy fácil de pisar al escribir código para distintos entornos: en Solidity, hacer uint amount = 1 * 10**18 está bien, pero en el front-end JS usar ethers.parseUnits("1", 6) lo deja mal; el script de Node que consulta el precio de DUSK en la REST de Binance (la cotización está en 1 DUSK = x U) está bien, pero al construir la transacción de DuskEVM si usas 1e6 pensando que es 1 DUSK para pagar el gas, la transacción se va a cero y encima pagas la base fee.
Lo más enredado es que la estimación de la fee de DuskEVM se divide en dos partes: la fee de ejecución L2 se calcula con DUSK (18 decimales) y la fee L1(DA) también se paga en DUSK (18 decimales) al productor de DuskDS. En Remix, la primera vez que desplegué: después de poner el gas limit, rellené mal el campo value con 2000000 (como si fueran 2 DUSK). En realidad era 0.000002 DUSK, menor que la base fee, y la rechazaron. Cambié a 2000000000000000000 (2e18) y entonces pasó.
Las variables secretas que marca Hedger también es lo mismo: tu @hedged uint256 shares representa 1000 participaciones de bono. Debes almacenar 1000 * 10**18. La view key se decodifica y el front-end lo muestra con formatUnits(18) como 1000; no lo mires como formatUnits(6), pensando que es 0.001.
¿Y ustedes, al pasar desde ERC-20, la primera operación también la mordió la cantidad de decimales?
@Dusk $DUSK #dusk
día del despliegue del contrato en testnet: escribí según mi memoria muscular de DeFi pasando parámetros transfer(addr, 1000000) para transferir 1 DUSK. Resultado: el nodo respondió “insufficient balance”. Mi wallet tenía 15 DUSK de prueba. Me dio un golpe de realidad en Blockscout: DUSK en la mainnet y en DuskEVM también usa 18 decimales (como ETH), no 6 decimales como USDC, ni los 8 decimales de algunos BEP-20. 1 DUSK = 1000000000000000000 unidades mínimas.
Este tipo de trampa es muy fácil de pisar al escribir código para distintos entornos: en Solidity, hacer uint amount = 1 * 10**18 está bien, pero en el front-end JS usar ethers.parseUnits("1", 6) lo deja mal; el script de Node que consulta el precio de DUSK en la REST de Binance (la cotización está en 1 DUSK = x U) está bien, pero al construir la transacción de DuskEVM si usas 1e6 pensando que es 1 DUSK para pagar el gas, la transacción se va a cero y encima pagas la base fee.
Lo más enredado es que la estimación de la fee de DuskEVM se divide en dos partes: la fee de ejecución L2 se calcula con DUSK (18 decimales) y la fee L1(DA) también se paga en DUSK (18 decimales) al productor de DuskDS. En Remix, la primera vez que desplegué: después de poner el gas limit, rellené mal el campo value con 2000000 (como si fueran 2 DUSK). En realidad era 0.000002 DUSK, menor que la base fee, y la rechazaron. Cambié a 2000000000000000000 (2e18) y entonces pasó.
Las variables secretas que marca Hedger también es lo mismo: tu @hedged uint256 shares representa 1000 participaciones de bono. Debes almacenar 1000 * 10**18. La view key se decodifica y el front-end lo muestra con formatUnits(18) como 1000; no lo mires como formatUnits(6), pensando que es 0.001.
¿Y ustedes, al pasar desde ERC-20, la primera operación también la mordió la cantidad de decimales?
@Dusk $DUSK #dusk