I cant add liquidity to my token pairs on the xrplEVM Sidchain Test Net.

[krm22]

🐛 XRPL EVM Sidechain Testnet Bug Report: UniswapV2Router02 addLiquidity Always Reverts

Summary

The standard UniswapV2 DEX contracts deploy and function correctly on the XRPL EVM sidechain testnet, but all addLiquidity transactions via the Router revert on-chain without a revert reason or event logs. This occurs even with compliant OpenZeppelin ERC20 tokens and a correct, fully wired setup. Manual ERC20 transfers and transferFrom work as expected. The same deployment and scripts work perfectly on local Hardhat EVM.

---

Steps to Reproduce

1. Deploy contracts on XRPL EVM:

   • Standard ERC20 tokens using OpenZeppelin contracts (18 decimals)
   • WETH9 contract
   • UniswapV2Factory and UniswapV2Router02 (wired to the above WETH9 and Factory)
   • Create pair (via Factory) for two tokens (e.g., TKA and TKB)

2. Mint and approve tokens:

   • Fund test account with ERC20 tokens
   • Approve Router to spend both tokens

3. Confirm setup:

   • Manual transfer and transferFrom of tokens work as expected on XRPL EVM
   • Pair contract is initialized with correct token0/token1 ordering, reserves are zero as expected

4. Attempt to add liquidity:

   • Call router.addLiquidity(tka, tkb, amountA, amountB, minA, minB, to, deadline) with valid params (works perfectly on local Hardhat EVM)

5. Observe failure:

   • Transaction reverts with status: 0, no logs, and no revert reason
   • The same code and deployment on Hardhat local works fine

---

Contract Addresses (XRPL EVM)

Contract	Address
Router	0xb20Cfd9D789e3f0DE3e259E4daD339115cAEF07a
Factory	0x4545573741470506cA0D0666fede8E7d25D4f570
WETH9	0x2e0C52DbC73D9319c0451775504E7f5F10C9EA04
TokenA (TKA)	0xc1E9773809bF89fFdfF3388fD5338220c123Ad84
TokenB (TKB)	0x33d7b306088fAeB3ad984CEa3B5c023ffA26cf89
Pair (TKA/TKB)	0x1E348a4a3eE8679BC7fa2287Eeff761b20d8Bf20
Test Account	0x03e774f5aA8119ac12eD563B37b91eb02b702102

---

Error Output Example

Error: transaction failed [CALL_EXCEPTION] (transactionHash="0x...", ...receipt={"status":0,...,"logs":[]})

• No revert reason in error
• No logs/events emitted from Router or Pair

---

What Works

• All contracts and addresses are correctly wired (factory and WETH9 verified on Router)
• ERC20 manual transfer and transferFrom work
• Pair contract shows reserves as expected (zero/zero before liquidity)
• Exact same flow works perfectly on local Hardhat EVM

---

Suspected Causes

• XRPL EVM sidechain may not fully support all EVM features (e.g., delegatecall, storage, or Uniswap’s assembly patterns)
• Possible opcode, storage, or event emission bug in the EVM engine for DEX contracts

---

Minimal Repro Script (JS/Hardhat)

const { ethers } = require("hardhat");
async function main() {
const router = await ethers.getContractAt("UniswapV2Router02", "0xb20Cfd9D789e3f0DE3e259E4daD339115cAEF07a");
const tka = await ethers.getContractAt("IERC20", "0xc1E9773809bF89fFdfF3388fD5338220c123Ad84");
const tkb = await ethers.getContractAt("IERC20", "0x33d7b306088faeb3ad984cea3b5c023ffa26cf89");
const [signer] = await ethers.getSigners();
await tka.approve(router.address, ethers.utils.parseUnits("1", 18));
await tkb.approve(router.address, ethers.utils.parseUnits("1", 18));
const tx = await router.addLiquidity(
tka.address, tkb.address,
ethers.utils.parseUnits("1", 18), ethers.utils.parseUnits("1", 18),
0, 0,
signer.address,
Math.floor(Date.now() / 1000) + 600
);
await tx.wait();
}
main().catch(console.error);

Network and Environment Info
XRPL EVM RPC/Network: https://rpc.testnet.xrplevm.org, chainId: 1449000

Hardhat Version: "^2.26.1"

Ethers.js Version: 5.8.0

Date tested: 05/08/2025

Request
Can the XRPL EVM team investigate why standard UniswapV2Router addLiquidity always reverts, even with standard OpenZeppelin tokens and correct setup, when all other interactions work and the same code works on local EVM?

If a fix or workaround is available, please advise.

If not, is this a known issue or upcoming fix in the XRPL EVM roadmap?

Thank you for your time. I am happy to provide contract ABIs, bytecode, more scripts, or do further testing if requested.