Update to StarkWare delegation program - call for feedback

🤷‍♀️ All-Purpose Hangout
1

Updates to the StarkWare Delegation Program

TLDR of the proposed change

After two rounds of expanding the reach and attracting more stakers, we are shifting to prioritize quality over quantity. Fewer validators will receive more delegation (up to 31 validators, compared to 130+ before). Validators under the updated plan will typically receive a larger amount (from 5M to 20M STRK, compared to 2M to 5M before), while higher standards of reliability and availability will be expected from them. This is a deliberate shift from breadth toward depth and long-term partnership.

Why we’re making this change

The delegation program exists to bootstrap a healthy, decentralized validator set for Starknet. As the network has evolved, we’ve learned that our current approach isn’t serving that goal as well as it should.

Maintaining a Starknet validator is a serious operation. Teams are expected to test their validators on testnet releases rigorously, stay up to date with protocol upgrades, maintain on-call services, and be highly available to provide feedback to best optimize the Starknet and staking experience, as Starknet progresses towards decentralization.

Previous rounds of the delegation program aimed to give significant delegation when the cost/investment reference was maintaining mainnet validator running. But as validators are expected to do more, it’s pivotal to ensure that the received amounts also better support significant off-chain resources and human-time which we expect serious stakers to allocate.

To the validators who will no longer receive delegation under the new structure: thank you. Your early participation helped get Starknet staking off the ground. This change reflects a shift in strategy, not a reflection on your work, and we hope you’ll stay part of the conversation as the validator set grows in future phases.

The new structure

Who is eligible

The StarkWare delegation program will continue to have two tracks, but their goals and amounts will change.

Route A - Partner delegation

Route A will be composed of up to 26 recipients, who will each be entitled to a significant delegation of at least 15M STRK. This amount will be higher if a candidate qualifies for route A under more than one track, or if the candidate has maintained significant testnet activity to date, and could reach up to 20M STRK.

All Route A participants must demonstrate 99% mainnet liveness over the last three months, and in addition must be one of the following:

  • A top staker. Be one of the top 8 stakers by STRK stake, which are not StarkWare or the Starknet Foundation. Delegations done by StarkWare or the Starknet Foundation will be ignored for the stake ranking here - the logic is to reward serious stakers which attracted a lot of staking from outside StarkWare or the Foundation (8 recipients).
  • A top-tier infrastructure provider. We want to recognize and reward serious infrastructure providers/stakers from other chains that maintain a Starknet staking service. Their involvement is a key factor in reaching out to a larger retail staking audience, and in gaining a healthy perspective on the do’s and don’ts of decentralizing the network. This track will be limited to at most eight participants (in addition to providers entitled through the “top staker” track). Submissions to this track should highlight the other chains the entity operates on (and the total stake it manages there), any audit the company holds (such as SOC 2 Type II), and continued involvement in the Starknet community or efforts made to attract non-StarkWare delegation (if any).
  • An ecosystem contributor. We want to recognize the contribution of ecosystem members to Starknet’s success, and ensure that core builders in the ecosystem have room to contribute to Starknet decentralization. Any app builder on Starknet whose app paid at least $2,000/month in network fees on average over the last three months is automatically eligible for this track. Additional ecosystem members who have made strong contributions to Starknet or its related tech (Stwo, etc.) in the last 6 months may apply and be considered by the StarkWare team. This track will be limited to at most ten participants (in addition to providers entitled through the other tracks). Submissions to this track (if not made by an app builder) should highlight a relevant contribution to the Starknet ecosystem made over the last 6 months.

Route B — symbolic delegation

Route B will be composed of up to 5 recipients, each entitled to a delegation of 5M STRK.

Rationale: The Starknet staking program has attracted a number of enthusiasts who actively participate in decentralization discussions, maintain a Sepolia footprint, and take their staking role seriously.

The criterion for this route is demonstrated 99% liveness over the last three months, on both mainnet and testnet. Applicants should ideally describe why they take interest in Starknet staking, what brought them to participate, and what perspective they can bring going forward.

Ongoing expectations from the third round participants

