> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/developer-guides/verify-contracts.md).

# Verify Contracts

Verify Solidity contract source on Rome via the hosted Sourcify service — standard forge verify-contract and hardhat-verify flows, badges on the Via explorer.

Rome runs a hosted [Sourcify](https://sourcify.dev) verification service. Once you verify a contract, its source and ABI become publicly reproducible and show up with a **✓ Source verified** badge on the Rome block explorer (Via).

Verification works with the standard `forge verify-contract` and `hardhat-verify` flows — you just point them at Rome's verifier.

## Verifier endpoint

| Environment       | Verifier URL                              |
| ----------------- | ----------------------------------------- |
| Testnet & Devnet  | `https://verify.testnet.romeprotocol.xyz` |
| Mainnet (Rubicon) | `https://verify.mainnet.romeprotocol.xyz` |

One shared instance serves every Rome testnet/devnet chain — you select the chain with the standard `--chain-id` flag.

## Foundry

After deploying (see [Deploy Solidity Contracts](/developer-guides/deploy-solidity.md)):

```bash
forge verify-contract <CONTRACT_ADDRESS> src/MyContract.sol:MyContract \
  --verifier sourcify \
  --verifier-url https://verify.testnet.romeprotocol.xyz/ \
  --chain-id <YOUR_CHAIN_ID> \
  --compiler-version 0.8.20
```

If the constructor took arguments, pass them so the bytecode matches:

```bash
  --constructor-args $(cast abi-encode "constructor(uint256)" 42)
```

You can also verify at deploy time with `forge create … --verify` or `forge script … --verify` (Foundry infers the chain id from `--rpc-url`).

## Hardhat

`hardhat-verify` ships with the Hardhat 3 toolbox. Point its Sourcify provider at Rome's verifier in `hardhat.config.ts` and run `hardhat verify`:

```typescript
export default defineConfig({
  // …plugins, solidity, networks…
  verify: {
    etherscan: { enabled: false },
    blockscout: { enabled: false },
    sourcify: {
      enabled: true,
      apiUrl: "https://verify.testnet.romeprotocol.xyz",   // Rubicon mainnet: "https://verify.mainnet.romeprotocol.xyz"
    },
  },
});
```

```bash
npx hardhat verify --network <your-network> <CONTRACT_ADDRESS> [constructor args…]
```

On success the verifier links the published source, e.g. `https://verify.testnet.romeprotocol.xyz/repo-ui/<CHAIN_ID>/<ADDRESS>`.

## Checking verification status

The explorer reads verification status from the verifier's API. You can query it directly:

```bash
curl https://verify.testnet.romeprotocol.xyz/v2/contract/<CHAIN_ID>/<ADDRESS>
```

A verified contract returns a `match` field:

* **`exact_match`** — bytecode *and* metadata hash match (a perfect, "full" match).
* **`match`** — bytecode matches; metadata differs slightly (still a genuine, verified match).
* `404` / `null` — not verified.

## Notes

* Verification needs only your contract's deployed bytecode + the source and compiler settings you submit — the same inputs as on any EVM chain.
* New Rome chains are onboarded to the verifier automatically; if you deploy to a fresh chain and verification can't find it yet, give it a short while or reach out.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rome.builders/developer-guides/verify-contracts.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.