RFC - The Future of the Validator Subsidy & Pseudo Jailing

Hi Faraz,
I really appreciate (and always did for many years!) your work and efforts! Even at this critical stage of the Radix-project are you still fully committed - Thank you!

Regarding your proposal, I have a similar stance like Jazzer has. The two subjects “Subsidy” and “Jailing” should not be combined, but agreed upon individually. Regarding the subsidy, I suggest that it should be tappered down over the next couple of months. A clear “road-to-zero-subsidy” should be agreed upon and communicated publicly so that all Node Runners can act accordingly. I’m afraid that this will create quite some pressure to the network’s stability since a lot of Node Runners might chose to just halt their Nodes without de-registering. And yes, I believe the way forward is a combination of independently chosen fees by the node runners and optimised structure in distributing the staking rewards. It must make economically sense to run a node on the Radix network long-term, or we will end up have a lot of low-quality, no-backup, cheapest-option nodes. Ultimately, the free market should fine the nodes’s fees and no penalty should be given to 0%-nodes vs nodes who decide to run with a higher fee.

Regarding the jailing approach, I’m a strong advocate that this must be implemented on the network level with an updated node software. I do not want a group of individuals being able to unregister nodes from the set. However, I fully support the concept of jailing, where “bad” acting nodes are taken off the validator set by means of a modified node software.

4 Likes
  • The Timeline:
    We don’t have the luxury of a 6-month transition. I’m afraid Foundation’s exit is happening faster than the community realizes, requiring immediate action.

  • The Subsidy/Jailing Link:
    We cannot cut subsidies without implementing jailing simultaneously. When subsidies will drop, quite some nodes will just GO DARK. Without a mechanism already set to kick those dead nodes asap (jailing), the network’s performance will crater.

  • KISS (Keep It Sucking Simple) like Peachy says (or KIFF if you prefer) :
    Now is not the time for complex architectural dreams like PoW integration. We need “survival-ready” code that WILL work with whatever the state of codebase Foundation leaves behind.

  • Proposed “Safety Rails”:

    1. Automatic Jailing: non-negotiable, to keep the network lean and active.
    2. Hardfloor Fees: Implementing a temporary minimum fee (e.g., 10 to 15% ?) to prevent “race-to-the-bottom” 0% fee nodes from centralizing all stake and making the network economically unsustainable for others in those hard time of “transition”.
    3. Subsidy: short term decrease to 0 (3 months after previous points integration, NOT CODED).

I’m sorry if this sound a bit alarming, but we will all be surprized how fast things are moving. We do not have many bullets and a lot of targets are coming at us. Let’s shoot ?

5 Likes

I will not be surprised and I expect a shitshow anyways - it’s just that it’s going to be the last shitshow run by this lot :sweat_smile:

As they have to be aggressively pursuing contract termination with current employees, running it down to the last management-only skeleton crew - without ppl, nothing will get done, so it’s only natural this is actually running full speed ahead on the FND’s side, no other way it can.

It’s inevitable that we’ll suffer impact from the fact that ppl running the nodes all these years were too dependent on those subsidies - pointless to think we can avoid it all.

I support whatever changes the status quo, but full rip of it now, while there’s still a FND is better than a tentative soft-landing that will probably be run over by FND’s winding down anyways. :neutral_face:

1 Like

I would be willing to use this jailing solution :+1:

So, another question.
Whatever “best of the worst case” solution we vote for.
How do we deploy it ? like code it ourselves and push it to fundation ?
First ask for fundation node repo ?
Any idea ?

I am in favor of cutting it ASSP down to nothing. We can then see the fallout and adjust if needed. I believe that we can keep all of this running with no subsidy or a very little one we add back later if absolutely needed.

1 Like

Thanks again to all for your feedback. Based on this feedback (and the polls shared here and in Telegram), a summary of the findings have been shared in Telegram (here) along with a revised proposal which is repeated here for clarity:

The findings from my Validator Subsidy RFC are as follows:

  • 42% of respondents want to end the subsidy immediately.
  • 44% want the subsidy to end within the next year.
  • 14% want the subsidy to remain indefinitely.

Many voiced concerns with the cost and potential selling pressure of the current subsidy ($500pm) over the next few months if left unchanged.

Based on a poll in the validator channel, 41% of nodes would consider shutting down if the subsidy were to end due to costs being unsustainable.

However, with a jailing mechanism in place, the community can consider reducing the number of active validators to mitigate this concern. The jailing mechanism would ideally be via a protocol upgrade but concerns raised (from Omar particularly) about the risks of implementing an upgrade in the short term make this a concern.

I would therefore suggest a revision to the proposal that aims to find a common ground to:

  • Immediately begin tapering the subsidy to preserve the treasury

  • Aim to end the subsidy altogether by June (with a backstop vote in May to maintain a subsidy at $100 per month if jailing cannot be implemented by then)

1 Like

Any idea on amount of work/ ETA to get the jailing solution done?

just ending this alone is very risky.
we also need Automatic Jailing and Hardfloor Fees with it.
we cannot afford a “lets see if networks halts or no”, we do not have the resources to restart everything if it does !

The jailling solution I presented initially is an enhancement to an existing access-manager component. The dev I am working with on doesn’t see this as a big lift, but I will report back with an estimate.

It’s worth mentioning, I use the current access-manager component with a python script that polls the gateway for missed proposals on my validator. If my node misses 3 or more epochs of proposals, the script automatically unregisters my node. We could just push this more amongst the validators as an optional way of ensuring liveness.

However, if Foxy can build a soft-jailing mechanism that can be implemented at the protocol level this would be preferable.

maybe we have another expert on node code rather than foxy already deep in Xian ?
let me see with others and report back

1 Like

I agree we need to phase out the subsidy, but please (as a community) take into account that raising fees takes two weeks, and it takes another 5 weeks to remove any earned fees from a validator.

Even if everybody were to increase their fees today, they won’t see any extra fee income for close to the next two months. Keeping the subsidy until the end of March (about two months from now) would give every validator a fair chance to increase their fees and keep paying their bills in the meantime.

2 Likes

i second this stance

Just to be clear though, protocol level changes would require an upgrade right? From the conversations I was reading around this it did not seem like it was going to be a sooner rather than later thing to achieve?

Yes, that’s right. I think there is a lot of concern around upgrades, and we should definitely tread carefully, but we have Stokenet and could potentially do a dry run too. I think the jailing component idea is sound, but there was some resistance to the idea amongst the validators, as it means giving power to a small number of people who could unregister nodes at their own discretion.

I’m still not a fan, but am slowly coming around on the severity, since Validators can always re-register.

My new doubt is whether the runners who would not cleanly unregister or keep their node online will proactively move their owner badge into the component. But that is another discussion / need for an incentive.

Maybe I’m just becoming more conservative lately due to stress and workload.

1 Like

Yeah I think the concerns are well founded. I agree with you that the biggest challenge is getting enough validators to move their owner badge into the component, perhaps it could be tied into visibility, for example the staking dashboard prioritises the display of nodes that have opted-in?

The other thing I was thinking of is trust and voting power. The original thinking was that this committee of node runners would be the decision makers, but perhaps the badge to unregister nodes should be held by the RAC, and the same governance process is followed for jailing a node, whereby the whole community are able to vote and the RAC enacts it if sufficient stake and participants agree.

1 Like

that feels like it would take too long if a collection of validators are dragging down the performance of the network

I agree, in which case we could still rely on the RAC members to be the jailers, but vote on agreed conditions for jailing, for example:

  1. More than X epochs of continuous downtime.
  2. Less than 80% uptime over a 1 week period.
1 Like

RAC should always be seen as facilitators - in this case, as the executors to carry out the community’s will and operational good-sense balance.

Anything else becomes oversight, smtg I believe we agree we don’t want.

1 Like