To retain delegation, they are expected to meet the following:

  • Mainnet uptime above 99%.
  • Sepolia (testnet) uptime of 99%. We recognize that Sepolia’s status has been suboptimal, and that running testnet infrastructure is real work.
  • Active participation in the staking conversations and providing feedback when asked. Teams are expected to give one hour per month (when asked for) for consulting the StarkWare team around best practices done in other decentralized networks, and provide feedback on the Starknet roadmap.
  • Starting staking V3/Decentralized validation is live (currently estimated for early 2027) - have a 24/7 on-call service in case there are production issues which require attention.

What’s next

We are moving forward on a tight timeline. While a change is needed, and soon, the details of the new program are open to feedback.

The intent is for the change in delegation amounts to take effect in five weeks’ time.

Over the next two weeks, we would appreciate any feedback you have on this proposal, as we work to finalize the high-level structure and mindset for the third round.

When the first two weeks end, we will communicate the final round criteria and mindset here, taking all feedback into account.

Once the overall round structure is closed, we will move to identify the selected stakers for the third round. Stakers will then have two weeks to apply and explain why they fit the new criteria.

To apply, please initiate an application request on StarkWare’s site, clearly stating which route you are applying to and why. (The site will be updated once feedback is digested and the details become final)

One week after the submission window closes, StarkWare will withdraw all existing delegations and redistribute them according to Round 3 logic across the chosen stakers.

2

Fully on board with the direction - it’s time to grow and move forward. The shift toward “fewer but more serious” is the right call. Much of the current breadth is decorative: when a large share of the 130+ validators are bots on default configs holding 2M each - not testing releases, not giving feedback, and likely to go down simultaneously at the first serious upgrade - that isn’t 130 independent points of failure, it’s a handful smeared across 130 wallets. Many addresses ≠ real decentralization. 30 real operators with actual uptime and involvement are more robust in substance. So I fully support the cleanup.

That said, narrowing has two flip sides worth flagging.

  1. Concentration within the selected set. The issue isn’t that there’ll be ~30 participants - it’s HOW stake is split among them. 30 independent operators with comparable shares is healthy. But with a gap of 15–20M (Route A) versus 5M (Route B), weight and influence tilt toward the top, and there’s a risk that decentralization ends up resolving to a handful of dominant players. That seems to work against the program’s own goal. I wouldn’t argue for “make everyone equal” - there’s a valid reason to pay serious operators with a heavier load more. But the current A/B ratio is too steep; a smooth scale makes more sense than two far-apart tiers.
  2. Route B viability. I’m not convinced 5M even covers the infrastructure given the stated requirements. Rough math at current numbers (STRK ~$0.03, network APR ~8%, commission ~10%): 5M delegated generates ~400k STRK in rewards per year, of which the validator’s commission is ~40k STRK ≈ ~$100/month. Meanwhile a participant is expected to run two nodes 24/7 (mainnet + Sepolia), give an hour of consulting per month, and maintain 24/7 on-call from 2027. That barely covers servers and doesn’t cover human time.

And there’s a structural bind here: to make 5M pay off, you’d have to raise commission - but high commission drives away external delegators, whose attraction the program states as a goal. So it’s either low commission and running at a loss, or viability at the cost of giving up external stake. For Route A (15-20M) the economics work out (~$300-400/month); for Route B they don’t.

Bottom line: narrowing down to serious operators - yes, absolutely. But it’s worth revisiting (a) the A/B gap, so a new pyramid doesn’t form inside the 30, and (b) the lower threshold, so it actually covers the requirements being placed on participants. Otherwise Route B risks being symbolic in more than just name. Curious what others think.

3

Thanks for this thoughtful response!

  1. Route B viability. I’m not convinced 5M even covers the infrastructure given the stated requirements. Rough math at current numbers (STRK ~$0.03, network APR ~8%, commission ~10%): 5M delegated generates ~400k STRK in rewards per year, of which the validator’s commission is ~40k STRK ≈ ~$100/month. Meanwhile a participant is expected to run two nodes 24/7 (mainnet + Sepolia), give an hour of consulting per month, and maintain 24/7 on-call from 2027. That barely covers servers and doesn’t cover human time.

