> ## Documentation Index
> Fetch the complete documentation index at: https://docs.canopy.deal/llms.txt
> Use this file to discover all available pages before exploring further.

# Verify Canopy Contracts on the Robinhood Chain Explorer

Before you send any transaction or integrate a contract address into your application, independently verify that the address is correct and that its deployed bytecode matches the published source code. Canopy contracts are verified on the Robinhood Chain block explorer (Blockscout), meaning the explorer has compiled the published Solidity source and confirmed it produces the same bytecode that is deployed at the canonical address. This guide walks you through the verification steps for both the core OTCVenue contract and the per-series ClaimToken contracts, and shows you how to wire the verified ABI into your ethers.js integration.

## Verifying the Core OTCVenue Contract

Use the following steps to confirm the canonical OTCVenue contract address resolves to a verified deployment on the Robinhood Chain block explorer and that its source matches what the project publishes.

<Steps>
  <Step title="Obtain the official contract address">
    Get the canonical OTCVenue contract address from the official Canopy documentation or announcement channels only. Never copy an address from a social media post, a Discord message from an unverified account, or a third-party site — these are common phishing vectors.
  </Step>

  <Step title="Search for the address on the block explorer">
    Navigate to the [Robinhood Chain block explorer](https://robinhoodchain.blockscout.com) and paste the address into the search bar. Confirm the explorer resolves it as a contract account, not an externally owned account (EOA).
  </Step>

  <Step title="Confirm source code verification on the Contract tab">
    Click the **Contract** tab on the address page. A verified contract displays a green checkmark next to the source code heading. If the tab shows only bytecode with no source, the contract is unverified — do not interact with it.
  </Step>

  <Step title="Check the contract name and compiler version">
    In the verified source section, confirm that the contract name reads `OTCVenue` and that the Solidity compiler version is `0.8.24` with optimizer enabled. A mismatch may indicate a redeployed or modified contract.
  </Step>

  <Step title="Download or copy the ABI">
    Scroll to the **ABI** section of the Contract tab and copy the JSON ABI. Save it as `OTCVenueABI.json` in your project. This ABI is generated directly from the verified source, so it is guaranteed to match the deployed contract interface.
  </Step>

  <Step title="Cross-reference against the Canopy GitHub repository">
    Open the Canopy GitHub repository and locate the published ABI artifact for the same release version. Diff it against the ABI you copied from the explorer. The two should be identical. Any discrepancy warrants further investigation before you proceed.
  </Step>
</Steps>

<Warning>
  Always verify contract addresses independently through official channels. Phishing sites frequently deploy lookalike contracts at different addresses with identical-looking interfaces. The only safe source of truth for the canonical OTCVenue address is the official Canopy documentation.
</Warning>

## Verifying ClaimToken Contracts

Each Canopy forward series deploys its own ERC-20 ClaimToken contract at a unique address. Verify these the same way you verify the core contract.

To find a series' ClaimToken address, either:

* Read the `SeriesCreated` event log emitted when the series was first filled — the `claimToken` address is included in the event parameters.
* Call `series(seriesId)` on the OTCVenue contract (where `seriesId = keccak256(abi.encode(asset, unlockTime))`) and read the `claimToken` field from the returned struct.
* Use the venue's `seriesIdFor(asset, unlockTime)` helper function to compute the series ID.

Once you have the address, search for it on the block explorer and confirm the source is verified under the Contract tab. ClaimToken contracts should show the contract name `ClaimToken` and an ERC-20-compatible interface.

<Note>
  ClaimToken contracts implement the standard ERC-20 interface. You do not need a Canopy-specific ABI to call `balanceOf`, `transfer`, or `approve` on them — any generic ERC-20 ABI works for those operations.
</Note>

## Using the Verified ABI in Your Integration

Once you have saved the verified ABI locally, instantiate the OTCVenue contract in ethers.js by importing it directly. Using the ABI from a verified local file — rather than hard-coding a partial interface — ensures you always have access to the full contract interface and reduces the risk of signature mismatches.

```typescript theme={null}
import VENUE_ABI from "./OTCVenueABI.json";
const venue = new ethers.Contract(VENUE_ADDRESS, VENUE_ABI, signer);
```

<Tip>
  Bookmark the verified explorer page for the OTCVenue contract and check it at the start of each development session. If the page ever shows the contract as unverified or the source has changed unexpectedly, pause your integration and verify the address through official channels before continuing.
</Tip>