SNIP 18: Staking’s First Stage on Starknet

📜 Development Proposals SNIPs
41

Hey @_dd !
For you first question, the answer is yes but, they will be able to move to another Staker S’ without waiting the 21 days if they wish.
On LST, several teams are already working on such protocols, it would be on top of the basic Staking protocol we develop, not built by us.

42

Thanks @NatanSW. Are you expecting solo stakers? I know for consensus, sequencers will need to compute a zkp for a previous block in order to propose a block. Is this feasible for users with consumer hardware?

43

Hi @NatanSW , I have just read the SNIP and as others have said, it’s a good step for the decentralisation of starknet. Congratulations!
I have a few questions.

  • Based on your answer, in future the staked STRK will be granted voting powers. What will happen to the delegated STRK? Will the votes be delegated as well?
  • Will there be a limit to the number of STRK that can be staked per node? And for delegation? For example, is it possible to have a node with only 20k staked and millions/billions of STRK delegated?
  • About the R parameter: how do I decide what value to set if I don’t know the hardware specs? How do I know what is the minimum value I need to set to cover my costs?

I am concerned about the decentralisation and protocol security.

  • I believe the 20k minimum is to allow solo stakers, but can they do it? Proving zk stuff is very expensive. If it is not possible, the chain will probably have very few nodes.
  • I am worried about delegations in the early stages especially if they give voting rights. Bad actors may start a race to drive R down to unsustainable values (the worst being R = 1 or 0) to get the maximum delegations and voting power. Moreover, in the early phases, when the costs are lower (or even 0 for bad actors), bad actors may vote against to some proposals or they try to harm the chain (stealing rewards harms the protocol). Honest players who get caught to the race will have to create a new node losing all their delegations.
  • About the R: is it possible to replace R with two parameters? The first, called maximum reward, is the same as R (and can only be lowered). The second is the actual fee can vary [0, maxFee] and it is used to calculate the commissions. The solution may solve the problem above. It should be easy to implement.
44

Only the pledged address can have voting rights, right?

45

Hay cosas que no están definidas o que si lo están aun no se han explicado.

  • me preocupa la centralización o la falta de proporcionalidad entre los validadores, es decir es bueno establecer por ejemplo que cada nodo o validador no pueda contener más del 5% del total en stake.
  • tampoco señala que no exista umbral en el poder de voto/stake es decir un VC que posea 1b no puede solo decidir que hacer con la red.
  • si bien se establece que mientras más STRK en stake menor será el STRK qué se distribuirá, el problema es que en unos inicios los VC. Estarán incentivandos a sostener sus token, en una fase intermedia dicha política incentivara a que ellos los vuelquen a mercado.
  • si bien eth hoy es deflacionaria, sus inicios fueron con inflación, la pregunta es si existirá algún mecanismo para que STRK sea deflacionaria?
46

Hey @NMoustache !
Thanks for taking the time to review and ask good questions :pray:

  • Not yet final: Staked delegated will also be counted as voting power for themselves. They could later delegate that voting power to anyone.
  • We found setting an upper bound not effective. The reason being you cannot know what is actually run per address. You can easily have multiple addresses using only a single instance of a sequencer. It does not ensure robustness or Stake distribution, unfortunaltly.
  • Currently no. We had a feature that sets a hard limit on the ratio between self_stake and delegated_stake. We decided not to implement it as it was too harsh and did not result in a better Stake distribution. You can check the first amendment to this SNIP linked above for more details. We will think of ways to have a more sophisticated way to incentivise self-stake.
  • About setting R, it depend on the amount of delegations you have and the market conditions. You can always lower it, and in the future, we might have more sophisticated commission policies like for example change within a time delay. The cost you should take into account right now is of running a full node. You can find our full node implementations and spec here:
  1. Juno (GitHub - NethermindEth/juno: Starknet client implementation.) by Nethermind - Spec (Hardware Requirements | Juno).
  2. Pathfinder (GitHub - eqlabs/pathfinder: A Starknet full node written in Rust) by EQLabs - Spec (Example: Pathfinder Node - The Starknet Book).
  • Utilizing STWO would make “zk stuff” much more accessible and cheap, it is a total game changer.
  • So having Stake delegations would not mean having a lot of voting power, exactly for that reason! see the first bullet point.
  • This is a very interesting suggestion! For this version, no. For later versions, this is totally on the table with other suggestions, thanks!
