BIT-0015: Subnet Owner Emission Splitting

[vstam1]

Summary

This BIT introduces subnet owner emission splitting, allowing subnet owners to automatically distribute their alpha emissions among multiple sub-owners using proportional shares. Building on the proven childkey delegation system, it enables collaborative development models, multi-party ownership structures, and separation of ownership control from reward distribution. The proposal maintains full backwards compatibility with existing subnets while adding new storage and extrinsics for configuring splits with a cooldown mechanism. All sub-owners stake to the owner hotkey, preserving existing validator consensus mechanisms, and scheduled changes are automatically executed during the epoch process. This enhancement removes the need for manual redistribution or complex external smart contracts, reducing operational overhead and enabling more flexible subnet ownership models.

[mcjkula]

I personally don't know if preserving the splits would make sense, given most of the time the coldkey swap is done to transfer the ownership from entity A to entity B.

In the case of the owner actually just swapping from coldkey A to coldkey B, it sounds less like a "problem" for them to rearrange the splits, than possibly a new owner not knowing of the existing splits, having their cut drained by the previous owner. (just an idea/worst case of malicious selling)

[namoray]

Disagree here, as a subnet should be owned by the 'sub-owners', not the owner. IMO this feature is best used to get rid of the concept of a singular owner completely and instead have lots of fractional owners - i.e. decentralised ownership

[mikelpalokaj]

Agreed /w Namoray here.
The whole point of adding an sn owner split is to split up the ownership of the subnet.
If an ownership transfer results in "full" transfer of the ownership the smaller owner shares are basically rendered to Null.

[mcjkula]

If an ownership transfer results in "full" transfer of the ownership the smaller owner shares are basically rendered to Null.

That's what I meant, isn't it? Should the underlying "SN owner" key be CK swapped (resulting in a full-transfer), then the sub-owners/splits should be removed/cleared.

[vstam1]

That's what I meant, isn't it? Should the underlying "SN owner" key be CK swapped (resulting in a full-transfer), then the sub-owners/splits should be removed/cleared.

Depending to whom the CK is swapped, I think he sub-owners should or should no be cleared. If its an internal transfer, clearing the sub-owners doesn't make sense and requires more operation burden. However, they should probably be cleared for a transfer to another party. Then the question is, when should the sub owners be cleared? During the scheduling of the transfer, or during the actual transfer 5 days layer.

[vstam1]

I do agree that by default the sub-owners should be cleared. Maybe we can add an "is_internal" key to the swap_coldkey call that skips this. And clearing should happen during actual transfer.

[namoray]

I think trying to automate some clearing of sub-owners has very little pros and a huge con

If you do that, it removes the ability to have decentralised ownership. They aren't sub owners, and the implementation is then just a small convenience to prevent manual transfers, and I see little reason to implement that. There is still a 'true' owner key and all the ramifications of that.

If you don't have this small convenience, then you have actual true split ownership. Each coldkey are completely independent, and each actually own a fraction of the subnet, which is incredibly useful for legal & operational reasons + removes trust. It actually allows the decentralisation of that ownership.

[mcjkula]

If you do that, it removes the ability to have decentralised ownership. They aren't sub owners, and the implementation is then just a small convenience to prevent manual transfers, and I see little reason to implement that. There is still a 'true' owner key and all the ramifications of that.

I like the idea of having multiple "owners" (not just the emission splitting). Seems like a larger/different proposal though and then there is also this. A question though if there would be no "true" owner in case of multiple ones, how would the emission split be decided for example, just 0.18/n_owners or can any one of them propose to change the split and requires m of n_owners to sign (multi-sig like)? I assume changing hyperparameters would then also be m of n_owners.

[vstam1]

If you don't have this small convenience, then you have actual true split ownership. Each coldkey are completely independent, and each actually own a fraction of the subnet, which is incredibly useful for legal & operational reasons + removes trust. It actually allows the decentralisation of that ownership.

This proposal is mostly for splitting the ownership emissions from the ownership actions. For example you could already make your independent coldkey structure with a multisig, where you need a majority of the multisig signers to change hyperparams. However you would also need all signing for moving alpha around which is not optimal. You can look at the structure in the image below. We have implemented it for SN65, so this is already possible.

What my proposal tries to accomplice is to make the emission distribution simpler when dealing with multiple parties. When you are talking about a small convenience, in the case of the setup above, you would need multiple signatures for each alpha transfer. With this proposal you can make a distribution, and you would only need the signatures if you want to alter the distribution. So it is also a nice building block for building out more complicated voting structures later on, where the multisig is replaced with a full on chain governance system for example. Hope this clarifies the intention of the proposal.

[namoray]

A question though if there would be no "true" owner in case of multiple ones, how would the emission split be decided for example, just 0.18/n_owners or can any one of them propose to change the split and requires m of n_owners to sign (multi-sig like)? I assume changing hyperparameters would then also be m of n_owners.

Emission splits could be as simple as; anyone can give away some or all of their share to another key.

And hyperparams would be X% of emissions required for example.

