I fail to understand how parachains having their own native token is universally a good thing.
It’s clear how different parachains might have unique use cases and requirements, so they may take different approaches to their tokenomics, but in that case couldn’t they build some specific infrastructure that they need on top of using DOT as a native currency?
If you look at https://parachains.info/ - each parachain that is currently launched has its own currency. I highly doubt that all of them need these currencies to fulfill their purpose. To me it seems like an attempt to cheaply tokenize value that may not be there for these projects to capture.
This seems to be accepted as a norm, but I can’t fail to notice how it’s fragmenting the network and brings little to no benefit to the ecosystem, apart from enriching the founders and investors of these projects?
Today I get onboarded to the ecosystem, and I get a wallet, acquire DOT, transfer it to the wallet and supposedly stake it to get some voting power. The day after I decide to build something on the Moonbeam network so I once again acquire and transfer DOT, then I bridge it to the parachain to be able to deploy my ink contracts. Then I decide to connect with my fellow builders so I bridge some tokens into SUB on Subsocial parachain, to then burn it into their own energy token?
If that (simple usage) example doesn’t sound ridiculous, then I must at least note that even in a world where everything is perfectly bridged to everything with infinite liquidity, this is not how mass adoption would look like.
Shouldn’t the ecosystem at least try to encourage the use of DOT as parachain’s native currency? Please explain to me where my judgment is wrong. I’d like to learn more about how non-monolithic economy would work (more conveniently) in the future.
It’s doable now if the parachain wants to be paid in DOTs, but…
We validate parachain’s blocks using their code, but we do not control what they do in their code, so users must trust the parachains DOT accounting. In practice, this works since the users must trust the parachains accounting in its native token anyways, but less than ideal.
We envision adding SPREEs which provides “enclaves” which run in the parachain’s coretime, and with which the parachain interacts, but whose code the parachain has no control over, and who have their own storage on the parachain, but which the parachain cannot touch.
SPREEs would permit transaction logic that users could trust even if they did not trust the parachain, so then really untrusted parachains could upgrade freely, but not access user’s funds. Along with agile coretime this permits services who do not bother building a token community, like smart contracts.
SPREEs should be much less dangerous than smart contracts calling other smart contracts too, in part because SPREEs communicate by messages, meaning any MEV needs several blocks to take effect.
SPREEs are delayed for several reasons: SPREEs require many low-level design choices, which nobody really made, and people who started made differently. PolkaVM adds more possibly better design choices. Reliable off-chain messages (XCMP v??) should come first, so SPREEs eat less message bandwidth. CoreJam complicates everything.
tl;dr Not this year for SPREE. “Letting the pefrect be the enemy of the good” for your original question.
I understand what you are saying, especially from the perspective of someone who enters the ecosystem via Polkadot and then looks into parachains.
The other perspective is that someone can come into the ecosystem via a parachain itself and not even need to know that it runs on Polkadot (just like you discover websites from their own marketing, not from the “AWS community”). The parachain can abstract the Polakdot part completely away from their own users (and handle acquiring DOT for Coretime on their own).
I don’t think it was ever proposed to be universally good (or bad). Polkadot is flexible enough to handle many approaches; developers have enormous flexibility in how they design and configure their runtimes. For a lot of applications, they could definitely just run with DOT. For others, maybe a new token does make sense.
So, I don’t think your judgement is wrong, just incomplete. DOT could certainly be used a lot more in parachains, but I don’t see any reason to compel every parachain to use DOT.
Honestly, it took my like a minute to get tokens for the parachains I wanted to use in a decentralized fashion, all I needed was my DOT. Setting up a user account in Web 2 is hardly less work.
Not saying that things can not be improved, but if the UX for swapping tokens is nice and integrated, I can actually see how this is not really an issue even for non technical users.
A couple of reasons for not doing that (some of these may depend on token properties not commonly known or available):
keeping a custom token gives you a literal growth option - you can spin-off to your own relay-chain, if you reach that scale, with much less disruption to your users.
right now ETH, DOT, etc are speculator token designs and, as you note, so are the parachain tokens. These have the drawbacks you note, but also all the advantages that securities offer. A further drawback of these speculator tokens is that it is next to impossible for a user (not speculator) to work out what is the network take-rate they are paying. If (when) consumer tokens are available it should be possible to work out, if not set/configure what the network take-rate is. In this case different networks will naturally have different take-rates and you will need different tokens to reflect that (as well as several other more subtle behaviors).
The last point is another type of growth option - even if DOT holders refuse to morph to a consumer token, your parachain token potentially could.
I wouldn’t say that the process is complicated myself, but it’s definitely novel for the non-technical users. While you and I are familiar with concepts of keeping different tokens on different accounts of different wallets, most users would have to spend time getting familiar.
Another point is, while it’s not complicated to bridge and swap tokens when it comes to the action, there’s a lot of friction in the questions that arise before it. Is this the right token I’m swapping to? Should I buy more than I currently need for future use? Do I still have any left since the last time I swapped? If so, how much?
I wonder if you can address the above problems with SPREEs? Would it be possible to let parachains use their own native tokens, keeping their sovereignty and possibility of growth, but have the process of bridging and swapping abstracted away from the end user, so that they only had to keep DOT in their wallet?
It could be slightly safer using SPREE, yes. It could be automated using messages through some DEX too, which maybe the user trusts more than the app being used, but…
All this brings inter-parachain bandwidth limits, which off-chain messaging should solve for full parachains, but on-demand parachains maybe more subtle.
Also, on-demand parachains might prove more likely to use DOT, because if they’re smaller projects without VC backing then they might just want the cash now, rather than doing their own token mess.
apart from enriching the founders and investors of these projects?
There you have it, I don’t think you need to look for more explanations
Rolling your own parachain is complex and expensive, even if your product is awesome and going to grow to millions of users it won’t happen over night so the great deal of work needed until you generate the necessary revenue to be at least sustainable has to come from somewhere. Not many people with the ideas have also the resources and conviction to develop a project for months or years from their own pocket so the “easiest” alternative is usually to make a pie, slice it and share it promising the slices will get tastier over time. It’s a big incentive that is very hard to counter, if you tell people to not make their own pie, they’ll have to get more creative when it comes to find resources for their project.
I would also like to see more parachains using KSM/DOT as their native token, I think it makes UX much better and we could stand out more uniting under a common shared economy. But to make it attractive enough for founders to not follow the tricky but potentially rewarding path of building your own economy, Polkadot token holders will need to make things much easier for those who want to build said KSM/DOT native chains(I like “extension chains” as Joe called them), It could be in the form of access to treasury funds with less barriers, discounted core time, etc.
I can say from experience that the process is currently far from ideal, I actually don’t know other projects other than Kreivo(the parachain we are building in Kusama) that are trying to build a non-system chain with the network token as its native token and I don’t blame anyone because it isn’t easy, starting is slow until you get some reputation(e.g.we started making tools), then surfing governance is quite challenging and energy consuming and for example we had to wait for block space to become free in Kusama before thinking about launch anything(a “free” system chain slot was not an option as we still want our governance to be independent).
I still believe it’s a better path to follow looking at the big picture and the benefit of the entire ecosystem, e.g. just us trying to make a simple more integrated chain with little resources has yielded PBA alumni and fellowship candidates that have the incentive to understand the protocol at a deeper level and make contributions, having to “suffer governance” for example makes us want to make it better so we kind of specialized in that part of the PolkadotSDK. Other projects with millions of VC funding might just wait for Parity so develop things put them together and don’t look back, not the best approach IMHO.