47

As the ITU Blockchain delegation team, we fully support the proposed mechanism for STRK token minting and staking.

This proposal aims to effectively manage inflation while aligning with staking incentives, contributing positively to the Starknet ecosystem’s growth. We have been delegates at Starknet from the beginning and believe this approach will enhance transparency and reward fairness.

Furthermore, we missed Starknet on Snapshot and are ready to participate more actively in the community!

48

We will not support the Staking’s First Stage proposal in its current state due to concerns about the inflationary rewards model, which could devalue STRK over time and the unclear timeline for Stakers taking on critical network responsibilities. Additionally, the 21-day security lockup period may deter broader participation. We believe adjustments in these areas are necessary for long-term sustainability and broader community engagement.

49

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.

We’re voting FOR this proposal.

We trust that StarkWare has decided on the outlined minting curved mechanism based on research that informed its design and setup. Furthermore, we believe that authorizing Starknet Foundation to adjust the minting curve’s constant ‘C’ either directly or indirectly through a monetary commission will allow us to be flexible based on the supply that is staked. In the future, once governance has matured, we believe these adjustments could be made by the DAO or a DAO-elected body.

We find the adjustment protocol reasonable as it provides both a justification for any change and sufficient time for relevant stakeholders to notice. However, we’d like to point out that withdrawal security lock-up is 21 days long, which means that even if someone wishes to unstake right after a change in the ‘C’ constant is announced, they won’t have enough time to do so before the change goes into effect. With that in mind, perhaps increasing the notice window to 28-35 days is prudent.

Lastly, we also want to echo the request for a plan to have staked STRK used in governance, not only as self-delegated but also as voting power delegated to someone else.

50

Congratulations on a successful vote and a major milestone for Starknet governance.

One suggestion, three days voting window is extremely short, unless its a time-sensitive and chain-breaking proposal, I highly encourage that future proposals should have at least a 10-day window.
Not sure who to tag for such feedback, cc @NatanSW

51

+1 On that.
The voting period was quite (too) short

52

Any spot on technical details of running the node? Say I wanna run it and get delegators in addition to my own funds locked. Pure technically what is requirements (hardware, bandwidth etc.)

53

@Itublockchain , thank you for the kind words!
Happy to see the engagement and care (:

54

Thanks for the feedback, We will take it into consideration.
Tagging @BoazStark , who is the PM working on governance.

55

Thanks for writing, the same as I wrote here:

56

Sure, here are two implementations:

  1. Juno by Nethermind - Spec.

  2. Pathfinder by EQLabs - Spec.

57

Thank you @kaereste for the vote of confidence!
About the having larger notice, I want to emphasize that exit the protocol, i.e. stop earning rewards (and in the future, stop sequencing blocks), is immediate, and in the future would take only ~hours. The enforcement of the withdrawal is ontop. This means you can stop running infra much earlier than 2 weeks.

58

I do not understand this. You must insert an intent if you want to unstake. Your STRKs are immediately removed from the total staked and you will receive no more rewards. After 21 days you can withdraw them. So you will not be affected by the changes.

59

These two have quite different technical requirements. Are they do the same job and implied to bring same rewards?

Also, do I understand properly, now we can already run a node? It is on testnet or mainnet, and is it bringing any rewards (or potential bonus in future)?

60

Hey @Eugene1976 , you can already run these nodes on testnet or mainnet.
This will not result in receiving rewards. Only if you lock funds, i.e. Stake, will you accumulate rewards.