Native Bitcoin Vaults on Substrate

[mgravitt]

Native Bitcoin Vaults - Project Abstract

Please provide a brief description of your project here summarising key points (1-2 paragraphs).

Native Bitcoin Vaults (NBV) is a composable Substrate application for native Bitcoin multisig wallets. NBV does NOT use peg tokens, wrapped tokens, synthetics, or any other cross-chain communication or escrow arrangement.

A vault is a BIP-174 multisignature Bitcoin wallet.

Substrate accounts set their Extended Public Key to their profile on the prebuilt Identity pallet. These accounts, vault signers, may be selected via any mechanism, usually an election.

Using Partially Signed Bitcoin Transactions (PSBT) and output descriptor, NBV facilitates secure receiving address generation and a seamless user experience for managing and executing multisig Bitcoin transactions.

Spectre Desktop (or Caravan) will be forked and customized so that NBV can pass the output descriptor to the signer, where the user has many options of compatible hardware wallets.

NBV allows for Substrate-based governance to establish which accounts should be responsible for a specific vault (usually via election), and provides those accounts the UI for signing Substrate transactions AND multisig Bitcoin transactions.

NBV also generates verifiable Bitcoin receiving addresses to enhance the security and comfort of donors and investors.

A DAO's native token(s) is nearly always secure and trustless. However, small businesses and DAOs also want to hold Bitcoin in treasury. These organizations frequently do not integrate their primary governance chain and Bitcoin, leaving open a significant vulnerability. NBV solves this.

For which grant level are you applying?

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $50,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for > $100k Web3 Foundation Council approval)

Application Checklist

• The application template has been copied, renamed ( project_name.md) and updated.
• A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
• I have read and acknowledged the terms and conditions.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted.

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Thanks a lot for the application. In general, this is really interesting. But I have a few questions also to make sure I understand it correctly.

• What for example is the advantage of your solution compared to having a bitcoin multisig wallet which is controlled by a DAO and signing a remark on substrate that says this multisig account is controlled by the DAO? I guess you could do the same on bitcoin using OP_RETURN.
• What deliveries will actually be implemented as a substrate pallet? Maybe you can add the programming language to each deliverable.
• Do you know of any similar projects on other blockchains?

[mgravitt]

@Noc2 Thanks for the swift response and good questions.

What for example is the advantage of your solution compared to having a bitcoin multisig wallet which is controlled by a DAO and signing a remark on substrate that says this multisig account is controlled by the DAO? I guess you could do the same on bitcoin using OP_RETURN.

This would be possible. At a high level, any state trie and state transition function can be summarized to a hash to sign in a remark. As seen with the RMRK NFT project 👍, a lot of functionality can be driven through that capability. The benefit of using remark is that it is compatible with the relay chains.

The trade-offs, IMHO, are mostly around usability, composability, and designing idiomatically, which I find incredibly useful for re-usability by other developers (particularly in initial releases). As an example, the Identity pallet developer chose to store fields, including the registrars' judgments 🧑‍⚖️ , within the pallet rather than hashing them into a remark field. I tend to think of these as "first class" attributes because the architect decided they were worth the space and mind-share of being stored directly on chain. In a similar pattern, I think the xpubs 🔑 are important enough to persist this way also.

In the future, I expect there to be a quite complex many:many relationship between users, DAOs, and vaults :safe. For example, within the Hypha DAO, we have "circles" or quests (projects) that are allocated a budget to a vault. There may be many circles/quests per DAO. There may also be many DAOs for each user, and they will likely may desire different xpubs in their profiles for these scenarios.

We can use the remark pallet, and I can see it being a valuable 'back-end' for NBV that works on the relay chains. I think there are likely privacy preserving benefits to this as well. But the functionality and logic of generating the output descriptors dynamically along with receiving addresses, the user experience, vault handling, managing the user flow, etc, would still need to be developed.

My suggestion would be that we implement the most vanilla, idiomatic way first, and then add compatibility to relay chain/remark as a next step. OP_RETURN compatibility is also interesting too. A caution with that is that, in my experience, the more complex/obfuscated the persisted state, the harder it is (more tooling/logic) for more casual users to verify and adopt. But there is absolutely value in pursuing these. Let me know what you think, and we would be happy to pivot or add this to the proposal.

