Add "soul-bound" feature to Runes

[HGraphPunks]

As far as I'm aware, the ability to have soul bound assets on bitcoin is cumbersome / non-existent. If a user uses Ordinals for soul-bound, there's no method of stopping that transfer from happening currently. Because runes are all on chain, I think a simple addition to the protocol mint function could suffice as a soul-bound option.

On the etching function, we add "sb": true or "sb": false. Attribute not present would default to false.

When that rune is transferred to a new address from treasury / pre-mint, or minted publicly for the first time, all future transactions are invalid.

This would enable soul-bound, on-chain trackers for rune projects, with the lowest technology lift. Indexing would have to also be enhanced to not process the movement transactions of runes that have sb = true in their etch transaction.

I'm open to other implementations, ideas, or insight to this addition. The main objective is creating a method that's simple, easy, and low-effort to implement, that enables soul-bound functionality of runes.

Casey can even rename "soul-bound" to "bloodmoney-adhesive", or anything else he wants to. The functionality of being impossible to move after distribution is the need.

[casey]

What are some use-cases for soul-bound assets? It would help a lot to understand the use-case of the feature. I'm also interested in specific examples of assets on other chains that use soul-bound assets.

We recently added the ability to add optional metadata to inscriptions, and are thinking of doing the same with runes.

The best way to accomplish this is probably to burn the asset, but also include metadata when burning which indicates a soul-bound holder.

Transferring an inscription already requires an OP_RETURN, and having two OP_RETURNs in a transaction is nonstandard, so we'll have to figure out how to add metadata to a runestone.

Runestones are sequences of integers, so we need to come up with an encoding for bytestrings.

I propose that we use pairs of integers with a specific odd tag. The first integer gives a length, and the second integer is interpreted as a little-endian byte string with that length, trunacted or zero-padded to match the length. One pair can encode 16 bytes, and if you need more than that, you concatenate them together.

Casey can even rename "soul-bound" to "bloodmoney-adhesive", or anything else he wants to. The functionality of being impossible to move after distribution is the need.

I actually like the name soul-bound, so it's safe. 😂

[HGraphPunks]

Heyo! Appreciate the response.

Main reasons for soul-bound assets:

• You can mass airdrop identifiers for holders, on-chain reputation systems, governance, achievements in games, etc.
• Use cases can span from identity, education, and decentralized credit systems.

An example of them on ETH: SBTs in Gitcoin Passport, where they verify a person’s engagement in the ecosystem without letting them sell that verification. It makes the entire concept of "proof of action" non-transferrable.

Optional metadata sounds very cool for runes. If you were to enable metadata and soul-bound, the runes could have visual or documental forms of representation to enhance a lot of referencibility that unlocks more of the potential of soul-bound assets.

I think the idea of burning and adding soul-bound function is interesting, though it makes the process of verification potentially more complex for users and indexers. I think just adding sb: true or excluding it in the etch transaction (like premine attribute, etc) seems light weight and only indexers have to adapt / less complex indexing than a burn mechanism to add the attribute.

[cbspears]

I like the idea of soulbound assets. If anyone's not familiar with the idea, Vitalik wrote the first seminal piece on them ( https://vitalik.eth.limo/general/2022/01/26/soulbound.html). I don't think he presents a compelling case for them in that blog, however. For use cases, it might be attractive to issue runes that cannot be sold, runes as "honorary" gifts (similar to honorary inscriptions), runes which function simply to ensure access in a token-gated community (e.g. an "emeritus" rune), etc. I actually think maybe the best way to accomplish this is to use various timelocking mechanisms, maybe CheckLockTimeVerify? It might be cooler to enshrine it into the protocol itself with some mechanism.