First of all, the maximum allowed commission with the delegation program would be 15%. (I believe this is already the case today). Secondly, route B indeed largely aims to help with infra costs of few eager individuals that take genuine interest in Starknet staking. (Notice that for core-contributors which are highly interested in Starknet as a whole there is the “ecosystem contributor” track inside routeA). This is also why this route is relatively small in the target number of recipients.

Concentration within the selected set. The issue isn’t that there’ll be ~30 participants - it’s HOW stake is split among them. 30 independent operators with comparable shares is healthy. But with a gap of 15–20M (Route A) versus 5M (Route B), weight and influence tilt toward the top, and there’s a risk that decentralization ends up resolving to a handful of dominant players. That seems to work against the program’s own goal. I wouldn’t argue for “make everyone equal” - there’s a valid reason to pay serious operators with a heavier load more. But the current A/B ratio is too steep; a smooth scale makes more sense than two far-apart tiers.

Notice that route A size is significantly larger than route B also with number of recipients (26 vs 5). So I don’t expect “concenrtation at the top” because most of the recipients will receive the larger amount. Its more “the ones in route B will be significantly behind the rest” situation. The main goal is securing 20+ sequencing partners that are highly committed and have respectable staking amounts - which is already a significant step forward with decentralization compared to today (This suggestion will roughly 3x the amount staked by the 20th staker, looking on today’s data). Do you think this is the wrong metric?

4

Thanks, that clears up a lot - and on concentration you’ve largely convinced me. I was picturing a pyramid (a few big + a long tail of small), but 26 at the larger amount vs 5 at the smaller is the opposite shape: most recipients get the larger delegation, and Route B is a small tail rather than the base of a pyramid. So “concentration at the top” was the wrong framing on my part - appreciate the correction.

On the metric: “20+ committed partners, ~3x the 20th staker vs today” is a reasonable target for this phase, and I agree it’s a real step forward. My one caveat is that it captures depth and commitment but not distribution among the top. You could hit 20+ partners and still have the top few holding a disproportionate share of stake and voting weight. So I’d suggest pairing it with a distribution measure - e.g. the ratio between the largest and the median participant, or a Nakamoto-style “how many entities to reach 33%/50%” - as a guardrail alongside your metric, not instead of it. Feels especially relevant since you describe these as sequencing partners: once ordering responsibility sits with this set, top-heavy distribution starts to matter for more than governance.

On Route B viability: the reframe makes sense. If it’s explicitly a small, symbolic track to defray infra costs for genuinely interested individuals - with core contributors routed to Route A’s ecosystem track - then it was never meant to be a business, and the 15% cap moves the math from ~$100 to ~$155/month, which fits “helps with costs” better.

The one thing I’d still flag: the ongoing requirements don’t seem to scale with that positioning. Asking Route B participants for 24/7 on-call from 2027, plus 99% uptime on both mainnet and Sepolia, is production-grade commitment on a deliberately hobbyist-grade delegation. Either the ongoing expectations could be differentiated by route - the same way the amounts already are - or, if the on-call expectation is firm, 5M starts to look under-scoped for what’s being asked. Would differentiating the expectations by route make sense?

5

Feedback from onchainaustria :austria:

First, some context on where we’re coming from: onchainaustria has been running both a mainnet and a Sepolia testnet validator since staking phase 1 went live. We rigorously test every new release on testnet before it hits mainnet, and we’re strong proponents of the direction StarkWare and Starknet are taking — particularly BTC staking and shielded transactions. We currently receive delegation under the program and intend to apply for Round 3.

Overall: we support the shift from breadth to depth. Running a serious validator — testnet testing, staying current with protocol upgrades, being available for feedback — is real, ongoing work, and it makes sense that delegation amounts reflect that. We especially welcome that sustained testnet activity is explicitly recognized in Route A (up to 20M STRK). Operators who have maintained a Sepolia footprint through its rougher phases have been carrying exactly the kind of load this program should reward.

