Actually, the entire @Dusk stack involves two related but different ledgers: one is DuskEVM’s execution ledger, which is presented externally as Ethereum JSON-RPC; the other is Dusk L1’s settlement ledger, which is presented externally as GraphQL / RUES. DUSK must be read as the same number in both ledgers, but their clocks, units, and decimal places are not the same.
DuskEVM is an OP Stack–style EVM execution layer. It returns blocks, logs, and receipts in standard EVM shapes; its final settlement and data availability are then anchored to DuskDS through batchers, state commitments, and bridging. In other words, this is not an “adapter that translates GraphQL in real time into JSON-RPC,” but rather a setup where final consistency between the two layers is maintained through bridging and state commitments. The real thing to pay attention to is cross-layer scenarios: inclusion on DuskEVM is fast, but full settlement and bridge confirmation require a few more steps—during that time, the states visible on both sides may temporarily differ.
The role of $DUSK makes this risk more concrete. On the L1 native side, LUX is used; 1 DUSK equals 10 to the 9th power LUX. For compatibility with the Ethereum tooling ecosystem, DuskEVM exposes DUSK with 18 decimal places. If bridging performs conversion or precision handling incorrectly, the same value in a single transaction might briefly not match across the two ledgers. For ordinary transfers this may only show as a display discrepancy, but for regulated settlement, it could become a “misoperation window where one side shows到账 while the other has not yet been finally confirmed.”
My conclusion after reading it all is: when evaluating #dusk , you can’t just look at that it’s “compatible with EVM”—you also need to examine the consistency guarantees between the L1 settlement ledger and the EVM execution ledger. The current materials do not sufficiently explain the authority-data-source priority, conflict detection, and repair mechanisms. And DUSK is precisely the number that must not be read incorrectly across these two ledgers. DYOR.
DuskEVM is an OP Stack–style EVM execution layer. It returns blocks, logs, and receipts in standard EVM shapes; its final settlement and data availability are then anchored to DuskDS through batchers, state commitments, and bridging. In other words, this is not an “adapter that translates GraphQL in real time into JSON-RPC,” but rather a setup where final consistency between the two layers is maintained through bridging and state commitments. The real thing to pay attention to is cross-layer scenarios: inclusion on DuskEVM is fast, but full settlement and bridge confirmation require a few more steps—during that time, the states visible on both sides may temporarily differ.
The role of $DUSK makes this risk more concrete. On the L1 native side, LUX is used; 1 DUSK equals 10 to the 9th power LUX. For compatibility with the Ethereum tooling ecosystem, DuskEVM exposes DUSK with 18 decimal places. If bridging performs conversion or precision handling incorrectly, the same value in a single transaction might briefly not match across the two ledgers. For ordinary transfers this may only show as a display discrepancy, but for regulated settlement, it could become a “misoperation window where one side shows到账 while the other has not yet been finally confirmed.”
My conclusion after reading it all is: when evaluating #dusk , you can’t just look at that it’s “compatible with EVM”—you also need to examine the consistency guarantees between the L1 settlement ledger and the EVM execution ledger. The current materials do not sufficiently explain the authority-data-source priority, conflict detection, and repair mechanisms. And DUSK is precisely the number that must not be read incorrectly across these two ledgers. DYOR.
