[Request for Comment] - Proposal to deploy HOP on Scroll zkEVM


Dear Hop Community, I’m Robert from the Partnerships team at Scroll and we’re reaching out to propose the deployment of the Hop Bridge on Scroll.

Scroll is live on Pre-Alpha Testnet and will launch on Goerli this month, and mainnet in Q3. The aim here is to have Hop be one of our early stage launch partners on Goerli as we view Hop as a highly crucial product for users to bridge their assets across various chains.


We propose for HopProtocol to deploy on Scroll for Goerli launch, and eventually support bridging between Scroll and other chains across the Ethereum ecosystem for Mainnet in Q3 this year.

On our side, we aim to support Hop’s expansion across the hundreds of dApps within our ecosystem as we believe direct dApp<>Bridge integrations will allow for improvements in on-chain user experience.

About Scroll

Scroll is an L2 Scaling Solution that is pushing the development of an Ethereum equivalent zkEVM. Our main priorities are to implement a bytecode-level compatible zkEVM with sound zk proofs, work on related initiatives to coordinate the development of layer 1 and zkEVM, and reach a community standard to improve Ethereum for the end game. Security is of highest priority for us and our current EVM implementation is well specified and robust. Our in-house security team also operates in close conjunction with the highest caliber auditors in the industry.

Scroll is built on a completely open source basis. This includes the ZK circuits, the proving system, and the verifier smart contract. Code security is also closely monitored by community developers from projects such as Zcash, 0xPARC, Ethereum Foundation, and Filecoin.

Today, Scroll is currently live on Pre-Alpha Testnet and contracts can be deployed permissionlessly by anyone and anywhere. We maintain a trustless Layer 1 <> Layer 2 bridge which supports arbitrary message delivery. The bridge is part of the rollup mechanism, verified by the smart contract and the zkEVM, which is more secure than classical relayer-based bridges.

Helpful Links

Twitter: https://twitter.com/Scroll_ZKP
Forum: https://community.scroll.io/


@cwhinfrey how do Goerli rollouts usually work for these?

Scroll seems to have a great team and compelling approach to scaling therefore I believe Hop integrating with Scroll aligns well with Hop’s overall mission of scaling Ethereum’s ecosystem and connecting Ethereum to the broader multi-chain world.

My only question to Scroll and Authereum Labs is what resources are needed to deploy on Scroll for Goerli launch?

cc @francom

So far we’ve put resources towards supporting a testnet if a vote like this has passed or in some cases we may go ahead and deploy on testnet if we think it’s in the DAO’s best interest and the DAO is likely to vote for a Mainnet deployment in the future. These types of votes are helpful signaling IMHO even though we don’t think testnet deployments necessarily need to be gated by governance. It helps us avoid putting work into supporting a network when the DAO might not want to support it on Mainnet. We’re always open to adjust our thinking here if anyone has feedback though.

Supporting a new network is a fairly manageable amount of work depending on how standard the network is. The work is typically scoped to hooking the Hop contracts up to the native message bridge, configuring the frontend/bonder/explorer software to support the new network, and general coordination with the team behind the new network. Anything atypical about the network can make this process significantly more work (not the case with Scroll) and we’ll make sure to raise the concern with the DAO if that’s the case.

Integrating testnets early on can be useful because we’re often able to provide feedback around the native message bridge design of new rollups which is an important component, especially for Hop. We’ve watched Arbitrum, Optimism, and Polygon iterate on their native message bridge designs and have gained a lot of experience working with native message bridges and the various edge cases that might come up.


Appreciate the response Chris! Scroll is also more than happy to work with Hop on our native bridge design (we can share docs/code on our prelim design with the team). If anyone has any questions or concerns regarding the proposal, please reach out to us or comment!

1 Like

Hello! Proposal has been moved to Snapshot:

[HIP-23] - Proposal to deploy HOP on Scroll zkEVM

1 Like

Voting yes. Based on @cwhinfrey’s additional context, this seems like another low-hanging fruit addition.

1 Like

Voted yes.

Read the discussion above, it seems like a no-brainer to deploy. Especially to do so while Scroll is still in their test-net phase to allow for a sufficient testing & feedback period.

1 Like

Voted yes. Scroll is a leading zk rollup with a strong team. There is little doubt deploying Hop on it will be beneficial to both Scroll and Hop users.

Voted yes. I really don’t think there is any downsides here. Scroll is at the forefront of ZKEvms research and would be a great addition to have them in HOP.

I have also voted Yes. Strongly in favour of HOP integrating with new chains, when appropriate and safe. It’s beneficial to be amongst the first.

Retrospectively noting I voted For this proposal. Makes complete sense to support zk rollups.