Saw a KOL post last week claiming DuskEVM is EVM-equivalent and Uniswap V3 deploys directly. I forked V3 Core and compiled it on Boreas RC1 to check.
First error hit in Pair.sol.
balanceOf reads _reserves from public EVM storage. DuskEVM's privacy layer routes liquidity depth through Hedger. Hedger variables do not live in EVM storage. So every view function that reads reserves hits a dead end. Uniswap's mint, burn, and swap all depend on synchronously reading reserves to compute the constant product. That entire arithmetic path has to be overloaded from scratch.
The shielding pool problem runs deeper. Uniswap LP tokens are standard ERC-20 with publicly visible transfers. Confidential LP on DuskEVM requires rewrapping with ConfidentialERC20. LP balances move inside Zedger notes. Swaps no longer update the reserves mapping. They consume the old note and mint a new one with amounts backed by PLONK proofs.
getAmountOut cannot work the same way. The original divides reserveIn and reserveOut openly. The Dusk version has to prove inside the circuit that old note minus input equals new note plus output. Input and output stay invisible to market makers but remain verifiable to anyone holding the view key.
On day eight I tried inheriting Pair from the ConfidentialERC20 base class. Permit function signature conflict immediately. Hedger approve uses note consumption, not the ERC20 allowance bitmap. SafeCast has to switch to HedgedUint256 throughout.
Minimum rewrites required: Pair contract, Router amount calculation, and Oracle TWAP sampling. The sampling target becomes a note commitment that cannot be directly read.
What carries over: Solidity syntax, Foundry, Remix, chainId config. The surrounding tooling works. Core AMM logic does not migrate without significant rework.
EVM-equivalent means the environment is familiar. It does not mean existing contracts run unchanged when privacy is involved.
#dusk $DUSK @Dusk
First error hit in Pair.sol.
balanceOf reads _reserves from public EVM storage. DuskEVM's privacy layer routes liquidity depth through Hedger. Hedger variables do not live in EVM storage. So every view function that reads reserves hits a dead end. Uniswap's mint, burn, and swap all depend on synchronously reading reserves to compute the constant product. That entire arithmetic path has to be overloaded from scratch.
The shielding pool problem runs deeper. Uniswap LP tokens are standard ERC-20 with publicly visible transfers. Confidential LP on DuskEVM requires rewrapping with ConfidentialERC20. LP balances move inside Zedger notes. Swaps no longer update the reserves mapping. They consume the old note and mint a new one with amounts backed by PLONK proofs.
getAmountOut cannot work the same way. The original divides reserveIn and reserveOut openly. The Dusk version has to prove inside the circuit that old note minus input equals new note plus output. Input and output stay invisible to market makers but remain verifiable to anyone holding the view key.
On day eight I tried inheriting Pair from the ConfidentialERC20 base class. Permit function signature conflict immediately. Hedger approve uses note consumption, not the ERC20 allowance bitmap. SafeCast has to switch to HedgedUint256 throughout.
Minimum rewrites required: Pair contract, Router amount calculation, and Oracle TWAP sampling. The sampling target becomes a note commitment that cannot be directly read.
What carries over: Solidity syntax, Foundry, Remix, chainId config. The surrounding tooling works. Core AMM logic does not migrate without significant rework.
EVM-equivalent means the environment is familiar. It does not mean existing contracts run unchanged when privacy is involved.
#dusk $DUSK @Dusk
