Very exciting to see this paper come together, it looks great overall. Can’t wait to see the effects of this in practice.
Wanted to chime in on the delegator unbonding period and orchestrator self-stake.
As @nhis and @Sparta have said, delegator mobility is important, both for realizing the full promise of MFS (where stake chases fees), but also for security of the validator set.
In all likelihood, a 21-day waiting period will mean stasis among the delegator set, similar to the status quo today. Fee-stake imbalances will be harder to correct (to the detriment of orchestrators). Potentially serious problems with the validator set could persist because stake cannot move quickly enough.
As suggested, a minimum self-stake for orchestrators is one way to resolve this tension: a 21-day lockup for orchestrators, while allowing delegators to transfer stake freely between orchestrators.
I’ve discussed this idea in other posts but it may be worth revisiting them in light of some of the the concerns raised here. I want to specifically address the concerns around 1) dynamic stake requirements being complicated to track and reason about, and 2) that it may be ultimately solvable at the market level, rather than within the protocol.
Complexity
To address the concern about dynamic self-stake being complex: it doesn’t have to be. Complexity is perhaps in the eye of the beholder, but I’m curious about the reaction to something like this, just as an example:
A self-stake percentage that starts high but decreases: 50% self-stake required for < 1,000 LPT, decreasing to 1% for > 1,000,000 LPT. Anything in between should fall on a curve: as total stake increases, the required self-stake percentage decreases.
This can be plotted on a fixed chart: self-stake of X would be eligible for Y of delegation (and hence, rewards). This should also govern validator eligibility.
Stake Curve
Illustrative example. The exact curve, thresholds, etc can always be adjusted. See here for a full (AI-generated) derivation of this particular formula.
With a decreasing stake-requirement, an established operator (that has enough stake for the fees they are capable of bringing in) almost always has plenty of self-stake and does not have to worry about stake maintenance, because:
- A proportional reward split among delegators means their self-stake share remains steady, at a minimum. Total stake grows, as the required self-stake percentage falls. Over time, this will actually result in orchestrators becoming under-delegated relative to their self-stake, assuming no additional delegation.
- Prioritized rewards increases the orchestrator’s self-stake share further (see next section on protocol handling)
- Reward cuts additionally increase the orchestrator’s own proportion of self-stake.
An orchestrator that has too much delegated stake simply wouldn’t qualify for rewards beyond what it is eligible for. There is a griefing attack around this, however we can accommodate that as part of the overall solution here; see the section on delegator saturation.
Decreasing stake encourages operators to consolidate under one on-chain identity, rather than tying up a larger share of stake among dispersed identities. Especially important with an unbounded orchestrator set; we want to give them reasons to consolidate, not to spin off new identities.
Protocol Handling of Self-Stake
To address the point that self-stake could be left up to the markets: while that is true, the protocol probably needs special handling of self-stake anyway. Enforcing a minimum is not a huge conceptual leap from there. The markets can probably enforce an even higher threshold.
For an explanation of why we need special handling, expand the section below on delegator saturation griefing. The details are less important than the simple fact we probably should have some special treatment of self-stake in the form of prioritized rewards distribution.
The other nice thing about prioritized self-stake: it encourages orchestrators to self-stake even more, to capture a larger share of their own rewards. This is in turn would be subject to the same 21-day lock-up, further increasing the security of the network.
Since I do not expect a self-stake requirement to be onerous at all, market forces could actually expect a higher amount than the minimum, as a way to show additional skin in the game.
Delegator Saturation Griefing
Orchestrator stake needs priority for rewards distribution, otherwise it will be vulnerable to a “delegator saturation” griefing attack where a large delegator dilutes the orchestrator’s own rewards.
The best way to address this is by rewarding orchestrator self-stake first, then distributing the remaining rewards (if any) pro rata to delegators. To put some numbers on it:
If a node has 1% of network stake and 1% of fees, with a quarter of that being self-stake they can keep 0.25% of the rewards, and the remaining 0.75% of delegators keep 0.75%.
If delegators double their network stake to 2% but their fees remain at 1%, they still get 0.25% of rewards and the rest of the delegators (1.75% of network stake) have to share the remaining 0.75%. Not great for delegators, but the orchestrator is unaffected. Without self-stake priority, the orchestrator’s share of rewards would drop to 0.125%.
Raising the reward cut is one approach to this problem, instead of implementing a reward-priority mechanism. However, the reward cut is a coarse knob, since it affects all delegators, and a somewhat adversarial movement. The orchestrator doesn’t necessarily want to upset its delegators, only to preserve its own return on stake.
Delegator saturation is not great for other delegators, but it doesn’t affect the orchestrator’s own reward share. If a legitimate orchestrator can’t make up the additional delegation in fees, then it’s no sweat (for the orchestrator). But if they can, then great: the additional delegation effectively increases their capacity for rewards.
It’s important to note that the stake requirement still doesn’t preclude someone from griefing the network with several different on-chain identities, particularly for small amounts. However, I think we have enough to chip away at the problem with:
-
Required self-stake, starting from a high amount like 50%
-
21-day transferBond lock for operators (zero for delegators)
-
MFS reward limits
-
Reward unlock period
-
Validation
-
Assorted market-level checks: additional self-stake, historical fee volume, time on-chain, validator penalties, etc.