You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am proposing a slight alteration to the release schedule of dtao because of concerns some of the subnet owners have regarding legal responsibilities caused by transferrable dtao subtokens.
The roadmap (or a "deployment plan", if you prefer) of Bittensor can be summarized (from a certain perspective) as follows:
Add of subnet subtokens and uniswap liquidity pools which allow exchange between TAO and subtokens
Switch the subnet emission emitter from root network weights to a mechanism which uses data from liquidity pools
Plan B: Decentralize governance of the subnets
Enable subtokens to be used by smart contracts
Enable subtokens to be atomically directly traded between coldkeys
In plan "A" the subnet governance decentralization happens after the subtokens become transferable/wrappable.
In plan "B" the subnet governance decentralization happens before the subtokens become transferable/wrappable.
The TLDR reason is that in plan "B" the subtokens are not atomically tradeable (or wrappable) until subnet governance is decentralized in order to prevent them from being classified as "crypto-assets" under MICAR, as "transferable securities" under MiFID II or as equivalents in laws of other jurisdictions.
Atomic trades of subnet tokens were not going to be part of the dtao release until 2025-01-22. Adding this feature 15 days before the scheduled vote to approve dtao has (we strongly suspect) changed the legal status and there was no time to figure out if or how to register with the government and what responsibilities will that put on subnet owners. Nobody prepared for this, since the documentation specifically specifies that subtokens will not be transferable (at the time of writing this it still says so).
Atomic transfers and smart contract support would be delayed until subnet governance is decentralized. Decentralized mechanisms generally are out of scope of government regulations. This shouldn't take long because in bittensor subnet owners can't really do much as it is.
I asked subnet owners if they are ready to comply with the relevant regulations. 12 out of 14 voted 👎. If plan "A" is used, the subnets operating from countries which regulate securities will be limited as to what they can do (until they register and learn how to comply with the law), while the subnets operating from Panama etc (where there is no regulation) will not be restricted.
The specific changes in the code which we'd need are very small:
No atomic transfers from/to subtokens LPs (there is a PR for this already)
Smart contract accounts (and "pure proxy" accounts controlled by them) cannot transfer to subtoken LPs
Sell subtokens on execution of scheduled_coldkey_move to prevent it from being abused to wrap subtokens
To be very clear, both plan “A” and plan “B” will lead to the same result and dtao will be released in virtually the same schedule, but it is my belief that plan “B” is better for The Mission. We must never lose sight of what it is we do here: we build distributed AI together. Having to deal with extra government regulations would slow us down and I think it is worth delaying the atomic transfers a bit to keep the high pace Bittensor is known for.
The text was updated successfully, but these errors were encountered:
I am proposing a slight alteration to the release schedule of dtao because of concerns some of the subnet owners have regarding legal responsibilities caused by transferrable dtao subtokens.
The roadmap (or a "deployment plan", if you prefer) of Bittensor can be summarized (from a certain perspective) as follows:
In plan "A" the subnet governance decentralization happens after the subtokens become transferable/wrappable.
In plan "B" the subnet governance decentralization happens before the subtokens become transferable/wrappable.
The TLDR reason is that in plan "B" the subtokens are not atomically tradeable (or wrappable) until subnet governance is decentralized in order to prevent them from being classified as "crypto-assets" under MICAR, as "transferable securities" under MiFID II or as equivalents in laws of other jurisdictions.
Atomic trades of subnet tokens were not going to be part of the dtao release until 2025-01-22. Adding this feature 15 days before the scheduled vote to approve dtao has (we strongly suspect) changed the legal status and there was no time to figure out if or how to register with the government and what responsibilities will that put on subnet owners. Nobody prepared for this, since the documentation specifically specifies that subtokens will not be transferable (at the time of writing this it still says so).
Atomic transfers and smart contract support would be delayed until subnet governance is decentralized. Decentralized mechanisms generally are out of scope of government regulations. This shouldn't take long because in bittensor subnet owners can't really do much as it is.
I asked subnet owners if they are ready to comply with the relevant regulations. 12 out of 14 voted 👎. If plan "A" is used, the subnets operating from countries which regulate securities will be limited as to what they can do (until they register and learn how to comply with the law), while the subnets operating from Panama etc (where there is no regulation) will not be restricted.
The specific changes in the code which we'd need are very small:
scheduled_coldkey_move
to prevent it from being abused to wrap subtokensTo be very clear, both plan “A” and plan “B” will lead to the same result and dtao will be released in virtually the same schedule, but it is my belief that plan “B” is better for The Mission. We must never lose sight of what it is we do here: we build distributed AI together. Having to deal with extra government regulations would slow us down and I think it is worth delaying the atomic transfers a bit to keep the high pace Bittensor is known for.
The text was updated successfully, but these errors were encountered: