Polar Path: A Pallet and process which allows parachain teams to make their native token accessible on the Ethereum network using Snowbridge

Ecosystem
,
1

TLDR;

Project Polar Path: A Pallet and process which allows parachain teams to make their native token accessible on the Ethereum network using Snowbridge.

The KILT Protocol team will develop the required runtime components, such as pallets, to facilitate this process. Additionally, a user-friendly interface will be provided by the community to enable seamless, end-to-end token transmits between Polkadot parachains and Ethereum, and vice versa.

Overview

Snowbridge has successfully implemented a way to bridge ERC-20 tokens to Polkadot. Bridging parachain tokens to Ethereum is still on the roadmap, but with unknown estimated time of arrival. KILT offers to implement an interim solution. The research started mid-May and the implementation could be ready and usable in a matter of roughly 8 - 10 weeks from the time of this proposal. Our aim is to provide parachains with a solution for creating an ERC-20 wrapper around their native tokens.

The solution will enable the trustless conversion of any existing native parachain token, into a wrapped parachain token on Ethereum, while maintaining the trustlessness guarantees Snowbridge provides. The pallet enables a configured conversion rate of parachain tokens on the origin chain to an ERC-20 wrapper token on AssetHub. The UI we are envisioning would allow crediting wrapper token balances to an account on AssetHub, or to an address on the Ethereum mainnet, leveraging the ERC-20 token bridging capabilities of Snowbridge. Likewise, wrapper tokens could be bridged from Ethereum mainnet to AssetHub and then converted back to the native currency on the origin parachain.

A parachain governance or community can select an ERC-20 token to serve as a recognized wrapper token of that parachain’s native asset. The initialization of the wrapper token ERC-20 contract can be performed by anyone, and can be incentivized via a bounty or funding proposal. It is up to parachain governance to verify that the setup fulfills its requirements for trustlessness. This would typically require the creator of the ERC-20 to relinquish control of the contract and move its total supply to the parachain’s sovereign account on AssetHub, as outlined in the example setup provided below. Once a decision to recognize a token and to enable transmitting has been enacted, wrapped tokens can be acquired, on AssetHub, by locking native tokens in a reserve account on the origin parachain. Holders of the wrapped token can move it around freely within and between AssetHub, Ethereum mainnet, and any network to which an ERC-20 bridge exists.

This proposal includes these three deliverables:

  • Implementation and documentation of a configurable pallet that can be deployed by any parachain within the Polkadot ecosystem (and possibly beyond) in order to wrap their native token into an ERC-20.
  • Implementation and documentation of a UI allowing users to interact with this pallet and with relevant features of AssetHub (executing reserve transfers for transmitting ERC-20 coins back to native assets)
  • Deployment of the pallet on KILT Spiritnet (mainnet) as a proof of viability of the approach and implementation, demonstrating its readiness for production.

Use Cases

  1. Parachain token (PARA) holders can deposit PARAs to the parachain’s swich pallet account and get wrapped parachain tokens (wPARA) credited to any account on AssetHub, according to the configured PARA/wPARA exchange ratio.

  2. wPARA token holders can deposit wPARAs on AssetHub and get PARAs on the parachain on any account of their choice, according to the configured wPARA/PARA ratio.

  3. wPARA token holders on AssetHub can transmit wPARAs to any account of choice on Ethereum using the Snowbridge trustless bridge.

  4. wPARA token holders on Ethereum can transmit wPARAs to any account of choice on AssetHub using the Snowbridge trustless bridge.

The following document describes the technical details of the initial setup and how the pallet tracks and records the conversion of parachain tokens against its wrapped version.

Polar Path: The Architecture

Setup

The setup provided in the proposal is only an example of how to use the proposed system.

For instance, parachains can offer a bounty to have an ERC-20 with a specific configuration be set up. Afterwards, the parachain can enact a proposal to enable transmitting between one of its tokens and the ERC-20 token.

Rollout

We will refer to agents and entities involved in the setup as E1, E2, E3, etc. Note that a single agent or entity could in principle take on all of the roles E1-En.

Parachain <> Ethereum setup

  1. Parachain defines T is the total issuance of the wPARA ERC20 smart contract

    • For example: parachain defines ‘T’ as the matching maximum supply of their parachain native token.

  2. Parachain governance deploys the new parachain runtime containing the new pallet

  3. Parachain governance opens HRMP channels with AssetHub

  4. E1 deploys the wPARA ERC20 smart contract on Ethereum

  5. E2 links the smart contract to the Snowbridge bridge

  6. E3 sends T wPARAs to the parachain account on AssetHub

  7. Parachain governance enables the transmitting between PARAs and wPARAs, optionally rewarding E1, E2, and E3 for their work in setting up the wrapped token.

