# Token contract verification on Etherscan

This document explains how to perform verification of the wrapped asset
contracts deployed by the Portal token bridge on Etherscan and similar explorer
services. The purpose of contract verification is to provide the source code of
the contract so that users have better transparency into the programs they
interact with (whether this makes a difference in practice is beyond the scope
of this document).

Verification requires uploading the source code and supplying the compiler
version and arguments that the deployed bytecode was compiled with. Etherscan
will then recompile the source code on their servers and match the result
against the deployed bytecode.

We will use the flattened source file, as it's easier to upload. Flattened just
means that the whole contract, including its dependencies, are inlined into a
single source file.
Wormhole's flattened source files can be downloaded from [Github
Actions](https://github.com/wormhole-foundation/wormhole/actions/workflows/evm-flattened-contracts.yml).
This page includes a version of the contracts for each ethereum contract
deployment. The deployed token contract tends not to change very often (if at
all), so it should be safe to just pick the latest run and download the
artifacts from there (download `flattened-contracts` at the bottom of the page
after selecting the run).

The file needed for token verification is `token/Token.sol`.

For our running example, we'll use the wrapped WETH contract deployed on
Moonbeam:
https://moonscan.io/address/0xab3f0245b83feb11d15aaffefd7ad465a59817ed

First, we verify that this contract is a proxy. This step can be done by
visiting the https://moonbeam.moonscan.io/proxycontractchecker page, and pasting
in the contract address. For ethereum, the site to use would be
https://etherscan.io/proxycontractchecker, and other chain explorers have
similar pages too.

This will present a popup with the following text:

> The proxy contract verification completed with the message:
> The proxy's (0xab3f0245b83feb11d15aaffefd7ad465a59817ed) implementation contract is found at: 0xb1731c586ca89a23809861c6103f0b96b3f57d92

Click save.

Next, we'll verify the actual source code. Head over to
https://moonscan.io/verifyContract and paste in contract address, in our case
`0xab3f0245b83feb11d15aaffefd7ad465a59817ed`. Fill in the rest of the form with
the following values, then continue.

| Field            | Value                     |
| ---------------- | ------------------------- |
| Compiler type    | Solidity (Single file)    |
| Compiler version | v0.8.4+commit.c7e474f2    |
| License type     | Apache-2                  |

On the next page, select "optimizations: yes", and paste the contents of
`token/Token.sol` from before into the source file textarea.

In the misc settings, enter 200 for optimization runs, and leave the rest as
default.

## ABI-encoded constructor arguments

The last missing piece is the ABI-encoded constructor arguments field.  These
are the arguments that the contract was instantiated with, and it will be
different for each wrapped contract.
There are two ways to proceed. The first method is easier, but does not
work on all explorers (it does on moonscan), the second method is more involved,
but will always work. Try the first, and if it didn't work, then try the second.

## Constructor arguments, method #1

Leave the constructor arguments field empty, and just proceed to verification.
This step will fail, because the deployed bytecode will actually include the
constructor arguments, and the result of compiling the source file doesn't.
At this point, some explorers will just return a generic error message saying
the bytecodes didn't match, without any additional information. If this is the
case, go to method #2.

If the page shows what the *expected* bytecode was, and lists out the *actual*
bytecodes it found in the source file, then we may proceed here. The *expected*
bytecode will be the same as the `BridgeToken` bytecode with the constructor
arguments appended to the end. This means that the `BridgeToken` bytecode is a
proper prefix of the expected bytecode. Just copy the rest of the bytes of the
expected bytecode (for example in your favorite text editor), i.e. the suffix
that comes after the `BridgeToken` prefix. Go back to the previous page, and use
these bytes as the constructor arguments. This time, verification should succeed.

## Constructor arguments, method #2

If the explorer page does not show the expected and actual bytecodes, then we
need to compute the arguments ourselves. For this, we will need the `forge` tool
(install from https://getfoundry.sh/), and a local checkout of the wormhole repository

```sh
$ git clone https://github.com/wormhole-foundation/wormhole.git
```

First, install the dependencies by running the `make dependencies` in the
`ethereum` folder:

```sh
wormhole/ethereum $ make dependencies
```

Next, we will run a `forge` script to compute the constructor arguments. For
this, we will need two pieces of data. First, the address of the Portal token
bridge contract on the chain we're performing verification on. This can be found
in
https://github.com/wormhole-foundation/wormhole/blob/main/sdk/js/src/utils/consts.ts
under the MAINNET section (or TESTNET if you're verifying a testnet contract).
For our example, the mainnet moonbeam token bridge contract is
`0xb1731c586ca89a23809861c6103f0b96b3f57d92`.

Next, we'll need the VAA (the signed wormhole message) that was sent to the
token bridge contract to create the wrapped asset. This can be found by finding
the transaction that created this contract. On the contract's page
https://moonscan.io/address/0xab3f0245b83feb11d15aaffefd7ad465a59817ed, the
"Content creator" field has a link to the "at txn ...". In our case, this is
https://moonscan.io/tx/0x9f6db0a0749558e8ef5bf24c1be148498fb3c451d040198b7362c2ce32469e67

Expand the details, which shows a call to `createWrapped` in the "Input data"
section. Click "Decode input data" which will show the hex value of the
`encodedVM` argument. In our case it's

```
 
```

We copy this field and go back to our terminal. Run the following

```
wormhole/ethereum $ forge script scripts/TokenABI.s.sol -s "token_constructor_args(bytes, address)" <VAA-BYTES> <CONTRACT-ADDRESS>
```

where in place of `<VAA-BYTES>`, substitute the hex sequence we just copied from
the explorer, and in place of `<CONTRACT-ADDRESS>`, the token bridge's address
from before (`0xb1731c586ca89a23809861c6103f0b96b3f57d92` for moonbeam).

Running that command prints the following:

```
 
```

Copy the hex *excluding* the 0x at the front, and paste that into the
constructor arguments field, then hit verify. The contract should now be verified.
