fix(Zora): Correct deployment #580
Conversation
The Zora SpokePool was affected by the same issue as the Redstone deployment. Additionally, correct the mainnet contract addresses for the Zora Adapter deployment. Zora listed both implementation and proxy addresses on their contracts page. These new addresses have been manually tested for message delivery, ETH and USDC token bridging. I additionally took the opportunity here to fix the Blockscout verification. Blockscout were automagically doing a partial verification based on similarly to the Redstone SpokePool, and were thus tagging this deployment as a Redstone_SpokePool instance. This was quite confusing and misleading. It's possible to force verification via hardhat-verify from version 2.0.7. Unfortunately this repo is stuck down at 1.x, so the workaround was just to skip over the "is already verified" check that hardhat-verify performs prior to attempting verification. Signed-off-by: Paul <108695806+pxrl@users.noreply.github.com>
| @@ -43,8 +43,8 @@ export const L1_ADDRESS_MAP: { [key: number]: { [contractName: string]: string } | |||
| blastDaiRetriever: "0x98Dd57048d7d5337e92D9102743528ea4Fea64aB", | |||
| redstoneCrossDomainMessenger: "0x592C1299e0F8331D81A28C0FC7352Da24eDB444a", | |||
| redstoneStandardBridge: "0xc473ca7E02af24c129c2eEf51F2aDf0411c1Df69", | |||
| zoraCrossDomainMessenger: "0x363B4B1ADa52E50353f746999bd9E94395190d2C", | |||
| zoraStandardBridge: "0xbF6acaF315477b15D638bf4d91eA48FA79b58335", | |||
| zoraCrossDomainMessenger: "0xdC40a14d9abd6F410226f1E6de71aE03441ca506", | |||
There was a problem hiding this comment.
This is concerning to see. Are we sure these addresses are correct now?
There was a problem hiding this comment.
The addresses are correct and have been tested from the dev wallet. A manual test of these addresses is basically mandatory and is part of the workflow, but that has been happening as part of the relayer changes. In this case it meant we need to circle back to contracts, so I think it's sensible to promote that test so it happens earlier in the process.
Here are the initial transactions on mainnet - each was verified to have a corresponding receipt on Zora.
USDC deposit: https://etherscan.io/tx/0x3acee5955629011f0174e37857ff7fb9bd1937e5c68a59fdca6959d7e802dbe6
ETH deposit: https://etherscan.io/tx/0x184b75b1b2f6ee4dbf9f62164acf8960a72a20eadee3882de22a8ebcead6a253
relayMessage via Zora Adapter:
https://etherscan.io/tx/0xa58c2adecbb9e461ea5a1e374e505d1481006767c10fa20c36bbd9fa6c87b193
fwiw, the original addresses were sourced from the Zora contracts page, but their naming is unintuitive vs. other chains we've added support for. The red addresses were originally sourced (matching the descriptions from all other OVM chains we've supported), but the green addresses are the correct ones. When sourcing these addresses I'd only looked for the full names L1StandardBridge and L1CrossDomainMessenger and hadn't spotted that there were others with the Proxy__OVM_ prefix.
Signed-off-by: Paul <108695806+pxrl@users.noreply.github.com>
The Zora SpokePool was affected by the same issue as the Redstone deployment. Additionally, correct the mainnet contract addresses for the Zora Adapter deployment. Zora listed both implementation and proxy addresses on their contracts page. These new addresses have been manually tested for message delivery, ETH and USDC token bridging.
I additionally took the opportunity here to fix the Blockscout verification. Blockscout were automagically doing a partial verification based on similarly to the Redstone SpokePool, and were thus tagging this deployment as a Redstone_SpokePool instance. This was quite confusing and misleading. It's possible to force verification via hardhat-verify from version 2.0.7. Unfortunately this repo is stuck down at 1.x, so the workaround was just to skip over the "is already verified" check that hardhat-verify performs prior to attempting verification.