As some of you may have heard, the Cosmos Hub has recently launched a new feature called Replicated Security. I wanted to start a discussion on the forum to gather everyone’s thoughts and opinions on the subject
Please take some time to go through the contents of this post.
The team at Function X remains neutral on Replicated Security and we do not have an official position on implementing Replicated Security
What is Replicated Security?
TLDR: Replicated Security is a feature that will allow other chains connected to a Hub such as Cosmos Hub and f(x)Core, to utilize the Hub’s validator set - including the validators’ voting power, to validate blocks on their own chain. This would allow other chains to inherit the security of the Hub, and validators and delegators on the Hub can benefit from earning rewards for their contributions in securing the other connected chains. Validators that misbehave when validating blocks on either chain will get a portion of their stake slashed.
Important Terminology:
Provider chain: the chain that leases out its validator set for securing other chains
Consumer chain: the chain that inherits the provider chain’s security
Articles (highly recommended to read to understand better):
Validators on the provider chain are not part of the governance of the consumer chain.
Since there is no longer a validator set on the consumer chain, stakeholders on the consumer chain do not participate in the POS consensus anymore. Governance is carried out by a different process where there is a separate representative role who token holders on the consumer chain can delegate to and who can perform functions that validators do for on-chain governance. These representatives do not need to run a validator node.
Remuneration Example for Validators in Replicated Security:
Transaction fees: By default, 25% of the consumer chain fees will be distributed to the provider chain. This number can be set differently for each consumer chain. Note that validators also have control over the minimum fee they are willing to receive.
Token inflation: If the consumer chain has a token, they can allocate a portion of the inflation to the Hub validators and delegators (in other words, “continuous airdrops”).
Application fees: If the consumer chain doesn’t have a token, a percentage of the swap fees, usage fees etc. can be distributed to the provider chain as well.
Known Limitations:
If the consumer chain is a sovereign chain before it participates in Replicated Security, the existing validator set will be made redundant once Replicated Security is implemented as the consumer chain would be using the validator set from the provider chain moving forward.
Validators that are participating in Replicated Security on the provider chain are expected to have their nodes up and running on the consumer chain. This inadvertently creates a limitation — economically, for the number of chains a validator can secure.
The distribution of validators’ staked collateral is asymmetrical. Validators earn rewards based on the amount of staked collateral they have. This further compounds the challenges that validators participating in Replicated Security face, as validators that have a higher stake could potentially receive significant rewards while validators with a lower stake may encounter financial difficulties.
Operational costs for validators would more than likely increase. Once Replicated Security is voted through, all validators on the provider chain must participate in Replicated Security - there is no opt-out as it stands.
There is also no guarantee that a validator can earn more or enough to cover operational costs and make profit. Validators may only start earning revenue from the consumer chain if adoption and usage reaches a certain threshold.
Feel free to post your thoughts and opinion on the topic, I’m curious to see what our community thinks about Replicated Security!
It’s difficult to project oneself on the impact of such a protocol over FunctionX, PundiX or MarginX without knowing what the intents of the foundation would be.
I’m going to consider multiple cases for a better understanding :
If FunctionX was to be a provider chain, and PundiX and MarginX were consumer chains:
the FunctionX validators would benefit directly from the fees of the consumer chains.
This would lessen the burden of validating blocks for PundiX and MarginX subnets by transferring them to FunctionX validators.
FunctionX validators would not benefit from any inflation from PundiX, neither from MarginX (this latter has no token on its own)
FunctionX validators could benefit from the application fees from PundiX and MarginX.
FunctionX validators would be submitted to higher CPU loads (especially for MarginX which has a huge number of TXs)
If FunctionX was to be a consumer chain, and CosmosHub (for example) was a provider chain:
Cosmos validators would gain knowledge of FX
FunctionX validators would almost disappear (at least, they wouldn’t gain anything or much to compensate for server costs)
Governance wouldn’t be impacted and stay as is for now
Questions:
Should we go thru a governance vote for every chain we’d like to be a provider of ?
Does the foundation intend to delegate FunctionX, PundiX or MarginX security (block validation) to another chain ?
How would it work for MarginX (for which we have absolutely no numbers) if MarginX’s intent was to delegate their security and since there’s no staked collateral from anyone (and no token) ?
Opinions:
I wouldn’t see any issue for now in using Replicated Security for FunctionX validators to secure PundiX chain.
I’d expect an estimate of the CPU (and SSD/NVME) overload if we were to use Replicated Security to secure MarginX.
I wouldn’t see much benefit of transferring FunctionX security to other Cosmos chains. The FunctionX network cannot be currently attacked, unless the FunctionX foundation attacks it itself (owns more than 2/3rd of $FX tokens).
I’d say that we would benefit from just discussing these matters for now, because impacts are above common understanding.
Scenario: Assuming f(x)Core is the provider chain and Pundi X Chain becomes the consumer chain.
Will f(x)Core validators receive PUNDIX tokens from transaction fees and/or PURSE tokens as a reward?
What if the rewards are insufficient to cover the costs and the provider chain decides to “remove” the consumer chain? It’s possible through a governance proposal to also remove reading from the docs.
Currently, 30m+ PUNDIX tokens are delegated to Pundi X Chain validators. What happens once Pundi X Chain on-boards as a consumer chain? Since there will be no validators, are the 30m PUNDIX delegated tokens being returned automatically to all the delegators? Or they will need to be manually un-delegating before RS, and have a deadline?
I understood that the utility of delegating PUNDIX tokens to receive PURSE tokens as block rewards is gone after Pundi X Chain becomes a consumer chain since there will be no validators. Delegating PUNDIX for governance voting rights, creating proposals, and receiving PURSE as block rewards gave it an additional utility.
I’m also wondering whether the timing is good for f(x)Core to become a provider chain since we currently only have Pundi X Chain and MarginX as subnets.
Should we go thru a governance vote for every chain we’d like to be a provider of ?
How would it work for MarginX (for which we have absolutely no numbers) if MarginX’s intent was to delegate their security and since there’s no staked collateral from anyone (and no token) ?
Yes, it should go through the usual social consensus procedure of forum > proposal > governance vote for every consumer chain, the same way it does for Cosmos. From what I understand, Cosmos validators and delegators then decide whether they want to accept the consumer chain.
But the question should be rephrased the opposite way - It’s not “we’d like to be a provider of”.
The validators & delegators should first determine which aspiring chain “wants to be a consumer chain” before determining whether their model is valid. The same way Neutron, Duality and Stride approached Cosmos to be a consumer chain internally and externally.
It can work both ways but usually you don’t approach someone and ask them if they want to build a brand new consumer chain, they should already have the vision to be a consumer chain so the goals are aligned for both the Provider & Consumer chain.
Iirc, there doesn’t need to be a staked token for a consumer chain. They can opt for FX-backed validators while having revenue options such as Transaction fees etc being paid to them.
If MarginX decides to lease security from Function X, MarginX can use FX to secure their chain.
Stride recently changed their model to this. Instead of using STRD to secure their chain, ATOM is now backing it - Proposal #799 on June 13 2023.
MarginX’s default tokens are USDT & FX so the list is already checked and the goals are very much aligned if they choose to be a consumer chain.
They can also propose 2 revenue streams - FX and USDT as revenue fees to the Provider.
As for governance, if I remembered correctly for MarginX, only traders get a say in this as only market makers can vote/propose which makes sense as they are the direct users of the MarginX platform. Correct me if I am wrong for this part.
Note: Stride has 4 revenue streams
15% of liquid staking rewards
15% of STRD inflationary staking rewards
15% of MEV revenue
15% of transaction fees
As reference, Stride is now a consumer chain and has adopted the ATOM-powered security model instead of their native token.
Also as a side note, recently I was talking to Jack Zampolin from Cosmos and most likely, if blockchains such as MarginX with their customized block time and consensus parameters are on the higher-end and wants to lease security from the main hub, I think(?) the provider validators may need to upgrade to have better hardware.
Thank you, @malcolmT, for opening up this discussion.
As one of the PUNDIX token holders, it is essential to understand what will happen to the token delegations after RS is adopted. @BlueStitch has raised good questions already; those are my questions as well.
Moreover, I think there should be a discussion about a “solution” after PUNDI X Chain becomes a consumer chain (if it’s going to happen). As @BlueStitch mentioned, 30m+ PUNDIX tokens are delegated. Let’s say those tokens will be returned to the holders. What’s next? And what use is there for PURSE tokens? The discussion cannot simply stop at whether F(x)Core is moving on to become a Provider Chain or not; how the subnets continue their journey should be considered as well.
Thank you. Looking forward to seeing more replies to the discussion!
As one of the PUNDIX token holders, it is essential to understand what will happen to the token delegations after RS is adopted. @BlueStitch has raised good questions already; those are my questions as well.
If the PUNDIX team choose to become a consumer chain, it will just be a transfer of the validator set over to the Function X validators.
$PUNDIX token can still be the governance token while $PURSE will be the block reward token.
The way it will work is part of the block reward, let’s say 15% of PURSE emitted can/will be allocated to the Function X validators as a block fee to secure the chain.
If the team chooses to do so, they can also add PUNDIX as a revenue fee to the Function X validator via Transaction Fee Revenue.
Note:
PUNDIX is earned via Transaction Fees
PURSE is earned via Block Rewards
There really isn’t much change for the token holders. They will retain their voting power.
As reference, Stride is an existing sovereign chain that became a consumer chain recently.
In case anyone is confused,
Interchain Security aka ICS is V1
Replicated Security aka RS is Latest
Both are the same, they just rebranded ICS to RS to better represent its actual use.
I understood that the utility of delegating PUNDIX tokens to receive PURSE tokens as block rewards is gone after Pundi X Chain becomes a consumer chain since there will be no validators. Delegating PUNDIX for governance voting rights, creating proposals, and receiving PURSE as block rewards gave it an additional utility.
It won’t be gone. As everyone can refer to the above picture, PUNDIX and PURSE can still retain all its uses. The only change is for the validators passing the security baton over to the main hub.
No change for the token holders except reduced APR.
Rewards will be reduced in exchange for extra security.
Rewards emitted will be allocated as revenue to the main hub.
Block production will be handed over to the main hub’s validator.
Current validators of the PundiXChain will have its role change to Governors if they adopt this approach.
If any part is wrong, feel free to correct me as I’m still learning also.
There is only 3 case study we can reference from because there’s only 3 consumer chain.
PundiXChain is an existing sovereign blockchain - that may want to convert.
Stride was an existing sovereign blockchain - that already converted.
Reason I’m using Stride as reference is because case study can only be done from 3 examples which is Neutron, Stride & Duality.
Stride is the best reference and case study for PundiXChain.
Cosmos Hub = Block Production for Stride Example: Function X = Block Production for PundiX
Emission of tokens
Allocation is split to the Hub & Stakers (Ratio is decided by team)
Additional revenue stream can also be added
Tokens is then delegated to Governors
Governors are the original validators previously before they became a consumer chain
Governors are In charge of voting, delegation etc.
They will not be node operators anymore - not in charge of block production
There’s really nothing much, it’s just that the main hub will be validating for multiple chains instead of each chain having to validate itself.
The main idea of ICS was to enable other chains to have the same degree of security as the hub while having a value accrue strategy to the main hub token - ATOM which is the revenue streams.
But there are discussions brought up by Jae Kwon about the possibility of a consumer chain that may try to misbehave to intentionally jail the main hub validators. The “solution” to this was having a separate slash proposal in place so it won’t automatically slash and jail the main hub’s validators.
