New Proposal for StarkWare’s Delegation Program During v2 — Feedback Request

[Manor]

New Proposal for StarkWare’s Delegation Program During v2 — Feedback Request

Introduction

Over the past few months, StarkWare’s delegation program has been running successfully and with great momentum. We’re happy to see that it contributes to Starknet’s resilience and helps strengthen participation across the ecosystem during this early phase of staking.

Feedback on the previous proposal played a major role in shaping its success, and we’re looking forward to hearing your thoughts again.

Scope of This Proposal

As with the previous iteration, this proposal applies specifically to StarkWare’s participation during Staking v2. As the staking mechanism evolves, our participation model will evolve with it, adapting to protocol changes and Starknet’s future needs.

Background

A lot has changed since we first launched the program. The validator set has expanded, the delegator base has grown, and the staking Pool itself has become larger and stronger. We’ve also seen new (and very welcome!) delegation initiatives launched across the ecosystem and, of course, Bitcoin staking has entered the picture.

All of this is great news; however, it also means the existing program no longer reflects the initial conditions for which it was designed.
To continue supporting long-term network strength, we believe the program should be adjusted to reflect both the network’s current state and where we believe it is heading.

With Staking v3 (expected around late 2026), validators will take on more responsibility. This makes it especially important to nurture not only small and new validators, but also a “middle tier” of long-term, professional operators with meaningful alignment and proven track records.

Distribution Strategies

Below are several options we’re considering. We’d love to hear your thoughts, as well as any additional ideas or alternatives.

• Option A — Same as Today, With Stricter Requirements

  Maintain the current program structure (Equal Allocation), but introduce higher stake minimums and stronger performance thresholds. For example, at least one month of continuous operation with 99% liveness, and a minimum self-stake of 100k STRK.

• Option B — Capped Matching Program With Residual Allocation

  A matching-based model, with predefined caps and stricter operational requirements. After the matching phase, any remaining delegation could be allocated proportionally or based on additional criteria.

• Option C — Proportional Delegation

  Delegate in proportion to each validator’s existing stake. While simple and transparent, this approach risks reinforcing stake concentration and may reduce opportunities for smaller operators.

• Option D — Two Delegation Tracks

  • Track A - Established, long-term validators
    Designed for validators with a proven operational history, a stronger self-stake (for example, above 1M STRK), and a consensus power cap (for example, below 5%). Validators in this category are expected to demonstrate long-term alignment and reliability, including at least three months of operation with a 99% liveness rate. The purpose of this track is to support stable, professional operators.

  • Track B - Smaller / emerging validators
    Focus on newer and smaller validators, aiming to encourage onboarding and support their growth over time. It emphasizes decentralization and accessibility and may include a slightly higher minimum stake than today (e.g., >50k STRK). The goal here is to nurture small validators and help them mature into long-term contributors to the network.

    Delegation would be allocated strategically between the two tracks to promote both reliability and decentralization across the ecosystem.

At this stage, Option D, the two-track model, seems best suited to support Starknet’s staking community in the coming months. It strengthens experienced active validators (excluding whales) ahead of the transition to v3, while still providing meaningful support and growth opportunities for newer and smaller validators. WDYT?

Just before you share your feedback

Before we wrap up, a few clarifications to keep in mind as you consider your feedback:

• We’ll ensure a reasonable transition period, so no one is caught by surprise by the proposed changes.

• The Starknet Foundation also operates a delegation program, and we aim for complementarity across the ecosystem.

• Complementary ecosystem initiatives to enhance validator decentralization will continue to expand alongside this program.

We’d love to hear your thoughts in the thread below.

Thanks!

[saniksin]

I support Option D (Two Delegation Tracks) as the strongest foundation for StarkWare’s delegation program during Staking v2 - but only with several critical modifications that ensure fairness, decentralization, and long-term validator sustainability.

---

Excluding Large Custodial & LST Participants

I believe that large custodial operators should be excluded from receiving delegation support.
This includes:

• liquid staking platforms
• wallet-integrated validators
• exchanges
• any validator with a monopolistic user-entry point

1) Large operators already have a structural advantage

They onboard delegators automatically through:

• built-in wallet staking flows
• LSTs
• exchange customers
• direct UI control

Independent validators must compete manually for every delegator and cannot match this distribution power. Supporting large custodial operators through delegation only increases centralization.

2) 0% commission distorts validator economics

Many large players run at 0% commission because they monetize through other products.
As a result:

• their validators operate at a loss
• they often maintain only ~20k STRK self-stake
• yet they continue absorbing most delegators due to UI monopoly

This is not sustainable and creates unfair conditions for independent validators who must maintain real infrastructure costs.

3) Delegation should prioritize emerging community validators

The purpose of StarkWare’s program is (and should remain) to:

• strengthen decentralization
• support new and independent operators
• broaden validator participation
• avoid stake concentration

Supporting whales or custodial platforms directly contradicts these goals and the direction of v2 → v3 evolution.

---

Raising Requirements - With a Fair Definition

I support increasing the minimum requirement (e.g., 50k STRK).
However, the threshold should be defined as:

self-stake + organic community delegations

Where:

• organic means delegators who chose the validator independently
• excludes delegation programs, custodians, exchanges, and institutional flows

If a small validator successfully builds trust and attracts community delegators on their own, this should be recognized and rewarded.

This approach:

