DOT for parachain fees [Polkadot Summit - Liquidity Workshop Notes]

The goal of the Liquidity workshop at the Polkadot Summit was to collaborate on amounts, terms, and uses of treasury funds to eliminate friction for users joining Polkadot.

One of the discussion points brought up in this this session was related to parachains accepting DOT for fee payment (in lieu of the parachain’s native token).

Although the notes from that session are posted separately, I wanted to pose some questions and open a thread for further discussion on this topic:

1. Would you agree that the best user experience is one with flexibility on which currency I need for fee payment?
2. Does your favorite parachain accept DOT for fees?
3. Does your favorite parachain accept USDT for fees?

Thank you to those who contributed to the session and to everyone who attended Polkadot Summit and/or Decoded in Copenhagen last month!

2 Likes

Parachains can easily accept DOT.

When Mangata X launched on Kusama in May 2022, we realized that many users will be locked out of participating when they don’t hold MGX.

Within 2 weeks we had KSM payment built and deployed into production.

This is a trivial choice to make. Parachains need DOT/KSM anyways, better to start accumulating early.

In terms of weight, we decided to not rely on oracles for pricing and just used the rough anticipated price of the native token * 10. This gives space for reality to play out after launch and can be changed later.

2 Likes

I am not sure if this is asking the right questions. Karura / Acala is the first parachain to accept relaychain tokens (and other tokens) as fee payment and it is proven to be a super useful feature. I just don’t see why any parachain wouldn’t want to have this and indeed many parachains implemented similar features.

However, we don’t really have a generalized pallet for this and depends on the implementations, it can be hard for a parachain without native swap to economically safely accept other tokens as fee currency. We already have some discussions on this forum on this topic and I believe the actual next step is not asking the questions we already know the answers, but figure out the implementation plan. e.g. how to create a generalized pallet that can be easily installed by all the parachains to achieve the goal. And more discussion are required on implementation details.

1 Like

I 100% agree.

What are the blockers to doing this? Are different chains using different implementations only to solve for liquidity or lack of liquidity between USDT, DOT, and their parachain token?

1 Like

There are no blockers. We just need someone to take the lead to do it.
A reminder, the proper way to develop a generalized pallet should involve those steps:

  • Collect and document requirements from involved parties (parachains teams in this case)
  • Create a specification that includes high level and low level details and ensure it meets functional and non functional requirements
  • Write some code
  • Deploy it
  • Iteratively improving it with feedbacks from downstream projects
1 Like

@seunlanlege and @jak-pan recently had some conversations about how this could be done - but ultimately there will likely always be many implementations of this, as different chains have their own perceptions of what is “needed” in the solution they deploy. i.e. some teams want a swap to be done in the background, whereas HydraDX for example just takes the TKN into the treasury - as ultimately tx fees are dust

I think this is explicitly what we want to avoid. Many different implementations will not only unnecessarily burn Polkadot resources but will also make it extremely difficult for tooling and infrastructure to support the Polkadot ecosystem.

It seems that there are three options to manage liquidity:
a) Least expensive: accept and keep DOT in treasury (for future core time or other expenses)
b) accept DOT to treasury, DCA over time (to stables, paraToken, or anything else)
c) convert DOT to paraToken at execution (most expensive)

I understand that technically each of these could have many different implementations - but does this cover the core solutions that teams may need?

On Bifrost side, we implemented this feature really early because we saw it as a pain point for users.
let’s don’t forget we are not Ethereum where ETH rules all the other coins.
→ 1 user gets ETH and he’s good for everything on any dapps (worths for L2s too).

So we introduced flexible fees.
On Bifrost-Kusama:

  • BNC
  • KSM
  • ZLK
  • USDT
  • vBNC

On Bifrost-Polkadot:

  • BNC
  • DOT

User can decide the default token he prefers for fees, if not available it switches automatically to other tokens (when possible).

This was pretty well discussed at every event (Decoded/Sub0).
I know it was not @alice_und_bob and Mangata’s vision at the beginning, they prefered users to make the effort to get MGX for tx, but i’m happy to see it’s going to change :slight_smile:

This issue is also a marketing issue. :warning:
WE CAN’T PROMOTE COLLECTIVELY MARKETING CAMPAIGNS (such as Layer3.xyz, Airlyft, Galxe…) because WE WOULD NEED TO DROP EVERY DIFFERENT TOKEN (for each different parachain) to users so that they can try our dapps.
We are facing this issue within Polkapals trying to set marketing campaigns with several parachains/dapps. Dropping dust KSM/DOT to users or giving them access to an address where they can withdraw some dust KSM/DOT for fees would be much simplier and would avoid to deal with 10 different tokens or more.

We need all parachains to have the possibility to pay for gas with DOT/KSM at a minimum, and with stablecoins as a back-up solution.