harmony-one / contract-verification-service

Verify & Publish Contract Source Code

contract-verification-service

Verify & Publish Contract Source Code

Install instructions

Requirements

• nodejs

Commands

• Fetch repo

https://github.com/harmony-one/contract-verification-service

• Install dependencies

npm install

• Develop

npm run build
npm run start:watch

• Build

npm run build

• Start prod

npm run start:prod

Cache Configuration

Contract verification service uses the node-cache in-memory cache to manage contract verification and reduce traffic to the servers.
Note: this is not optimised for load-balanced / distributed services as each service will contain its own verification cache which is cleared if a contract state goes from un-verified to verified. Consider using redis for a distributed caching to support multi-node contract verification.

The following are the parameters that can be configured:

1. CACHE_STD_TTL - the max duration that a cached item exists in memory before it is purged (default 86400 seconds - 1 day)
2. CACHE_CHECK_PERIOD - the period for which the cache-checker will periodically check for expired cache items (default 600 seconds - 10 minutes). Increase this to keep cache-misses in memory longer
3. CACHE_MAX_KEYS - the max number of keys that are kept in memory before cache additions begin to be reject (default -1, unlimited keys). Set this value to reduce memory usage
4. CACHE_MISSED_TTL - the duration of time that a missed cache item (e.g. database returns null) is cached (default 300 seconds).

Cache - miss (where the contract source code retrieval returns null) are cached in-memory for 5 minutes. When a contract verification is performed and is successfuly, the cache is updated with the verified contract details. This allows the system to cache null values on repeated queries (most contracts are not verified) while still clearing these cache values in the case where the contract verification has occurred.

Note: Cache are flushed on reset, there is no persistence.

contract-verification-service's Issues

Add support for DEVNET

Add contract verification support for devnet through hardhat-verify

Issue verifying contract - version 0.5.x

0.5.x handles metadata differently (looking for 0x265/0032) as indicators for the metadata information.

Note: we should consider using sourcify for contract verification which can handle the unique metadata settings.

This is related to a request from Harmony Launcher and UniswapV2Factory contract verification failures.

Verification API (similar to Etherscan et. al)

It's not currently possible to verify contracts deployed on Harmony in a quick and easy way, such as at deploy/upgrade time via Hardhat or other dev frameworks. With the Harmony Explorer's added restriction of accepting only a single -- possible flattened -- Solidity file, verification can be/is essentially impossible for contracts with large dependency bases and inheritance trees which don't play nice with flattening.

Having a publicly exposed API endpoint a la Etherscan et. al which accepts sets of files (for example) would enable quick and standardized contract verification for developers, which might greatly increase the number of verified contracts on the Harmony ONE blockchain on the whole.

This issue isn't to call out the team in charge of the API, far from it; rather, it's to have this issue open and on the books at all so that it can be looked at, whether now or in the future.

Verification for large files

Verification for large files

Right now we send solidity sources via http request. It has limits. So users have problems with large contract sources.

Solution: We should to add file loader and load file to service. Like on etherscan.

Issue with verifying open-zeppelin contracts with same filenames

When verifying contracts with same filenames in different sub-directories the verification will fail. This is caused by the use of the filename (and not file structure) when verifying the contracts; if the same file appears in nested directories this verification will throw exceptions.

Contract Address

I am trying to store this token ( Harmony one ) in my metamask wallet but unfortunately i can't find the contract address for the token. Which wallet do you suggest for me to store the token or where can i find the contract address.

Add support for truffle-verify

Hardhat-verify currently supported by harmony,'s contract verification service; this ticket is for support of truffle-verify

Issue on verifying factory contract

I try to verify - https://github.com/adenafinance/uniswap factory code.

I had the contract deployed on the mainnet but to make sure that I didn't make any changes, I deployed on the testnet too.

1. mainnet - https://explorer.harmony.one/address/0x44485473431faf6efa11d346d1057182d2a0a290

2. testnet -https://explorer.testnet.harmony.one/address/0x010628ec9f9870cc901076d23edcfe0bcb6807b8

As you can see bytecodes are the same, which means I should get it verified after flattening the code.

The factory is a fork of sushiswap - https://explorer.harmony.one/address/0xc35dadb65012ec5796536bd9864ed8773abc74c4?activeTab=7 this is sushi's factory address which is also not verified.

I'm positive that the verification service is not working properly.

verification failing for previous 2 weeks

I was using the hardhat-etherscan tool to do verification, and it was working until recent 2 weeks. I wonder is this related to RPC nodes issue or the recent gas increase?

Could you look into if the service is affected by this?

Verification returning success but devnet explorer not updating

This is using @nomiclabs/hardhat-etherscan.

Running this

npx hardhat verify --network harmonyDev <deployed contract address> "Constructor Argument 1" "Constructor Argument 2"

returns this:
`
Successfully submitted source code for contract
contracts/OwnerNFTs.sol:OwnerNFTs at 0x12db62b3579d23298b914bd921c0f6d5a5d7618d
for verification on the block explorer. Waiting for verification result...

Successfully verified contract OwnerNFTs on Etherscan.
https://explorer.ps.hmny.io/address/0x12db62b3579d23298b914bd921c0f6d5a5d7618d#code
`

but the explorer does not update with the contract code

Verify Bridge Contracts Failing

Trying to verify this source code results in issues with bytecode length:
https://github.com/synapsecns/synapse-contracts/blob/master/contracts/bridge/SynapseERC20.sol
https://github.com/synapsecns/synapse-contracts/blob/master/contracts/bridge/SynapseERC20Factory.sol

Explorer link (notice bytecode):
https://explorer.harmony.one/address/0x1852F70512298d56e9c8FDd905e02581E04ddb2a?activeTab=7

This is a copy of the SynapseERC20 contract on https://moonriver.moonscan.io/address/0xe96ac70907fff3efee79f502c985a7a21bce407d#contracts

Contract Name: SynapseERC20
Optimizations: YES (10,000 runs)
Compiler Version: 0.6.12

Note: this is a minimal EIP 1167 delegate contract that proxies to a different contract (in MoonRiver, it is proxy to https://moonriver.moonscan.io/address/0x84a420459cd31c3c34583f67e0f0fb191067d32f#code)

TLDNameWrapper.sol verification issues

We are trying to verify TLDNameWrapper.sol using VerifyContract Page on shard 0
We get the error "Compiled bytecode do not match with bytecode from blockchain

Which appears to be coming from the contract-verification-service

Input parameters are as follows

• Contract Address: 0x69e756d56762fc66ade2ea8da4ced4f888d0cf8a

• ContractName: TLDNameWrapper

• Language: Solidity

• ChainType: mainnet

• Compiler: 0.8.17

• Optimizer: Yes 200

• Solidity Contract code flat-TLDNameWrapper.sol.txt this was generated using npx hardhat flatten contracts/ENSDeployer.sol

• Constructor Arguments (ABI-encoded) (generated using https://abi.hashex.org/)
  Inputs

  • 0xA1494298A8704538eeF2cBA3EEb13eF750F50a09
  • 0x91cA002f8217b939a4f24EeCB992e07dCDecA32c
  • 0x538EEBa281DF86f509025bCA2DD81F22fC49a19c
  • country

  Value

  000000000000000000000000a1494298a8704538eef2cba3eeb13ef750f50a0900000000000000000000000091ca002f8217b939a4f24eecb992e07dcdeca32c000000000000000000000000538eeba281df86f509025bca2dd81f22fc49a19c00000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000007636f756e74727900000000000000000000000000000000000000000000000000
  

  Screenshot