BNB Chain Fusion: Enhanced Security and Improved UX for stkBNB

Avatar photo

Introduction

The BSC community has decided to implement BEP-333, BSC Chain Fusion, which brings major changes to the staking and governance of the chain, along with the chain architecture.

The first phase of BSC Chain Fusion, BNB Beacon Chain First Sunset Fork, occurred on April 15th, 2024. Tomorrow, April 18th, 2024, the chain is undergoing the second phase of the BSC Chain Fusion roadmap, BNB Smart Chain Feynman Hardfork.

In this blog, we will dive into the details of BSC Chain Fusion and explore its impacts on stkBNB (don’t worry, these changes only improve our product). Let’s dive in.

What is BNB Chain Fusion?

BNB Chain Fusion aims to merge BNB from a dual-chain structure into a single chain. This transition involves moving functionalities from the BNB Beacon Chain to the BNB Smart Chain, ultimately decommissioning the Beacon Chain. These changes are intended to simplify processes by eliminating cross-chain transfers, reducing security risks, and aligning the BNB chain’s architecture with current needs and growth in the future.

BNB Beacon Chain

Originally, the BNB Beacon Chain was created to handle staking and governance, while also enhancing the security of the BNB Smart Chain. It also facilitated other functions such as minting/burning digital assets and issuing new digital assets.

The Beacon Chain previously hosted an on-chain order book DEX, but this was discontinued in BEP-151 as alternative DEX forms dominated the market. Along with the advancement of the smart chain, the Beacon Chain became redundant. Having dual chain structure slowed down the development iteration and exposes products dependent on the both chains to security vulnerabilities.

Following the removal of the DEX and the evolution of the smart contract side chain (BNB Smart Chain, or BSC), most functionalities other than staking and governance could be performed on BSC. As a result, the Beacon Chain became a legacy system and posed a technical debt for core developers.

BNB Chain Fusion Roadmap

The transition of functionalities from the BNB Beacon Chain to the BNB Smart Chain represents a significant undertaking. It’s not just a simple network upgrade where validators need to update their software; it’s a complete change to the chain itself. Many other network participants depend on the Beacon chain for various reasons, so they all need time to adjust to these changes. This upgrade affects everyone from delegators to centralized exchanges. For this reason, the BNB chain community has created a roadmap to give all of stakeholders enough time to adjust their systems accordingly.

To tackle this big upgrade, the whole roadmap splits the migration into different phases, giving all stakeholders enough time to make the necessary changes. Let’s learn about each phase and what changes will happen in each of them.

First Sunset Fork: This fork took place on April 15th, 2024. During the First Sunset Fork, few types of transactions on the Beacon Chain were disabled to encourage users to keep their funds in their wallets during the migration process to BSC. These are the types of Beacon chain transactions which were disabled: TimeLockMsg, TimeRelockMsg, FreezeMsg, IssueMsg, MintMsg, IssueMiniMsg, HTLTMsg, DepositHTLTMsg.

During the migration process, the creation & editing of validators, as well as new delegations, are prohibited to prevent conflicts with validators on BSC side. Transactions related to these actions are also disabled on Beacon Chain. Here are types of transactions that are disabled: MsgCreateValidatorOpen, MsgCreateSideChainValidator, MsgCreateSideChainValidatorWithVoteAddr, MsgEditSideChainValidatorWithVoteAddr, MsgSideChainDelegate, MsgSideChainReDelegate.

Additionally, the governance module will also be automatically disabled when the voting power falls below 5M BNB.

BSC Feynman Hardfork: This fork is occurring tomorrow, April 18th, 2024. With BSC Feynman Hardfork, BEP-294, BEP-297, and BEP-299 will be deployed.

BEP-294 will immediately grant triple voting power to validators created on BSC, incentivizing the transfer of voting power from the Beacon Chain. 

BEP-297 governance functionality will be activated once more than 10 million BNB are migrated to BSC. 

BEP-299’s smart contract will be deployed with this hardfork but it won’t be activated as the Merkle root is still empty. Only after the Beacon Chain comes to a complete halt, the Token Migration feature will be initiated by setting the Merkle root for balance dump through governance.

This fork also adds a cross-chain re-delegation feature which allows users to un-delegate their stakes from Beacon Chain and then delegate them on BSC in one transaction.

Second Sunset Fork: This fork is scheduled to take place in early June 2024. Following the transfer of more than two-thirds of the voting power to BSC, the Beacon Chain will disable additional transaction types and execute specific logic to refund funds to users’ wallets. The following type of transactions will be disabled: MsgSideChainSubmitProposal.

