Skip to main content

Native Bitcoin Vaults (NBV)

  • Team Name: Hashed Systems (Max Gravitt)
  • Payment Address: bc1qcqzspw5ykm7rv4ph8ahzynvp6jmfdp8hvwevpv6xaqq9wt79vlasygls3w (BTC)
  • Level: 2

Overview​

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 nbv 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.

Background​

We believe that Bitcoin is the premiere store of value, and that Bitcoin directly on the native chain is more valuable and easier to use than any wrapped tokens, peg tokens, or synthetics.

Bitcoin is the premiere store of value. Handling Bitcoin on its native chain via partially-signed-bitcoin-transactions (PSBTs) and cold storage wallets is by far the most secure and easiest to use manner.

NBV allows for Substrate-based governance to establish which accounts should be responsible for a specific vault (usually via election), and provides those treasurers 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.

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

NBV Use Case Diagram​

Native Bitcoin Vaults Use Cases Diagram

Project Details​

User Identity Setup​

To get started, each account will need at least one Extended Public Key (xpub) docs.rs. This can be used to calculate a nearly infinite number of receiving addresses, and it can be combined with other xpubs to generate BIP-0174 compatible PSBT multisig wallets.

User calls set_xpub to specify their xpub:

polkadot-js-api --ws wss://n1.hashed.systems tx.nbvStorage.setXPub '{
    {
       "Raw": "[dca67f77/84/1/0/0]tpubDEQ2wZuuDfizT2aThADBimVaDwWb3aK6WtA3VRMoCDog2Gg3PtDa1gHWhZYEiGba5XA2D2opry9MxZVVjgAaGM8MCnvW6kt6v5AURRyLHPh/*"
    }
}' --seed "bargain album current caught tragic slab identify squirrel embark black drip imitate"

Treasurer Selection​

A treasurer is any account that is a participant on an NBV wallet.

A set of treasurers may be decided in any manner. In our experience, there is typically a set selected at genesis of a community, and then that set changes based on elections o the application and approval of a badge or assignment. The set is a BoundedVec of AccountIDs.

Once decided, the set_signers extrinsics is called with this list of accounts as well as the threshold for the number of signers required to approve a bitcoin transaction.

pub fn set_signers(
  origin: OriginFor<T>,
  signers: BoundedVec<AccountID, usize>,
  threshold: u8) -> DispatchResultWithPostInfo {
  // ...
}

Bitcoin Output Descriptors​

This extrinsic persists enough information to generate the multisig wallet's output descriptor. "Output script descriptors are strings that contain all the information necessary to allow a wallet or other program to track payments made to or spent from a particular script or set of related scripts (i.e. an address or a set of related addresses such as in an HD wallet)" [1].

Output descriptors are supported in Bitcoin Core and are quickly becoming the preferred portable format for wallets. In particular, they are the cornerstone of the Bitcoin Development Kit, a well-maintained Rust library and "the simplest way to integrate Bitcoin wallet features into any application" [2].

Here's an output descriptor for a 3 of 5 multisig wallet:

wsh(multi(3,tpubDEQ2wZuuDfizYa8Vxo92Jz96nDhwwHTczsHTpSt4hnSRaWhQbj8Nrb46QitDpeEABLQSHPSyxdCn8gUDE6uZ2TWPLreLzvhFZLPPyrSizBz/1/0/*,
  tpubDEQ2wZuuDfizZR2aCmD5gpHJtsXET1zpYmR1JA9nMp4EWDcnnC957ekfaysjF4T8hSNJj98fEcUocnhds3Gwot8G145AZDsYjpwuJto4DFQ/0/0/*,
  tpubDEQ2wZuuDfizUWke1ZhreeVoybZiYiRept7ifSNSefbmPEM7yeNkbH1Kx4uMBnCtq2bB95oT1YX1ZAFuTfA1LetiTTrYuP6ShXsUUv6Bd8Q/0/0/*,
  tpubDEQ2wZuuDfizT2aThADBimVaDwWb3aK6WtA3VRMoCDog2Gg3PtDa1gHWhZYEiGba5XA2D2opry9MxZVVjgAaGM8MCnvW6kt6v5AURRyLHPh/0/0/*,
  tpubDEQ2wZuuDfizdnKYinDkouHHo7CeDdgScMfPYLMR8cnq3PYj85SccVnXa2Yt9HfVXq1riCkDLQG7R5YwcR8HY5z79M5b6zNsX4pZ12ngu1i/0/0/*))

Generate Receiving Addresses​

A common attack with Bitcoin is a man-in-the-middle attack where an attacker's address is injected unbeknowst to the sender, who inadvertently sends coins to the attacker. NBV will generate verifiable single-use receiving addresses to provide to donors and investors that contribute send Bitcoin.

Using BDK-CLI, the addresses are generated as follows:

$ bdk-cli wallet --descriptor 'wsh(multi(3,tpubDEQ2wZuuDfizYa8Vxo92Jz96nDhwwHTczsHTpSt4hnSRaWhQbj8Nrb46QitDpeEABLQSHPSyxdCn8gUDE6uZ2TWPLreLzvhFZLPPyrSizBz/1/0/*,
  tpubDEQ2wZuuDfizZR2aCmD5gpHJtsXET1zpYmR1JA9nMp4EWDcnnC957ekfaysjF4T8hSNJj98fEcUocnhds3Gwot8G145AZDsYjpwuJto4DFQ/0/0/*,
  tpubDEQ2wZuuDfizUWke1ZhreeVoybZiYiRept7ifSNSefbmPEM7yeNkbH1Kx4uMBnCtq2bB95oT1YX1ZAFuTfA1LetiTTrYuP6ShXsUUv6Bd8Q/0/0/*,
  tpubDEQ2wZuuDfizT2aThADBimVaDwWb3aK6WtA3VRMoCDog2Gg3PtDa1gHWhZYEiGba5XA2D2opry9MxZVVjgAaGM8MCnvW6kt6v5AURRyLHPh/0/0/*,
  tpubDEQ2wZuuDfizdnKYinDkouHHo7CeDdgScMfPYLMR8cnq3PYj85SccVnXa2Yt9HfVXq1riCkDLQG7R5YwcR8HY5z79M5b6zNsX4pZ12ngu1i/0/0/*))' get_new_address
{
  "address": "tb1q433j97374mss5na5eu7f0ja29rx2fsretgs2h4f5p886x5mqg65q74fhzv"
}

To calculate the next address, the index of the BIP-32 derivation is incremented. This index is saved in the pallet state as u32. When NBV detects that a UTXO is received on an address, the index on-chain is incremented.

Proposing a Transaction​

Any user can propose a Bitcoin transaction. The required input is simply the destination address and the amount to send. This unsigned transaction is saved and the eligible signers see this proposal in their queue for review.

pub fn propose(
  origin: OriginFor<T>,
  recipient: bitcoin::util::address::Address,
  sats: u32,
  memo: T::Memo) -> DispatchResultWithPostInfo {
    // ...
}

Within the user interface, the list of proposed and partially signed transactions will show in a table along with an identifier of which accounts have and have not signed the transaction.

Signatures​

When a treasurer requests to sign a PSBT, a QR code with the PSBT content is shown on screen. The user scans the QR code with BlueWallet, an open source React Native mobile application.

image

After signing the PSBT, the user can click 'Share', which generates a QR code with the signed payload. The user will be able to scan this back into the NBV web application, where it is saved temporarily in storage until enough treasurers have signed.

The unsigned transaction must be signed by a threshold number of signers, and then it will be finalized and broadcast by the off-chain worker.

Tech Stack​

License​

Unless W3F has an opinion or there are other factors to consider with the dependencies, all deliverables will be licensed MIT.

Bitcoin Rust Libraries​

The pallet will be built with the premiere Bitcoin Rust libraries, including:

no_std Support and Contingency​

Of course, the pallet requires compilation to WASM, which means support for no_std. This requires changes to all three of the above libraries, each of which already has open Github issues.

The heavy lifting for this has mostly been completed, but the libraries with the updates have not been released yet. Our first preference is to use them directly with their latest release.

However, if they are not released in time, we will either a) build a custom library, or b) host native Rust services as an off-chain worker.

Both of these are temporary solutions, and we would later revert to mainline when the release is available.

Bitcoin Dev Kit​

BDK has an extensible structure that, according to their website, "developers can implement customized logic for blockchain backends, databases, signers, coin selection, and more, without having to fork and modify th[e] library."

Our preference is that we will be able to do just this by supporting a Substrate data store as a bdk::database::Database. However, we can also use BDK in a stateless manner and manage the information outside of BDK storage.

Bitcoin Signer: BlueWallet​

The strategy is to use well-adopted standards such as output descriptors to be compatible with multiple signers. For the initial phases, we will use BlueWallet, an open source React native Bitcoin wallet.

BlueWallet communicates with our NBV web application using QR codes. Users can import the overall multisignature vault from NBV into BlueWallet to sign transactions and view transaction history. After a user signs a PSBT, they can click 'Share', which produces a QR code, and that can be scanned back into NBV where it will be combined with other PSBTs, finalized, and broadcast.

Native Bitcoin Vault (NBV) Web Client​

The NBV client will be developed in Vuejs or React, and will support the polkadot{js} browser plugin. The user will be able to create, edit, or remove xpubs from the Identity pallet using the NBV client.

It will also support:

  • creating and deleting Bitcoin vaults,
  • creating multisig Bitcoin proposals,
  • viewing a list of open proposals,
  • viewing past approved and denied proposals,
  • viewing the details of transactions, and
  • opening them in the signer.

The client will support create, edit, and delete of Bitcoin vaults. Users will be able to add accounts as a list of treasurers and save it. Our primary use case is for treasurers to be decided via on-chain governance, but manual direct creation will be useful for simple usage and also small businesses, non-profits, etc.

Scoping​

In Scope of this Proposal​

  • Features - Support for all of the use cases shown in the use case diagram above.
  • Pallet(s) - At least one pallet delivered. As much as reasonable, we will model the prebuilt multisig pallet to align with comfortable patterns.
  • Node - At least one node, as a reference implementation with the minimum feature set enabled.
  • Hosted Instance - We will host a testnet and mainnet instance of the reference implementation, including Bitcoin Core nodes.
  • Documentation
    • we will author and host an mdBook with an explanation of the mechanics of NBV
    • book will include detailed documentation on all user-facing features
    • source code will be documented in the same manner as Parity's prebuilt pallets
    • video explainer and demonstration of all features will be recorded and published
  • Support - we will provide user and developer support for no less than 2 years
  • Maintenance - we will maintain the components on the mainline releases of Substrate for no less than 2 years

Out of Scope​

  • Other Coins - Substrate is rich with governance and multisig features for native tokens, and we are not attempting to improve upon that per se. The only token supported within the Treasury itself is Bitcoin.
  • See Future Road Map - see below for details about the post-release road map.

Ecosystem Fit​

We believe that Bitcoin is the premiere store of value. Bitcoin handled directly on the native chain is more valuable, safer, and easier to use than any wrapped tokens, peg tokens, or synthetics.

The initial target audience for NBV is Hashed Chain, a multi-tenant, standalone Substrate blockchain for hosting and operating small businesses or DAOs. I also believe that it will be a useful utility on many chains in many scenarios. These opinions are based on our hands-on and pragmatic experience over the last several years.

Our team has a proven track record with building software for small businesses and DAOs. We built the Hypha DAO platform (based on EOSIO and operating on Telos). That platform has well built treasury, accounting, and financial tools for small business. It has been used for over two years, including support for recurring, payroll-type proposals, multichain redemption processes, and much more. It uses a native USD-peg token paid to members for weekly salary, and the holder may redeem it for Bitcoin or ETH as they desire.

We also built Hancock Sovereign Organizations, which is a stack similar to Hypha that "enables organizations and teams to operate with autonomy, freedom, and transparency." You can find documentation on some of Hancock's features here.

Our direct experience, which has been hands-on and highly pragmatic, is what informs the utility and product-market fit for NBV.

Interlay BTC​

The only Bitcoin related project in the Polkadot/Substrate/Kusama landscape that I am familiar with is Interlay. It uses a peg token that is held in escrow. This is super useful for Defi applications of course. However, small businesses or DAOs that primarily desire to HODL Bitcoin in treasury are more comfortable with native Bitcoin. In the future, we may find synergies that combine functionalities of the same code base or chains.

Team 👥​

We are Hashed, an open source blockchain development team. We currently have nine team members, seen below from our 2021 in-person summit.

Project Team members​

  • Max Gravitt - Architect/Lead and Proposal Author
  • Sebastian Montero - Blockchain Engineer
  • Abel Yanez - Blockchain Engineer
  • Alejandro Garcia - UI Developer
  • Other team members as needed

Among the other Substrate experience, Max and Sebastian have also completed the Substrate Runtime Developer Academy.

Contact​

  • Registered Address: 30 N Gould St, Ste R, Sheridan, WY 82801
  • Registered Legal Entity: Hashed Systems DAO LLC

Team's Experience​

We have significant experience developing and operating blockchain applications across the industry, including in the public domain, enterprise, and banking.

Prior Grant on Telos Network​

In 2019, we were rewarded a grant to develop a federated profile system for Telos. You can find that proposal here and the relevant repos are Telos Account Creator Services and People and Profiles Project.

In a nutshell, it supports free account setup after SMS verification, authentication to off-chain OAuth systems via blockchain signing, saving of profile data on/off chain, and secret, bi-directional masked communication over SMS and email.

These tools have been operational continuously since release and have supported thousands of users.

Node Operations​

Max is enrolled in Kusama Thousand Validators. The validator has been chilling for quite some time but is coming back online soon.

Max is the founder of Telos Kitchen, currently the 6th most-voted-for team on the network. Telos is delegated proof of stake. Unlike Polkadot/Kusama, Telos prohibits payment of block rewards back to voters, ensuring it is based wholly on community contributions, node performance, and reputation. So, in essence, these votes are the community's attestation that we are a trustworthy and high performing team adding long term value to the networks we participate in.

Research publications​

Max has co-authored a number of papers, including

Team Code Repos​

Published Blockchain Videos​

These videos were recorded by Max and feature projects that we developed.

Development Roadmap 🔩​

Overview​

  • Total Estimated Duration: 3 months
  • Full-Time Equivalent (FTE): 2 FTE (across 4 developers)
  • Total Costs: 43,200 USD

Languages​

  • All pallets and any associated backend services (e.g. bdk_services) will be developed in Rust.
  • Primary web app (Native Bitcoin Vault Manager) will be in Vuejs

Milestone 1 — Prepare Dependencies and Build Vault Configuration​

  • Estimated duration: 6 weeks
  • FTE: 2
  • Costs: 21,600 USD (project will have 4 developers contributing, blended rate of $50/hour)
NumberDeliverableSpecification
0a.LicenseMIT
0b.DocumentationWe will provide both inline documentation of the code, an mdBook with an explanation of the mechanics of NBV, detailed explainers for all user-facing features.
0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
0e.VideoWe will record and publish a video explainer and demonstration of all features in English and Spanish.
1.BDK IntegrationPreferably, we will build a no_std version of BDK, and if not, we will create an off-chain worker for all pertinent functions
2.Account xpubUser can set an xpub on their account in the NBV pallet
3.Output DescriptorsGenerate output descriptor (vault/wallet) based on the selected Vault Signers
4.Generate Receiving AddressesNBV will be able to generate receiving addresses for a vault
5.List and View vaultsNBV client will show a list of treasuries/vault, their labels, and the eligible signers
6.Pass to SignerScan a treasury/vault from NBV into BlueWallet

The following Extrinsics or RPC calls, with relevant UI functions, will be included in milestone #1.

  • set_xpub - we may need to create a wrapper Extrinsic to appropriately fit the data into the Identity pallet
  • create_vault - takes a set or BoundedVec of accounts as well as the signature threshold. (we may also have a T::ClassId to categorize vaults 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 will be visible in the Vault Manager client and provides a link to the Signer app. This generates a proposal_id.
  • generate_new_address - receives vault_id, reads the vault descriptor, calculates last_used_address to check for UTXO. If one exists, increment the derivation_index and return a new address based on that. If the last address is still empty, simply return that one again (this will likely also have a flag to force incrementing the index). This behavior is similar to many wallets work.

Milestone 2 — Signing, Broadcasting and a Hosted Release​

  • Estimated Duration: 6 weeks
  • FTE: 2
  • Costs: 21,600 USD (project will have 4 developers contributing, blended rate of $50/hour)
NumberDeliverableSpecification
0a.LicenseMIT
0b.DocumentationWe will provide both inline documentation of the code, an mdBook with an explanation of the mechanics of NBV, detailed explainers for all user-facing features.
0c.Testing GuideCore functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0d.DockerWe will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.
0e.Video & ArticleWe will author an article, as well as record and publish an updated video explainer and demonstration of all features in English and Spanish.
1.PSBT SigningUsers will be able to sign transactions using our customized signer (Spectre Desktop) and save the output to the Substrate node.
2.Transaction BroadcastWhen the threshold of signatures has been reached, the node will broadcast the transaction to the Bitcoin network (via integrated Bitcoin core node)
4.Hosted InstancesWe will host a testnet and mainnet instance of the full solution (as a standalone Substrate chain) for no less than 2 years
5.EZ-TryThe hosted instances will have EZ-Try, which is our method of ensuring any level user can easily go to the app with no prerequisites and try it. (e.g. auto-faucet, auto-generate xpubs)
6.Support & MaintenanceWe will provide user support and maintain compatibility with Substrate releases for no less than 2 years

The following Extrinsics or RPC calls, with relevant UI functions, will be included in milestone #2.

  • save_psbt - receives proposal_id and the PSBT payload. 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 - recieves the proposal_id - PSBTs require a finalization step before broadcast.
  • broadcast - receives the proposal_id - this will broadcast the transaction to the in-built or configured Bitcoin Core node.
  • save_finalize_broadcast - the save_psbt function will also accept an optional flag for convenience so that if the node detects that the threshold is met with the provided approval, then the node should finalize and broadcast it.
  • erase_vault - receives vault_id - remove vault and any open proposals or PSBTs from storage
  • cancel_trx - receives proposal_id - remove any records and PSBTs associated with the transaction

Future Plans​

Immediate Use​

We will immediately use the functionality for a number of DAOs, communities, and businesses that we work with and participate in. This is a critical feature that these teams desire before they are ready to migrate to the Polkadot ecosystem.

Greater Context​

In the greater context, we are working towards a Substrate standalone chain and/or parachain/parathread to be used by small and medium-sized businesses.

Over the last several years, we have established a leading presence in this area of blockchain. For example, last year, we were the first organization to ever tokenize real estate directly on chain in a manner where the token represents FINAL and INSTANT settlement of ownership. This was only possible in Wyoming after the DAO LLC legislation became effective in July 2021. In other words, a token holder can show their asset(s) to the Wyoming Supreme Court and they will protect their property rights. The LLC veil also sheilds DAO members from any personal liability. We attend the legislative sessions in person of the Select Committee for Blockchain and Financial Innovation in Wyoming.

For a detailed legal explanation and step-by-step review of how we achieved this, please see our Digitalness Primer article and how Kitchen Lands DAO LLC Buys 35 Acres in Wyoming. In fact, the Chairperson of the Committee, Senator Chris Rothfuss, tweeted in support of our efforts and legal interpretation.

This project has received much positive feedback and press, including this article from The Information.

Other Small Business/Non-profits Tools​

Along these lines, we have and are building several other critical modules for small businesses, including:

  • Double-entry Accounting, with support for Income Statements, Balance Sheets, etc. (This is hard and complex, but unlocks enormous TAM)
  • Support for Payroll procedures
  • Company governance requirements such as hiring and dividends
  • Tools and reports for legal compliance ONLY IF user organizations require it. (We are NOT legal or compliance wonks by any stretch (nor do we want to be), but these features can be relatively low complexity and open the ecosystem to a lot of new users.)

Feature Roadmap​

  • Coin control - this will add support for selecting which UTXO(s) should be used for a transaction proposal. For now, this will be decided programmatically.
  • Taproot - with the infrastructure in place, there will be many interesting and useful features to support, such as taproot and time locks. However, the plan is to support simple sends with the initial release.
  • Labeling - we may or may not support address and UTXO labeling in the initial release. It is a useful and important feature, but there are a few ways to achieve it and we don't want to get distracted with that yet.
  • Smart Contract - this can also be developed in an Ink! smart contract, and we will likely pursue this in a future release.
  • Sweep Proposal - when the set of Vault Signers changes, usually with each election, the Bitcoin is typically transferred to a new multisig wallet. In our experience, only one or two Vault Signers change in a single election to maintain stability. In the future, NBV will generate an unsigned transaction proposal for this and populate it into the list of active proposals.
  • Mobile Experience - particularly for viewing proposals and signing PSBTs
  • Multiparty Computation - we are reviewing the benefits and requirements to inform if/how we wish to support this
  • Privacy - privacy preserving features, perhaps using functionality from Phala

Additional Information ➕​

How did you hear about the Grants Program? Web3 Foundation Website

Other relevant info:

  • Max is an advisor on the Liberland project, building on Substrate, which I believe may also submit a grant request (not written by me).
  • We have developed and deployed (albeit mostly prebuilt) a 5 node testnet to serve as a shell for this and related business features.
  • We have significant experience with Bitcoin and some with the Bitcoin Dev Kit.
  • Although we have no specific plans as of yet, as we grow our presence and migrate users to Substrate, we may evaluate pursuing a parachain or parathread slot for enhanced security.
  • No other teams besides Hashed (us) have contributed financially or otherwise to this project.

Q&A​

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. As referenced above, there is also interlay/interbtc in the Dotsama ecosystem which seems to be trustless and supports 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, and certainly not with the strength of user experience that non-technical users expect and we intend to build.

Comparison to Remark pallet​

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. For example, within the Hypha DAO, there are team "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 and circles/quests for each user, and they will likely desire different xpubs in their profiles for these scenarios.

We can use the remark pallet, and it would be 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, still needs 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 future step. OP_RETURN compatibility is interesting too. A caution with that is, 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.