BIT-0018: Distributed subnet ownership

[l0r1s]

The current Bittensor subnet ownership model creates significant limitations by registering ownership to a single on-chain entity. It offers no native mechanism to distribute ownership rights or rewards, hindering collaborative governance and investor participation.

This PR introduces Distributed Subnet Ownership, a protocol-level solution that allows both economic and governance rights to be fractionalized into on-chain shares. This enables multiple stakeholders to co-own and manage a subnet directly on-chain.

A native implementation provides a standardized, secure, and efficient framework, which is preferable to bespoke smart contract solutions. By integrating this functionality into the protocol, we can strengthen decentralization, improve transparency, and lower coordination costs for subnet operators, contributors, and investors.

[ppolewicz]

Investors and Contributors differ - Investors provide capital while Contributors provide work. It'd be good to distinguish those clearly so that we have the language to talk about it later.

[ppolewicz]

Can't someone time new proposal additions to happen as soon as the previous one is terminated, blocking the ability of the governance body to raise proposals?

This can be potentially addressed by making it so that the closing block pseudo-randomly (based on last valid drand seed?) assigns a preferred voter with share-weighted probability that they are going to be selected to prevent sybil attack where a small shareholder will fracture themselves into a thousand pieces to increase their chances of being selected.

After the previous proposal is terminated, the preferred proposer would have a few blocks during which only they could submit a new proposal.

[vstam1]

Simplified Solution to Governance Attack Prevention
I propose simplifying the solution to this problem. Since proposals already require >10% of voting shares to be created, we can assume an attacker holds <50% of total shares (otherwise, they could simply block any proposal, resulting in complete governance failure).
Mechanism:

Release all voters' shares immediately after proposal execution
Delay the unlock of the proposer's shares for X blocks
This prevents attackers from continuously blocking governance decisions

Attack Limitations:
An attacker could execute at most 4 consecutive proposals by distributing their shares across 4 separate accounts, each holding the minimum 10% threshold required for proposal creation.
Timing Considerations:
The unlock delay must be shorter than the proposal expiry time, ensuring that even delayed proposers can participate in subsequent votes.
This approach maintains voting accessibility while creating a natural cooldown period that prevents malicious actors from monopolizing the governance process.

[ppolewicz]

but it prevents the small holders from triggering a vote. If no holder has at least 10%, no voting can happen.

[ppolewicz]

lets not introduce a new being, but use the subnet superblock (one epoch block in 20 tempos)

[l0r1s]

@ppolewicz I think it has been discussed that there is no concept of "superblock"

[ppolewicz]

Alice signs it with her coldkey

[l0r1s]

@ppolewicz that is implied because almost all extrinsic are signed with coldkey but you think it needs be more explicit?

[ppolewicz]

this document needs to be revised by an AI to remove multiple mentions of the exact same thing, I'm pretty sure this one appears at least 3 times

[ppolewicz]

not in v1. Voting shares percentage only is good enough to start.

[vstam1]

I would even say that MembersProportionMoreThan does not make any sense, as a voter could quite easily sybil attack this vote.

[ppolewicz]

💯

[l0r1s]

@vstam1 @ppolewicz That's right, I will remove it entirely and only have it support % of shares

[ppolewicz]

how about u64?

[l0r1s]

@ppolewicz I don't think using u64 shares split is needed? Do we have a use case for this?

I got the impression that owning at least 0.1% of share is enough for most use case?

[ppolewicz]

Suggested change

	When a proposal reaches the required threshold, it is executed automatically and immediately with the permission of the subnet owner. The execution happens as soon as the threshold is reached, without requiring manual intervention.
	When a proposal reaches the required threshold, it is executed automatically and immediately. The execution happens as soon as the threshold is reached, without requiring manual intervention.

[l0r1s]

@ppolewicz After thinking about it, that could cause issue when a proposal is executed at a time not allowed, for example, an hyperparameter in the last 10 blocks of a tempo. Letting the proposal creator finalizes the proposal avoid this kind of issue. Also avoid us having to schedule the proposal execution that could fails.

[ppolewicz]

I think the division between Governance shares and Profit shares should be emphasized more in the document

[vstam1]

I like the general approach of this BIT. A couple of remarks:

• I think you could directly split the owner share over the share holders during the distribute_dividends_and_incentives function. Shares are already being paid out to 256 UIDs, and with a max of 50 share holders, it would only increase the run logic by 20%.
• I think both the profit shares and the governance shares should go to a coldkey. The profit shares will probably stake from the share holder's coldkey to the owners hotkey as the alpha always needs to be stakes to a hotkey from a coldkey.
• As I also mentioned above, I think you should remove the MembersProportionMoreThan voting strategy as it opens up for sybil attacks where share holder splits it share over multiple accounts.
• I do not completely understand how ShareProportionMoreThan share value is chosen? Can a proposer just chose the share proportion? Or is it based on the call that you try to execute? So for example hyperparam change X needs at least 70% while Y needs only 50%?

