Skip to content

Conversation

open-junius
Copy link
Contributor

Description

According to the #1938, kappa only set by root.

Related Issue(s)

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update
  • Other (please describe):

Breaking Change

If this PR introduces a breaking change, please provide a detailed description of the impact and the migration path for existing applications.

Checklist

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have run cargo fmt and cargo clippy to ensure my code is formatted and linted correctly
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

Screenshots (if applicable)

Please include any relevant screenshots or GIFs that demonstrate the changes made.

Additional Notes

Please provide any additional information or context that may be helpful for reviewers.

@open-junius open-junius self-assigned this Aug 14, 2025
gztensor
gztensor previously approved these changes Aug 14, 2025
@sam0x17
Copy link
Contributor

sam0x17 commented Aug 16, 2025

merge conflict

@surcyf123
Copy link

Can we please not merge this? Kappa is good for subnet owners to be able to set for commodity-based subnets. Without being able to set a low kappa, you can't make a subnet where miners can only provide a commodity to a single validator. They should have the freedom to do this.

For example. on subnet 51 I want a low kappa so that miners can provide just 1 GPU to 1 validator and still get incentive. This is impossible if you force kappa to .5. There must be a kappa stake dominating validator in order for a miner that should get paid to be able to get paid. I don't want that and I'm sure other subnet owners don't want that either. Subnet owners should have more power, not less, in order to get their commodity to be economically viable and productionizable.

If we make this change and stop allowing miners to get paid for providing commodities to less than kappa stake weighted validators, it creates a hole in the system.

#STOPTAKINGAWAYSUBNETOWNERRIGHTS

@surcyf123
Copy link

Can we please stop taking away subnet owner rights? This is a bad idea to merge for many reasons. If this is merged, this destroys the ability for subnet owners and miners to have more freedom about how they should allocate, and get paid, for the commodities they provide to the validators.

Why do we want to do this? Rhef wants to do this because he thinks that if he keeps taking away more and more rights from subnet owners, he will eventually be able to stop any subnets from scamming. This is an impossible cat and mouse game to win. They will always be able to change hyperparams, change the validator code, create hidden/obfuscated links in their code, bias their own miners by having privledged information, among a myriad of other potential other subnet owner exploits.

So, with this in mind, we should let the ones who are going to scam scam, and let the market do it's job to push those subnets to 0. This was the whole point of dtao. Give subnet owner more control because they know their industry and market best. Rhef does not know the market better than every subnet owner for their own subnets.

For example, on subnet 51, I want miners to be able to provide just 1 GPU to 1 validator, and get paid by that validator. This change would make that impossible to do anymore even though that miner should be getting paid. It creates a system that unfavorably biases kappa stake dominant validators. Which only paves the way for more exploits.

Becase now, the only way for a miner to get paid for providing 1 GPU is if 1 validator has more than kappa stake. That should not be a requirement for a subnet to operate in an economically viable manner. There needs to be more levers that subnet owner can pull in order to bring the market to profitability instead of less.

Taking away subnet owner rights will make it slightly harder to scam, but at the same time, much more difficult to bring a product to profitability. What do you prefer? I prefer being able to make my subnet work.

Please stop this trend of making more params root only or creating restrictions on the ranges that they can set.

#STOPTAKINGAWAYSYBNETOWNERRIGHTS

@surcyf123
Copy link

oh sorry I thought my comment got deleted so I rewrote it, ignore the redundancy please

@open-junius
Copy link
Contributor Author

@ppolewicz pls check comments from @surcyf123 .

@open-junius open-junius added the skip-cargo-audit This PR fails cargo audit but needs to be merged anyway label Aug 19, 2025
Comment on lines +252 to +254
KappaCanSetByOwner::<T>::get(netuid)
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is needed, the code called inside the function is explicit enough?

Comment on lines +811 to +824

/// Set if Kappa can be set by owner
///
/// # Arguments
///
/// * `netuid` - The unique identifier for the subnet.
/// * `can_set` - Whether Kappa can be set by owner.
///
/// # Effects
///
/// * Update the KappaCanSetByOwner storage.
pub fn set_kappa_can_set_by_owner(netuid: NetUid, can_set: bool) {
KappaCanSetByOwner::<T>::insert(netuid, can_set);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is needed, the code called inside the function is explicit enough?

Copy link
Collaborator

@l0r1s l0r1s left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small comments, my other question is why do we want to control if a subnet owner can update kappa or not? isn't kind of restrictive to depends on root to allow that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
skip-cargo-audit This PR fails cargo audit but needs to be merged anyway
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants