Skip to main content

Status: draft

Version records:

  1. 2024/09/05 created by Owen, v0.9.0

Bitlayer - Liquidity Re-Staking Protocol Collaboration Technical Proposal_English version

Abstract​

In Bitcoin Layer 2 networks like Bitlayer, there is a type of BTC staking project where users can participate in BTC staking activities on Bitlayer (referred to as the Layer 2 network). Simultaneously, the project team stakes the corresponding BTC on the Bitcoin mainnet (Layer 1) associated with the user’s Layer 2 BTC (BL-BTC) into Layer 1 staking protocols (e.g., Babylon), enabling users to earn dual or multiple staking rewards. In the spirit of maintaining network and user asset security, as well as fostering a collaborative and mutually beneficial ecosystem, this document outlines the technical cooperation plan between Bitlayer and liquidity re-staking protocol project teams. The aim is to implement joint management of custodial funds, ensuring the security of users' assets.

Motivation​

  • Due to the limitations of the Bitcoin mainnet, it is not possible to operate liquid staking/re-staking protocols directly on the Bitcoin network. When users participate in these protocols through Bitlayer (Layer 2), the issue of secure custody of Layer 1 assets arises. If the funds staked by users on Layer 2 are entirely entrusted to the project team for withdrawal and movement to Layer 1 for staking, this creates a fully centralized trust model. This poses significant risks to user asset security, the reputation of the Layer 2 network, and the overall prosperity of the ecosystem.
  • Bitlayer is committed to building and developing a Bitcoin Layer 2 network that inherits the security, trustlessness, and programmability of the Bitcoin network. In principle, Bitlayer does not directly participate in the development of on-chain protocols. However, under the premise of ensuring security, Bitlayer will strive to offer users more opportunities to capture yield from their assets, including liquid staking and re-staking protocols.

Specification​

Layer 2 Staking Contract Specifications​

Staking​

  1. When a user participates in staking, a staking event needs to be triggered. The event is defined as follows:
event TokenStaked(uint256 indexed reqId, address indexed user, uint256 indexed amount, address token, uint256 planId, uint256 duration, bytes extraInfo);
  • The protocol must provide a globally unique ID for each user interaction, reqId, to ensure the uniqueness of the event identification.
  • tokenrefers to the contract address of cryptocurrency. For a native token, use the 0 address to represent（ 0x0000000000000000000000000000000000000000）.
  • Staking activities can be carried out in stages, and the staking/unstaking operations on the Bitcoin network can be performed as a whole according to the total amount of each stage. In this situation, the planId can be used to identify which stage the user is participating in.
  • For duration Staking Duration ,and extraInfo Extra Custom Information, are all optional and can be extended as needed.

Unstaking​

Supports two ways to unstake: open redemption for the whole plan and on-demand application (early) unbinding.

open redemption for the whole plan​

The contract provides the following functions for Bitlayer to agree to open redemption:

function approveWithdraw(uint256 planId);
Apply for unbinding on demand​

Need to be performed in steps:

  1. When a user requests to unstake, the following event is emitted:
event UnboundRequired(uint256 indexed reqId, address indexed user, uint256 indexed amount, address token, bytes extraInfo);
  1. Once Bitlayer (the official cross-chain bridge) receives the corresponding funds from Layer 1, it approves the user's unstaking request. The Layer 2 staking contract should provide the following interface (supporting batch releases) and emit the following event
function approveUnbound(uint256[] reqIds);
event UnboundApproved(uint256 indexed reqId, bytes extraInfo);
  1. The users' final withdrawal of the staked principal, including the relevant functions and events, is determined by the protocol and is not covered in this proposal.

Permission management specifications​

  • The staking contract should aim to be as decentralized as possible, minimizing centralized management authority.
  • All management permissions related to using or transferring of funds within the contract must be governed by a multi-signature wallet, DAO contract, or other decentralized governance solutions. Bitlayer must be an indispensable participant in this governance. Relevant permissions include, but are not limited to:
    • Contract upgrade permissions;
    • Permissions to directly withdraw or transfer user funds within the staking contract;
    • Permissions to execute arbitrary code (such functions should be avoided if possible; if necessary, they must be controlled by multi-signature approval)

Layer 1 Fund Management Specifications​

  • Must use MPC self-custody or third-party custody, and provide a dedicated wallet account.
  • Account management permissions must be jointly managed by the project and Bitlayer.
  • Custody services must include a whitelist function; the dedicated wallet can only transfer funds to whitelist addresses and perform staking.
  • Set Bitlayer's official bridge hot wallet as a whitelist address; any changes to the whitelist must be approved by Bitlayer.

Layer1 and Layer2 Interaction Plan and Process​

The process is shown in the figure below：

Please note：

  • In Step 3 and Step 7, transfers of funds between the bridge hot wallet and the dedicated staking wallet must include the reqId from the layer2 user's staking/unstaking request to ensure order association.；
    • The method for including the reqId in transactions: Provide an OP_RETURN UTXO including a JSON string with the content: {"StReqIds":"id1,id2"}, where multiple IDs are separated by commas, such as {"StReqIds":"100,101"}.
  • If, due to certain objective constraints, this cannot be achieved, the Bridge Relayer will release funds based on the principles of amount matching and first-come, first-served approval. If there is no single unbonding request that exactly matches the current received amount, the funds will be released according to the first-come, first-served principle by combining requests as needed.
    • For example: If there are three requests with amounts of 1 BTC, 2 BTC, and 1 BTC, respectively, and the bridge hot wallet receives a transfer of 3 BTC from the dedicated staking wallet, the first two requests will be released in the order of their submission. In addition, for the case of unified redemption, step 5 in the above figure is not required, and step 8 is changed to execute the approveWithdraw(uint256 planId) function.