sBTC Updates - Weekly MegaThread

Working Groups
#1

Moving forward, I’ll be sharing the weekly sBTC updates here for more ecosystem visibility. This issue first appeared on Bitcoin Writes. You can subscribe here to get these straight to your inbox.

Dear Bitcoiners,

As a follow up to our recent issue on user experience, the sBTC working group has started to define the UX for key ecosystem applications.

Here’s a little alpha leak for you.

sBTC is going to unlock a Bitcoin-native UX when transacting on the Stacks network. This means that Bitcoin will become the primary unit of account for trading NFTs and transacting in DeFi. This is how it would work:

(Thanks to Mark and the Hiro Wallet team for providing this preview)

In this example, the user would log into Gamma and send a Bitcoin transaction to purchase the NFT. Bitcoin is automatically converted to sBTC, which executes a smart contract call and the NFT is delivered to the users Stacks address where it is secured by 100% of Bitcoins hash power.

Our goal is to define the best practices that will reduce friction for Bitcoiners and provide an exceptional user experience. There is still lots of work to be done, but we’re steadily making progress.

:computer: Engineering Updates

  • sBTC Eng Working Group Update
    • :white_check_mark: Formed sBTC Workstreams to accommodate the growing sBTC Working Group.
    • :white_check_mark: Workstream leads own communication with other workstreams and call out risks.
    • :information_source: Let Igor know via Discord to be looped into a workstream.
    • Visit the sBTC Eng Wiki for all relevant resources.
  • Workstream Updates
    • Bitcoin
    • Blockchain
      • Lead: Mårten Contributors: stjepan, soju-drinker, jacinta
      • Risks:
        • Commit-reveal design might not fulfill our needs.
        • Peg-handoff is not getting enough attention.
        • Peg-out request SIP-021 definition potentially needs update.
      • Asks from other workstreams:
    • Clarity
      • Lead: José Contributors: Fernando, Jesus, Marvin
      • Scoping remade with insights from the team.
      • Contacting stacks core leads for reviews.
    • Crypto
      • Lead: Joey Contributors: Mike M, Igor
      • Completed WTF paper audit. Continuing with FROST code audit.
    • Frontend
      • Lead: mijoco Contributors: Sergey, Igor
      • Finished final touches on deployment for sBTC Bridge Web and API
    • Nakamoto
      • Lead: Aaron
      • Plan is to have a detailed task breakdown by next week.
      • Highlights of unknown unknowns.
    • Security
      • Lead: StacksSec Contributors: Scott
    • Stacks Signer
      • Lead: Jacinta Ferrant
      • Work has just started on project plan
  • Bitcoin Builder Updates
    • @mårten#2709
    • mpj#2095
      • Setup arm build matrix for rust continuous integration. This is the first step for building the coordinator in Arm-based device like Android
    • @fjs#4368
      • Deployment of sbtc-bridge (web and api)
    • @Jacinta#2534

:hammer_and_pick: Go-To-Market Updates

  • Kicked off sBTC brand working group (Link)
  • Awarded 10 critical bounties to accelerate the growth of sBTC (Link)

:earth_africa: Around the Ecosystem

9 Likes
Stacks Blockchain Core Development Update, June 2023
#2

This issue first appeared on Bitcoin Writes. You can subscribe here to get these straight to your inbox.

Dear Bitcoiners,

Product-market fit is when a product satisfies a strong market demand. It starts by identifying the customers who are likely to use your product and the features to build to ensure you are meeting their needs.

The following chart is a great illustration of this.

How do you know when you have product-market fit?

You know you’ve achieved product-market fit when you are experiencing exponential growth… without marketing. Your product is considered a “must have” and you are testing the boundaries of the system’s capacity.

Note: I’ve noticed crypto sometimes confuses product-market fit by assuming that speculative growth is equivalent to real user demand. Sometimes the signal gets buried. Product-market fit isn’t likely to happen in a “big bang” style event, but rather through sustained execution over time. This is why we focus on building flywheels.

Now, let’s break this down for sBTC.

Market

Target User: As of April 2023, over 45 million unique addresses have a non-zero balance of Bitcoin. These 45M users represent over $500BN serviceable addressable market (SAM). This is a very large target market, which is the ideal place for startups to operate.

Underserved Needs: One of the most common answers I hear to “What would you like to do with your Bitcoin?” is the ability to take out a stablecoin loan without a centralized counter-party. The reasoning for this is simple. Bitcoiners don’t want to sell their Bitcoin, but they do want to access dollars without incurring a taxable event.

Currently, there are very few options on the market to do this. Over the past several years, this market has been been occupied by centralized companies like BlockFi and Celsius, which forced users to incur counter-party risk (…and we all know how that turned out.) There is a significant need for decentralized alternatives.

Large market + underserved needs = huge opportunity

Product

Value Prop: sBTC’s value proposition is to access Bitcoin DeFi without a centralized counter-party. Instead of a custodial or federated solution, sBTC relies on a decentralized set of signers that allow users to “peg in” their Bitcoin to use in smart contracts.

Feature Set: Building the right features requires a deep understanding of your target user as well as the competitive products on the market. Since sBTC is a tool to build programmable applications, one of the most important metrics to watch is how easy it is for developers to integrate it into their dapps. The GTM group is actively researching key features and scoping product milestones. You can see early discussion on the forum to align the product with Bitcoiner values.

UX: The majority of users who interact with sBTC may not need to use it directly. Ideally, a user would log into an application with their wallet and deposit Bitcoin collateral to their account, which executes a swap to sBTC on the backend. Once the user has sBTC, a smart contract may be executed to release stablecoins to the user’s account or to liquidate the collateral if the value falls below a pre-determined threshold.

Check out this recent Bitcoin Writes issue for more thoughts on how the GTM working group is approaching UX.

The goal for sBTC is to successfully deploy Bitcoin capital in apps, products, and smart contracts alike that prove that you can unlock Bitcoin into productive use cases. We’re focused on tightly scoping the product, and ensuring developer and app user growth. I think we have the opportunity to build something special that the market clearly needs.

“When a great team meets a great market, something special happens.”

:computer: Engineering Updates

sBTC Workgroup Updates

  • :white_check_mark: sBTC Alpha Deployment unblocked. Thank you @mijoco!
  • :warning: Need to reallocate blockchain workstream resources to signer workstream to support sBTC Alpha.

Workstream Updates

  • Blockchain
    • Lead: Mårten Contributors: stjepan, soju-drinker, jacinta
    • Definition and implementation plan for commit-reveal format
      • Got a lot of good feedback on the design. Thanks to everyone who helped! :pray:
      • Next step is to formulate a SIP and implement support for the protocol in Stacks
    • Peg handoff wire formats PR is out
    • StackerDB local testing setup is taking shape
    • Started work on the first StackerDB RPC
  • Frontend
    • Lead: mijoco Contributors: Sergey, Igor
    • Moved to multinet - sBTC now supports a network toggle to switch between testnet and mainnet in-app.
    • Moved from self hosted mongodb docker containers to Cloud managed via Mongo Atlas
  • Signer
    • Lead: Jacinta
    • Work has just started on project plan. Meeting next week to review product requirements.
  • Bitcoin Builder Updates

:hammer_and_pick: Go-To-Market Updates

  • Began process of procuring various legal opinions related to sBTC
  • Kicked off work with a new potential signing partner
  • Scoped launch goals, challenges, and dependencies for updated project plan
  • Presented keynote talk and sBTC panel during Bitcoin Unleashed
  • Made progress with several teams building potential ‘flagship apps’
  • Started planning for a sBTC-focused hack event in Q2

:earth_africa: Around the Ecosystem

  • Growing the Bitcoin Economy - keynote talk during Bitcoin Unleashed (Link)
  • sBTC panel discussion featuring builders such as Zest Protocol, ALEX, and Hiro Wallet (Link)
  • ALEX launched their cross-chain bridge on Mainnet :tada: (Link)

Many folks from the working group are heading to Austin, TX for Consensus this week. Reach out if you’re in town!

Have a great week ahead everybody.

Andre

2 Likes
#3

For folks that like rhymes:

As a rhyme:

When there’s a demand that’s grand, with a product at hand,
Product-market fit comes with customers planned.
Identifying those users, the ones who’ll choose us,
The features we create, meeting needs without fuss.

Just take a look at this chart, illustrating the part,
Where product-market fit begins, where it starts.

How do you know when you’ve got it just right?
When exponential growth takes flight, without marketing in sight.
Your product’s a must-have, testing system capacity,
Bursting the boundaries, with tenacity.

In crypto confusion, the signal gets lost,
Speculative growth, real user demand tossed.
Product-market fit won’t happen with a bang,
But sustained execution, that’s where we hang.

Now let’s break it down, for sBTC,
Market, target user, opportunity we see.

By April 2023, millions of addresses unique,
Bitcoin non-zero balances, the market we seek.
Over 500 billion, a large target indeed,
Ideal for startups, to grow and succeed.

Underserved needs, what users desire,
Stablecoin loans, no centralized party to hire.
No selling Bitcoin, just dollar access,
Taxable events, no need to address.

Few options on the market, centralized ones in place,
BlockFi, Celsius, counter-party risk we must face.
Decentralized alternatives, a need so significant,
Large market, plus underserved needs, equals opportunity magnificent.

Product value, sBTC’s proposition,
Access Bitcoin DeFi, no centralized mission.
Custodial, federated, no need to rely,
Decentralized signers, pegging in, give it a try.

Feature set, understanding users, and competition,
sBTC, a tool for building apps, with great ambition.
Integrating easily, developers watch with care,
GTM group, researching features, scoping milestones to bear.

UX, user experience, interacting discreetly,
Logging in, depositing collateral, swapping to sBTC neatly.
Smart contracts executed, stablecoins released,
Or liquidating collateral, when values decreased.

The goal for sBTC, deploy Bitcoin capital well,
In apps, products, smart contracts, success stories to tell.
Unlocking Bitcoin, productive use cases we see,
A market need, something special, a grand opportunity.

“When a great team meets a great market, something special takes place.”

5 Likes
#4
#5
#6
#9

This Week’s News & Stories - Mon, 24 Apr 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Dear Bitcoiners,

Last week, the Stacks community showed up in force to Consensus 2023. I had the honor of speaking about sBTC at the Keep Bitcoin Weird event along with Alex Miller, Chris Castig, and Kyle Ellicott.

Kyle Ellicott (Bitcoin Frontier Fund), Alex Miller (Hiro), Chris Castig (Console), Andre Serrano (sBTC)

Discussion highlights:

  • Kickstarting Bitcoin DeFi

  • Moving Bitcoin from L1 to L2 in a decentralized way

  • Bitcoin’s economic security

  • The power of identity in Web3

We met with several partners for sBTC throughout the week, and there was positive sentiment from builders on developing new use cases. Check out the latest progress updates on sBTC below 👇

💻 Engineering Updates

  • Testing Infra - Sergey Shandar

    • ✅ Code coverage in CI for our Rust code. Preparing PR Rust code coverage in CI #307

    • Working on a document on how we can achieve 100% coverage.

    • Asks from other workstreams:

      • ⚠️ Our code coverage is very low. ~33%. We need to increase.

  • Bitcoin / DLC - Tycho Onnasch

    • Made a draft technical design

    • Fernando will be working on a technical draft of the DLC implementation discussed in sBTC Eng Bitcoin: DLCs, sBTC

  • Bridge / Frontend - Mike Cohen

    • Switching the commit tx from P2WSH to P2TR. Mostly learning Taproot/Tapscript. Adjusted the UI and API to handle the Tapscript data

    • Writing a blog post on this experience - working title “sBTC Commit Transactions”

  • Blockchain - Mårten Blankfors

    • ✅ stacks-coordinator transaction broadcasting now tested

    • ✅ Draft implementation for commit-reveal support in Stacks

      • ⚠️ Initial SegWit support limited to P2WSH/P2TR nested in P2SH

    • Asks from other workstreams:

      • ⚠️ We need feedback to know if it’s enough to support the P2SH nested SegWit transactions or if we should follow-up with full SegWit/taproot support for commit-reveal.

  • Clarity - José Orlicki

    • ✅ Organized key tasks.

    • ❤️ More tests added:

      • Marvin: Adding Clarity native testing.

      • Fernando: adding SegWit testing.

      • Jesus: adding sBTC Asset Contracts tests.

    • Asks from other workstreams:

      • ⚠️ At least one vector testing case for Peg-In. Already discussed with Marten.

      • ⚠️ Get more input from Stacking Pools

  • Crypto - Joey Yandle

    • Core-eng repo back using wtfrost and p256k1 from crates

    • frost-signer/coordinator now using wtfrost Signer trait instead of accessing parties directly

  • Signer - Jacinta Ferrant

    • ✅ Met with Rena, Andre, and crew to go over initial requirements gathering

      • ❤️ Kudos to Igor for taking the lead on the meeting last minute

    • ⚠️ Priorities are in Coordinator Alpha release so not enough time to devote to Signer this week

    • Asks from other workstreams:

      • ⚠️ Please consider what sort of functionality you would want/expect as a signer and document

  • Bitcoin Builder Updates

    • @mårten#2709

      • Open PRs:

        • ✅ Draft: commit-reveal support in Stacks: stacks PR#3683

          • ⚠️ Initial SegWit support limited to P2WSH/P2TR nested in P2SH

          • ⚒️ Needs thorough testing

        • ✅ Contribution guidelines + DCO check: core-eng PR#292

          • ⚠️ Open question whether we should go with a CLA instead of the DCO check

        • ✅ Peg handoff wire format: stacks PR#3673 updated to stacks PR#3687 based on TM fork.

          • ⚠️ High latency for reviews. Most likely due to the Stacks hard fork work taking precedence.

    • @stjepan#1659

    • @Ӿoloki#3105

      • Merged core-eng PR#273; Use wtfrost and p256k1 from crates; use Signer trait without accessing parties

⚒️ Go-To-Market Updates

  • ✅ Several working group participants attended Consensus, met with partners, and spoke on panels regarding sBTC

  • ✅ Shared pre-mortem takeaways with working group

  • ✅ Conducted UX research interview with LNswap, Gamma

  • ✅ Progress on legal work stream

  • ✅ Competitive research draft completed

🌍 Around the Ecosystem

Signing Off,

Andre


Powered by beehiiv
1 Like
#10

This Week’s News & Stories - Mon, 08 May 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Dear Bitcoiners,

The landscape around Ordinals and BRC-20s is rapidly evolving. In this issue, we’ll break down everything you need to know and why it matters for sBTC.

🚀 BRC-20 Mania: What’s all the hype about?

BRC-20 tokens provide a new standard for issuing and managing assets on the Bitcoin blockchain. The idea started as an experiment to see if Ordinal theory can facilitate fungibility on Bitcoin. Anyone can deploy, mint or transfer tokens using Ordinal inscriptions through a “First in, First out” model. It uses a format called JSON, which can be broken down like this:

Although BRC-20s are still in their early stages, their proof of concept has demonstrated strong demand for issuing assets on Bitcoin. In just two months, they have risen to over $500M in market capitalization and $10M in 24 hour trading volume. While the most popular BRC-20 tokens are meme coins like MEME and PEPE, this breakthrough could quickly expand to encompass tokenized real world assets.

📈 The Demand for Bitcoin Block Space is Exploding

So far, $14M total fees (USD) have been paid for inscribing Ordinals. Yesterday alone saw a record breaking $2.5M fees paid in a single day. In fact, Bitcoin transaction fees surpassed the block subsidy coinbase reward due to high demand for Bitcoin block space. This was a crucial moment, which demonstrated a path to long-term sustainability for Bitcoin’s security model.

🧠 What does this mean for sBTC?

Stacks is poised to serve as the scaling layer for Ordinals. As fees increase on Bitcoin L1, we anticipate more activity transitioning to L2. sBTC and sOrdinals are needed to move Bitcoin to L2 in a secure and decentralized way and unlock the full capability for Ordinals.

