strkBTC as a Stakable Token on Starknet

strkBTC as a Stakable Token on Starknet

Thank you to @NatanSW from StarkWare for putting this proposal together.

Introduction

The following vote proposal is based on SNIP 38 and Proposal 10. It relates the introduction of a new privacy BTC wrapper, strkBTC, and the Bitcoin Staking mechanism on Starknet. Specifically, it advocates for strkBTC to be a stakable BTC wrapper on Starknet.

As the core Bitcoin staking protocol and its initial wrapper set have already been ratified through prior governance (Proposal 10), the purpose of this vote is narrower in scope: to approve strkBTC as an eligible BTC wrapper for staking on Starknet, under the already-passed wrapper listing process.

Context on strkBTC

strkBTC is part of a broader initiative to bring native protocol privacy to tokens on Starknet. Over time, strkBTC will become the canonical BTC representation on Starknet, given its advanced and trust-minimized bridging design and strong ecosystem support. You can read more about this on SNIP 38.

Proposal Items

Approval of strkBTC as an Eligible BTC Wrapper for Staking

This proposal seeks to add strkBTC to the community-approved list of BTC wrappers that may be enabled for staking on Starknet.

If approved, strkBTC will become eligible for inclusion alongside previously ratified wrappers, subject to the existing operational process.

Governance and Enablement Process

As established in the passed wrapper listing framework described in Proposal 10, for a BTC wrapper to be supported in the staking protocol, two conditions must be met:

  1. It must first be approved by a community vote.
  2. An onchain transaction must then be sent by the Monetary Committee enabling the wrapper in the staking protocol.

The Monetary Committee may only enable wrappers that have been explicitly approved through governance.

Conclusion

This vote proposes the approval of strkBTC as a new eligible BTC wrapper for staking on Starknet, under the governance framework already ratified in Proposal 10.

We plan to bring this to an onchain vote on April 30th, 2026.