Core Blockchain (Core DAO): The Destination for Bitcoin Yield & Bitcoin Staking
Core Blockchain (Core DAO): The Destination for Bitcoin Yield & Bitcoin Staking
Core Fusion Upgrade: Guideline for Devs and Users
5 min read · November 7, 2024
Core Fusion Upgrade: Guideline for Devs and Users

The upcoming Fusion Upgrade is one of the most significant developments in the journey of the Core blockchain. It is scheduled for 19 November 2024 at 07:00 AM UTC. The Fusion Upgrade will introduce significant improvements, including enhanced Bitcoin staking opportunities, scalability, and overall performance. Developers and users on Core must be prepared to address the changes for a smooth, uninterrupted experience.

Here's a detailed explanation of the Fusion Upgrade for developers and users and the actions they need to take.

Background: What is the Fusion Upgrade?

The Fusion upgrade introduces changes incompatible with previous versions of the Core blockchain. For developers and users, this presents exciting opportunities and challenges. New rules, logic, and technical changes are implemented, offering enhanced scalability and performance while requiring prompt action to adapt to the updated workflows and guidelines.

Key Features of the Fusion Upgrade

  • BTC/CORE Dual Staking: The Fusion upgrade introduces dual staking, allowing BTC holders to earn higher rewards by simultaneously staking BTC and CORE. The more CORE staked relative to BTC, the greater the reward boost for BTC staking.

  • lstBTC: A new ERC-20 liquid staking token, lstBTC, will be introduced. Pegged 1:1 with Bitcoin on Core provides liquidity for staked BTC while allowing users to earn rewards in CORE, offering a balanced solution between earning yield and maintaining liquidity.

  • Included Hardforks: The Fusion upgrade integrates essential changes from previous hardforks, such as Berlin, London, and Shanghai, from Ethereum. It also merges Hertz and Kepler hardforks and versions up to v1.3.9 from BNB Smart Chain, improving scalability and user experience on the Core blockchain. The Fusion upgrade also includes the Demeter Hardfork from Core.

Major Changes Affecting Developers and Users

The Fusion upgrade brings significant changes for dApp developers and users alike. These changes affect how CORE and Bitcoin's staking and unstaking functions operate on Core and how accrued rewards from CORE/BTC/Hashpower delegations are claimed.

  1. Retirement of PledgeAgent.sol

One of the most impactful changes with the Fusion Upgrade is the retirement of PledgeAgent.sol, which was previously responsible for managing delegations from users. Users and developers will now need to interact with StakeHub.sol and dedicated agent contracts for different asset types for functionalities previously tied to PledgeAgent.sol, i.e., CoreAgent.sol for CORE, BitcoinAgent.sol for Bitcoin and HashPowerAgent.sol for handling bitcoin hash power delegation. Here’s a breakdown of the significant changes:

  • delegateCoin, undelegateCoin, transferCoin: These methods related to staking/unstaking and transferring staked CORE have been moved to CoreAgent.sol. While forward compatibility exists (calls to PledgeAgent.sol will be forwarded to CoreAgent.sol), developers are advised to update their dApps to interact with CoreAgent.sol directly.

  • claimReward: The reward claim logic has now moved to StakeHub.sol. While it remains forward-compatible with PledgeAgent.sol, its behavior has changed. Previously, only CORE staking rewards required claiming, while rewards for Bitcoin and hash power delegations were distributed automatically. With the Fusion upgrade, however, all staking rewards—including CORE, Bitcoin, and hash power delegations—now require reward claims. Developers should keep this shift in mind when designing reward-related features, and users should ensure they claim their accrued rewards promptly.

  • delegateBtc, transferBtc, claimBtcReward: These functions—which handle Bitcoin staking, unstaking, and reward claiming—have been migrated to BitcoinStake.sol and renamed delegate, transfer, and claimReward. These functions no longer support forward compatibility, so developers must update BTC staking dApps to use the new BitcoinStake.sol interface. The claimReward function is no longer public and has been consolidated under StakingHub.claimReward, allowing users to claim rewards across all supported delegation types from a single interface.

  1. Manual Reward Claims

In prior versions, accrued rewards were automatically distributed during delegation, transfer, or undelegation events. With the Fusion Upgrade, rewards will no longer be automatically distributed. Instead, users must manually claim their rewards by calling StakeHub.claimReward().

Developer Implications: If your dApp currently relies on automatic reward distribution, it must be updated to accommodate this change. Specifically, you should implement prompts or notifications reminding users to manually claim rewards via StakeHub.claimReward() to ensure they receive all accrued rewards.

User Implications: Users should know that rewards will no longer be automatically distributed and must claim them manually. To avoid missing out on any accrued rewards, users are encouraged to regularly check and claim rewards through StakeHub.claimReward() interface, especially after delegation, transfer, or undelegation events, to ensure all rewards are claimed on time.

  1. BTC Staking Reward Calculation

The method for calculating BTC staking rewards has been revised. Instead of using Bitcoin transaction IDs, rewards are now calculated based on the Core reward address.

Workflow Changes