👉The Bottom Line: BRC-20 tokens have expanded the market opportunity for sBTC. It also shapes how we approach our go-to-market strategy. We’ll be following this trend closely to see how it evolves over the coming weeks and months. One thing is certain: excitement around building on Bitcoin is back 🧡

💻 Engineering Updates

  • ❤️ Will enabled the funding of Quarter 3 Critical Bounties for a total of 12 BTC and 240k STX!!

  • ❤️ Sergey submitted an ask to the Stacks Foundation for six engineers for one quarter to focus on build, testing and security infrastructure for sBTC.

  • ✅ Igor resourcing the Nakamoto workstream with engineers.

  • ✅ Hosted a design discussion to align and prioritize features for sBTC.

  • ✅ Aligned on sBTC terminology

    • Use Deposit instead of Peg-in or Wrap

    • Use Withdraw instead of Peg-out or Unwrap

    • Terminology aligned with Subnets and other bridges.

    • We are open for comments on this and otherwise will begin renaming references in code, design docs and white papers starting next week.

  • ✅ sBTC Alpha work is progressing and unblocked.

Workstream Updates

  • Testing Infra - Sergey Shandar

  • Bitcoin / DLC - Fernando Foy

    • ⚠️ We are still looking for a way to make it so that the borrower does not have to sign to refresh a DLC

    • Asks from other workstreams:

      • If someone knows of any additional and extensive DLC libraries, this would be helpful.

  • Blockchain - Mårten Blankfors

    • ✅ Unit tests for commit-reveal operations in Stacks

    • ⚠️ Reclaim path for commit transactions needs attention

    • ⚠️ StackerDB RPC interface stalled on technical issue (borrow-checker battle)

  • Crypto - Joey Yandle

    • ✅ Updated sBTC alpha contract

      • Added key IDs to signer data

      • Signer data map is keyed off signer id not key id

    • ✅ Updated frost with Jacinta

      • All integer types are no longer platform dependent

        • u32 or u64 as necessary

        • Casts to usize are now explicit and panic if failure

      • Signer ID for v1 is no longer fake

        • v1::Signer has u32 id field

        • ID is persisted and loaded

    • ✅ Updated core-eng with Jacinta

      • Config now tracks sBTC alpha contract changes

    • ✅ Onboarded new p256k1 contributor and reviewed/merged PR

      • Replaced base58 crate with bs58

        • base58 crate was not maintained and had no license in repo

        • Error types did not implement Display/Debug

          • This prevented wrapping the errors in types that did

    • ✅ Fixed audit branch

      • Adds comments throughout code to note issues

        • Places where we need to validate inputs

        • Possible vulnerabilities

        • Confusing code

      • Unfortunately it had an awkward merge from main

        • Required a difficult interactive rebase/squash/format

  • Bridge - Mike Cohen

    • See also Bridge’s GitBook updates page.

      • Committed PR 105 which tidies up code around building the commit tx. Several options currently co-exist and work will continue in subsequent PR.

      • Created a risk assessment on the requirements around commit.

      • Finished off web project CI - staging branch is now default for PRs - serves as a safety latch for production builds.

    • Asks from other workstreams:

      • Blockchain Work Stream for sync up on the commit / reveal / reclaim flow.

  • Signer - Jacinta Ferrant

    • ✅ Met with Igor to get contact info for requirements gathering/coordination with related critical bounties

    • ⚠️ Priorities still on Stacks Alpha Project

  • Stacks Foundation sBTC Bounties - Will Corcoran

    • ✅ Home Stretch: DeMining / DeStacking Pools

    • ✅ Proof of Concept: sBTC Electrum Integration concept

    • ✅ Awarded: Stacks-Signer for Mobile and ClarityGPT

    • ✅ Teamwork!: UX/UI on sBTC Bridge, Stacks-Signer, DeStack Pool, and Nakamoto Block Sim coming together here.

    • ⚠️ Flagged: Jacinta and @mxn flagging Stacks.rs WIP - plan to work with grantee @Rswol to expand scope accordingly

    • ⚠️ Audits: DeMine / DeStack first - all others at sBTC code completion

    • ❤️ Funded!: 3Q CBs (sBTC-related CBs = 12 BTC + 240k STX!! (thanks Igor and Sergey)

  • Bitcoin Builder Updates

    • @mårten#2709

      • Open PRs:

        • ✅ Draft: commit-reveal support in Stacks: stacks PR#3683

          • ⚠️ Initial SegWit support limited to p2wsh/p2tr nested in p2sh

          • ✅ Unit tests implemented

          • ⚒️ Working on integration tests

        • ⏸️ Contribution guidelines + DCO check: core-eng PR#292

          • On hold due to unresolved CLA uncertainty

        • ⏸️ Peg handoff wire format: stacks PR#3687

          • On hold due to Stacks hard fork

    • @Ӿoloki#3105

      • Merged p256k1 PR#59 rev version for crates.io

      • Reviewed p256k1 PR#60 switch base58 crate to bs58

      • Reviewed frost PR#102 Add persistent ID to v1::Signer

      • Reviewed frost PR#99 Make all usize into u32

      • Merged core-eng PR#311 Update sBTC contract to store key-ids per signer and use signer-ids as key for signer map

      • Reviewed core-eng PR#318 Update config to better match sBTC contract changes

⚒️ Go-To-Market Updates

  • Progress on sBTC design decisions, including how to handle transaction fees in the wallet

  • Collected feedback on oracles to provide additional tooling for sBTC builders

  • Exploring ecosystem workstream to support founders on sBTC

  • UX research workstream is kicking off this week

🌍 Around the Ecosystem

  • Stacks ecosystem continues to deliver:

  • Don’t forget your tickets to Bitcoin Builders Conference! I’ll be interviewing sBTC core developers Igor Sylvester and Joey Yandle

Signing Off,

Andre


Powered by beehiiv
2 Likes
#11

This Week’s News & Stories - Mon, 22 May 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Happy Monday Bitcoiners,

Last week in Miami was magical ✨. Builder culture has returned and you could feel it in the air. The most popular topics discussed were on ZK rollups, Trustless Bridges, Layer 2s & Ordinals. What a difference a year makes!

The week started off at the Bitcoin Builders Conference. I had the privilege of interviewing gigabrains Igor Sylvester and Joey Yandle for an sBTC technical deep dive. We covered threshold signatures, future scalability and much more.

Takeaways from the Conference:

Ordinals are accelerating Bitcoin. With higher sustained fees and block space demand, builders are racing to add functionality. We’re going to see an explosion of new use cases and applications being built. Ordinals also ensure Bitcoin is the unit of account for digital native transactions, which affirms its role as a monetary asset.

BRC-20s are here to stay. The discussion on long-term viability of BRC-20s was largely split due to its relatively inefficient design and reliance on indexers. However, my takeaway was that BRC-20s will evolve and new standards will emerge that become backwards compatible. Their MVP has shown real demand, but now it’s time to move beyond meme coins to real utility.

ZK rollups are coming to Bitcoin. Zero-knowledge proof systems can offer greater flexibility on top of Bitcoin’s base layer and introduce a range of novel applications. In the near-term sovereign rollups are coming, but it will take years for Bitcoin to implement the opcodes necessary for full ZK rollups.

Trustless Two-Way Pegs are the holy grail. This has been an elusive problem in the Bitcoin community. With the growth of sBTC, the market is starting to pay attention. This is good because it shows we’re working on the right problem, but also a reminder that speed and execution will be critical to protect our current lead.

Stacks is well positioned. Stacks has a strong community of product leaders and experienced developers. We have a head start extending Bitcoin’s functionality and builders that get involved now can capitalize on this next phase of growth.

👉In conclusion: Bitcoin is fun again and I am so excited to see what the community develops over the next few years.

Highlights from the Event:

💻 Engineering Updates

  • Testing Infra

    • WIP: CodeCoverage for p256k1 and WSTS.

    • Need to finalize Work Scope for Testing/Build/Security Engineers that will activate on July 1st.

  • Blockchain

    • Document, test and clean up commit-reveal PR

    • Getting some protocol updates through

      • Allow unpadded payloads in commit-reveal

      • Include a version byte in all sBTC data payloads

      • Length-prefix contract name string in deposit/peg-in payload

    • Test vectors with OP_DROP payloads

  • Clarity Eng

    • Can simulate mining Bitcoin blocks/transactions in Clarinet via testnet controller now.

    • First peg-in tests that check if the transaction was mined, extract peg information, and mint sBTC tokens. (Consuming taproot witness script.)

    • Bridge deposit unit tests will be updated.

    • Setting up POX-2 for Clarity-only testing.

    • Began peg-transfer processor contract.

    • Merge Clarity Bitcoin library very soon, in review.

  • Stacks Signer

  • Stacks-signer: UI & API for Dashboard

    • Merged two PRs related to Create typescript Bridge library. Creates a shared lib for the web and api projects containing the common functions.

    • Keeping User Stories and Trello Kanban board up to date.

🌍 Around the Ecosystem

  • Bitcoin Builders Conference Livestream (Link)

    • Note: The sBTC talk has not been posted yet. I’ll share the recording once I receive it.

  • Tweet thread: A technical primer based on "sBTC Technical Dive", by Kenny Rogers (Link)

  • BRC-20 tokens are now trading on ALEX and they are rapidly rolling out new trading primitives (Link)

Signing Off,

Andre


Powered by beehiiv
1 Like
#12

This Week’s News & Stories - Fri, 02 Jun 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Dear Bitcoiners,

This week, the sBTC go-to-market group has been working on product research to improve the Bitcoin DeFi experience for users and developers.

For sBTC to be successful, it’s crucial that we understand user pain points and design solutions that meet their needs better than alternatives.

Here’s a summary of the work so far:

  • Four conversations with Stacks product owners to uncover assumptions and pain points.

  • Six conversations with people in Stacks, Bitcoin and Ethereum ecosystems to inform messaging guidelines.

  • Competitive research and product reviews to understand what’s on the market.

Over the next few weeks, we’ll be conducting user interviews and plan to publish a report with our findings. Below, I’ll go into more detail on our initial takeaways.

Target User: who is likely to care about our product?

The first question to ask when building a product is who are we building for? Two primary audiences we consider for sBTC are Bitcoin Holders and DeFi Users.

Our initial assumption is that Bitcoin holders and DeFi users have different views and motivations. For example, the former optimizes for security and sovereignty while the latter optimizes for experimentation and collective ownership. This is an assumption we will test through user interviews and research.

The rise of Ordinals has shown that there is a category of users who hold Bitcoin passively, but use Ethereum and Web3 protocols daily. This has revealed demand for productive use cases on Bitcoin, which was echoed in the latest State of Stacks Messari report.

Both user categories would like to earn yield on their Bitcoin with minimal friction; however, the value proposition for each group might be slightly different. With Bitcoiners, we may want to highlight the non-custodial and safety aspects of sBTC; whereas Web3 native users may care more about the competitive yield opportunities.

Early research suggests that Web3 native users are more likely to experiment with new protocols, whereas Bitcoin holders may be skeptical if there isn’t a “Bitcoin-first” experience (ie using a separate network and token).

We’ll publish more insights in the coming weeks and months as we conduct more interviews and test the UX flows for sBTC products.

Signing Off,

Andre

Special thanks to Elena Giralt for contributing to this post.

💻 Engineering Updates

  • Blockchain ⛓️

    • sBTC alpha testing is progressing.

    • Upgraded Alpha Stacks node to 2.4 consensus.

    • Fixed several minor bugs.

    • Currently lacking a deployed bridge UI.

    • Initial test-vectors for wrap/unwrap with commit-reveal are in place.

  • Clarity Eng 🔭

    • Major review of sbtc-stacking-pool.clar by Fernando and Marvin.

  • Crypto Eng ⚙️

    • Implemented Display and Debug for remaining p256k1 objects.

    • Updated frost-coordinator integration test to use code objects not binaries (link)

      • Improved code coverage from 49% to 65%.

    • Fixed a signature verification bug.

    • Discovered an inconsistency in HashMap iteration.

  • Stacks Signer 🖊️

    • Received feedback from the Clarity workstream on the signer diagrams.

    • Organizing meetings to finalize sBTC transaction flow design.

    • Initial Web UI for Stacks Signer is available for feedback.

    • Making progress on Android UI.

    • Received feedback on the WARP API and planning changes.

  • Stacks Grants 💰

    • Latest bridge work is complete here.

    • Working on implementing the design.

    • Added an API call to pull in balances for users' addresses.

⚒️ Go-To-Market Updates

  • New sBTC website is live with a refreshed brand and pitch deck.

  • User research interviews starting next week. Aligning with engineering on Bridge product testing.

  • Planning sBTC pitch competition mid-June. Stay tuned for details.

🌍 Around the Ecosystem


Powered by beehiiv
1 Like
#13

This Week’s News & Stories - Tue, 20 Jun 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Dear Bitcoiners,

Bitcoin Summer is finally here! With new ETF rumors swirling, regular breakthroughs on Ordinals, and sBTC development in full swing, it’s off to an exciting start.

ICYMI

✅ Progress on sBTC Alpha testnet. sBTC brings Bitcoin liquidity to the Stacks layer. The protocol makes it easy to create Bitcoin applications that benefit from low fees, improved performance, and full smart contract capabilities. The sBTC working group is making great progress toward the roadmap. The following picture was taken on testnet using the Hiro Wallet.

🔗 Recursive Inscriptions. The latest breakthrough in Ordinals allows inscriptions to request and use data in other inscriptions. This reduces the data stored on-chain and allows for more expressive smart contract functionality. This thread does a great job of ELI5. In short, this unlocks more composeability for ordinals contracts and could enable powerful new use cases for Bitcoin.

🚀 New Hope for Bitcoin ETFs. Last week BlackRock officially filed for a spot Bitcoin ETF. BlackRock will be using Coinbase to custody the ETF. This is a big deal. BlackRock is the world’s largest asset manager and has an ETF approval record of 575-1. Given the SEC has denied every previous Bitcoin ETF application, will this time be different?

Regardless of what happens with the ETF, this summer is for building. With the explosion of new possibilities on Bitcoin, this is the best time to go heads down creating tools and applications. We’ve got you covered with a list of ideas to get started.

Signing Off,

Andre

💻 Engineering Updates

Blockchain

  • Successful implementation of sBTC alpha deposits.

  • Withdrawals are still in progress. Support is needed for the sBTC bridge app, including bug fixes #445 #447

  • Requests for other workstreams: introduce support for OP_RETURN withdrawals in the testnet sBTC bridge.

Testing Infra

  • Drafted plan for the sBTC Testing Team to improve and simplify the development process.

Clarity

  • Reviewing remaining pull requests and updating the roadmap. There’s on-going discussion how to optimize functionality for a minimum-viable product.

Crypto

  • Updated sBTC roadmap

  • Reviewed WSTS Audit and worked on WSTS Security Proofs

Signer

  • Progress on Android UI, incorporating sBTC bridge design scheme.

  • Mock API is nearly complete. Meetings scheduled next week to collect product feedback from key stakeholders.

Better Blocks

  • Organized Better Blocks tasks as a project board.

  • Pull request #3759 is in the review process, and work started on issue #3753.

Grants

  • Critical Bounties applications close on Tuesday, June 20th (Today). Don’t forget to submit!

sBTC Bridge:

  • Worked on OP_RETURN withdrawals for sBTC alpha.

  • Implementing the UI/UX design.

⚒️ Go-To-Market Updates

  • Updating the product roadmap to provide clear deliverables for 2023.

  • Completed 15 interviews for the user research study and preparing a report with the takeaways.

🌍 Around the Ecosystem


Powered by beehiiv
1 Like
#14

This Week’s News & Stories - Mon, 31 Jul 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Dear Bitcoiners,

Bitcoin Summer is here and sBTC is sprinting ahead. There’s been a lot happening over the last few weeks, so let’s dive in.

ICYMI:

🏃‍♂️The sBTC working group kicked off a ten week sprint, focusing on critical areas of development and streamlining core engineering efforts.

The goals for the sprint are as follows:

  • ✅ sBTC v0.1 goes live as a smart contract — without consensus breaking changes. This will allow us to simplify the go-to-market and start testing under live conditions.

  • ✅ Nakamoto consensus changes, which significantly improve the speed and security of the Stacks network, go live on testnet.

  • ✅ Improvements to testing infrastructure

🎯 There has been significant operational changes to improve communication and collaboration across all contributors in the working group; as well as increased organization and clarity on project scopes.

🧠 This will allow us to ship safer, faster, better code.

🔗 The sBTC project board has moved to the new Core Engineering Github repo.

👉 For more information on the current sBTC engineering initiatives, check out the following documents:

Ready Layer 2: Bitcoin Pitch Competition

Ready Layer 2 is a Bitcoin Pitch Competition focused on generating new ideas and business models for sBTC. The event will be hosted virtually on August 18. Register here.

Q1 2023 sBTC Objective & Key Results

Here’s an overview of the objectives for Q3 2023.

Objective 1: Deliver sBTC Developer Release

sBTC version 0.1 is a developer focused release to enable early testing in live environments. This is a key step on the way toward the Nakamoto release that will support sBTC without consensus breaking changes.

Objective 2: Create an sBTC SDK for developers

This will allow us to validate and test future sBTC versions, and make it much easier for developers to integrate their apps with sBTC.

Objective 3: Engage participation in early sBTC releases

We aim to get early and iterative feedback on sBTC, to improve the core product and build sustained momentum over time.

🌎 Around the Ecosystem


Powered by beehiiv
2 Likes
#15

This Week’s News & Stories - Thu, 24 Aug 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Dear Bitcoiners,

Last week, the sBTC working group got together IRL for a hackathon that spanned contributors across all the major workstreams. The energy this week was electric — and the team made considerable progress on components of sBTC and the Nakamoto upgrade.

✍️ This week’s newsletter will highlight the wins and takeaways from the event.

Hackathon Recap

The Stacks community is full of humble geniuses spread around the world. On August 14, we logged off Zoom and descended on New York City for a week long hackathon. The event was an incredible reminder about what we can achieve together in-person.

💻 Day 1 | Tuesday, Aug 15

  • We kicked off the week with a brainstorming session on product requirements for the sBTC Signer. The Signer is responsible for validating block production under Nakamoto consensus and approving/denying deposits and withdrawals for sBTC. This set the tone for a productive week!

  • Next, we laid out the goals for the week and formed teams focusing on:

    1. sBTC Signer

    2. Block Producer Signer & Stacks Signer

    3. Clarity Wasm

  • Jude shipped an implementation of StackerDB — the communication protocol that enables Stacks nodes to query each other. This helped unlock a lot of downstream work for the rest of the teams.

  • I presented a workshop on sBTC’s product-market fit

Day 2 | Wednesday, Aug 16

  • Elena led the sBTC Signer user stories workshop

  • We held workshops on sBTC commit-reveal, signer, and coordinator — which resulted in a comprehensive design of the Signer architecture

  • More sessions on the Nakamoto and integration testing plans

💡 Day 3 | Thursday, Aug 17

  • We were able to use StackerDB to run a full DKG (distributed key generation) round. Kudos Joey!

    • The current code includes both ECDSA sign/verify of all DKG messages (to verify they came from the expected sources), and encrypt/decrypt of the DkgPrivateShares messages.

  • The Wasm team established the basic setup for testing and executing our compiled Wasm modules. Brice demoed a benchmark showing a >90x speedup over the existing runtime.

  • We completed an initial integration into Clarinet, to allow for simple testing in the clarinet test and clarinet console environments.

  • We clarified our release strategy for the Nakamoto & sBTC upgrades (details to follow in a later post).

Overall, the team left feeling energized with more clarity on the scope of deliverables for the upcoming releases. While the core engineering team was hacking on sBTC, the marketing team was busy hosting an sBTC competition of their own…

Ready Layer 2: Bitcoin Pitch Competition Recap

Ready Layer 2 is a Bitcoin pitch competition that offered $10,000 in prizes for the best ideas, prototypes, and plans for new sBTC-powered applications. Truly an exciting weekend, the event drew 360+ registrants, 100+ participants, and 24 completed submissions.

The winners: (drumroll please 🥁)

All projects that were submitted can be viewed using this link.

We couldn’t have done it without our fantastic partners. Huge shoutout to Hiro, Xverse and ALEX for their support of the event!

Highlights from Sprint 3

sBTC:

  • Commit-Reveal & Coordinator:

    • Enhanced coordinator scaffolding and revealer trait.

    • Managed stacks-core docs and updated sBTC contract names.

    • Prepared signer architecture docs for Hackathon.

    • Explored testing, commit-reveal updates, and sBTC development.

    • Started work on Stacks P2P layer implementation.

  • Cryptography:

    • Reviewed and finalized various PRs for Signer trait, taproot, and DKG.

    • Collaborated on schnorr signatures and BTC transaction formats.

    • Worked on approve/deny flow with nonces and exposing schnorr signatures.

    • Full DKG running on top of StackerDB!

  • sBTC SDK:

    • Completed length-prefixed contract names for sBTC deposit parsing.

    • Ensured SIP-005 compliant principal encoding and outlined future steps.

    • Planned next steps for stacks-core and sbtc-core .

  • sBTC UX/UI:

    • sBTC bridge deployment planning.

    • Continuing refactoring of sbtc-bridge-lib.

    • Xverse bridge integration.

    • Finished Xverse PR.

    • Started work on signer dashboard.

    • Designed sBTC Dashboard.

    • sBTC Bridge Settings page design.

  • Clarity:

    • Enhanced test coverage for sBTC Minting contract.

    • Developed unit tests and Clarity Trait for sBTC.

    • Actively progressing on sBTC Clarity trait contract and security exploration.

    • Engaged in PR reviews, Clarity libraries, and contract fixes.

  • Signer:

    • Brainstormed Signer docs/implementations.

    • Created tickets and discussions related to signer schema and withdrawal mapping.

    • Continued documentation and signer scaffolding work.

    • Reviewed developer release smart contracts.

    • Working on stubbing out signer architecture.

  • Product & Project Mgmt:

    • Planned and hosted a hackathon.

    • Workshopped launch planning, scope decision, and migration plan.

    • Workshopped sBTC user stories and product-market fit.

    • Contributed to Explorer integration, partnerships, and documentation.

Nakamoto:

  • Shipped StackerDB!

  • Producer Architecture

  • Wire format parsing for producer candidacy operation

  • Nakamoto block producer bitcoin operations

  • Block Producer RPC Endpoints

  • Integration: Block Producer Binary

ClarityVM:

  • Defined stack memory model in Wasm runtime.

  • Implemented clar2wasm compiler operations.

  • Reviewed design concerns and rebased with improvements.

  • Worked on var operations and clar2wasm implementation.

Around the ecosystem

Signing off,

Andre


Powered by beehiiv
1 Like
#16

This Week’s News & Stories - Fri, 08 Sep 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Gm Bitcoiners,

Bitcoin Summer is coming to an end and sBTC builders are in the arena. This summer, the sBTC working group has made considerable progress streamlining the roadmap and core milestones. As always, Bitcoin Writes is the go-to place for the latest updates on sBTC development.

sBTC - bringing Bitcoin onchain

👉 What’s New? The current priority for the working group is deploying sBTC on the Stacks testnet to test deposits and withdrawals. This upcoming release milestone is built for Bitcoin Builders - to focus on capturing early feedback and improving the developer experience.

👉 Why does it matter? It’s 2023 and the majority of Bitcoin activity still happens on centralized services. The opportunity is wide open to deliver a superior platform for trading, lending and borrowing Bitcoin in a decentralized way. This release is a big step toward that.

Nakamoto - new and improved

👉 What’s New? A proposal called Nakamoto v1 has been published, which describes changes to the Stacks blockchain that include:

  1. Fast Blocks: Transactions mined and confirmed within seconds instead of minutes, achieved by increasing block production speed.

  2. Bitcoin Finality: Once a transaction is confirmed, reversing it becomes as difficult as reversing a Bitcoin transaction, eliminating forks in the Stacks blockchain.

  3. Bitcoin Fork Resistance: Stacks transactions valid after a Bitcoin fork will be re-mined in the same order, while invalid transactions will be dropped. (This feature is not consensus-critical and could be added in future releases.)

  4. No Bitcoin Miner MEV: Bitcoin miners will not have an advantage over Stacks miners, requiring competitive BTC spending to earn STX.

👉 Why does it matter? This proposal, if implemented in its current form, would significantly reduce the estimated time to implement Nakamoto, potentially allowing us to ship sBTC faster 🚀

We’ll be sharing more details on the upcoming milestones and roadmap over the next few weeks — stay tuned.

Nakamoto:

  • Completed Mockamoto Node & RPC endpoints

  • Enhanced StackerDB (load from smart contract, full ECDSA signing, event observer, RPC interface)

  • Progress on Stacks Signer (libsigner)

  • Worked on Epoch 3.0

sBTC:

Clarity:

Clarity Wasm:

  • Summit ported to stacks-blockchain

  • Built all functions necessary to support boot contracts

  • Tested execution of complex Clarity contracts in Clarinet and stacks-node

Quality of Life:

  • Progress on stacks-e2e-testing

  • Developed Clarity contract property testing plan

  • Created Rust orchestrator design document

  • Focused on DevnetJS and bitcoind debugging

  • Implemented mutation testing

Signing Off,

Andre


Powered by beehiiv
1 Like
#17

This Week’s News & Stories - Fri, 22 Sep 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Dear Bitcoiners,

Can you feel it? The sentiment around Bitcoin is shifting. The confluence of institutional interest, regulatory clarity and developer resurgence has created tailwinds as we head into year end.

Given this, I believe now is the best time to be building in the Bitcoin ecosystem. Bitcoin L2s like Stacks can offer more flexibility for developers. When the Nakamoto upgrade goes live, it will significantly improve the speed and security of the network while providing the ability to transact BTC natively onchain.

I was recently asked “why does sBTC matter?” — this is a good question that’s worth reflecting on. Here’s my take:

Bitcoin is permissionless finance. It's an opportunity to democratize access to basic financial services. The problem is, when Bitcoin grows in popularity, network fees increase that can make the network prohibitively expensive except for whales and institutions. Bitcoin L2s ensure that everyone can transact on the world’s most secure network.

Bitcoin is the ability to opt out of a wildly unpredictable monetary policy and opt in to one that is reliable and stable. It is the best form of money available and sBTC provides new ways to be able to use and interact with it.

sBTC is needed to actually see a Bitcoin economy develop, where BTC is not just sitting idle but actually serving an important utility for businesses and users alike.

Why do you think sBTC is important? I’d love to hear from you.

- Andre

🔊 Call for sBTC Testers

The Stacks ecosystem is gearing up for the sBTC Developer Release, allowing select developers to build and test with an early version of sBTC. $50,000 in prizes are available for users to get involved. Sign up here.

✍️ New and Noteworthy: Stacks Thesis

Paul Veradittakit, Partner at Pantera Capital, published a Stacks thesis. This thorough report goes into the importance of Bitcoin scalability, the role of sBTC & the Nakamoto upgrade, and a deep-dive into the use cases and ecosystem.

Read the full post here

💡 Tweet of the Week

Marvin Janssen is a core protocol developer in the sBTC working group. He published a tweet thread highlighting the great work being done to deliver sBTC.

The original "sBTC Mini" protocol will not see an official testnet launch, as the sBTC work groups shifted gears. Nonetheless, I wanted to highlight some achievements and novel work done by the #Clarity WG composed of @FriendsFerdina1, Friedger, Jesus, Jose, and myself. 1/

— marvin.btc (@MarvinJanssen)
Sep 22, 2023


Powered by beehiiv
1 Like
#18

This Week’s News & Stories - Fri, 20 Oct 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Gm Bitcoiners,

Hello from London! This week, I’m excited to share that the sBTC Developer Release has been deployed on Stacks devnet. This week’s issue will go over the main things you need to know to get up to speed on this milestone.

💻 What is the sBTC Developer Release?

The sBTC Developer Release is a minimum-viable testnet deployment of sBTC. It will allow the sBTC working group to test deposits and withdrawals, without the complexity of a decentralized set of signers. Instead, this release uses a central coordinator, which has two primary functions: (1) mint and burn sBTC (2) fulfill peg-out requests.

👩‍💻 Who is this release for?

As its named, this release is primarily for Bitcoin developers to begin building applications that will utilize sBTC. Over the past few weeks, the testing group has onboarded 150 qualified developers for the testing program. We’re seeking contributors to help catch bugs and provide invaluable feedback to the working group.

🔎 What is included in this release?

  • End-to-end deposit and withdrawal flows

  • SDK and CLI to interact with the protocol

  • Bridge API and Web Application

To get started, here is a tutorial of a demo application that uses the Bridge API. Kudos to Kenny Rogers for creating this overview guide! For more detailed documentation, check out this developer guide.

-Andre

Tweets of the Week

Copper becomes the first major custodian and digital asset infrastructure provider to signal their intent to support the expected Nakamoto and sBTC upgrades. Their announcement is a must-read for any Bitcoin builder (especially those of you keen on sBTC) and covers their integration with the Stacks, bringing Stacking, custody, and SIP-010 support to the network.

We’re thrilled to announce our integration with @Stacks – the leading Bitcoin layer for dApps and smart contracts.

This integration allows institutional clients to safely custody, trade, and leverage Stacking with all existing and future SIP-010 tokens on the Stacks blockchain.… twitter.com/i/web/status/1…

— Copper.co (@CopperHQ)
Oct 18, 2023

(Shameless plug) The Bitcoin Layer 2 thesis is gaining speed. This is one of the most exciting things to be working on in the industry and I’ve summarized a few of my thoughts on the opportunity below.

The Bitcoin Layer 2 Thesis

1. Bitcoin is the most reliable, secure foundation to build decentralized applications. At $500B market cap, it is also a large and mostly untapped market.

2. Institutional adoption will result in significant capital inflows to BTC. As Bitcoin ETFs… twitter.com/i/web/status/1…

— andre.btc (@andrerserrano)
Oct 11, 2023

The BitVM whitepaper got a lot of coverage last week and it has the potential to bring more expressivity to Bitcoin. Check out this take from Muneeb on how it impacts Stacks. (Hint: it’s a good thing)

How does BitVM impact Stacks? BitVM can contribute to growing the market size of Bitcoin DeFi and apps. We're not in a zero-sum game but a positive-sum game. Ethereum L2s are already a $50-$60B market, whereas Bitcoin L2s and related projects are barely a $1-$2B market (depending… twitter.com/i/web/status/1…

— muneeb.btc (@muneeb)
Oct 13, 2023

Bitcoin Unleashed London - Day 2

Day 2 of Bitcoin Unleashed is here. Doors open at 9am and programming will run from 10am - 2:30pm. For those not able to attend in person, check out the full livestream.

If you see me around, be sure to let me know what you would like to see built on sBTC 💪


Powered by beehiiv
2 Likes
#19

This Week’s News & Stories - Mon, 06 Nov 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Dear Bitcoiners,

Before we dive in, I’m happy to share that all of the sBTC talks from Bitcoin Unleashed are now live! You can check them out in the link below.

In this discussion, I sit down with sBTC core developers and gigabrains Jude Nelson, Mike Cohen, Friedger Müffke and Will Corcoran to discuss building sBTC-powered applications. Now, on to this week’s main updates.

🚀 Hermetica launches Bitcoin yield vault powered by sBTC

The first app to launch on the sBTC testnet is now live! Hermetica uses automated derivative strategies to generate a Bitcoin yield. The strategy has been back tested over the past six years and generates an average 6.5% APY. Check out the Hermetica Earn Vault.

This is a huge milestone for sBTC, which is now one step closer to delivering on its vision to make Bitcoin a productive asset. The sBTC testnet was released only two weeks ago and we are thrilled to see Hermetica become the first to integrate it into their application.

sBTC Design Sessions

Since the launch of the sBTC developer release, the working group has been focused on its next milestone: Mainnet. The sBTC working group been hosting daily SIP review calls, which have significantly simplified the design and uncovered some key new features. Summaries of all the key decisions can be found on Github.

⚙️ sBTC will support the OP_DROP transaction format (Github)

sBTC deposit transactions are initiated on Bitcoin with a special data field that includes the account address to which sBTC is minted. The working group has decided to use the OP_DROP format for this transaction, which affords a few key benefits:

  1. OP_DROP lowers sBTC integration efforts. It allows users to peg in BTC from any Bitcoin wallet, custodian, or exchange. By enabling deposits from custodians, this also simplifies the process for institutions, which have strict internal policies for which wallets they can use.

  2. OP_DROP allows for superior UX. Stacks apps can now abstract sBTC peg-in operations away, enabling users to interact with apps directly with native BTC.

Since this format uses two transactions to fulfill a sBTC operation, we call it the commit-reveal scheme. Documentation can be found here.

Check out this tweet thread for more detail, courtesy of Tycho from Zest Protocol.

1/ Many asked for an sBTC OP_DROP deep-dive, here we go 🧵

— tycho.btc (@TychoOnnasch)
Oct 31, 2023

🛡️ sBTC will not launch with a cap on the total supply (Github)

When the sBTC whitepaper was first released, it included a maximum amount of BTC that can be deposited. This was known as the liveness ratio, calculated by the total amount of STX locked in consensus.

The response from the community has been that this feature could inhibit adoption of the protocol due to its scalability limitations. By removing the hard cap, the working group is favoring a design where >30% of the signers are reputable and professional entities, which provide an additional backstop to secure the BTC threshold wallet.

Importantly, this decision ensures the sBTC protocol can scale to meet the demands of users today. Our strategy is to deliver the best practical system in the near-term while also ensuring the protocol can upgrade to meet the evolving needs over time. Long-term, the working group is doing active research and development on new technologies that could reduce the trust assumptions of the peg, such as BitVM or Discreet Log Contracts.

🎉 Mockamoto PR has merged! (Github)

This milestone brings the Nakamoto node online. Mockamoto is the first major milestone to launch Nakamoto on Mainnet. It supports the following functionality:

  • There is a single miner, and no stacker. It produces one block about once every five seconds.

  • It runs against a Bitcoin regtest node, which produces Bitcoin blocks once every 60 seconds.

With this update, we are one step closer to sBTC. The working group plans to provide more detail on the roadmap and implementation for Nakamoto and sBTC in the upcoming weeks.

Signing Off,

Andre


Powered by beehiiv
2 Likes
#20

This Week’s News & Stories - Mon, 04 Dec 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

As Bitcoin transaction costs continue to rise and its secure yet limiting scripting language hinders app builders from creating fully expressive smart contracts, there is a pressing need for a secure, scalable, and user-friendly Bitcoin layer. One intriguing development is the expected use of OP_DROP in the context of BTC deposit transactions on the Stacks layer for Bitcoin. In this article, we'll delve into the mechanics and advantages of OP_DROP as the ecosystem looks to further develop its Bitcoin L2 with sBTC.

Understanding sBTC

Bitcoin L2s aim to activate the Bitcoin economy by making BTC deployable in smart contracts on a scalable and user-friendly Bitcoin layer. sBTC, a 1:1 Bitcoin-backed asset, will address the main bottleneck to unlocking this BTC capital: A decentralized way to move BTC from Bitcoin L1 to and L2 and back. In more technical terms, sBTC serves as a decentralized BTC ‘peg’ on the Stacks Bitcoin Layer, secured by Stacks’ consensus. The process of moving BTC to sBTC is generally referred to as a ‘deposit’ (and out as a ‘withdrawal’), but you may also see the terms ‘peg-in’ and ‘peg-out’ and occasionally even ‘mint’ and ‘burn’ depending on a particular person’s preference, but they all describe the same action. Read more about sBTC here.

OP_DROP Mechanism

You can see how important deposit operations are to sBTC and therefore to the layer overall, so it follows that how those transactions get done is also extremely important.

Enter, OP_DROP.

OP_DROP is a mechanism used to format a deposit transaction. OP_DROP plays a crucial role in encoding the sBTC destination address into the Bitcoin L1 address used for depositing BTC.

What sets this system apart is the ability to deposit BTC to sBTC directly to a Stacks address via a single Bitcoin L1 transaction. OP_DROP works by sending BTC to a slightly modified Bitcoin address that contains the Stacks address to which sBTC should be minted. OP_DROP also enables users to deposit BTC to sBTC from any wallet, exchange, or custodian using a user interface connected to a Stacks address. In contrast to OP_RETURN, this user-friendly approach allows users to deposit via a single transaction.

This is a big step up from OP_RETURN systems that require a second output to be generated, which is both a larger task for exchanges and requires specialized wallet software with knowledge of how the deposit/withdrawal system works, limiting growth.

With OP_DROP, users can deposit their BTC into sBTC with a single, standard Bitcoin transaction.

Use Case: Zest Protocol

Consider a user who wants to earn yield on their BTC through Decentralized Finance protocol Zest. By sending BTC on Bitcoin L1 to a Zest Protocol yield pool, sBTC enters the Zest Protocol yield pool on the Stacks L2. In the same block, Zest Protocol mints a receipt token to the user.

This new mechanism without a second output represents a significant leap forward with multiple benefits for users and entities aiming to leverage Bitcoin layer Stacks.

Broader Accessibility

Building a second output is a tough ask to a custodian (like Coinbase) to do just to support sBTC deposits. With OP_DROP, a user can generate a deposit address and send BTC there from Coinbase. This wouldn’t work with OP_RETURN, since Coinbase would have to build the second output in the transaction with an added Stacks address.

Cost Efficiency and User Experience

This approach not only enhances user experience by simplifying the process but is also tax-efficient. Unlike in many jurisdictions where wrapping tokens can trigger taxable events, users in this system do not need to hold sBTC.

OP_DROP on the Stacks Layer

As of now, Stacks is the only layer capable of leveraging OP_DROP deposits. This is because Stacks has in-depth and detailed read access to Bitcoin state, while ensuring that Stacks nodes are in sync with Bitcoin state. As a result, a Stacks smart contract can detect whether BTC has been deposited using the OP_DROP format. While other layers can read the state of the Bitcoin chain, they don’t have the same low-level script interpretation necessary to parse the data out of an OP_DROP transaction directly in their smart contract code.

In summary, the use of OP_DROP in BTC deposits on the Stacks layer introduces efficiency, flexibility, and tax benefits for users. As this technology continues to develop, it will be interesting to see how it shapes the broader landscape of decentralized finance on Bitcoin.


Powered by beehiiv
#21

This Week’s News & Stories - Wed, 06 Dec 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Dear Figment, welcome to the Stacking party.

Figment is one of the leading providers for blockchain infrastructure, partnering with the industry’s top exchanges, custodians, wallets and asset managers. Today, I’m excited to share that Figment will support the Stacks layer with an institutional ‘Stacking’ solution and start rolling out service to their network of 250+ clients.

Figment brings deep expertise in security and industry best practices. They have become a hands-on contributor, supporting the Stacks network with the rollout of the expected Nakamoto and sBTC upgrades. This post will break down what this means and why it matters.

Unleashing the Potential of Bitcoin on the Stacks layer

We’re at the forefront of a Bitcoin renaissance that will usher in new opportunities to make BTC a productive asset. sBTC will enable fast, low-cost transfers of BTC on Layer 2, and more expressive applications that will unlock new use cases for Bitcoin. Building a robust validator network is a top priority that will help ensure the network is secure and decentralized. This is an important step toward that goal and we are glad Figment has decided to join us on the frontier.

Figment’s Strategic Role as a Signer on the Nakamoto Upgrade

Importantly, Figment announced they will become a Signer for the upcoming Stacks Nakamoto upgrade, helping Stacks take another step forward as a complete Bitcoin L2. Stacks Signers will have a key role: To validate (or ‘sign’) Stacks blocks and process sBTC transactions, ensuring seamless movement of BTC between Layer 1 and Layer 2. Through this integration, Figment is helping to secure the network and enable the next generation of scalable Bitcoin applications.

A Unique Offering for Bitcoin Staking

There is a huge untapped opportunity for Bitcoin staking. Stacks is the only layer that is able to offer a native Bitcoin yield, which it achieves through its novel Proof-of-Transfer (PoX) consensus mechanism. This mechanism is how Stacks achieves Bitcoin’s reorg resistance, inheriting the essential security properties that make Bitcoin the world’s most trusted network. Figment is positioning itself as an early mover in this sector and is exploring novel products that it could enable.

Bringing Institutional-Grade Services to Stacks

Figment's involvement brings institutional-grade infrastructure and services to the Stacks ecosystem. Their expertise provides a solid foundation for institutions looking to explore and capitalize on the opportunities in the Bitcoin DeFi space. With Figment's support, these institutions can confidently participate in Stacks, knowing they have a reliable and experienced stacking partner onhand.

How Does This Affect Builders?

  • White Label Services: Figment’s White Label services allow builders to integrate stacking directly into their applications without the additional overhead of running a Signer node.

  • Easy Integration: Figment offers flexible APIs that allow app developers the ability to manage their token operations in a seamless way.

  • Security & Performance: Figment’s infrastructure is optimized for security and resilience of staked assets, while providing high uptime for their services.

Concluding Thoughts

The sBTC working group is excited to work closely with Figment over the next few months rolling this out. They have become an active participant on the Stacks network and share a deep understanding of the Bitcoin L2 vision.

If you are interested in supporting institutional stacking services within your business or application, please get in touch.


Powered by beehiiv
#22

This Week’s News & Stories - Mon, 11 Dec 2023

View this on bitcoinwrites.com and subscribe to receive updates via email.

Unlike other BTC bridges, sBTC is not supported by a central custodian or a federation: instead, sBTC is secured by an open network of signers, making sBTC the most decentralized, Bitcoin-backed asset.

In this article, we’ll cover the fundamentals of the sBTC security model, the role of sBTC Signers, and how the sBTC working group is enabling a more scalable sBTC protocol design.

A Bitcoin-Backed Asset Worthy of Bitcoin

sBTC embraces the core principles of Bitcoin: decentralization, permissionless, and trust-minimization. The system is:

  • Open Membership: sBTC operates as an open network, where anyone can become a validator, increasing the decentralization and inclusivity within the sBTC ecosystem. In contrast, other alternatives have closed groups of signers.

  • Decentralized: The software libraries for sBTC can support over 150 validators, surpassing the limitations of current multi-sig implementations. This allows for a broader and more diverse set of participants, further strengthening decentralization.

  • Trust-Minimized: sBTC provides users and developers with a trust-minimized option—you interact with a decentralized network instead of a central custodian or small group of signers, aligning with the core principles of Bitcoin.

  • Collateral-Backed: Unlike alternative multi-sig approaches, which have zero collateral backing their respective Bitcoin pegs, sBTC has $250M+ of collateral in STX tokens deposited in the protocol, providing a substantial incentive to maintain the peg.

Who Are the Signers?

The sBTC asset is supported by this network of “validators.” There can be up to 150 of them, and anyone can join/leave the signer network as they desire. We expect these validators will be a combination of:

  • Trusted institutions (including exchanges and custodians, such as Figment and Copper)

  • Stacking pools (such as Xverse)

  • Individual node operators

These signers lock up Stacks tokens (STX) in order to be a signer on the network, and for their work to maintain the sBTC peg, validators earn BTC rewards, making honest behavior the most profitable course of action.

Greater than 70% of these signers are required to approve deposit and withdrawals from the system. This means that as long as at least 30% of validators are honest, the BTC deposited in sBTC is secure. To steal the BTC deposits, malicious actors would need to convince a number of validators that represent > 70% of the stacked STX capital to collude in order to steal the BTC funds. This is highly unlikely in practice given Stacks validators are geographically dispersed entities with significant business risk for behaving maliciously.

For more technical details on the implementation and design of sBTC, please refer to the SIP025. The SIP is currently under community review, pending approval on a future date to be announced.

Inheriting Bitcoin’s Security

sBTC has a number of traits that make it more secure than other Bitcoin-backed assets.

sBTC has read access to Bitcoin.

Because Stacks smart contracts have read access to Bitcoin, users can send simple Bitcoin L1 transactions to interact with Stacks and deposit BTC for sBTC. In contrast, moving BTC to a chain that is not designed to work with BTC, like Solana or Ethereum, do not have this read access, which brings different security assumptions.

Stacks forks with Bitcoin.

A lot of complexity is introduced to Bitcoin-backed projects on other chains, given that Bitcoin and the other L1 are independent of each other. When Bitcoin forks, the other chain won’t care, and each fork can destabilize the peg as large numbers of transactions can be forced to roll back after the fact.

Unlike those projects, Stacks auto-follows all Bitcoin forks and derives its security from Bitcoin. There is no risk of the sBTC peg being deprecated by a Bitcoin fork because the entire Stacks blockchain will reorg alongside Bitcoin, bringing the peg back into alignment with Bitcoin.

sBTC is reorg-resistant.

Taking this one step further, the security properties of a Stacks transaction are the same as doing a Bitcoin transaction. As soon as a Bitcoin block arrives, Stacks transactions start getting Bitcoin finality. This is not possible with other systems. In other words, Stacks does not have a separate security budget. The security level of a Bitcoin L1 transaction in a Bitcoin block is the same as a Stacks transaction that gets packaged into that Bitcoin block.

FAQ

Does sBTC have a hard cap/liveness ratio?


The original white paper proposed a liveness ratio, essentially a cap on the amount of sBTC that can be minted based on the value of STX locked into the protocol. This concept came from a security model of economic incentives, in which stackers have full signing control over a Bitcoin wallet containing the locked BTC. In the original white paper this was set to 60% of locked STX (i.e. if there is $200M of STX locked, the system capacity is $120M of BTC).

However, after further research and consideration, the sBTC working group concluded that such a cap would significantly limit potential DeFi usage and discourage large players from entering the system. Given these findings and market realities, the sBTC design no longer has this liveness ratio, and instead relies on the trust-assumption of honest institutional validators as the final security backstop.

The research concluded that a hybrid system that has both (a) anonymous signers with locked STX and (b) known, institutional signers that collectively hold > 30% locked STX, is arguably more secure than a system with just anonymous signers with locked capital. This is because institutional participants have significant incentives to behave honestly and thus bolster the organic economic incentives of the system.

For more information on this topic, see these resources:

What happens if the value of STX drops in relation to Bitcoin’s price?

Even if the price drops, validators will still have STX locked in the protocol, offering economic incentive to behave rationally (and remember, validators are also incentivized to behave honestly through the BTC rewards earned by their work to process deposits and withdrawals.)

With a combination of institutions, pools, and individuals, the design offers enough flexibility that we believe that at least 30% of signers will remain honest regardless of the price. The decision to utilize a combination of both economic and reputational incentives supports this assumption because institutions are likely to continue normal Signing operations, even if the collateral backing the system declines relative to BTC.

What is the purpose of the STX token?

The STX asset has two main uses: (a) mining incentives i.e., to keep the mining system open and decentralized; and (b) STX is the capital locked up in consensus that provides economic security to users who mint sBTC. STX will collateralize the sBTC system, offering greater levels security than systems that don’t post any collateral.

Concluding Thoughts

sBTC is a protocol that will enable users to put their Bitcoin to work in a secure and decentralized way. It enables permissionless movement of BTC onto the Stacks Layer through its open network of Signers who validate deposit and withdrawals transactions.

The current designs ensure that sBTC remains a collateralized system that also benefits from a high-reputation, institutional Signer network. Importantly, this enables sBTC to scale to meet the growing demand for Bitcoin L2s in the short-term. The sBTC working group is also committed to long-term research and development of new technologies that will allow us to continue to reduce the trust assumptions of the protocol.


Powered by beehiiv