A few points of feedback:

  1. The A/B gap. We’d echo @saniksin’s concern here: 15–20M vs. 5M is a steep two-tier split. A smoother scale between the tiers would reduce the risk of a new concentration pyramid forming inside the 31, without abandoning the principle that heavier obligations deserve heavier delegation.

  2. Route B economics. At current STRK prices and a 10% commission cap, 5M delegated barely covers infrastructure for a mainnet + testnet setup, let alone human time and (from 2027) 24/7 on-call. If Route B is meant to be more than symbolic in name, we’d suggest either raising the floor or explicitly scoping Route B’s obligations more lightly than Route A’s.

  3. Weight for continuity. We’d suggest that operational track record since phase 1 — uninterrupted mainnet + testnet operation, release testing across every upgrade — be given explicit weight in selection, not just the last three months of liveness. Long-term continuity is a better predictor of Round 3 reliability than a 90-day snapshot.

  4. The transition window. The plan to withdraw all existing delegations one week after submissions close and then redistribute could create a brief but significant stake shift. We’d encourage making the withdrawal and redelegation as atomic as possible to avoid attestation/reward disruption for validators and their external delegators during the switchover.

Happy to elaborate on any of these, and looking forward to the finalized criteria. We’re glad to keep contributing our testnet feedback and operational perspective as Starknet moves toward staking V3 and decentralized validation.

6

Dear StarkNet team!

I acknowledge that some reduction in the number of nodes is needed to remove inactive or low-quality nodes. However, cutting from 130+ down to just 31 is too drastic. It risks excluding dedicated, individual participants, leaving only «large players” in control.

Many of us, as smaller contributors, provide quality results and uphold decentralization. Instead of reducing to 31, I propose a more moderate reduction(perhaps around 75)so that individuals who deliver value can continue supporting the network’s strength. This balanced approach would still improve node quality while preserving decentralization and trust.

Personally, I am in love with your project and hope that I will have a chance to contribute.

7

I also worry that Route A will worsen the centralized top stack of validators, since being in the top 8 is one of the requirements to receive even more delegation.

  • If any smaller validators have any chance at staying in the program we would only have the Route B option. Since the beginning of Starknet on both Mainnet and Sepolia myself and some other smaller validators have maintained a 99%+ presence on these chains, not just for the last 3 months, but since November 2024. Currently I run 3 main net instances and 2 Sepolia instances.

  • I do agree with the quality over quantity stance when it comes to validators and I think better infrastructure will help the network compete with other L2’s, however historically, top heavy chains have not been very successful. As an example, looking at any Cosmos chain, they have all failed over the years because each became a top heavy Oligarchy, and users want to see a decentralized spread and know their funds were secure. When Starknet went live I noticed many similarities to the staking mechanisms as Cosmos/Atom, which I was hoping Starknet would be able to avoid, but one only has to look at the current top 5, which represents some 53% of the staking power.

  • There seems to be a view that smaller validators cannot compete with the larger ones, however I think smaller validators need to be given benefit of the doubt to prove themselves for the new requirements. If some have maintained 99%+ since November 2024 then they must be doing something right. We have complied with the requirements that were set out for us. If there is additional infrastructure or equipment required then many of us will comply with the requirements/specs. It seems that it is being assumed that smaller validators cannot keep up. While this might be the case for some, I know myself and some other smaller validators that would have no problem keeping up with the specs required. Although I do know the disparity of 15/20M vs 5M would continue to push smaller validators out and make then unable to compete.

    I would like to see a fair playing field. Smaller validators are already at a disadvantage with being excluded from the front staking page on any explorer. Anyone that has been staking since the day 1 launch surely deserves some credit for over 2 years of continous staking.

    Teku

8

We support the direction of prioritizing quality, reliability, and long-term commitment from validators. This is the right direction for Starknet as staking matures.

However, we would like to raise one concern about the proposed Sepolia/testnet liveness requirement over the last three months.

Until now, there was no clearly communicated expectation that validators should maintain near-perfect testnet uptime during that specific period as a condition for future delegation. Most professional validators naturally prioritize mainnet reliability first, because this is where user funds, staking security, and production reputation are at stake. Testnet infrastructure is important, but in many validator operations it is treated differently from mainnet unless strict requirements are communicated in advance.

