ReStaking module powered by EGLD - Gravity - MIP - 11

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:

  1. Sovereign Shards - MIP-7 - part - 1
  2. Sovereign Shards - MIP-7 - part - 2

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.

  2. 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.

  3. 100 stakedEGLD per validator node must be locked for the specific Sovereign Chain. The minimum number of nodes is 20.

  4. 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”.

  5. The SovereignChainConfig contract can enable/disable users locking stakedEGLD for specific nodes, or only validators can put for themselves.

  6. Maximum stakedEGLD can be defined as well.

  7. 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.

  8. 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.

  9. 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.

  2. Initial computation would mean to have 2 EGLD per day as cost when Sovereign Chain posts one header at 2 minute intervals.

  3. 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.

  4. 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.


Wow, so much to dive into. I am still processing it but have some questions.

  1. What happens if someone removes delegation and a sovereign chain node goes below 100 EGLD or even the main delegation goes below 1000?

I imagine the node operator is notified and has the 10 day unbonding time to make sure the minimum requirements are met? If not or if they don’t meet the requirements in time, what happens to that chain?

  1. The fees are mentioned for sending state every 2 minutes with a calculated fee of 2 EGLD a day.

I imagine that is the cost for the entire chain or is that for each node/validator on the sovereign chain? If it is total cost, how is that paid? As a rental fee of sorts from the chain operator?

Is the 2 minutes for state and 8 for DA a recommendation? A minimum/maximum?

  1. Since state is only sent to the main chain every 2 minutes in the example provided, does that mean funds have to be sent to or located on that specific sovereign chain to avoid double spend or any issues?

To further clarify let’s assume OneFinity chain is up and running. If I want to perform a swap on OneDex located on this chain, do I need to transfer funds to the OneFinity chain Smart contract and then perform the swaps?

If not, how will a DEX on shard 1 for example know that my swap on OneFinity chain was successful altering my balance if info regarding the swap is only recieved every 2 minutes?

I’ll be able to provide thoughts on the setup once I have more clarity on how it works. Thanks!

1 Like
  1. The enshrined bridge feature of transfer and execute by user will not work. This is a highly unlikely scenario, users can still get there funds out. A choice can be made to not let unLocking under the given minimum 1000+nrNodes*100. I do believe there will be much more eGLD locked for each SovereignChain, as it will be beneficial for users and projects as well.

  2. That is the cost for the entire chain, they are paid by the validators when they push the data towards the metachain. Rollup sequencers do this as well, and they pay much higher prices on ETH.

  3. There is no double spend. Each chain will work correctly by default. And user cannot get 2 times the same tokens back from the chain. One proof will work for one time only and it will have a challenge period as well.

  4. The rollup data is pushed in order to give users and exit way even when the SovereignChain has stopped or acts malicious. Finality is one round in both mainchain and sovereignchains. If you make a swap on a sovereign chain it will act as cross shard processing on mainchain, transfer funds and execute.


One important factor is the use of stakedEGLD and how it can bring together projects, communities, liquidities. In technical term we could say the model is a non custodial delegation with one-time restaking and double staking.

We said in the blogpost that users can sponsor SovereignChains with staked eGLD. This means non custodial delegation of stakedEGLD to a selected sovereign chain. This user will earn eGLD yield from the mainchain, and will earn additional rewards from sovereigns.

Going further, in this ecosystem liquid staked eGLD can be used as well. Thus anyone can leverage and use those funds to lock as an economic security fund to the SovereignChain. This will bring community, investors and the builders of the sovereigns chain much closer and everyone can earn more. Plus the economic security of each chains can grow tremendously.

If we look further, even LP positions with liquid staked eGLD can be used to lock in the security fund of the sovereign. Growing the efficiency of used assets, growing liquidity in DEXs while giving additional benefits for liquidity providers.

Now, this is the most complex economic model for SovereignChains. The resulting paradigms and security models are powerful. There is no need for Sovereign projects to worry to much about gathering a high stake as the whole ecosystem will tons of benefits from SoveignChains and users will be happy to delegate for the security funds.

The Sovereign Chain economics is about projects, community, $EGLD, investors, users, validators. Each of the actors benefiting from it and the whole system creates a compounding effect as well. Staked $EGLD gets a new utilisation for actively securing new application specific chains. With the created model every user can join the ecosystem, being an active part of the bootstrapping and security of the chain.

Users can stake EGLD through the SovereignStakingSC, this will earn yield the same as direct delegation. Users can lock $sEGLD, $vEGLD, $LEGLD (other Liquid Staking options as well), but not only liquidity pool or farm positions which have staked EGLD in them. All the rewards will go still to the user, and nobody can take away the locked funds. The custody is completely at the user. Now, when the user chooses a SovereignChain to lock the funds, he will earn dual yield as he will earn from the rewards generated by that chain (the specifics of this is up to each project - but looking around other ecosystems we can see a range from 5-30% additional rewards).

Investors can look with a new eye into the EGLD economics model and actively support new projects, new launchpads, new economies.

Validators will have more job to do, creating more revenue, actively using those servers and infrastructure. New validators can join the system, without the need to validate in the mainchain. More service providers will come as new markets open up.

Project will benefit by starting with a high economic security and can continuously grow this without the need of a hard bootstrapping process. Projects do not need upfront funds, as users, investors can safely lock funds to support the project and to earn more. As the community gathers together the new product gets a much bigger usage and visibility. Projects can setup their own staking, token, rewards setup. They can create any complex economics models they see fit on top of the EGLD model. Projects have a complete freedom to innovate internal staking/delegation/validator/rewards model.

This was a long thought process of creating an economics model which benefits everyone. Feel free/obliged to give feedback!


Thank you for writing this up, this is a lot to parse through and grasp your vision.

If it’s not too much to ask, could it be possible to see some basic diagrams/schematics/visualisations to help in explaining the proposal? From a personal view, it can be difficult to fully understand abstract concepts without some visual aids alongside :slightly_smiling_face:


After reading more about the Cosmos situation, this makes a lot of sense. Thank you for writing this up.

hey Robert, finally getting to review this extraordinary vision for sChains, gracias. As many have said, much to take in. Very much looking forward to this. One thought ran through my mind: with all the various forms of staked egld that can be further vested into sChains, will we validators also be able to use our staked egld that we dropped into the original contracts oh so long ago? If so, that would be amazing, especially for us smallNoders.

Yep. Actually working on that as well. Plus the possibility for a validator to stake to itself.

1 Like

More information on how the economics of SovereignChains and validator pool can be thought of:

The SovereignChain economics will create an economic security fund and plus it will create a pool of validators. From there users and validators can choose the SovereignChain to validate and/or secure economically. This directly means SovereignChains can tap into the ecosystem, offer a set of benefits and users and validators will join the system, thus there is no need to gather personally the needed funds and the needed validators but to leverage the existing pool.

SovereignChains can still choose other methods for the selection of validators, such as NFTs, dual staking, whitelisting and more. The design does not limit customisability, but enables direct creation, easy onboarding, and no brainer start of any new sovereignChain.

Some questions still remain: like should we enable multiple restaking?

Can you define multiple restaking? Does this imply that i could effectively leverage a chuck of EGLD that is originally staked in my node, to a number of other offerings? And if i could stake to myself, does this suggest i could create and stake to say… 5 new nodes from my one original node?

Yes. You can leverage the already stakedEGLD and start validating, securing SovereignChains as well.

Also, it is not per Node, but the stake as value. Your original node will work on the mainnet, for SovereignChain you will launch new nodes.

Hi Robert, we shouldn’t allow multiple restaked eGLD.

We need some kind of “competition” between sovereign shards, to ensure only the best ones has support and that is clear which ones are simple dumb sovereign shards or scams.

If my “dry powder” to support sovereigns is infinite because I can use my staked eGLD into as many sovereigns as I want… any sovereign will have support and then the value of this security will be lower.

The same way I can’t vote 2 times with one staked eGLD I shouldn’t be able to “vote” for 2 sovereign chains reestaking for them at the same time with same eGLD.

Sovereign Shards - Rethinking the Economics

Since the initial announcement of the Sovereign Shards, I’ve been thinking and debating with fellow stakeholders in the ecosystem, including builders, staking providers and community members.

I want to suggest some amendments to the economic plan made by @robert, but first, let’s discuss the purpose of Sovereign Shards.

The Need for Sovereign Shards

Sovereign Shards are designed for projects, governments and institutional actors to launch a shard with custom rules, adapted to their specific use case. It can be transaction speed, fees, interoperability with EVMs etc…
In addition, Sovereign Shards benefit from the settlement layer and data availability of the Main Shard.
Both the settlement and the compressed state require gas fees on the Main Shard, paid in EGLD.

The Atom Fear

We’ve seen members of the community worried about Sovereign Shards and the impact on EGLD based on the Cosmos example.

Cosmos was designed very differently from Sovereign Shards. It’s not about launching an extension of the blockchain but rather a stand-alone one. You can connect with other blockchains in the ecosystem through IBC (Inter-Blockchain Communication Protocol) but there is no settlement or forced interaction with the main chain.
In short, you can launch a blockchain without needing a single ATOM. There are no costs to be paid in ATOM for fees.

Cosmos Appchains vs Sovereign Shards

The economic model of Cosmos Appchains and Sovereign Shards can’t be compared as their designs are vastly different.

This is my own opinion but by fearing the Cosmos model, the proposal is overcompensating by giving too much importance to EGLD on Sovereign Shards. Let me explain.

Sovereign Shards for Adoption

Sovereign Shards are a technological feat that the blockchain ecosystem has been trying to achieve for years.
It will allow new and existing projects to create a shard adapted to their needs, it could be gaming, finance, data, AI and more…

MultiversX has everything needed from a technical point of view to attract new builders and users already today, but the reality is different.

There is no doubt that new users come to an ecosystem through successful projects, as an example, hundreds of thousands of users joined Solana through the StepN project giving exposure to blockchain, and we can only speculate it helped their current success.

MultiversX hasn’t had a similar project, yet.

For each StepN, there are hundreds if not thousands of projects that will fail or won’t reach similar success. But to get a “StepN” we need those hundreds of projects.
To get those hundreds of projects we need to attract more builders, through builders we’ll gain adoption.

Current Economic Proposal

The current economic proposal is aimed at pleasing EGLD holders, giving the native token even more use cases and giving the possibility to do restaking. But at what cost?

As of now, each sovereign shard will need validators that are running on restaked EGLD.
This means a user will be able to delegate EGLD to a Sovereign Shard validator to receive the regular Main Chain rewards through restaking but also from the Sovereign Shard itself.

As you may know, many blockchains, MultiversX included, have an inflation mechanism to incentivise validators to secure the network while waiting for enough transaction fees to make running a validator profitable.
Blockchains raise funds by selling the native token which is needed to run validators.

In this current form, a project launching on a Sovereign Shard would need to incentivise stakers and validators while the token used to validate would be the EGLD.
The project’s token would then have inflation to reward the stakers but wouldn’t be used to secure the network.
In addition, the cost of running the network both in hardware and settlement cost would make it even more challenging.

While I understand the case for having EGLD at stake for Sovereign Shards, I’m worried it will become a hindrance to attracting new projects, builders and lastly, users.

Let’s take the case of a project that already exists on another chain and is looking into Sovereign Shards, their community wouldn’t be able to become validators/stakers of this Sovereign Shard unless they invest in yet another token. The project itself would need to distribute its token to EGLD holders, not their community, to be able to run the network.

As an EGLD holder myself I see why this could be attractive but I think we would be losing in the long run as we would have fewer Sovereign Shards and therefore less settlement fees and fewer users on MultiversX.

It’s important to recall that the gate to MultiversX and all the Sovereign Shards will remain xPortal.
New users discovering a project on a Sovereign Shard will interact with the Main Chain, will most likely buy EGLD and discover what else MultiversX has to offer.

Sovereign Shards should be seen as a tool to bring mass adoption to MultiversX, so let’s make it attractive to builders.

What’s my suggestion?

Keeping the 1000 EGLD stakedEGLD to start a Sovereign Chain.

Give 3 options when configuring a Sovereign Shard:

  1. EGLD Sovereign Shard - EGLD is used to stake and validate. Incentivises existing MultiversX users to reStake their EGLD and support a new Sovereign Shard.

  2. Dual Staking - Different from the one suggested in the initial proposal. A Sovereign Shard launches with at least 20 * 100 EGLD validators. Possibility to run validator with the Sovereign’s own token. For example: 20 EGLD Validators and 80 Token Validators, allowing for the MultiversX users to participate but also non-MultiversX users interested in the new Sovereign Shard.

  3. Token Staking - The Sovereign Shard still staked the 1000 EGLD to run the Sovereign Shard. But only the project’s token is used for staking.
    This gives the option for projects to launch a Sovereign Shard and attract new investors/users who aren’t familiar with MultiversX and wouldn’t have joined the ecosystem if it wasn’t for this project.

Security: We would need to discuss if the composability and cross-shard transactions would be limited under options 2 and 3.

For Option 2 I believe the security remains similar to Option 1 if only the EGLD Validators take care of the cross-shard interactions.

For Option 3 we need to discuss further if there are any security risks for the Main Chain if malicious Validators take over the Sovereign Shard.

Settlement: Some Sovereign Shards might not need composability or cross-shard transactions due to their purpose (gaming, inscriptions, data, RWA etc…) In those cases, the Sovereign Shard would still pay for data availability and ensure any data needed on the Main Chain is stored accordingly.

My suggestion focuses on creating a balance between attractiveness to external builders while rewarding EGLD holders. Builders now have a new option other than parachains, subnets and appchains.
The economical model takes into account that projects might want their token to be at the heart of the shard and reward users who stake their own token.
The Sovereign Shard would still need to pay fees in EGLD to settle on the Main Chain and stake 1000 EGLD to get it started. This is already far more valuable for EGLD compared to the appchain model from Cosmos while ensuring it remains attractive enough for projects.

In addition, as discussed in Option 2, we could imagine a blend of both. Instead of doing airdrops to EGLD holders (as seen on Cosmos, Avalanche etc…), they can incentivise them to reStake EGLD to receive a share of the rewards while still being able to run validators with their own token.


As discussed, we need to establish how the Sovereign Shard security would get impacted through options 2 and 3.
With those options, Sovereign Shards can become the go-to solution for projects looking to launch a custom chain. But for it to happen we need to ensure clear communication which includes promotion and tutorials on how to launch Sovereign Shards and how to adapt them to one’s use case.

I believe this suggestion to be more rewarding than the current proposal for the whole MultiversX ecosystem in the long run, including the EGLD performance.
The more Sovereign Shards we will have running the more EGLDs will be paid in fees and the more Daily Active Users the ecosystem will gain which has a much more positive impact than enabling to stake the same EGLDs once more.

MultiversX and EGLD will benefit from mass adoption through Sovereign Shards, so let’s make them as attractive as possible to bring new actors to the ecosystem.

Open the possibility to run Sovereign Shards through a different token than EGLD both in addition to EGLD Validators or as the only token to run the shard. Ensuring Sovereign Shards are as attractive if not more than other existing solutions found on other layer 1s.
This suggestion aims to benefit MultiversX and EGLD in the long term through both EGLD utility (through staking and fees) and the adoption of the network.


Edits in progress. Stay tuned!

1 Like

Competition vs Collaboration.

We are checking the dynamics of reStaking protocols from other ecosystems and how they grow and how they work. Right now the idea is to let the projects to choose whether he wants multiple reStaking or not.

1 Like

I was not clear enough in the communication and in the title as well.

SovereignChain SDK is an open source project which can be used freely for projects to launch their own chains, with their own rules. From their the projects can join or not the gravity reStaking layer. So it is important for these 2 things to be separated, and from now on, we will try to communicate with this.

  1. The gravity reStaking modul enables using and launching only with reStaking.
  2. It enables dual staking as well - the projects job is to define the minimum stake there. Like the project defines that validators which stake X amount of Project token can only validate. They can set that this amount can be delegated/not, and what is the minim stake for a validator/delegator as well.
  3. The project can define that rewards are sent only to those who stake the projects token, but still be connected to the reStaking layer. The validators can select to share rewards to the reStakers.

There are no limitations to launch the SovereginChains. The built-in enhanced cross-chain process from Sovereign to Mainchain will work only if the project is using the reStaking module, this is needed because of security for the transferAndExecuteByUser opcode. But the SovereignChain can be still connected to the mainchain, with bridge which is open sourced and was heavily tested.

1 Like