Multi-Asset Vaults

[joshdoman]

@casey I started working on your transfiguration idea, which would turn an inscription into a rune—and potentially back again—and I started thinking that perhaps we could make it even more flexible while still accomplishing the same goal.

The goal shouldn't just be to turn an inscription into a rune. What we really want is a way for groups of people to have shared ownership over an asset.

This got me thinking: what if we wanted to send an inscription to a rune_id that already exists? Moreover, why limit one rune_id to one inscription? Why couldn't a rune_id own multiple inscriptions?

For that matter, why couldn't a rune_id own any type of asset, including other runes? This would essentially allow any rune_id to function as a vault, capable of owning multiple assets (e.g., art, stocks, memecoins, stablecoins, wrapped bitcoin, etc.), with ownership represented as fractional shares. You could then have vaults that represent an art collection, a mutual fund, or any other type of portfolio.

You'd also likely want a way for rune_id holders to reach consensus on how, where, and if an asset should be sent out of the vault. You could be opinionated and require that all runes be held in one transaction to execute a transfer, but I think vault owners would prefer more flexibility. Here's an example of what that might look like:

1. First, a vault owner creates an edict proposing that one or more assets be sent to a specific UTXO (which could be one they create themselves). The edict includes the recipient’s location (block, tx, output) and details on each inscription and rune balance to be transferred.
2. Next, vault owners sign off by referencing this proposal, with the ability to revoke their approval later.
3. When the final required signature is added, the assets are transferred—provided the UTXO still exists.

I think this could be a really compelling concept, especially if well-run vaults gain traction. As I understand it, similar types of vaults are already popular on other chains. This would essentially function as a virtual multisig, for runes and inscriptions.

It’s obviously ambitious, but with careful design, it could be a powerful new primitive, enabling novel ownership models on Bitcoin. Flexibility around governance would be particularly valuable (e.g., defining thresholds for approval, enforcing response deadlines, setting expiration dates for proposals, etc.).

Would love to get your thoughts! I’d like to nail down exactly what we want to build, at the very least to clarify how an inscription should be sent to a rune_id. If it's sent during an etching, it can only be assigned at the rune’s creation, and a rune would be limited to owning a single inscription. However, if we introduce a tagging mechanism that allows inscriptions to be sent to any rune_id, that would enable transfers both during and after creation—allowing an existing rune to receive 1 or more inscriptions. We can decide later how governance should function to approve outgoing transfers, and how to allow runes to be sent to a rune_id.

[casey]

I think this is compelling, however, this would make knowing the location of inscriptions dependent on indexing runes, which I would like to avoid.

The two protocols are relatively simple because they are independent, but if you could send an inscription to a rune, and then rune holders could somehow control where the inscription transferred, based on number of runes, then to know where the inscription was you would have to know the state of runes.

Currently, after an inscription is created, it purely follows the sat it was created on, with no exceptions. It would be a massive increase in complexity to make exceptions based on the runes protocol.