With what Vstam1 implemented combined with the subnet leasing feature, everything I described may already be achievable.

[camfairchild]

imo, this makes more sense as a pallet creating an account abstraction, forking the multi-sig pallet or something.
Then all the logic can be encapsulated in the pallet and we don't need to have the feature be so coupled with the rest of the runtime.

[vstam1]

@camfairchild

Then all the logic can be encapsulated in the pallet and we don't need to have the feature be so coupled with the rest of the runtime.

You mean abstracting it away from the subtensor pallet, right? New pallet will still be part of the runtime so either direction, it will be coupled with the runtime.

imo, this makes more sense as a pallet creating an account abstraction, forking the multi-sig pallet or something.

I don't think forking the multisig pallet is the right solution for this use case. Subnet owners can already implement multisig ownership structures (Subnet 65 has already taken this approach).
The core value proposition of this BIT is providing a clean separation between ownership actions and emission distribution. This simple initial approach would significantly streamline governance workflows. For instance, I could configure 100% of rewards to flow to a smart contract that handles emission distribution, without needing to implement a comprehensive ownership contract capable of managing all hyperparameters.
Not every governance solution will fit every subnet's needs, so providing subnets with flexible, modular tools might be a better approach than forcing a one-size-fits-all solution. This targeted approach maintains the simplicity of single-owner governance for operational decisions while enabling flexible reward distribution mechanisms that can be tailored to each subnet's specific requirements.

[camfairchild]

You mean abstracting it away from the subtensor pallet, right? New pallet will still be part of the runtime so either direction, it will be coupled with the runtime.

By "not so coupled" I mean it will be less coupled than if we integrate it directly into the same pallet.

We should treat it like a separate module.

I don't think forking the multisig pallet is the right solution for this use case. Subnet owners can already implement multisig ownership structures (Subnet 65 has already taken this approach).
The core value proposition of this BIT is providing a clean separation between ownership actions and emission distribution. This simple initial approach would significantly streamline governance workflows. For instance, I could configure 100% of rewards to flow to a smart contract that handles emission distribution, without needing to implement a comprehensive ownership contract capable of managing all hyperparameters.

I think you're taking me too literally. I mean something similar to the Multisig pallet. Where there is a new account abstraction that can be used.

Possibly you'd create it by specifying where new stake goes and it's distribution, who is the proxy for executing transactions, etc.

Not every governance solution will fit every subnet's needs, so providing subnets with flexible, modular tools might be a better approach than forcing a one-size-fits-all solution. This targeted approach maintains the simplicity of single-owner governance for operational decisions while enabling flexible reward distribution mechanisms that can be tailored to each subnet's specific requirements.

Exactly, it should be modular. I just don't think putting it into the subtensor pallet would be best. Designing it to function on its own will probably work out nicer.

[vstam1]

Exactly, it should be modular. I just don't think putting it into the subtensor pallet would be best. Designing it to function on its own will probably work out nicer.

It's definitely possible to move all the distribution logic to another pallet, where it starts simple and can be built out afterwards. Let's call this pallet pallet_emission_distribution. The pallet_emission_distribution would still need to be tightly coupled to pallet_subtensor, or we need to introduce a trait for all staking operations. However, pallet_subtensor could loosely couple to p_e_d, which could now start with a trait only exposing a single call: distribute_ownership_emissions.

Is this the way you are imagining it? I can alter this BIT to include this as a second solution as well.

[l0r1s]

Reading through the proposal, I see some similarities with how the current leasing system works (only available for new subnet through crowdloan).

To give some context, at the moment leased network can only be registered through a crowdloan. Logic is already in place for proportional owner cut distribution to different shareholders (distribution logic and coinbase hook) every interval of 1000 blocks. Owner cut is accumulated during this time and distributed when the block number modulo this interval is 0 (to avoid running it too often if there is a large number of leased networks given it must go over all leased networks contributors). A shareholder share to the lease is defined by his contribution over the crowdloan cap when the crowdloan is finalized. A lease creator can also defines if he wants to distributes a percent of the owner cut (for example 50% of the actual owner cut). The lease creator can operates the subnet using the proxy created when the lease is created. There is no actual way to transfer your shares to some other coldkey.

Now, to make it possible to have a lease for an actual active subnet, the following needs to be done:

1. Creating a new extrinsic only callable by subnet owner that creates a perpertual lease (no end block), 100% emission share and a unique shareholder holding 100% of the lease shares, the subnet ownership is then transfered to this lease (pallet derived account).

2. Creating a new extrinsic to allow share transfer between shareholders.

3. Create a voting system to allow decentralized decision making (different strategies could be configured like 2/3 of shareholders or >51% of total shares amongst voters or even fixed to a specific key or multisig) using the lease proxy to allow management of the subnet. It can takes inspiration from the collective pallet where there is is this notion of strategies (EnsureProportionAtLeast, EnsureProportionMoreThan...)

1 and 2 can be made relatively easily with the actual implemented logic by extracting reusable parts. The distribution would not change at all (except if I'm missing something?) and 3 would need a well thought and flexible implementation to have different strategies that can be used to govern the subnet operations.

[vstam1]

@l0r1s Thanks for the detailed reply! A couple of notes on the implementation details you described above.

Creating a new extrinsic only callable by subnet owner that creates a perpetual lease (no end block)

Is it possible to make the end block configurable? I could see situations where there are subnet deals where other parties only receive subnet shares for 1-2 years, for example. This is especially the case for subnet incubators that help subnets with initial setup. Making this setting optional would help a lot with flexibility and different lease structures.

Create a voting system to allow decentralized decision making

Would this work alongside the admin proxy access, or would we need to handle all hyperparameter changes based on this voting strategy?

One thing I personally don't like (and I think many subnet owners would agree) is that the alpha share these shareholders receive is automatically sold for TAO. This puts serious downward pressure on the subnet price and would require manual alpha buybacks if these shareholders actually want to hold alpha instead of TAO, opening up MEV opportunities. I'd rather see all shareholders receiving alpha directly staked to the owner's hotkey. Then these shareholders can decide for themselves when they want to sell the alpha. This creates more stability for a subnet, which is preferable from an owner's perspective.

Last question regarding the pallet-derived coldkey/hotkey: Would this mean that an owner wouldn't be able to run a validator on their own netuid, since they can't directly sign set_weights extrinsics as the hotkey is a derived account? It's just a design decision to consider, but I was wondering if you'd already thought about it.

[camfairchild]

The pallet_emission_distribution would still need to be tightly coupled to pallet_subtensor, or we need to introduce a trait for all staking operations.

I don't understand this.
The idea would be that the new stake would flow through to the owners of the stake based on the set-distribution.
We wouldn't need to modify any extrinsics.

If anything, you would specify a voting mechanism in the pallet and use a call-filter, similar to the proxy_pallet, to make sure only some calls are allowed or what quorum they require.

The reason that EVM is so often suggested here is because this sort of voting mechanism and token-holder rights (as you guys all discussed above) are perhaps better dictated on a case-by-case basis, and therefore not generic enough for a pallet (think software vs firmware).

[l0r1s]

Is it possible to make the end block configurable? I could see situations where there are subnet deals where other parties only receive subnet shares for 1-2 years, for example. This is especially the case for subnet incubators that help subnets with initial setup. Making this setting optional would help a lot with flexibility and different lease structures.

Yes, at the moment you can put a None as the end block, in that case, the lease is perpetual or you can set a specific end block and the lease will be active up to this end block and after this the beneficiary (in case of crowdloan) can dispatch the terminate_lease extrinsic and take ownership of the subnet. I can imagine another case where you don't want the lease to be terminated but simply have shareholders with expiration block where their shares is transferred to some other shareholder.

Would this work alongside the admin proxy access, or would we need to handle all hyperparameter changes based on this voting strategy?

The proxy in the case of a new network lease is for the future subnet owner to be able manage the lease while he doesn't have ownership of the subnet but in the case of active network there is probably no "future owner" because we want to keep the decision making voted across shareholders. In that case, the voting abstraction is probably better and having something similar to the "prime member" in the collective pallet where we first try to have a majority of shareholders to agree on a vote or we default to prime member vote.

One thing I personally don't like (and I think many subnet owners would agree) is that the alpha share these shareholders receive is automatically sold for TAO. This puts serious downward pressure on the subnet price and would require manual alpha buybacks if these shareholders actually want to hold alpha instead of TAO, opening up MEV opportunities. I'd rather see all shareholders receiving alpha directly staked to the owner's hotkey. Then these shareholders can decide for themselves when they want to sell the alpha. This creates more stability for a subnet, which is preferable from an owner's perspective.

I think this is something that could be changed to be more flexible, instead of unstaking the alpha that needs to be distributed and transferring tao for the shareholders, we could have a second strategy that transfers stake to the shareholders

Last question regarding the pallet-derived coldkey/hotkey: Would this mean that an owner wouldn't be able to run a validator on their own netuid, since they can't directly sign set_weights extrinsics as the hotkey is a derived account? It's just a design decision to consider, but I was wondering if you'd already thought about it.

I haven't thought about it but I feel like this break the assumption that the ownership of subnet is decentralized, no?

[vstam1]

Thanks @l0r1s!

1. Configurability of lease endtime sounds good.
2. Having something like the collectives pallet with a prime member could be a good solution as voting strategy. I would include the share size of each member and just require >50% vote to pass something, with the prime member being the deciding vote if its exactly 50%.
3. Flexibility in payout sounds good to me as well.
4. Its definitely a design decision to disable validating from owner uid. If the owners could still use the childkey proxying to select validators, it should be fine. Otherwise it becomes a bit cumbersome for shareholders to swap their stake to an actual validator.

You said you would start working/designing this system next week. Are you first writing a BIT and do you need help? I would also suggest to keep this BIT open as well as an alternative solution, so owners can have a vote on which design they prefer.