[l0r1s]

@vstam1

1. It doesn't change much to have the distribution done in distribute_dividends_and_incentives or in the hook given you still have 50 keys to iterate over to split the owner cut but doing it like the way described make it more flexible and loosely coupled which is a long term goal of splitting the logic to declutter the coinbase.

2. I'm not sure to understand, the alpha distributed needs to go to some hotkey and we don't want to take a default hotkey associated with the coldkey provided?

3. Taken into account, will be removed entirely.

4. That is something to determine but I thought it would allow more flexibility on a per proposal basis depending on what needs to be voted on? Or maybe just having 51% is fine for all?

[vstam1]

@l0r1s

It doesn't change much to have the distribution done in distribute_dividends_and_incentives or in the hook.

I'm all for making it a hook inside another pallet that handles the distribution. What I was thinking about is the concept you describe with DistributedSubnetProfitInterval, looking like you want to have a new interval for distributing owner shares. What I'm wondering is if we cannot just distribute the tokens during the coinbase run. The coinbase calls some hook in this new pallet and this hook distributes the tokens directly instead of having a new interval.

I'm not sure to understand, the alpha distributed needs to go to some hotkey and we don't want to take a default hotkey associated with the coldkey provided?

I would by default stake the distributed tokens from the share holder's coldkey to the subnet owner's hotkey. After distribution they can of course still change the hotkey they stake to using the normal staking operations. You can of course also choose to distribute the tokens to some share holder's hotkey, meaning that the share holders have to supply a hotkey by default. If we go the first route, it means each share holder could just have 1 key, that both owns the profit shares and the governance shares.

Taken into account, will be removed entirely.

👍

That is something to determine but I thought it would allow more flexibility on a per proposal basis depending on what needs to be voted on? Or maybe just having 51% is fine for all?

51% would keep is simple, however having the flexibility to require a different percentage per proposal has its advantages. I would go over the potential governance calls that can be voted on, and look if they have large differences in importance. We might be able to compare it to normal laws vs the constitution. I think for example you need a 2/3 majority in the US to change the constitution, while you need >50% to change normal laws. This is something that can be discussed in the dev calls.

[l0r1s]

@vstam1

I'm all for making it a hook inside another pallet that handles the distribution. What I was thinking about is the concept you describe with DistributedSubnetProfitInterval, looking like you want to have a new interval for distributing owner shares. What I'm wondering is if we cannot just distribute the tokens during the coinbase run. The coinbase calls some hook in this new pallet and this hook distributes the tokens directly instead of having a new interval.

The profits will be accumulated during the coinbase, and there is only 1 write, when you update the PendingAccumulatedProfit, and on the DistributedSubnetProfitInterval (maybe every day or every N hours), you distribute the actual PendingAccumulatedProfit to each shareholders. This is indeed a new interval but it avoids running the distribution too often and bloat the logic run every block. It could even be optimized in the future to use OnIdle if needed.

I would by default stake the distributed tokens from the share holder's coldkey to the subnet owner's hotkey. After distribution they can of course still change the hotkey they stake to using the normal staking operations. You can of course also choose to distribute the tokens to some share holder's hotkey, meaning that the share holders have to supply a hotkey by default. If we go the first route, it means each share holder could just have 1 key, that both owns the profit shares and the governance shares.

I'm not sure to understand the difference between stake the distributed tokens from the share holder's coldkey to the subnet owner's hotkey and they stake to using the normal staking operations. If we distribute the alpha directly to the shareholder hotkey, what prevents them to delegate to the subnet owner hotkey?

Also not sure about the last part where we provide only 1 key, user can provide only hotkey and we could infers the coldkey but allowing both makes it possible to split further if they want, like I want one of my coldkey to handle the governance and I want a hotkey linked to some other coldkey to handle the profits.

51% would keep is simple, however having the flexibility to require a different percentage per proposal has its advantages. I would go over the potential governance calls that can be voted on, and look if they have large differences in importance. We might be able to compare it to normal laws vs the constitution. I think for example you need a 2/3 majority in the US to change the constitution, while you need >50% to change normal laws. This is something that can be discussed in the dev calls.

I feel like this would be kind of cumbersome to manages on our side in the long term by having to update this on every new extrinsic. Having at least 51% gives flexibility, if they want to create proposal with 2/3, that is their business.