# Verify Your Deployed Contracts

Deploying a smart contract to mainnet is a point of no return — any misconfiguration or overlooked mistake can lead to loss of funds or trust. A robust verification process after deployment ensures that the contract matches the audited code and behaves as expected. Below is a structured guide to verifying a smart contract deployment securely and thoroughly.

***

## Why Deployment Verification?

1. **Ensure Audit Relevance**: Confirm that the deployed contract matches the version that was audited.
2. **Prevent Silent Modifications**: Detect unauthorized or accidental changes between audit and deployment.
3. **Some Misconfigurations Are Invisible in Audit**: There are misconfiguration issues that can't be caught in an audit — they must be verified in the context of a live deployment.

***

## Steps for Deployment Verification

1. **Verify Source Code and Compiler Settings**
   * **Match Bytecode**: Ensure the deployed bytecode corresponds exactly to the audited source code.
   * **Match Compiler Version & Settings**: Confirm that the Solidity compiler version and optimization flags are identical to those used during the audit.
   * **Upload to Etherscan**: Upload the Solidity source code that matches the deployed bytecode to Etherscan for public verification. Use Etherscan’s contract verification UI or tools like `sourcify.dev` to verify the contract on-chain. Ensure the provided source code, constructor arguments, and compiler settings generate the exact bytecode deployed.
2. **Verify Final Code Version**
   * **Post-Fix Deployment**: Confirm that the deployed version contains *all* fixes and patches introduced during and after security reviews.
   * **How**: Cross-check the Git commit, release tag, or hash used for deployment against the version approved in the final audit report.
3. **Check Constructor Arguments**
   * **What to Look For**: Ensure initialization parameters (e.g., admin addresses, external token addresses, fee rates) are correctly set.
   * **How**: Decode the deployment transaction input or read constructor arguments from block explorers and compare them with audited config files.
4. **Confirm Contract Ownership and Roles**
   * **Ownership, Admin Rights & Role Setup**: Make sure privileged roles are held by the correct addresses or multisigs *and* that role permissions (`AccessControl`, `owner()`, etc.) are correctly configured and verifiable on-chain.
5. **Validate Upgradeability Setup**
   * **If Using Proxies**: Check that the proxy points to the intended implementation and that the upgrade admin is properly configured.
   * **How**: Inspect storage slots manually or use tools like `openzeppelin-upgrades` to verify the proxy pattern.
6. **Confirm Deployment Scripts Were Followed**
   * **Replay and Audit the Script**: Ensure the deployment was executed via the approved and audited scripts.
   * **Best Practice**: Automate deployment with reproducible scripts (e.g., Foundry, Hardhat) and record the transaction hashes.
7. **Match Deployed Addresses**
   * **For Multisigs, Tokens, Registries**: Confirm that all deployed contract addresses match those expected in documentation, frontends, and audit reports.
   * **Cross-check**: Ensure integrations and monitoring systems use the correct addresses.
8. **Enable Public Verification**
   * **Verified Source Code**: Publish the verified source code to public block explorers.
   * **Public README / Audit Link**: Make the audit report and deployment configuration publicly accessible to build user confidence.
9. **Tag the Commit Hash as a Release on GitHub**
   * **Why**: This provides a public, immutable reference to the exact code version that was deployed.
10. **Export Contract Addresses to Your GitHub Repo**
    * **Why**: Keeping deployed addresses in your repository (e.g., as a JSON or markdown file) improves transparency and simplifies integration for users and partners.
    * **Best Practice**: Include network name, contract name, address, and optionally, verification links.


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.optimumsec.xyz/deployment/post-deployment-verification.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.