Unlocking Liquidity | DOT as a unified gas token
This initiative falls under the UX Bounty scope and the necessary resources will be covered by its budget. You can find all relevant materials here
Overview
Using Polkadot as a multi-chain ecosystem should be as simple as possible for users. Requiring users to own the native token for every parachain they want to use in the Polkadot ecosystem creates significant UX barriers.
Many project teams believe that this is necessary to give their token utility. Practically speaking, this is not the case. As long as the chain is earning fees, it is not relevant in which token it earns them. Chains can always swap fees earned in other assets for their asset, satisfying the demand for the native token while removing barriers for users.
Key Pain Points
- Liquidity
- Polkadot is facing issues when it comes to liquidity, and we believe that a âless than idealâ user experience can be detrimental to users wanting to commit their funds to an ecosystem with a UX that is not favorable.
- Unfriendly onboarding experience for new users
- Having an on-boarding experience in which a user struggles to navigate the ecosystem can leave a new user feeling unwelcome, abandoned, and alone when it comes to experiencing Polkadot. First impressions count and having to buy a multitude of tokens to simply âtestâ some of the great products within the ecosystem is off-putting.
- Trapped Assets
- New users will inevitably take the plunge, theyâll try out new products and explore the ecosystem only to be left realizing that they cannot move assets back out without having to buy the native token, leading to trapped assets.
How can we solve this?
Weâve identified two main methods to solve this UX issue. We have also included our suggestions for which teams should adopt.
Method 1: Accept DOT natively in the runtime
- Allows the Parachain to natively accept DOT as a gas fee in your runtime without having to use
pallet_asset_conversion
.
Method 2: Usage of pallet_asset_conversion
- Swap DOT to your native token under the hood.
Whilst both methods will allow seamless integration of accepting DOT as a gas-fee token, we personally advocate for the usage of Method 1.
Method 2, whilst also using your token, will require an LP to do this, which may raise concerns with slippage and fragmented liquidity.
Call To Action - What teams have already implemented this and which method have you used?
How does this benefit the ecosystem?
Onboarding
We believe that a good UX will lead to easier and effortless onboarding for new users entering the ecosystem.
Increased Adoption
Increased Onboarding will lead to a plethora of new ecosystem users. Allowing them to try out new dApps, projects, and products, helping showcase DOT and the project teams to a wider audience.
Unlock Liquidity Barrier
Increasing adoption will help unlock that stagnant liquidity barrier. New users will have little to no blockers in bringing liquidity to the broader ecosystem.
Good UX â Easy onboarding â Increased adoption â Unlock Liquidity Barriers
Next steps
Weâd like your feedback and would like to open up this post to the ecosystem about their thoughts. Specifically which method youâd prefer and your reasons as to why.
Once decided, we can work with each team individually to evaluate their compatibility for each method, helping provide informative feedback, information, guides and eventually, opening a PR.