How to use DApp Doctor

The ten steps

1. 01

   Open Diagnose

   Go to Diagnose to check the RPC configuration your dApp actually uses. The engine runs six read-only checks.

   Open Diagnose

2. 02

   Enter the RPC URL

   This is the endpoint your app calls. It must be http or https. The example below is illustrative, not a recommendation.

   https://mainnet.base.org

   Example only. Use the URL from your own .env or wagmi config.

3. 03

   Enter the expected chain ID

   The chain ID is the network your application believes it is on. DApp Doctor compares that number to the network the RPC actually answers.

   • Base Mainnet: 8453
   • Ethereum Mainnet: 1
   • Arbitrum One: 42161

   Those numbers are examples. Use the chain your dApp is built for.

4. 04

   Add a contract (optional)

   If the app reads a contract, paste its address. Without one, bytecode and the critical read stay NOT TESTED — that is risk, not proof that they work.

5. 05

   Add a critical read (optional)

   A zero-argument view the app depends on. DApp Doctor encodes it, calls it with eth_call, and decodes the answer. If the function is missing or the ABI is wrong, the check fails.

   symbol() returns (string)

   Example of the expected shape: name() returns (type).

6. 06

   Add a fallback RPC (optional)

   A backup endpoint. If it points at another network, the day the primary goes down the app will silently read the wrong chain. Without a fallback the diagnosis cannot be READY.

7. 07

   Run the diagnosis

   Press Diagnose. The button shows that the checks are running. There is no live per-check progress from the server — the wait is one real request.

   Running diagnostic checks…

8. 08

   Read the result

   The stamp is the verdict. READY means all six checks passed. AT RISK means nothing critical failed, but there are warnings or untested checks. BLOCKED means a critical check failed — the headline names it.

9. 09

   Fix the problem

   Each failing check has a summary (what was observed) and an action (what to do). Observed data is under the row if you need the raw evidence.

10. 10

    Compare before and after

    A single report proves the failure. Compare runs the broken configuration and the fixed one at the same moment and shows which checks were FIXED or REGRESSED.

    Open Compare

What the verdicts mean

What a check outcome means

• PASS

  The check completed successfully.

• WARN

  The check completed, but the configuration may need attention.

• FAIL

  The check found a problem that should be fixed.

• NOT TESTED

  The check could not run. That is not evidence that it works.