This applies to us directly. We have focused primarily on mainnet quality and reliability, and we did not treat perfect Sepolia uptime over the last three months as a critical delegation requirement. This should not be interpreted as a weak mainnet operation or low validator quality.

We believe we are not alone in this. Many strong validators may have made similar operational decisions: protect mainnet first, allocate more attention to testnet when there is a clear release, upgrade, or explicit requirement. From a network perspective, this is generally a healthy priority — validators should care deeply about mainnet safety and availability.

Our suggestion is to make the Sepolia/testnet liveness requirement forward-looking, or introduce a grace period after the final criteria are published. Once the requirement is explicit, validators can adjust monitoring, alerting, and operational priority accordingly, and StarkWare will get a much fairer signal of who is committed to maintaining both mainnet and testnet infrastructure at the expected standard.

9

On the metric: “20+ committed partners, ~3x the 20th staker vs today” is a reasonable target for this phase, and I agree it’s a real step forward. My one caveat is that it captures depth and commitment but not distribution among the top. You could hit 20+ partners and still have the top few holding a disproportionate share of stake and voting weight. So I’d suggest pairing it with a distribution measure - e.g. the ratio between the largest and the median participant, or a Nakamoto-style “how many entities to reach 33%/50%” - as a guardrail alongside your metric, not instead of it. Feels especially relevant since you describe these as sequencing partners: once ordering responsibility sits with this set, top-heavy distribution starts to matter for more than governance.

I agree that giving the top-8 validators the same amount given to the 20th is suboptimal in terms of encouraging stake distribution. The counter-argument here is that giving more to non-top-8 validators create a weird incentive for the 9th/10th validators to stop care about attracting more delegations and be competitive as then their delegation from StarkWare will lower . We will definitely consider this tradeoff with the team

The one thing I’d still flag: the ongoing requirements don’t seem to scale with that positioning. Asking Route B participants for 24/7 on-call from 2027, plus 99% uptime on both mainnet and Sepolia, is production-grade commitment on a deliberately hobbyist-grade delegation. Either the ongoing expectations could be differentiated by route - the same way the amounts already are - or, if the on-call expectation is firm, 5M starts to look under-scoped for what’s being asked. Would differentiating the expectations by route make sense

The requirement for on-call is relevant only for when Staking V3 is alive. When this will happen, any validator in Starknet will participate in actually securing the netowrk, and event where many validators are offline during a bug could result in a prolonged downtime. While Staking is permissionless, and anyone can join, we wouldn’t want to encourage unavailable operators to participate in staking by delegating to them. Notice that Staking V3 has no concrete ETA yet. Route B validators have some time to stay around, get more traction, increase their stake before it ships and the on-call expectation kicks in.

10

  1. The A/B gap. We’d echo @saniksin’s concern here: 15–20M vs. 5M is a steep two-tier split. A smoother scale between the tiers would reduce the risk of a new concentration pyramid forming inside the 31, without abandoning the principle that heavier obligations deserve heavier delegation.

  2. Route B economics. At current STRK prices and a 10% commission cap, 5M delegated barely covers infrastructure for a mainnet + testnet setup, let alone human time and (from 2027) 24/7 on-call. If Route B is meant to be more than symbolic in name, we’d suggest either raising the floor or explicitly scoping Route B’s obligations more lightly than Route A’s.

Can you be more explicit with the suggestion on 1? What middle tier you see?

Around point 2, which connects to it - when staking V3 kicks in, as per the current plan, all validators will be responsible to secure the network liveness. Keeping Starknet stable and reliable while it moves to decentralized phase is the top priority, as “Starknet was down for couple of hours because we couldn’t reach validators” will be a disasterous event. One of the goals of round three is clarifying to validators they all should be mentally ready to take this responsibility in the future (there is still some time before we get there - and one of the other goals to is to nourish a strong community which can give us the best feedback on how to get there, together)

  1. Weight for continuity. We’d suggest that operational track record since phase 1 — uninterrupted mainnet + testnet operation, release testing across every upgrade — be given explicit weight in selection, not just the last three months of liveness. Long-term continuity is a better predictor of Round 3 reliability than a 90-day snapshot.

