BIT-0015: Subnet Owner Emission Splitting

bits/BIT-0015.md

@@ -0,0 +1,196 @@
+# BIT-0015: Subnet Owner Emission Splitting
+
+- **BIT Number:** 0015
+- **Title:** Subnet Owner Emission Splitting
+- **Author(s):** vstam1
+- **Status:** Draft
+- **Type:** Subtensor
+- **Created:** 11-08-2025
+- **Updated:** 11-08-2025
+- **Requires:** -
+- **Replaces:** -
+
+## Abstract
+
+This proposal introduces a subnet owner key emission splitting system that allows subnet owners to automatically distribute their alpha emissions among multiple sub-owner-keys using proportional shares. Building on the existing childkey delegation framework, this system enables subnet owners to define a list of sub-owner-keys that receive a predetermined portion of the owner's cut from subnet emissions. This enhancement supports collaborative development models, multi-party ownership structures, and separation of ownership control from reward distribution without requiring complex external smart contracts.
+
+## Motivation
+
+Currently, subnet owners receive their alpha rewards as a single, indivisible payment through the `owner_cut` distribution mechanism. This creates several limitations in the Bittensor ecosystem:
+
+1. **Limited Collaboration Models**: Multiple developers, investors, or contributors cannot automatically receive their share of subnet rewards, requiring manual redistribution or complex external arrangements.
+
+2. **Rigid Ownership Structure**: The current system forces all ownership benefits to flow to a single entity, preventing natural business partnerships and investment structures where multiple parties should share in the success.
+
+3. **Separation of Concerns**: Owners cannot easily separate their control functions from reward distribution, limiting possibilities for treasury management, automated distributions, or smart contract integrations.
+
+4. **Manual Distribution Overhead**: Any reward sharing currently requires manual transfers,
+   creating operational burden, operational security (security) issues and potential disputes.
+
+The existing childkey delegation system already provides a proven model for proportional stake distribution that can be adapted for owner rewards, making this enhancement a natural extension of existing Bittensor functionality.
+
+## Specification
+
+### New Storage Items
+
+```rust
+/// Maps netuid to a vector of (proportion, sub_owner_account)
+pub(super) type OwnerEmissionSplits<T: Config> = StorageMap<
+    _,
+    Blake2_128Concat,
+    NetUid,
+    Vec<(u64, T::AccountId)>, // (proportion, sub_owner_coldkey)
+    ValueQuery,
+>;
+
+/// Pending owner emission splits (with cooldown mechanism)
+pub(super) type PendingOwnerEmissionSplits<T: Config> = StorageMap<
+    _,
+    Blake2_128Concat,
+    NetUid,
+    (Vec<(u64, T::AccountId)>, u64), // (splits, cooldown_block)
+    OptionQuery,
+>;
+```
+
+### New Extrinsic
+
+```rust
+pub fn schedule_owner_emission_splits(
+    origin: OriginFor<T>,
+    hotkey: T::AccountId,
+    netuid: NetUid,
+    splits: Vec<(u64, T::AccountId)>,
+) -> DispatchResult
+```
+
+### Modified Owner Cut Distribution
+
+```rust
+// Distribute the owner cut with splits support
+if let Ok(owner_coldkey) = SubnetOwner::<T>::try_get(netuid) {
+    if let Ok(owner_hotkey) = SubnetOwnerHotkey::<T>::try_get(netuid) {
+        let splits = OwnerEmissionSplits::<T>::get(netuid);
+
+        if splits.is_empty() {
+            // Original behavior - all to owner
+            log::debug!(
+                "owner_hotkey: {:?} owner_coldkey: {:?}, owner_cut: {:?}",
+                owner_hotkey,
+                owner_coldkey,
+                owner_cut
+            );
+            let real_owner_cut = Self::increase_stake_for_hotkey_and_coldkey_on_subnet(
+                &owner_hotkey,
+                &owner_coldkey,
+                netuid,
+                owner_cut,
+            );
+
+            // If the subnet is leased, notify the lease logic that owner cut has been distributed.
+            if let Some(lease_id) = SubnetUidToLeaseId::<T>::get(netuid) {
+                Self::distribute_leased_network_dividends(lease_id, real_owner_cut);
+            }
+        } else {
+            // Distribute among splits
+            Self::distribute_owner_cut_with_splits(
+                &owner_hotkey,
+                &owner_coldkey,
+                netuid,
+                owner_cut,
+                splits,
+            );
+        }
+    }
+}
+```
+
+### Execution of Scheduled Changes
+
+Similar to childkey delegation, scheduled emission splits are executed during the epoch process. The system automatically processes pending splits that have passed their cooldown period during the `block_step()` function execution, ensuring splits are activated in a systematic and secure manner without requiring additional user intervention.
+
+### Stake Allocation
+
+All sub-owners stake to the owner hotkey, maintaining the existing staking structure while enabling proportional emission distribution. This ensures compatibility with current validator and consensus mechanisms.
+
+## Rationale
+
+### Design Decision: Building on Childkey System
+
+This proposal leverages the existing childkey delegation framework for several reasons:
+
+1. **Proven Architecture**: The childkey system already handles proportional distributions, validation, and storage patterns that work well for this use case.
+
+2. **Consistent User Experience**: Users familiar with childkey delegation will immediately
+   understand the owner splitting mechanism.
+
+3. **Reusable Components**: Cooldown mechanisms can be adapted from the existing system.
+
+### Alternative Approaches Considered
+
+1. **External Smart Contract Distribution**: While possible, this approach would require subnet
+   owners to implement complex ownership logic in smart contracts and manage the interaction
+   between Subtensor and EVM systems. Additionally, smart contracts would need to be maintained
+   and updated as the Bittensor protocol evolves, creating compatibility risks with the fast-changing
+   system. This also creates a high entry barrier for subnet owners who may not be experts in
+   blockchain development, limiting participation to those with advanced technical skills or
+   requiring expensive external development resources. 
+
+2. **Immediate Effect Changes**: Adding a cooldown period (similar to childkeys) prevents rapid manipulation and provides stability.
+
+### Limitations and Trade-offs
+
+- **Maximum 10 Split Recipients**: Prevents excessive gas costs and storage bloat while supporting most practical use cases. This is more flexible than the childkey system's 5-child limit since each subnet has only one owner compared to multiple validators.
+- **Cooldown Period**: Adds delay but prevents abuse and ensures stability.
+- **No Nested Splits**: Sub-owners cannot further split their portions, keeping the system simple and preventing complex dependency chains.
+- **Leased Subnet Restrictions**: Subnets that are still in a lease period cannot set emission distributions, as the owner key remains under system ownership during the lease. Only after the lease period concludes and full ownership transfers to the beneficiary can emission splitting be configured.
+
+## Backwards Compatibility
+
+This proposal maintains full backwards compatibility:
+
+1. **Default Behavior Unchanged**: Subnets without configured splits continue to operate exactly as before, with all owner emissions flowing to the original owner.
+
+2. **Existing Storage Preserved**: No changes to existing storage items or data structures.
+
+3. **API Compatibility**: All existing RPC calls and queries continue to work unchanged.
+
+4. **Migration**: No migration is required. Existing subnets can optionally adopt the splitting system when ready.
+
+The only change is the addition of new extrinsics and storage, with the owner cut distribution logic enhanced to check for splits before proceeding with the original behavior.
+
+## Open Questions
+
+### Coldkey Swap Behavior
+
+When subnet ownership is transferred via coldkey swap, there are two potential approaches for handling existing emission splits:
+
+1. **Preserve Splits**: Sub-owners remain unchanged and can be altered by the new owner once the swap is completed. This provides continuity but may not reflect the new owner's intentions.
+
+2. **Clear Splits**: Sub-owner splits are automatically removed when the coldkey swap is scheduled, requiring the new owner to explicitly configure new splits. This ensures clean ownership transfer but disrupts existing arrangements.
+
+The implementation choice will need to balance continuity with security and clear ownership transfer expectations.
+
+
+## Security Considerations
+
+### Potential Attack Vectors
+
+1. **Owner Key Compromise**: If an owner's key is compromised, an attacker could redirect all future rewards. This risk exists in the current system and is not increased by this proposal.
+
+
+### Mitigations
+
+1. **Ownership Verification**: Only the verified subnet owner can set splits, using the same verification as other owner operations.
+
+2. **Cooldown Period**: Prevents rapid manipulation and gives time to detect unauthorized changes.
+
+3. **Rate Limiting**: The cooldown mechanism inherently provides rate limiting for changes.
+
+### Impact on Protocol Security
+
+This proposal does not affect the core consensus or economic security of Bittensor. It only modifies how existing owner rewards are distributed, without changing the total amount or the earning mechanism.
+
+## Copyright
+
+This document is licensed under [The Unlicense](https://unlicense.org/).