Child hotkey progressive tax system

[keithtensor]

Is your feature request related to a problem? Please describe.

With the release of child hotkey staking, several big issues have arisen:

• CHK performs too well, which disincentivizes validators with real infra
• CHK is not reducing validator centralization due to its runaway APY
• CHK may be incentivizing validator sybil attacks
• CHK isn't really being effective as a security improvement tool
• CHK has been used in conjunction with malicious validating practices on new subnets as a means to further enrich undesirable actions

Describe the solution you'd like

Progressive Tax System
To address these issues, we suggest creating a "progressive tax system" that looks like the following:
-- Base (fixed) 4% CHK Fee (2% Recycle, 2% take) as long as the CHK target vali's weight is <37% on the subnet, then we increase the Recycle side by 1% (Recycle side only) per 1% of weight until the chk target vali's subnet weight hits 50%. The Recycle increase is linear until 50% weight, at which point it swaps to 18% Recycle/0% take.

Visually, this looks like the following:
— <37% Weight = 4% CHK Fee (2% Take, 2% Recycle)
— 37% Weight = 5% CHK Fee (2% Take, 3% Recycle)
— 38% Weight = 6% CHK Fee (2% Take, 4% Recycle)
— 39% Weight = 7% CHK Fee (2% Take, 5% Recycle)
— 40% Weight = 8% CHK Fee (2% Take, 6% Recycle)
— 41% Weight = 9% CHK Fee (2% Take, 7% Recycle)
— 42% Weight = 10% CHK Fee (2% Take, 8% Recycle)
— 43% Weight = 11% CHK Fee (2% Take, 9% Recycle)
— 44% Weight = 12% CHK Fee (2% Take, 10% Recycle)
— 45% Weight = 13% CHK Fee (2% Take, 11% Recycle)
— 46% Weight = 14% CHK Fee (2% Take, 12% Recycle)
— 47% Weight = 15% CHK Fee (2% Take, 13% Recycle)
— 48% Weight = 16% CHK Fee (2% Take, 14% Recycle)
— 49% Weight = 17% CHK Fee (2% Take, 15% Recycle)
— 50% Weight = 18% CHK Fee (2% Take, 16% Recycle)
— Over 50% Weight = 18% CHK Fee (0% Take, 18% Recycle)

Boost APY Cap:

• The boost to APY caused by the CHK Take component is capped at +20% of the gross underlying APY.
• For example, if validator was at 20% gross APY with a 10% vali take (18% staker apy, 2% vali apy) prior to any CHKing, and the max boost that chk take can generate was +20% relative increase, then the most it could add is an extra +4% (total gross: 24% gross apy, which is 21.6% apy for stakers and 2.4% apy for the vali. Any would-be excess APY is Recycleed.

CHK for Security:

• CHK fees between hotkeys owned by the same cold key are always 0%
  Anti-Sybil:
• Only 1 hotkey per coldkey per subnet can have vpermit

Describe alternatives you've considered

We had previously considered two alternatives, both of which caused more problems than they solved.

• The first was a minimum CHK fee of 9% (half take, half recycle), however this did not help resolve centralisation, provided too much upside for sybil, and created too many edge cases that were exploitable by already recognised undesirable validation practices.
• The second alternative was to scale the progressive tax system based on how much each validator was delegating to a single validator (ie. highest tax rate if CHKing to a single validator, lower tax if CHKing to multiple validators), however this created too much sybil incentive, and was less effective at avoiding centralisation as directly targeting the CHK-target validator weight.
  Ultimately, the combination of factors in the described solution helped resolve the most existing issues while introducing the least number of new problems.

Additional context

No response

[camfairchild]

CHK fees between hotkeys owned by the same cold key are always 0%

This part is already implemented

[ppolewicz]

There is no consensus on whether the progressive tax is the right solution because it incentivizes usage of multiple uids to avoid taxes.

It's also blocked until we can effectively deal with weight copiers (any CHK tax will increase WC quite a lot)