Multichain Faucet Claim Flow

[fainashalts]

As an initial push to help developers receive funds for multiple testnets at once, we need to provide a claim flow that allows redistribution of funds through a multibridge approach.

[jvmi7]

As a starter, we have a few options here:

• Add a UI change that is a modal which describes to the user that they can claim to sepolia and then use superchain.tools/bridge in order to distribute the funds
• Potentially use multicall in order to write a subsequent transaction after bridging to allow the user to bridge the funds on multiple networks after claiming
• Add functionality to our backend in order to enable users to claim on multiple chains at once

cc @mayanksayshi lmk if this makes sense

[fainashalts]

@jvmi7 @mayanksayshi have you made a decision on the path forward here? I think multicall is what was discussed originally as a way to smooth this out for users, and so we can punt the backend changes to a broader redesign of the faucet. Curious what @tremarkley thinks as well. If this is already decided/underway please link to the PR so we can have a source of truth here for this task. Thank you!

[mayanksayshi]

Hey @fainashalts, I had a sync with @pharger @jvmi7 @tarunkhasnavis. Please see the meeting notes.

Key Points from Faucet Backend Sync:

1. Multicall Implementation:

   • The multicall approach is confirmed and optimized for gas costs.
   • This allows users to bridge ETH to multiple networks after claiming on Sepolia.
   • The current solution is a temporary fix leading up to DevCon, with plans to update the backend post-DevCon for more seamless multichain claims.

2. Gas Optimization:

   • The multicall setup is gas-optimized, though users will incur a small fee (~0.003 ETH per bridge transaction).
   • For DevCon, this setup should suffice for developers to get started.

3. User Experience:

   • The flow simplifies claiming ETH on Sepolia and bridging to multiple networks in a single transaction.
   • A single button will handle the multicall bridge, with atomic transactions to manage failures.

4. Backend Improvements Post-DevCon:

   • The current implementation is temporary, and a more robust backend solution for multichain deposits will be implemented after DevCon.

Link to work in progress figma file: https://www.figma.com/design/rBlLeciYg1jJBUDYmtjzr0/%F0%9F%9A%B0-Superchain-Faucet---Multichain-Support?node-id=4221-69614

[mayanksayshi]

@fainashalts @pharger @jvmi7 @tarunkhasnavis Here is the link to the latest Figma design

https://www.figma.com/design/rBlLeciYg1jJBUDYmtjzr0/%F0%9F%9A%B0-Multichain-Faucet---Devcon-Sprint?node-id=4237-101085&t=dmlX6VDSLTYko9nn-1

I’ve updated the faucet design to support claiming ETH on multiple networks, while the 24-hour wait period between claims remains. To meet the DevCon deadline, we’ve introduced a temporary two-step process: claim to Ethereum Sepolia first, then bridge to the desired network.

After DevCon, we’ll streamline this into a one-step process where users can claim directly to any network. I’ve kept the UI and logic changes minimal to ensure smooth implementation with the team.

If you can review it today and provide your feedback, I can apply the changes and have it ready for the developer handover by tomorrow. :)

[jvmi7]

@jvmi7

• The button copy should be "Claim 0.1 ETH on n networks"

Do you think saying 0.1 ETH on N networks is misleading? When i read that I think that I'll be getting 0.1 ETH on each network. Calculating the amount of ETH you will receive on each network based on the number of networks selected made more sense to me. @mayanksayshi

[mayanksayshi]

@jvmi7

• The button copy should be "Claim 0.1 ETH on n networks"

Do you think saying 0.1 ETH on N networks is misleading? When i read that I think that I'll be getting 0.1 ETH on each network. Calculating the amount of ETH you will receive on each network based on the number of networks selected made more sense to me. @mayanksayshi

@jvmi7 you are right lets stick with you solution :)

[fainashalts]

This initial issue is finished, with work continuing in #572.