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.