An AML-Compliant Freezable Runes Standard

[joshdoman]

This PR attempts to implement a simple freezable runes standard that would be compliant with anti-money laundering (AML) regulations. The ability to freeze and unfreeze balances is the one missing feature that entities subject to AML need in order to issue securities on Bitcoin using the runes token standard.

The case for securities on Bitcoin
More and more public companies are adopting a Bitcoin Treasury strategy. These companies want to raise capital in bitcoin, but their shares can't trade directly against bitcoin in a permissionless way. If, however, their shares could settle on Bitcoin, they could easily raise bitcoin by issuing new shares, and bitcoin holders could easily invest and divest, without moving through fiat rails or doing KYC. These entities, though, are subject to AML and KYC regulations, meaning they must know who they are issuing securities to, and they must have the ability to freeze balances, if subject to a court order. This applies to stablecoin issuers as well.

I acknowledge that the idea of freezable runes runs counter to the core Bitcoin ethos. If someone doesn’t like the idea of owning assets that can be frozen, they shouldn’t own stock in any public company, but that shouldn’t preclude others from doing so. Companies are already subject to the jurisdiction of their host country, and to invest in their stock is to accept that jurisdiction.

If done properly, a feature that enables freezable runes would pose no risk to existing rune holders, as long as all users know which runes can be frozen, old versions of ord recognize freezable rune etchings as cenotaphs, and anyone can clearly see onchain whether a freezable rune is frozen or not.

If that’s all it takes for AML-compliant assets to be issued on Bitcoin, I think an official freezable runes standard is worth exploring. The runes standard is already the most transparent and easy to use token standard on Bitcoin, and I think it should be the standard of choice for AML-compliant assets as well.

Proposed Specification
Described below is an overview of how the implemented freezable runes standard works, but it is not a formal specification:

Etchings may contain a “Freezer” tag, which identifies the name of the rune that can freeze and unfreeze balances.

The “Freezer” tag is an even tag, so older versions of ord would register the etching as a cenotaph.

Runes are frozen and unfrozen by a freeze edict:

struct FreezeEdict {
  rune_id: Option<RuneId>,
  outpoints: Vec<OutPointId>,
}

An edict freezing runes is integer encoded following Freeze tags.
An edict unfreezing runes is integer encoded following Unfreeze tags.

Outpoint IDs are encoded as the block height, the transaction index, and the output of the outpoint to be frozen (or unfrozen).

struct OutPointId {
  block: u64,
  tx: u32,
  output: u32,
}

The rune_id is encoded as None if the first integer following the Freeze or Unfreeze tag is zero. Otherwise, the first two integers encode the Rune ID.

Freeze and unfreeze edicts are processed after input runes are unallocated, but before transfer edicts are processed.

A freeze (or unfreeze) edict may only freeze (or unfreeze) rune_id if the freezer rune, specified when rune_id was etched, is unallocated.

If rune_id is None, a freeze (or unfreeze) edict may freeze (or unfreeze) all runes that are freezable by unallocated runes.

A freeze (or unfreeze) edict freezes (or unfreezes) balances at all outpoints authorized to be frozen (or unfrozen).

A frozen balance is burned if the outpoint is spent while the balance is frozen. This prevents users from trading frozen balances, which would violate AML regulations.

Request for Feedback

I’d appreciate honest feedback on this proposal. Here are a few points I'm especially curious about:

• Technical Details: Are there any potential pitfalls or edge cases in the way freeze/unfreeze edicts are processed? I'd appreciate suggestions on how to simplify or improve the implementation.
• Client Compatibility: Do you see any issues with older clients treating freezable rune etchings as cenotaphs? The goal is to prevent users on older clients from accidentally buying frozen runes.
• Balancing AML Compliance and Bitcoin's Ethos: I know this idea might raise concerns since it introduces a regulatory mechanism into a traditionally permissionless system. How do you feel about the trade-offs here?
• User Risk: The current design burns frozen balances if they're spent. It’s harsh, but it’s simple, and I think it’s necessary to properly comply. In the worst case, if a balance is accidentally frozen and then burned, the issuer could issue a new balance to make the user whole. Do you think this is the right approach, or would you suggest a better one?

I’d be interested to know if the maintainers are open to exploring this type of proposal. The goal is to enable AML-compliant assets without affecting those who prefer non-freezable runes.

Thanks for taking the time to review this - I’m looking forward to your honest feedback!

[cbspears]

I must admit I am somewhat impressed.

[yilakb]

As long as freezability is optional and the default state remains non-freezable, this aligns with Bitcoin’s ethos. Issuers who need compliance can opt in, while others remain unaffected. Seems like a balanced approach.

[casey]

First let me say that just in terms of quality, this PR is awesome. We very
rarely get PRs for large feature which are as well written and have as
comprehensive testing. So kudos for that!

I have a few qualms which I think prevent merging this PR. Some of them are
technical:

• Someone who holds runes could continually watch the mempool for freeze
  transactions, and avoid them by broadcasting a higher-fee transaction that
  moves the runes.

• The fact that frozen rune, when spent, is burned, is problematic. Wallets
  would have to actively watch both the mempool and chain for freeze
  transactions, and lock outputs which were frozen to avoid having them burned.

  Worse, if the wallet has in-mempool transactions which move the runes, and
  then detect a freeze transaction, they have no recourse to avoid those runes
  being burned. (Technically, if the transaction has inputs other than the one
  being frozen they could RBF a conflicting transaction which spends only the
  non-frozen input, but that might not be the case if the transaction only has
  the input with the rune being frozen.

• As an alternative to freezing, an issuer could send runes into a 2-of-2
  multisig, with one key being held by the issuer, and one key being held by
  the owner. This would allow any kind of freezing scheme, wouldn't suffer from
  accidentally burning frozen runes, and wouldn't require dedicated freeze and
  unfreeze transaction. To freeze, the issuer would simply refuse to cosign
  transactions. The 2-of-2 multisig could implemented using MuSig, which
  wouldn't incur any additional overhead compared to a single signature.

• If an admin key is stolen, an attacker could freeze all runes and demand a
  ransom.

• If we add a new even key, a transaction could be made which is considered a
  cenotaph by unupgraded versions of ord and which includes an admin token. If
  a freeze transaction is later issued with that admin token, old versions of
  ord will not see it, since to them, the transaction didn't contain the
  required admin token, but new versions would see it as a valid freeze
  transaction. Old version of ord might then accidentally spend the frozen
  runes, thus burning them.

Some are less technical:

• I don't think that freezing is really in the spirit of runes. Runes attempt
  to be as permissionless as Bitcoin, and I'm not sure that freezing is a good
  fit for the protocol.

• I'm not sure that if we add this, we'll see adoption of runes that wouldn't
  occur otherwise. There hasn't been, as far as I know, any real adoption of
  digital stock issuance, or other things which would require freezing.

• If we add this, some people might use it, for example people issuing
  securities or stablecoins. However, if we don't add it, then those people
  possibly would have gone ahead with their projects anyways, so perhaps not
  giving them the option would be better.

  For example, lets say that at some point in the future, some company wants to
  issue a stablecoin via a rune. If this feature exists, they may make the rune
  freezable. If this feature doesn't exist, they might issue it anyways but
  without the ability to freeze the rune. I would strongly prefer the latter.

• Even if this is opt-in on a per-rune basis, users might not realize that a
  particular rune is freezable. Making it so that no Runes are freezable would
  mean that users don't need to check or think about it, and there's no
  possibility for confusion.

• Some people will probably use this in an irresponsible way, to issue a rune
  with a seemingly low team issuance, but then freeze large portions of the
  circulating supply so they can sell their issuance at a high price.

I think this can't be merged at the moment, so I'm going to close it. Although
thank you for writing such a comprehensive PR.

I think it would be a good idea to open an issue, where this can be discussed
further, although I personally would probably be against the feature, unless
all or most of the issues above are resolved.

In particular, I'm curious if there are any projects which would use this. If
somehow not adding this prevents the formation of issuance of real securities
on Bitcoin, then I would certainly be more in favor.

[joshdoman]

Thanks, @casey! I really appreciate the detailed feedback and the kind words about the PR. You’ve raised some solid points.

I created issue #4213 to continue the discussion and explore potential improvements that could address a few of the technical concerns you raised, like the risk of accidental burning. I’ll also keep this branch updated with master in case the community sees value in merging it—or something like it—in the future.

Thanks again for the thoughtful review and encouragement!