With the implementation of sub-chains (MarginX etc) on FX chain for improved transaction capacity, will main FX validators validate sub chain transactions as well?
If there will be separate group of validaors for every sub chain added, will FX be the native gas fee for sub-chains? Also, transaction fee collected on sub-chains will be shared with FX Core validators?
I would like some clarification from the team @Richard
Q1: With the implementation of sub-chains (MarginX etc) on FX chain for improved transaction capacity, will main FX validators validate sub chain transactions as well?
A : No. For a new sub-chain which is different from the main fx chain for etc Margin X, there will be a separate set of validators validating the subchain transactions.
Q2. If there will be separate group of validators for every sub chain added, will FX be the native gas fee for sub-chains?
A: It depends on each sub chain, for instance Margin X , the native gas fee is in FX.
Q3. Also, transaction fee collected on sub-chains will be shared with FX Core validators?
Yes. The fee collected will be shared with the set of validators validating the subchain transactions
Thank you for answering these questions.
In regards to commission collect by FX Core validators validating subchain transactions, if the native gas fee is NOT FX, how will the FX Core validators get compensated?
for instance, if subchain transaction fee is in pundix tokens and , so the rewards will be in pundix and purse tokens.
And to clairfy again, FX core validators will also be entitled to collect portion of subchain transactions fees collected in native tokens (depending how many subchain transanstions they process)
The rewards will be shared based on the stake behind each validator.
What about delegators? How come I have never received any purse or pundix delegating fx?
How will new chains help token holders? Pundi X chain looks independent from FX
Any validators want to add anything.
@cop4200 interesting topic. Now, I am wondering how different subchains do work and impact fx ecosystem.
From what I understand from @wm451’s answer, Margin X chain would directly impact FX coin use. So, what about Pundi X chain. How does FX ecosystem benefit from it with regards to the token holders?
@wm451 as Pundi X chain has been up and running for a reasonable time, how has this impacted fx overall? Has Validators/Delegators from FX chain benefitted from Pundi X chain? If yes, would it be possible to share a number
These questions are also appearing on other chains especially Avalanche and Polygon.
Read CEO of Avalanche full thread on this: x.com
Avalanche subnet chain can use their own token for gas but the subnet validators are REQUIRED to purchase AVAX.
So there is demand for AVAX, no matter how many subnets there are.
For example:
Crabada is Avax’s #1 game. They are gonna have their own subnet soon on Avalache and their gas token will be $TUS.
Question: How will FX ecosystem benefit if the side chain decides to use their own token for gas + validation?
You can read Miles’s conern thread on this too: x.com
Avalanche CEO replied to his thread.
However, for subnets on FXCore, $FX is not required unless more apps like Margin X is built which require FX.
So how will subnets benefit the FX ecosystem if they decide to use their own token for gas & validation?
For example for Pundi X Chain, if the transaction fees paid is in pundi x tokens, then the rewards will be in pundi x/purse tokens.
So one time purchase of 2000 tokens is all the benefit the main chain gets on Avax? That’s still short dealing the main token holders. Any high transaction apps will be built on their subchains and main chain won’t see any benefit from it.
1 validator = 2000 AVAX
So if the subnet requires say, at least
50 subnet validators - 2000 x 50 = 100,000 AVAX taken away from circulation just from 1 side chain
So AVAX is still needed no matter what chain is built on it - at least some sort of demand.
But FXCore subnet chain doesn’t have any compulsory requirement for FX to be used so i was wondering how will FX be utilized as there is no demand unless the subnet uses FX as gas fee + validator.
Margin X, for example, uses FX as gas fee which is nice. There is demand here.
Pundi X Chain uses its own token for gas, as well as validation so FX isn’t used here. No demand.
My question is the same as Miles - what if future sub chains follow #2 which means every side chain is using its own token for gas and its own token for its validation?
AVAX made it compulsory for all subnet to utilize AVAX token but FXCore didn’t.
Well… The tokenomics clearly needs clarification.
Let’s say a merchant on PundiXChain has a customer who wants to use his own wallet to pays for goods in BNB using BSC, and that the price is 100 BUSD, assuming he won’t go thru DeXPass for that.
First off, we need to handle a 100 BUSD<=> BNB transaction using BSC, then handle a x% transaction fee in original currency (BNB over BSC). This latest $BNB would require conversion to PUNDIX on PUNDIXCHAIN in order to be burnt. Only PUNDIXCHAIN is used, hence only PUNDIXCHAIN validators should collect fees. There’s still the issue with the automatic market making exchange of BNB to BUSD on BSC, and BUSD or BNB fée to PUNDIX on PUNDIXCHAIN.
Then, imagine we’re using future FXUSD. There should be one fee as well, but higher because we now need to exchange over FxCore and over BSC.
At least, that’s how I think this should work.
How we go interchains is of the essence here, and only time will tell. But team’s intentions about it, even if they are hypothesis, is very important for correct communications towards investors.
One thing to keep in mind is that it would require to adapt over time to what other chains will propose about this, and what fees will look like by then. WE need the system to be smarter and faster than current Visa and MasterCard systems.
We might actually do that, for a new subnet created in Function X, a certain amount of $FX is needed. How much would you say makes sense?
Zac, i would like to give my input on this as well. I think in addition to staking FX (should be a small amount) for validator creation for subchains, we should convert portion of subchain transaction fees collected to FX and distributed to FX Core delegators/validators.
It will be more beneficial for FX holders in the long run and won’t be a burden for low volume subchains (pay more, as you use more).
This might be a bad idea, my reasons are:
If subchain transaction fees are used to re-distribute to FXCore validators, then nobody would want to validate any subchain since the benefits are not equal. They would rather just be a validator on the main chain.
This will lead to the subchains not being as secured as they are supposed to be since they are not getting paid fully for the job they are doing on that chain.
I think it is more sustainable long-term to keep the fees directly for each chain/validator.
Validators that are supporting any chain, no matter what chain will be able to get the full fruit, instead of splitting it up and giving it to the main chain.
As much as i love to receive extra FX from subchains as a delegator from the main chain, i think it would be unfair to them.
Maybe i’m not seeing something, hopefully someone can correct me if what i’m saying is wrong.
My suggestion is to collect a portion of subchain fees. Of course it will have to be small (1-3 %) to stay competitive and may be 0% in start to lure in projects.
Think of it as SAAS model: don’t pay for it upfront (low to 0 FX staking for creating subchain validators) but pay as you use.
Imagine FX Core is a highway, than charging one time fee for a lifetime pass (whether someone uses it once a year or once every hour) is a better option (for both users and the highway owners) or should everyone be charged per trip. Also, per trip option has the flexibility to charge as low as zero to stay competitive.
5000 (“fxUSD”) 
IMHO a subtle mix of the 2 approaches could be interesting:
Another possibility is to leave each subchain live its own life within the FX ecosystem, still requiring point 1 though, and to apply FX fees only when interblockchain module is required (i.e. if it requires to interoperate with another subchain of the FX ecosystem).
All this needs to be thought out very carefully because it seems to me we are relying a lot on the Cosmos SDK, and we need to make sure we’re not forking from the initial Cosmos idea, the risk being to be exposed to a lot more work on the FXCore side later on.
Regards,
@FrenchXCore