• incentivizes real engagement with the community
• ensures that the threshold reflects genuine validator reputation
• prevents large custodial players from passing requirements artificially

---

Improved Option D - Why It Works Best

With the modifications above, Option D becomes the strongest and fairest model.

Track A - Established Validators

With additional rules:

• exclude custodial / LST / exchange validators
• require meaningful self-stake
• require sustainable commissions (no loss-leading business models)
• limit consensus power

This supports professional, long-term aligned validators without empowering monopolies.

Track B - Emerging Validators

With modified requirements:

• minimum 50k combined (self + organic) stake
• strong liveness expectations
• clear path to graduate into Track A
• focus on community-based operators

This track provides real opportunities for new validators - independent, decentralized, motivated to build.

---

Why This Is the Best Direction for the Ecosystem

These adjustments:

reward community-driven validators
prevent stake centralization around custodial giants
create a sustainable validator landscape
support both reliability and decentralization ahead of v3
reflect the real economic and operational differences between validator types

---

Summary

I support Option D, but only with the following improvements:

• Exclude large custodial, LST, and wallet-integrated validators from receiving delegation
• Introduce sustainability requirements to prevent zero-commission distortion
• Set a minimum threshold of 50k STRK, defined as self-stake + organic delegations
• Reward validators who build real community trust
• Provide a clear growth path from Track B → Track A

This creates a balanced model that strengthens decentralization while preparing the validator set for responsibilities expected in Staking v3.

[Manor]

Thanks for the great feedback and the concrete suggestions really appreciate it!

The input we received in the previous round genuinely helped improve the program, and it already feels like this round is heading in the same direction.I fully understand where your points are coming from, and I’m generally aligned with the direction you’re recommending. A few specific notes:

Excluding “whales” operators

You highlighted an important concern.
In the proposal, this is partially addressed through the consensus power cap (e.g., a max of 5%)..

0% Commission

I completely acknowledge the issue you raised here.
Zero-commission models can create distortions, and we’ll continue evaluating this as we refine the program structure .
BTW, looking at the current numbers, I believe the size cap (up to 5% of the Pool) will organically mitigate most of this challenge as a by-product.

Transition from Track B → Track A

That’s actually the intended outcome.
One of the goals is to support smaller validators as they grow, mature, and eventually transition into the group of long-term, reliable operators.

---

Thanks again for the thoughtful input; it’s extremely helpful.
Looking forward to continuing the discussion!

[onlyoneAlexia]

Thanks for sharing this, Manor, this makes a lot of sense.

The validator landscape today is very different from when the program launched, and a one-size-fits-all delegation model can’t support where Starknet is heading. I really like the two-track approach because it acknowledges two truths:

1. We need long-term, professional operators who can handle the responsibilities coming in v3.

2. We also must keep Starknet accessible for smaller and emerging validators so decentralization doesn’t suffer.

Option D seems like the first model that balances both reliability and growth. It creates space for new validators while strengthening the middle tier which is essential for the network’s resilience.

Looking forward to seeing how this develops, and appreciate the transparency + willingness to iterate with the community.

[Teku]

I agree with the post from saniksin.

I would also like to see original Starknet validators who have been running validators since attesting went live on main net and test net to be rewarded with delegations in some way also. I know the program is designed to attract new users, however I think the validators that took the plunge early and who have held on until now with excellent uptime have proven they are reliable already.

Regarding the self-staking requirements, a lot of smaller validators delegate to themselves to boost their rank already. So it may not appear that they have a large self stake, but may be in control of some large delegation addresses to themselves.

[y3v63n]

Agree with both @saniksin and @Teku . Option D seems like the best choice. However modifications are needed to exclude large self-sustained entities from the program. At the same time, I would love to see more support for the validators who has been there since the launch of staking on Starknet.

[Manor]

Thanks for the feedback! - really appreciate it.
I’m glad to hear that the two-track approach resonates and feels like a good fit for where we are right now. Our goal is exactly that: supporting different validator profiles while enabling healthy, long-term growth of SN’s staking.

[Manor]

Yo - thanks for the feedback, this is super helpful.

On your first point - I agree. There’s real value in rewarding validators who have shown long-term commitment and reliability, not just in attracting new ones. I think Option D moves in that direction by allocating more meaningful delegation to validators who demonstrate sustained, high-quality operations over time (we mention three months in the proposal, but that’s definitely something we can revisit. would love to hear what you think is a better timeframe).

On the self-staking point - that’s a good point. Do you have a suggestion for a better way to account for this, beyond requiring the minimum stake to come from the same address rather than via delegation?

[Manor]

Thanks!

• In Option D, excluding large self-sustained entities is partially addressed through the consensus power cap (for example, a max of 5%). Do you think a different percentage would make more sense here? pls explain.

• Supporting validators who’ve been around since the launch of staking is also something Option D aims to cover, by providing more meaningful delegation to validators who demonstrate sustained, high-quality operations over time.

I’d love to hear additional ideas you might have for addressing these points even better.

Cheers

[Teku]

Perhaps on the first point the total number of attestations might be a useful multiplier for Starkware delegations, as this rewards uptime as well as time served as a validator.

On the second point I have multiple addresses I delegate to my validator pool from. I could prove I own these addresses by signing a message to prove ownership of them. For me to self-stake from my validator account I would need to un-bond from multiple accounts and consolidate, which is possible but a bit of a pain.

[Manor]

Thanks!
2 good points to consider.