Interesting suggestion! Will discuss it with the team and get back to you

11

Thank you for the feedback and the dedication.

Notice that route B is tailored for helping validation cost for dedicated individuals which would like to participate in Starknet staking (alongside all the responsibilities this bears). Would you change anything in the criteria itself?

Around number of recepients -going to 75 recepients means adding at least 200M STRK to this program even if they all join the 5M track. As the budget for this program is set, this realistically means lowering significantly the amount each recipient will receive. Do you think that this is a good direction to go to?

12

If any smaller validators have any chance at staying in the program we would only have the Route B option.

This is incorrect. Notice that only 8 of the 26 recepients of track A will be the top-8. The other 18 will be designated stakers from other chains which can give the best perspective on how to decentralize, or strong contributors to the Starknet ecosystem. Some of the non-top-10 validators are extremely committed to the Starknet ecosystem, and this shift will allow them to take a more active roll in staking as well.

When Starknet went live I noticed many similarities to the staking mechanisms as Cosmos/Atom, which I was hoping Starknet would be able to avoid, but one only has to look at the current top 5, which represents some 53% of the staking power.

I agree that giving the 1st and 20th validator the same delegation loses the opportunity to balance the field a bit. @saniksin also raised a similar point. I’d discuss this with the team, as it has some tradeoffs

I would like to see a fair playing field. Smaller validators are already at a disadvantage with being excluded from the front staking page on any explorer. Anyone that has been staking since the day 1 launch surely deserves some credit for over 2 years of continous staking.

The point of route B is exactly that, to keep committed stakers around even if they are not a recognized staker elsewhere or committed to the Starknet ecosystem through not-staking-related-contributions.

Notice that the amounts individual contributors were delegated so far tended to be 2M, so this suggestion will more than double the delegation here.

13

Until now, there was no clearly communicated expectation that validators should maintain near-perfect testnet uptime during that specific period as a condition for future delegation. Most professional validators naturally prioritize mainnet reliability first, because this is where user funds, staking security, and production reputation are at stake. Testnet infrastructure is important, but in many validator operations it is treated differently from mainnet unless strict requirements are communicated in advance.

You are correct that this requirement was not explicitly communicated before. This is why past active testnet operation is not a prerequisite for route A which is aimed to keep around staking services on other chains which can give the best perspective on how decentralization os done elsewhere, and top ecosystem initiatives with huge contributions elsewhere.

It is however a requirement for route B - route B is aimed to capture the few enthusiastic individuals which are honestly caring about staking and would like to be part of our journey , even though the amounts delegated to them won’t do significantly more than covering the cost this participation entails. Requiring sepolia activity as a prerequisite for route B was the suggested criteria to isolate the stakers that went above and beyond in terms of commitment to Starknet staking out of their own free will.

14

Totally agree with this. There are small validators who have been around since day 1 providing uninterrupted mainnet and testnet attestations. I believe this could almost be a middle tier for the program. You are not going to find a more loyal validator than someone who has been attesting Since 2024 until now with 99%+ .

15

+++ Agree with u 1000%

16

Thank you for your thoughtful reply.

Yes, I would be willing to receive a smaller allocation if it means preserving decentralization and giving more dedicated community members the opportunity to participate.

In my opinion, decentralization is one of StarkNet’s greatest strengths. If the program becomes accessible only to a very small number of participants, it may unintentionally discourage long-term contributors who have been supporting the ecosystem for years.

Regarding the criteria, I believe they could be improved by placing more emphasis on quality and consistency of contribution, rather than simply selecting the smallest possible group.

For example, factors such as:

validator uptime and reliability,
long-term commitment,
technical contribution,
community participation,
and overall performance

could carry more weight than limiting the number of recipients so aggressively.

I also think a tiered approach could work well. Instead of selecting only 31 recipients, more participants could be accepted with different allocation sizes based on performance and contribution. This would maintain high standards while avoiding unnecessary centralization.

I believe many independent operators would gladly accept a smaller allocation in exchange for having the opportunity to continue contributing to StarkNet’s decentralization.

Thank you again for taking the time to discuss this with the community.

