April 1, 2024
min read

General Economics for Sovereign Chains - Powered by EGLD

Sovereign Chains are the next evolution in terms of modular and customizable architectures on top of MultiversX. They are an extension of the main ecosystem, seamlessly interconnected, built correctly from day zero, keeping decentralization, security and composability in mind,  as opposed to L2s that start out centralized. This post will focus on the economics side of the system. For introductory context, design overview, or differentiators over existing solutions, refer to these posts:


At its core, Sovereign Chains will inherit the SPoS (Secure Proof of Stake) from the mainchain, using the same consensus, validator rating system and staking/delegation contracts. Any PoS network must provide a set of services (producing blocks, maintaining a blockchain) to its users. Users request tasks, and the network gives appropriate responses. The user can then check if the network response has met the consensus rules. A common user task might be to include a transaction on the blockchain. Here, a valid response would be a block that contains the transaction, supported by signatures from at least two-thirds of the infrastructure operators.

As is the case for any chain, we can generally define a set of trust assumptions:

  • Economic Trust: Trust from people who have skin in the game in the form of money 
  • Decentralized Trust: Trust from having a decentralized network run by independent and geographically dispersed operators
  • Inclusion Trust: Trust that validators will make and include your blocks the way they agreed to do with you and the consensus software they are using

These kinds of guarantees are accepted when certain promises are backed by financial risk that make it unreasonable for a logical economic actor to act badly. The main feature of economic trust is that the validation rules are objective in nature. Objectivity means that if an operator dishonestly changes the specified validation rules while doing the task, then an observer can make an objective on-chain proof to punish the dishonest validator.

However, starting a new Proof-of-Stake (PoS) network is difficult. It usually involves creating a new token and convincing people to buy and stake the token. These native tokens are often unstable (high price volatility while bootstrapping), causing high inventory risk for holders. These native tokens might also be hard to get because of how new they are and the lack of exchange listings. In addition, PoS networks in the early stages might face the risk of a “death spiral” because the value of the native token is closely linked to the system’s overall security. A sudden drop in its value could greatly reduce the PoS network’s security, leading to a fall in Total Value Staked (TVS). This decrease in TVS could further lower the native token’s price, creating a death spiral.

To address the aforementioned negative points, Sovereign Chains will be able to programmatically access the security and trust features of MultiversX, according to the needs of each custom implementation. Furthermore, by tapping into this design, Sovereign Chains can benefit from shared security, bigger economic trust and easier validators bootstrapping. Developers would not have to worry about creating a trust network from scratch. Instead, they could design systems that pay fees to the programmable network to get the amount of security they need, in order to build innovative distributed systems that can help shape a new and upgraded version of the Internet. 

The solution is dual-staking. Dual staking uses two tokens to secure the same PoS network. If one of these tokens is an external network token with lower volatility, higher liquidity, and more access, namely EGLD, it solves the problems new PoS networks face. Instead of requiring stakers to hold an unstable new token, they can stake EGLD into the network. Along with staking EGLD, stakers can also optionally stake the network’s native token, if any. Dual staking is meant to reduce the “death spiral” effect. If the native token’s price declines, the PoS network’s security is still impacted, but the effect is limited. This is because the EGLD staked in the PoS network provides a base economic security.

The next goal is to define an economics model and a set of parameters with focus on growth and usage of EGLD, while giving all the freedom of economics model inside the Sovereign Chain. The model has to give a good starting point when it comes to economic security for the underlying projects, not forgetting concepts like shared security. Creating a self sustaining autonomous economic layer is the end goal.

Important questions to be asked and answered:

  1. How to enable the creation of sovereign chains with good economic security from day one for all new projects?
  2. How to ensure continuous growth in staked eGLD for the given sovereign chain? 
  3. The higher value a Sovereign Chain has, the greater economic security it needs - the market will act as a balancing force.
  4. What is the minimum EGLD staked per Sovereign Chain?
  5. What is the minimum EGLD staked required for a Sovereign Chain node?

Definition of stakedEGLD: user/validator/sovereignChain creator deposits the eGLD to the SovereignChainStaking SmartContract, which is going to be delegated to the mainnet delegation contracts, earning EGLD yield as in any other delegation. Furthermore, as the SovereignChainStaking SC is based on the general liquidStaking contract model, it will offer constant re-delegation of rewards towards various staking providers. The list of features of stakedEGLD/SovereignChainStaking contract:

  1. Allow delegation to self: staking providers will prefer to delegate their own funds to themselves
  2. Allow the Sovereign Chain to setup a list of StakingProviders to which users/nodes can delegate
  3. If no list is set, the staking provider is chosen based on totalStake, APR and validatorStatistics, prioritizing the SPs which offer good services but have less totalStake.
  4. Allow deposit of existing liquid staking tokens.
  5. Locked funds are slashable according to the rules of the Sovereign Chain.
  6. Any user can select to which SovereignChain they want to lock the funds. Sovereign Chain is allowed  

