Frontend Contract Address Config Validator

WHAT IT DOES

This tool validates your frontend's contract address configuration file — the list of contract names and addresses that your dapp uses to interact with the blockchain. It reads the on-chain bytecode for each address to confirm that a contract exists on the selected network. It also performs EIP-1967 proxy detection by reading the implementation storage slot, flagging proxy contracts and displaying their implementation address. Optionally, if you provide an ABI for a contract, the tool attempts to call a simple view/pure function on that contract to verify that the ABI correctly matches the deployed bytecode. The output is a clear table showing the status of each entry, with color-coded badges for existence, proxy status, and ABI test results.

HOW TO USE

Connect your wallet via the BGWallet bridge — this provides the RPC endpoint for on-chain reads. Select the network that matches your frontend's target chain. In the config input area, paste your contract entries — one per line, in the format: contractName,address or contractName,address,abi (ABI is optional). For example: USDC,0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 or MyProxy,0x123...,[{"inputs":[],"name":"implementation","outputs":[{"internalType":"address","name":"","type":"address"}],"stateMutability":"view","type":"function"}]. Click "Validate config". The tool processes each entry, fetches the bytecode, checks for proxy patterns, and optionally tests the provided ABI. Results are displayed in a summary table with individual status indicators.

ONE TECHNICAL SECTION

The validator uses eth_getCode to confirm that a contract exists at each address. For proxy detection, it reads the EIP-1967 implementation storage slot (0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc) using eth_getStorageAt — if the slot contains a non-zero address, the contract is flagged as a proxy and the implementation address is shown. When an ABI is provided, the tool filters for view/pure functions that take no parameters, then attempts to call the first such function using ethers.js. A successful call suggests that the ABI is compatible with the deployed bytecode; a failure indicates a mismatch or that the function is not available. This provides a lightweight smoke test for ABI correctness without requiring full type verification. All checks are performed sequentially with appropriate error handling, and the results are displayed in a sortable table format.

WHAT IT CANNOT SEE

This tool cannot verify that the contract address is the intended deployment for the given network beyond basic existence and bytecode checks — it does not know what you expected to be deployed at that address. It cannot detect if the contract is paused, deprecated, or malicious — it only confirms that a contract exists. It cannot validate that the ABI matches the bytecode beyond a superficial signature check (calling one view function); it does not verify all functions or events. It cannot detect runtime code changes via proxies without manual resolution of the implementation address — if your frontend uses a proxy, you must ensure the ABI corresponds to the implementation, not the proxy. It also cannot detect beacon proxies, diamond proxies, or custom proxy patterns that do not follow the EIP-1967 standard. The tool relies entirely on you to provide the correct network and address mappings — garbage in, garbage out.

PLEASE NOTE

This tool works exclusively on EVM-compatible chains. The config input must be plain text with one entry per line. The ABI, if provided, must be a valid JSON array. The tool is read-only and does not sign or send any transactions. It is designed for frontend developers and DevOps workflows to catch configuration errors before deployment. Always cross-check critical addresses against official sources such as the project's documentation, Etherscan, or the contract's deployment transaction.