An Example Polar Path: Set up step

UI/UX experience

This technical document doesn’t include the vision of the UI/UX. We would highlight here a few of the goals and requirements of the UI/UX but this can be done by an external partner of the proposal.

Goals

  • Enable users to transmit one parachain token to its wrapped ERC20 variant on AssetHub
  • Enable users to transmit ERC-20 wrapped parachain tokens from AssetHub to and from Ethereum via Snowbridge
  • Design a generic system that the parachain teams can integrate into their own runtime

Requirements

  1. It should be a simple UI that initiates the transmission with a click and signature.

  2. It should be easy to transmit between different tokens.

  3. It should be easy to transmit from Polkadot to Ethereum.

  4. It should show the corresponding tokens with which the selected token can be transmitted.

    • e.g. KILT should show Polkadot eKILT on AssetHub or eKILT on Ethereum

  5. It should be possible to only transmit with Eth and Polkadot.

  6. It should work with Sporran and other Polkadot native wallets

  7. It should work with MetaMask

Migrate from the new ERC-20 Parachain token to the Native Parachain token

Once Snowbridge supports Polkadot-native tokens, there will be a discussion on how to migrate the workaround into the new Snowbridge functionality.

8 Likes
2

um we already built this 2-3 months ago, with a simple architecture that uses our existing messaging protocol: Asset from polkadot by yrong · Pull Request #1155 · Snowfork/snowbridge · GitHub

we are planning to merge and go live soon once our initial bridge functionality has baked in and the above has been finalized and audited

i’m not sure an additional different implementation would add any value?

4 Likes
3

Dear Snowbridge and KILT Protocol Teams,

Firstly, I want to express my gratitude to both teams for your continued efforts and contributions towards enhancing the Polkadot and its parachains ecosystems. It’s clear that both teams are deeply committed to providing robust solutions for bridging tokens to the Ethereum Network and back.

Regarding the proposal for Project Polar Path:

Snowbridge Team: Thank you for highlighting that a solution for bridging ERC-20 tokens from Polkadot has already been developed and is awaiting finalization and auditing. This is indeed promising news. Given this context, I have a few follow-up questions:

  1. ETA: Could the Snowbridge team now provide an estimated time of arrival for the release of this functionality? Specifically, is it likely to be ready before the 8-10 weeks timeframe estimated by the Polar Path proposal?
  2. Swap Duration and Fees: It would be helpful to have an idea of the duration and cost involved in using the Snowbridge solution. The proposal mentions a swap duration of 20-45 minutes and gas fees ranging from $10-$150, with efforts to lower these in future phases. Could you confirm if these estimates align with your findings? Additionally, what is the ETA for this reduction, and what fees/swaps do you realistically think can be achieved?

KILT Protocol Team: Thank you for proposing an interim solution. I appreciate the proactive approach. To provide further clarity:

  1. Timeframe: Could you specify the expected duration for token swaps using your solution and the associated gas fees? This would help in comparing the two approaches more effectively.

  2. Costs: Could you specify the expected cost.

General Considerations:

  • Value of Multiple Solutions: It would be useful to understand the potential benefits and drawbacks of having two solutions in place. Besides the potential additional costs, are there any specific technical or operational concerns that might arise from implementing both solutions concurrently?
  • Fallback Mechanism: Having two solutions might also offer a form of redundancy. Could both solutions potentially serve as fallbacks to each other, ensuring continuous functionality in case one encounters issues?

Once again, thank you to both teams for your dedication and hard work. Your contributions are vital to the continued growth and success of our ecosystem. I look forward to your responses and to furthering this collaborative effort.

Best regards,
1gn0r4nd

4

Hi.
For the questions to the KILT Team: Cost and duration depend on SnowBridge. For general considerations: we have the feeling that parachains want this solution rather sooner than later. By using only mechanisms that already work and are audited, we can deliver in very short time. This also takes away pressure from the SnowBridge team.
Cheers, ingo

5

Hi Ingo,

With the newly proposed Polar Path implementation from the KILT team, will the KILT token need to be utilised in any way to access or use this additional solution?

I’m hoping that the Polar Path expansion will be integrated with DIDs and the KILT Blockchain, potentially locking up more tokens over time as usage increases, therefore also adding additional use case and token necessity to the KILT Blockchain.

Can you clarify if this is the case?

Thank you!