Reiterating: Every staked eGLD will be delegated to staking providers on the mainchain, so users will directly earn eGLD rewards as well, making it an easy choice for validators/users who want to support Sovereign Chains to buy and stake eGLD.

The initial parameters for launching a Sovereign Chain:

  1. A minimum of 1000 stakedEGLD locked for the specific Sovereign Chain.
    • This amount can be sponsored/crowdfunded by the community as well, and for a Sovereign Chain it will be beneficial to gather much more than the required minimum.
  2. 100 stakedEGLD per validator node must be locked for the specific Sovereign Chain. The minimum number of nodes is 20.
    • Users will select to which node they want to lock the 100 stakedEGLD. If the validator is making the staking for themselves, it will automatically lock for their own node. We can name these “sponsors”.
    • The SovereignChainConfig contract can enable/disable users locking stakedEGLD for specific nodes, or only validators can put for themselves.
  3. Maximum stakedEGLD can be defined as well.
  4. The aforementioned numbers can be changed through governance vote, depending on the market conditions and the requirements of certain sovereign shards. The governance will be done using the stakedEGLD data from the Sovereign Chain Staking Contract.
  5. There is no requirement for a Sovereign Chain validator to be a mainnet validator as well, as the growth of Sovereign Chains can be completely independent.
  6. This is only the minimum, as these numbers can be higher depending on the setup of each Sovereign Chain, they can change their configs to higher numbers, but not lower.

Settlement layer and data availability:

The Sovereign Chains are not run in a silo, but they are seamlessly connected to the MultiversX ecosystem, thus they will need to keep this connection working - the validators of the Sovereign Chains have the job to keep the connection through the cross-chain processing module, settlements and data availability. The validators, in order to post data and execute on the mainchain, will use EGLD as gas.

  1. Settlement layer: once per X rounds the Sovereign Chain is obliged to post the blockHeader to the mainchain, using the SovereignChainHeaderVerifier contract. This checks integrity, signatures and correctness. From the blockHeader.rootHash any user is able to get out from a sovereignChain without the cross shard process, by using merkle proofs of his tokens on the sovereignChain. As technology progresses and integration of ZK proofs are developed, sovereignChains will include complete ZKProofs of all the state changes beside the header.
    • Initial computation would mean to have 2 EGLD per day as cost when Sovereign Chain posts one header at 2 minute intervals.
  2. Data availability: once per X rounds the Sovereign Chain will post the compressed state changes from last DA push to current DA push. Whether these state-changes are correct can be verified by using the previous roothash, applying the state changes and checking the resulting roothash to be equal with the one posted from the header.
    • Initial computation would mean to have 2 EGLD per day as cost when Sovereign Chain posts compressed state changes every 8 minutes.

This design enables seamless further optimisations and further addition of new components, such as ZK proofs and proof of proofs, or full rollUp state. The choices will be made by each specific Sovereign Chain, while ensuring security in all cases for the users, tokens, apps.

Dual staking means dual yield as well:

Sovereign Chains can also have their own tokens to be staked and their own economics, thus creating dual staking. On the SovereignChainConfig contract, the initiator of the chain can configure the tokenID and the minimum amount of tokens to be deposited per node/per user. 

On Sovereign Chains with the combination of one-time reStaking (the eGLD is staked on the mainchain first and then locked for Sovereign Chain, thus one-time restaked) and double staking, it will be possible for developers/custom appChains/bridges to tap into the already existing economic and decentralized trust of existing validators, and will also make sure that new validators and economics models can tap into the built framework.

From this design the whole ecosystem can gain on multiple fronts. Staking eGLD will result in a stable yield thus validators/sponsors will have a source of stable income. The new Sovereign Chains will bring more usage and more fees to both Sovereign Chains validators and to the mainnet as well. Enhanced composability will mean that most of the dApps on the mainnet will be viewed as a central focal point for the sovereign shards. Validators/delegators will be able to earn additional rewards from fees accumulated on Sovereign Chains and from rewards of the second staked token. Every Sovereign Chain will start with a high trust by default. The gain is higher for delegators/sponsors as well, as they would earn dual yield from the dual staking system, Sovereign Chains have to incentivize validators/delegators/backers to lock stakedEGLD and to stake the native token as well.

Furthermore, using this framework, a complex shared security state can be achieved between multiple parties. However, this is in the research phase at the moment. The idea is to have a set of validators registered on the SovereignValidatorStaking smart contract, and those Sovereign Chains which want to tap into the shared security to enable shuffling in and shuffling out of validators from one Sovereign Chain to another - actually doing a coordination similar to what the metaChain does for each of the current shards at the end of every epoch. However, in case of dual staking, we have to see how this model works and also to see whether validators and Sovereign Chains would like to have and adopt this. Shared security and random shuffling of validator nodes will add more value, more trust, more users and developers as well.

Further discussions and feedback are welcome on Agora:

Author Profile Picture
Robert Sasu
Core Developer
Published by
Author Profile Picture
Robert Sasu
Core Developer
Published on
April 1, 2024
Share this article