Planning

High level planning, use cases etc

Introduction

The sBTC Bridge is part of the bigger sBTC project being delivered in two phases - sBTC Mini and fully SIP-021 compliant sBTC. The priorities of the Bridge is to serve the needs of the wider project - the Bridge makes it possible to test and experiment with various aspects of the system.

Kanban Process

See the UI/UX Design Plan and individual plans for each bounty for milestones.

The project will be run Kanban style, see the sBTC User Stories and tracked via the sBTC Bridge Trello board (please request an invite on Discord if you want access).

User Stories relate to one of these Critical Bounties.

• Issue #877: CB-2Q23-04.3 : sBTC Stacks-Signer Dashboard: RPC-API and UI

• Issue #872: CB-2Q23-03.1 : sBTC Bridge: API Continuation

• Issue #873: CB-2Q23-03.2 : sBTC Bridge: Integration with Trezor & Ledger

Note: the work to bootstrap and deliver sBTC alpha is summarised in Appendix 1 below.

Milestones

Issue #877: CB-2Q23-04.3 : sBTC Stacks-Signer Dashboard: RPC-API and UI

MS1: Transaction Formats

• Un/wrap transactions conform to spec.

• User is able to reclaim unspent wrap transactions

MS2: Proof of Reserves

• All user transactions leading to mint / burn of sBTC are visible in the interface.

• All signer transactions are visible.

• sBTC mints and burns are

MS3: Protocol Governance

• voting on protocol upgrade (note: this is not signer voting on transactions) via integration with third party DAO project.

Issue #872: CB-2Q23-03.1 : sBTC Bridge: API Continuation

MS1: CI and Deployment

• Staging and production environments fully supported

• CI process defined and working

MS2: Scalability and Redundancy

• database can be horizontally scaled.

• API can be horizontally scaled

Issue #873: CB-2Q23-03.2 : sBTC Bridge: Integration with Trezor & Ledger

MS1: Trezor Support

• Data connection via Trezor Bridge

• Users can sign transaction from the bridge using Trezor

MS1: Ledger Support

• Data connection via Ledger Live

• Users can sign transaction from the bridge using Ledger

Delivery

The plan tracks delivery of each Bounty against work items - e.g. Pull Requests. Each PR links to an issue in the Repo which describes the work item. An overview is mapped in this table of Pull Requests to Bounty.

Description	Item	Bounty	days
Move Mongo DB to Cloud hosting	#21	872/MS1	3
Simplify container management	#24 #104	872/MS1	2
Migrate Web Hosting from GCP to Cloudflare	#109	872/MS1	2.5
Commitment Transaction	#105	877/MS1	8

Appendix 1: Previous Phases

Work delivered to bootstrap the sBTC Bridge Web and API components prior to kickoff of the Foundation Bounties.

Phase I: Pegging In/Out

Bootstrap the project and provide basic screens for user to build Bitcoin wrap/unwrap request transactions according to the spec SIP-021

1. Bootstrap application, bitcoinjs and node polyfills working

2. Deployment - github pages

3. Gating - access control via Hiro Wallet

4. Views

   • peg in transaction builder

   • peg out transaction builder

   • transaction signing

5. Integrations

   • Electrum wallet compatible transactions for sign / broadcast

   • sbtc-alpha contract via Micro Stacks

   • Bitcoin explorer integration via mempool.space and api.blockcypher.com

6. Caching layer via reactive wrapper around local browser storage

7. Unit tests - vitest

Time: 10 days

Delivered on 3rd Feb

Phase II: Transaction History

1. Views

   • display transactions

   • filter transactions

2. Integrations to read / parse

   • mint transactions

   • burn transactions

   • fulfillment transactions

3. Local caching to speed up queries where possible

4. Unit and e2e tests including creation of test data and stubs.

Time: 9 days

Delivery by 24th Feb

Phase III: SBTC Data Indexer Rest API

This component is a stateless, open API whose primary purpose is to make the sbtc-bridge application fast. It will achieve this by pre-reading and aggregating SBTC related blockchain and smart contract state into a Mongo database.

Secondary purpose to provide additional metrics and business intelligence for SBTC.

This component can be readily extended via Websocket API.

1. API application deployed via docker, provides;

   • access to bitcoin rpc and stacks node rpc

   • reads/caches contract event data on schedule

   • NodeJS / Typescript application

2. Mongodb deployed via docker

3. Deployment on GCP k8 Cluster

4. Features

• Read and index sbtc peg in txids

• Read and index sbtc peg out txids

• Rest API calls to return these txids

The estimate here is for a working prototype deployed on testnet implementing the minimal feature set above.

Time: 12 days

Delivery: 17/31

Phase IV: OP_DROP Tx Format

OP_DROP is a format that may help to broaden the user base for SBTC.

1. OP_DROP Wrap

2. OP_DROP Unwrap

3. Decode OP_DROP transactions to retrieve stacks signer.

Time: 5 days

Delivery: 3/17