Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative dtao release schedule (plan "B") #12

Open
ppolewicz opened this issue Feb 5, 2025 · 0 comments
Open

Alternative dtao release schedule (plan "B") #12

ppolewicz opened this issue Feb 5, 2025 · 0 comments

Comments

@ppolewicz
Copy link

ppolewicz commented Feb 5, 2025

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:

  1. Add of subnet subtokens and uniswap liquidity pools which allow exchange between TAO and subtokens
  2. Switch the subnet emission emitter from root network weights to a mechanism which uses data from liquidity pools
  3. Plan B: Decentralize governance of the subnets
  4. Enable subtokens to be used by smart contracts
  5. Enable subtokens to be atomically directly traded between coldkeys
  6. Plan A: Decentralize governance of the subnets
  7. Decentralize governance of the rest of bittensor
  8. Remove authority nodes (allow fully decentralized block creation)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant