Seeing a lot of confusion online about Tether’s USDT coming to bitcoin/lightning via taproot assets and compliance. Questions people seem to have:
- Tether doesn’t support anything they can’t unilaterally freeze funds on - how can you freeze funds on taproot assets?
- Taproot assets is fully permissionless, and works on private blockchains like liquid. How can there be compliance with the Travel Rule?
- How does Tether comply with OFAC compliance if they support a fully permissionless network?
These confusions hinge on a lack of understanding of how taproot assets work. People seem to think it’s a lightning specific protocol, but it isn’t. It’s actually a layer 1 protocol that works with lightning.
So let’s drop lightning for a bit, and talk about taproot assets and universes, the missing piece left out of these conversations.
Understanding Universes in Taproot Assets
Taproot assets used to be called Taro before Lightning Labs got sued into changing the name. Taro was a clever acronym that explains how taproot assets works much better than the current name.
Taproot Asset Representation Overlay. It’s an overlay on top of a bitcoin transaction, where you only store proofs in taproot leaves. The “overlay” data is stored in what’s called a universe, and different assets are stored in different universes. A “universe” is a thing you can run like a blockchain but doesn’t work like one. It contains data like existing users and holders of an asset. You can spin up a public universe, run a local one, clone/sync an existing public universe very much like a blockchain.
Critically, it isn’t one - it’s much more like a git repository.
But universes are just a repository of proofs and proof owners. Very little security exists, because they are reliant on bitcoin for fund transfers.
A bitcoin transaction transfers taproot assets, and the sender publishes proofs to the asset universe to finalize the transaction. The recipient won’t be able to validate the transaction until the universe registers the transaction.
Maybe you can see where I’m going with this from a compliance standpoint.
Compliance Mechanisms in Taproot Assets
Crucially, the bitcoin tx can’t be stopped (because bitcoin), but the centralized universe can be forced not to register certain transfers. This is the angle from which compliance can be enforced.
Simply put, it’s possible for the bitcoin tx to be confirmed without the universe recognizing the fund movement. This doesn’t result in a “fund freeze” like some may have experienced, but rather a disavowing of funds.
It’s possible to clone a universe and run alternates that someone can publish a disavowed transaction to - although this shouldn’t work. Since the value of USDT is dependent on tether’s ability to convert to USD, if tether says “for this specific asset tx, we will not convert back to USD for whichever reason” then anyone who accepts the tx now potentially has an asset that has no value. So - no one ought to accept the asset. Even though the asset still exists, can move unilaterally, and without permission.
In this sense USDT is permissionless in definition because no one can freeze it. But no one can stop tether from disavowing it.
This behavior extends beyond compliance however. You can put any arbitrary rules on any asset and if the asset stops following them, have the universe disavow the asset. Sound familiar? Sounds kind of like covenants! But not very cryptographically guaranteed.
Actual Compliance Considerations
There are at least 2 compliance considerations off the top of my head that might apply to universes.
OFAC compliance
- OFAC - Office of Foreign Assets Control
- List of addresses associated with entities the US gov forbids financial relations with
- Terrorists, narcos, countries, regimes, etc
- Basically - Do not send or accept money from these banned entities or face up to 20 years in prison
- The gov really doesn’t mess around with OFAC
Travel Rule Compliance
- Transfers above a threshold (normally $1,000 USD) must have KYC associated
- This is typically done by the receiving institution directly checking in with the sending institution via a TRP (Travel Rule Protocol) like coinbase’s TRUST.
- Universes will likely have to participate, or will be ready to provide relevant info that institutions will use to pipe into TRPs to get KYC, defeating any privacy protocols taproot assets might be built on top of.
Even if a universe doesn’t wish to participate, they’re in what’s called a “Position to know” which is the government’s way of saying “this is a centralized entity I can point a formal gun at, and force compliance.” It’s this specific concern that drives applications to be fully decentralized. Not because decentralization is specifically good and centralization is somehow bad.
It’s a way to get around compliance rules (free money is free of regulatory restrictions).
But really, anyone who is truly concerned about this shouldn’t be using USDT. Tether has long since complied with these restrictions, and many other fully decentralized alternatives have existed for quite some time.
Final Thoughts
USDT isn’t fully permissionless, never has been. Taproot assets may have many usecases, but fundamentally it was built for stablecoins, and this kind of compliance has been a need from day 1.
There are ways to use taproot assets like USDT as a restricted entity, while keeping all the intermediary institutions relatively happy, but I won’t be sharing those hacks in this article. I want Bitcoin to grow, I want lightning to grow, and I want stablecoins to grow.
While I build freedom technologies that my enemies will use, I still hate scammers, terrorists, and I won’t make it easy for them to defraud institutions like my own or my friends.
Need to catch up on Taro/Taproot Assets?
Why do I know so much about this?
I'm ex-lightning labs, and helped review taproot-assets (back when it was called taro). Now I'm working on magnolia, an api driven non-custodial custodian that allows bitcoin businesses to accept fiat without ever touching it. We plan on supporting USDT on lightning because it's pretty cool. Find me on twitter.