Final Sunset Fork: This fork will occur in late June 2024. After the Final Sunset Fork, cross-chain communication between the Beacon Chain and BSC will cease. Validators on the Beacon Chain will gradually shut down, and the chain will no longer accept new transactions or propose new blocks. 

Certain funds, including staking funds for validators, BEP2/BEP8 tokens not mirrored or bound to BSC, and small staking rewards, will be permanently locked and unrecoverable.

Post BC Fusion: This phase is expected to happen in July 2024. Following the fusion, the core dev team will dump the ledger of the Beacon Chain and generate a merkle tree, which will be publicly reviewed for about a month. 

A governance proposal will set the merkle root and approver account of the token migration contract, and a dapp will facilitate token migration from the Beacon Chain to BSC. All blockchain data of the Beacon Chain will be archived on Greenfield, Filecoin, and Arweave.

Impact on stkBNB

All these changes coming to BSC are going to help our BNB liquid staking product, stkBNB, to become more efficient and secure. Let’s learn about these changes and how they improve stkBNB.

Improved Security

Previously, the dual-chain architecture presented challenges for liquid staking protocols, notably in managing token transfers for staking on the Beacon chain and monitoring deposits and withdrawals via a contract on BSC. Because the Beacon chain lacks smart contract support, staked tokens were transferred to protocol-controlled Beacon chain addresses, with a bot orchestrating asset allocations.

Since the Beacon chain does not support smart contracts, staking tokens were sent to addresses on the Beacon chain, controlled by the protocol, and a bot managed the allocation of assets on the Beacon chain, potentially risking private key exposure.

With the fusion of chains shifting staking to the BSC, there is no longer a need for cross-chain transfers. The new stkBNB contract utilizes a stake hub contract, allowing all staking functionalities to be accessed through smart contracts on the BSC itself. This means that everything is now controlled by smart contracts, eliminating the security vulnerability related to private keys.

Less Lockup Period

Prior to the chain fusion, users faced restrictions on the frequency of unstaking requests from the Beacon Chain, limited to one request every seven days per address. Additionally, there was a seven-day unbonding period for assets, coupled with a one-day buffer in withdrawals, as the stkBNB contract processed unstaking requests daily. Collectively, these constraints extended the total time to unstake tokens to 15 days.

Following the fusion with the BSC, the unstaking process has been streamlined, reducing the duration to just 8 days. The previous limitations regarding unstaking requests on the Beacon Chain are now obsolete as staking has transitioned to the BSC. While there remains a seven-day waiting period plus a one-day delay, users can now access their assets seven days earlier than before.

Redelegation

If an address does not operate its own validators but still wishes to stake tokens, it can engage in a process known as delegation. This involves supporting a validator by allocating tokens to them.

Under the previous chain structure, if you decided to transfer your delegated tokens to a different validator for any reason, the process was cumbersome. It required first unstaking the tokens, which involved a seven-day waiting period, followed by re-staking with the new validator.

One advantage of this feature is you will retain the reward that you were missing in the 7-day unbonding period previously.

Better stkBNB Exchange Rate

As mentioned previously, before the BNB Chain Fusion, all staking actions were handled on the Beacon chain, and the exchange rate was updated once a day. With changes in the new stkBNB contract, now anyone can call a function to calculate the latest exchange rate multiple times a day. This improvement allows for a more accurate and frequently updated exchange rate, providing up-to-date information at any given time.

Conclusion

In conclusion, the implementation of BEP-333 marks a strategic evolution for the BNB ecosystem. BNB chain fusion transitions BNB from a dual-chain to a single-chain structure, eliminating the legacy Beacon chain and migrating functionalities such as staking and governance to BSC.

As we’ve seen, these changes bring numerous enhancements and security measures to the ecosystem, especially for liquid staking products like stkBNB. From boosted security to the introduction of new features like re-delegation, the advantages of chain fusion implementation are crystal clear.

The BNB chain fusion represents more than just a technical upgrade; it marks a significant advancement for the entire BNB ecosystem.

About pSTAKE

pSTAKE is a multi-chain liquid staking protocol that unlocks liquidity for your staked assets. With pSTAKE, you can securely stake your Proof-of-Stake (PoS) assets to earn staking rewards, and receive staked underlying representative tokens (Tokens) which can be used to explore additional yield opportunities across DeFi.

At present, pSTAKE supports Cosmos (ATOM), Binance chain (BNB), dYdX network (DYDX), Osmosis (OSMO), Stargaze (STARS) and Chihuahua (HUAHUA).

Website | Twitter | Telegram | Blog | YouTube | Forum

Total
0
Shares
Previous Post

pSTAKE Incentives Program April 2024

Next Post

Enhancing the OSMO Liquid Staking Distribution Using stkOSMO

Related Posts