The changes introduced by the Fusion upgrade require developers to thoroughly review how their dApps and smart contracts interact with Core’s staking mechanisms. Furthermore, users must understand and align with the updated guidelines for Core v1.0.12 protocol workflow changes for staking, delegating, and claiming rewards. Key considerations include:

  • Testing for Compatibility: Even though a few methods in PledgeAgent.sol remain compatible, developers should not rely on this for long-term stability. Testing your dApp before and after the hardfork ensures seamless operation.

  • Update dApps for new workflows: dApps that handle BTC staking will need to be updated to reflect the latest workflows for staking assets programmatically on the Core blockchain in compliance with release v1.0.12.

  • Adapt new staking workflows: Stakers and delegators are strongly recommended to adapt to the latest workflows for staking assets programmatically as per the changes in release v1.0.12, discussed below.

Changes with Staking Assets on Core

With Core Protocol v1.0.12, the process for staking CORE/BTC and Hash power delegations remains straightforward. Instead of the PledgeAgent.sol smart contract, calls are required to the dedicated agent smart contracts. Let’s break down the updated workflow for CORE, BTC, and Hashpower delegations.

  1. Staking/Unstaking/Transferring CORE Tokens

a. Staking CORE Tokens

To stake CORE tokens, you need to call the CoreAgent.delegateCoin() method, passing the address of the validator and the amount to stake.

  • Parameters: You must provide the validator’s address (candidate) and the amount of CORE to be staked (parsed in msg.value).

  • Note: To stake your CORE, the validator you wish to stake your asset with doesn’t necessarily need to be elected, but they must be registered and in active status to accept delegations.

b. Unstaking CORE Tokens

To unstake your CORE tokens, use the CoreAgent.undelegateCoin() method

  • Parameters: Provide the validator’s address and the amount of CORE to be unstaked.

  • Important: with the Fusion Upgrade, accrued rewards will no longer automatically transfer when you unstake. With the PledgeAgent.sol retired and replaced by StakeHub.sol, users must explicitly claim rewards using the StakeHub.claimReward() method.

c. Transferring Staked CORE Tokens

To transfer your staked CORE tokens to a different validator without losing any rewards can be done by calling CoreAgent.transferCoin().

  • Parameters: Pass the addresses of both the source and target validators, along with the amount of CORE to transfer.

  1. Delegating Bitcoin Hash Power

Core allows users to delegate Bitcoin hash power, measured in Bitcoin blocks, to the validators on the Core blockchain.

a. Delegating Bitcoin Hash Power

Miners can delegate their Bitcoin hash power by embedding Core-specific staking information in Bitcoin block transactions. The steps are detailed in the Core documentation: Staking BTC Hash Power.

b. Relaying Bitcoin Hash Power to Core Blockchain

Relayers are essential to Core's infrastructure, ensuring smooth integration between Bitcoin and Core. They are responsible for transmitting Bitcoin hash power staking transactions to the Core blockchain by calling the BtcLightClient.storeBlockHeader() method.

  1. Staking Bitcoin

With Core Protocol v1.0.12, like in previous versions, users can stake Bitcoin by creating a Bitcoin transaction and locking up BTC assets on the Bitcoin network using native Bitcoin's CLTV technology.

a. Staking and Redeeming Bitcoin Tokens

To stake Bitcoin, users construct a Bitcoin transaction that includes a time-locked UTXO and Core staking information in an OP_RETURN output. For more information on how to stake and redeem Bitcoin assets on the Core blockchain programmatically, please visit the BTC Staking Tool Repository.

b. Transmitting Bitcoin Stake Transactions

The functionality of delegateBtc is moved from PledgeAgent.sol to BitcoinStake.sol and renamed to delegate.

Relayers or users can transmit Bitcoin stake transactions via the BitcoinStake.delegate() method.

c. Transferring Staked Bitcoin Tokens

The functionality of transferBtc is moved from PledgeAgent.sol to BitcoinStake.sol and renamed to transfer. To transfer staked Bitcoin tokens, call the BitcoinStake.transfer() method.

  1. Claiming Rewards

Once you’ve staked/delegated assets, you can claim rewards for all types (CORE, Bitcoin, and Bitcoin hash power) by calling the StakeHub.claimReward() method.

What Happens If Developers Don’t Upgrade?

If developers don’t make the necessary adjustments, their dApps may face functionality issues after the Fusion Upgrades go live on the Mainnet. It is highly recommended that developers upgrade their dApps to align with updated workflows and perform thorough testing to ensure the smooth running of their dApps without any interruptions.

Action Items for Developers on Core

To ensure a smooth transition with the Fusion Upgrade, developers must:

  • Review the Full Changelog: Go through the changelog for Fusion to fully understand the breaking changes and new features impacting your dApps, smart contracts, or blockchain integrations.

  • Test Thoroughly: Run tests on both the pre-upgrade and post-upgrade versions of your dApps to ensure everything functions correctly.

  • Update Documentation: If you manage a public-facing dApp, update your documentation and user guides to reflect the changes in reward claims and staking mechanisms.

  • Monitor for Issues: After the Fusion Upgrade goes live on the Core mainnet, monitor your dApps closely for any unexpected issues and be ready to implement fixes or optimizations as needed.

Conclusion

The Fusion upgrade marks an exciting new chapter for the Core blockchain, introducing enhanced BTC staking options and improved scalability. By staying proactive and implementing the necessary updates, developers and users can maximize the benefits of this upgraded environment.