Relayer Smart Contract to Facilitate ETH Bridging to Canto

[tstereth]

Hey all! I’m Thomas, technical writer at MKT and contributor to Canto.

Although it doesn’t strictly involve protocol development on the Canto side, I wanted to share an idea I had to expedite the ETH bridging flow to Canto: a relayer smart contract that wraps ETH and sends it to the Gravity Bridge smart contract.

This would remove the need to 1) wrap ETH and 2) approve WETH on mainnet, streamlining the bridging flow and optimizing for wallet security best practices.

With B-Harvest and Plex already working on protocol and UI-level tweaks to simplify the onboarding/bridging experience, this could be the cherry on top.

The Problem

Bridging ETH to Canto is currently a convoluted process. On the Ethereum side, users must first wrap their ETH, approve it for transfer by the Gravity Bridge smart contract, and finally call sendToCosmos on that smart contract. Not to mention generating a Canto public key.

On the Canto side, users then need to convert their assets for use on the Canto EVM, and get CANTO to use as gas for their first transactions.

While B-Harvest’s work will simplify the flow on the Canto side, bridging ETH will still require multiple steps on the Ethereum side: first wrap, then approve, then send.

Proposed Solution

Although not a dev, I’ve been contemplating whether it would be possible to deploy a relayer smart contract on Ethereum which would abstract away the wrapping and approval of ETH/WETH.

The proposed relayer contract would have a single payable function which can be prompted by bridging frontends. The function params would be identical to those of the sendToCosmos method on the Gravity Bridge smart contract.

When bridging, users would call the relayer contract’s single method with the same calldata as they would use when calling sendToCosmos, with msg.value equal to the amount of ETH being bridged.

Internally, the smart contract would:

1. Wrap the ETH on the WETH contract
2. Call sendToCosmos with the user-provided calldata (thereby specifying the correct Canto native/bridge destination address)

In the constructor, the smart contract would set an infinite WETH approval to the Gravity Bridge. Since the relaying interaction is atomic, funds should not be held in the smart contract and ideally using the relayer is risk-free.

The end result is that it would be possible to bridge ETH to Canto in one single wallet interaction (not accounting for Canto public key generation), as opposed to three. Also, there would no longer be the need to approve WETH, which is potentially beneficial for wallet security.

Request for Feedback

I’d be keen to get feedback on this idea from Canto contributors and users, as well as experienced smart contract engineers. Specifically, would this be helpful, and can it be built with zero-to-minimal smart contract risk?

[t_k]

I think this idea could work, and the smart contract code should be quite minimal and easy to audit.

Alternatively, Plex is currently developing a version of the bridge front end that allows users to select ETH, and then prompts users to wrap it (just like users are prompted to give erc20 allowances). It’s not atomic, but should be safer since no extra smart contract code is required.

Here’s a screenshot of that (ignore the spacing for now)

[tstereth]

Thanks TK. I think the seamless wrapping feature you are working on at Plex will improve the bridging UX considerably.

I still think this relayer contract would be valuable for reasons mentioned previously (fewer clicks, no need for approvals). Time will show if it can be built/audited effectively.

If there are any smart contract devs on this forum willing to prototype/audit this, please let me know!

[Mujiati]

Saya sangat suka sekali guys

[Kuritsu]

I think this idea seems interesting, and and create a quick prototype. I need to look at the gravity bridge in more depth, but it seems feasible and rather simple.