What deliveries will actually be implemented as a substrate pallet? Maybe you can add the programming language to each deliverable.

I can add more details on this into the PR. All deliverables will be in Rust except for the web app, which will likely be in Vuejs because we have existing componentry there. Although we are also familiar with React, which we may use because the polkadot.{js} team has done such a great job with their app and tooling in React.

The pallet will have storage for the vault metadata, with a label and likely a hash to an IPFS doc describing the mission or background for that vault. And of course, storage for output descriptors and the most recent index per vault to come up with the accurate derivation paths and receiving addresses.

Extrinsics (minimum)

• create_vault - which takes a set or BoundedVec of accounts as well as the signature threshold. (we may also have a T::ClassId to categorize them similar to the Uniques pallet. 🤔 )
• propose - this receives the vault_id, recipient_address, and amount_in_sats. This constructs an open unsigned transaction saved within the pallet (or saved and hashed in the pallet), which shows in the Vault Manager client and provides a link to the Signer app.
• save_psbt - this may be an RPC call but not an extrinsic. Security here is not really important (only convenience). The intermediary PSBT files will be saved with the node but perhaps on IPFS and hashed on chain. They are all transient by nature and will be erased after they are broadcast or expired, the earlier of the two. PSBT wallets (such as Spectre Desktop/Caravan) typically require users to share the intermediate files through a side channel, like email or chat, so this will be a nice usability upgrade.
• finalize_tx - PSBTs require a finalization step before broadcast.
• broadcast - this will broadcast the transaction to the in-built or configured Bitcoin Core node.
• save_finalize_broadcast - the save_psbt will also accept an optional flag for convenience so that if the node detects that the threshold is met with that approval, then the node should finalize and broadcast it.

We may have issues with no_std support in some of the dependencies. These projects are actively working on it, and 2 of the 3 are done but just waiting on release. We will weigh the pros/cons here once we get into it deeper. The contingency plan is to build the pallet API consistent with the no_std version, and if we don't feel it is ready on our timeline, we would use offchain workers running native Rust. The extrinsics above would effectively be "pass thrus" to those workers. Then, when ready, we can swap these workers for the no_std versions to work directly in WASM.

Do you know of any similar projects on other blockchains?

There are tons and tons of examples of wrapped Bitcoin of course, with various forms of trust, custody, and/or light clients. There is also interlay/interbtc in the Dotsama ecosystem which apparently is trustless and has insurance for lost Bitcoin.

In a few DAOs we built and participate in on Telos, there's an onchain badge for treasurers as they are elected/assigned, which helps, but certainly falls well short of delivering what NBV does.

Besides that, I have not come across any tools or products that offer this capability at all, and certainly not with the strength of user experience that non-technical users expect and we intend to build.

[mgravitt]

Coincidentally, this recently came across my feed. An unfortunate, all to common reminder of the short-comings of wrapped tokens. Even when these problems are fully resolved technically to be flawless, on Polkadot or otherwise, it will be many years before users would be comfortable with them for long term storage.

[Noc2]

Thanks for the very detailed reply. To be honest, I already partly answered the question myself (usability) when I wrote it down, but I thought I’m going to ask it anyway ;-) Could integrate the additional details into the application/milestone deliveries? Especially regarding the pallet.

[Noc2]

Btw. it might take a little bit longer to get necessary approval and feedback, since we are currently on a retreat.

[laboon]

I think using PSBTs in Substrate is a very interesting way to go about using bitcoin in the Polkadot ecosystem, and will be useful to other teams as well. Looking forward to seeing this come to fruition and plan on testing it out myself.

[Noc2]

I’m also happy to go ahead with it.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at grantsPR@web3.foundation and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[mgravitt]

Very excited for this, thank you!

It isn't an announcement, but is it ok if I share a link to this document in the BitcoinDevKit development Discord channel? It will help with context regarding some of my tech questions.

[Noc2]

Very excited for this, thank you!

It isn't an announcement, but is it ok if I share a link to this document in the BitcoinDevKit development Discord channel? It will help with context regarding some of my tech questions.

This should be fine. The grant application and PR is public anyway. Thanks for double checking.