Your local node already works. What it does not have is a trading interface. Point DexLadder at your own RPC URL and your fork gets a professional terminal — order ticket, pool view, ABI console — without a key ever entering the app.
Any JSON-RPC endpoint you run: Anvil, Hardhat, or a private fork of mainnet. You supply the URL; DexLadder reads chain state from it and sends transactions signed by the node's own unlocked development accounts. There is no key field in the product, no seed phrase prompt and nothing to import — which is precisely why it is safe to point it at a fork holding real forked balances.
As its own Fork panel, and as a venue on the order ticket. The second matters more than it sounds: it means the whole order stack — market, limit, OCO and TWAP — can route to your pool. You are not testing a swap button; you are testing your contract under the same execution machinery the rest of the terminal uses.
Protocol developers who want to see their AMM behave under realistic order flow before it meets real users. Auditors reproducing an execution path by hand. Anyone who has written a pool and wants to know what a 5% notional order does to it, without writing a test harness and a front end first.
Transactions are signed by your node, not by DexLadder. Nothing about your fork is transmitted anywhere — the app runs in your browser and talks to your machine. Loopback addresses are explicitly permitted in the app's content security policy for exactly this reason, and for the bring-your-own-bot signal endpoint, which works the same way.
No. There is no key input anywhere in the product. Transactions are signed by your own node using its unlocked development accounts.
Any JSON-RPC endpoint — Anvil and Hardhat are the usual choices, including forks of mainnet state.
Yes. Paste its ABI into the console and call any method on it.
Open the desk — free, no account — no account, nothing to install