PS. Large companies are not automatically better validators. Many independent operators maintain excellent uptime, respond quickly to issues, and are deeply committed to the ecosystem. A healthy decentralized network benefits from diversity of operators, not only from concentration among the largest organizations.

17

Thanks for the follow-up, Ohad. To address your specific questions:

1. The A/B gap and middle tier:
Regarding a specific suggestion, a 10M STRK tier would make sense for operators who provide high-quality technical engagement but don’t meet the capital-heavy “Top 8” or “App Builder” criteria.

As for our application, onchainaustria is aiming for Route A. We have been an ETH validator since genesis, a Uniswap operator, and have operated a dozen NYM nodes (decentralized VPN) for many years. We have the technical infrastructure, know-how, and routines in place to accommodate the new requirements and upcoming obligations within the Starknet ecosystem. Furthermore, we are already operating a dual machine and client setup on both mainnet and testnet to ensure client diversity and 100% uptime—a clear demonstration of our trust and support for the path Starknet is taking. While we do not currently run a 24/7 on-call service, we have the background to implement these standards as the network evolves toward V3.

2. Route B economics and V3 liveness:
I agree that network liveness is the top priority and that “Starknet is down” is not an option. However, to be “mentally ready” for that responsibility, the economics must support it.
At current STRK prices and a 10% commission, a 5M delegation barely covers the server costs for a professional mainnet + testnet setup. It does not cover the human time required for the consulting hours you are asking for, nor the preparation for future 24/7 on-call duties. To make this viable for serious operators, I suggest raising the Route B floor to 7.5M or 8M STRK.

3. Weight for continuity:
I am glad the team is discussing this. We have been here since Phase 1 and we are certainly here for the long term. We look forward to seeing how the team incorporates operational history into the final selection.

Looking forward to the finalized criteria.

18

Thanks!

Yes, I would be willing to receive a smaller allocation if it means preserving decentralization and giving more dedicated community members the opportunity to participate.

I must admit that so far this seems like a minority opinion, as most comments here point out that the amount allocated for tier B is on the verge of being too low. But lets see how more feedbacks will potentially change this in the coming week

And thank you for suggesting the factors

19

Thanks Ohad and the StarkWare team for keeping the discussion open.

I support the direction of improving validator quality. As Starknet moves toward Staking V3, reliability, upgrade readiness, and operational discipline will matter more and more.

That said, I think there are two points worth reconsidering.

First, the gap between Route A and Route B feels a bit too large. Route B is helpful, but 5M STRK may not be enough for serious independent operators who are expected to maintain mainnet and testnet infrastructure, follow releases, provide feedback, and prepare for future production responsibilities. A middle tier, perhaps around 8M–10M STRK, could be a good balance for operators with strong uptime, long-term commitment, and solid technical operations, even if they are not large infrastructure companies or top stakers.

Second, I would be careful about giving too much weight to recent testnet status. I agree that testnet participation is important, but if it was not clearly communicated earlier as a major selection criterion, using recent testnet liveness too heavily now may feel a bit retroactive. Many operators focused mainly on mainnet reliability, while treating testnet as a place for testing, experimentation, and upgrade preparation. It would be fairer to consider testnet participation as a positive signal, but apply stricter expectations more clearly going forward.

In the end, I believe the validator set should include both large providers and committed independent operators. Diversity of operators is also part of network resilience.

The current Web3 environment is already difficult for many teams and operators, so I also hope we can find a way to support each other and keep building together.

20

Hey Ohad, appreciate you keeping this open for discussion.

Wanted to flag that the Ecosystem Contributor track feels a bit too narrow right now. I get that the $2K/month fee metric is a solid signal, but it totally overlooks a whole chunk of contributors — people building the actual tooling that keeps the network stable.

For context, our team built a monitoring bot that’s currently used by ~30% of Starknet mainnet validators. It handles epoch tracking, wallet balances, and governance alerts. We aren’t generating fees, obviously, but validators keep telling us it’s saved their nodes from downtime more than once.

It feels like that kind of public infra is just as valuable as dApps that generate volume. Would love to see the definition broadened to include these public goods, instead of just focusing on apps that pay fees.