Introduction
SNIPs (Starknet Improvement Proposals) are the Starknet analogue of Ethereum EIPs. However, in the current state of affairs, there are aspects in which a SNIP differs from an EIP both in its purpose and in its (lack of) processing. As pointed out by the community, little attention has been devoted to the topic over the past few months. The purpose of this text is to revive the SNIP process and propose short-term improvements.
EIP vs SNIP today
The fundamental difference is in handling protocol-level improvement proposals, i.e those which require protocol changes. Ethereum, being decentralized, requires “meta-consensus” on protocol changes among validators and subsequently among client teams. The Ethereum Foundation is a considerable driving force for EIPs, but it does not directly control block proposals. Starknet, in its currently centralized state, strictly requires involvement of the Starknet core teams in StarkWare to implement protocol changes.
Since genesis, almost all protocol-level changes (e.g. version features) have not gone through the full SNIP route, having been decided internally instead. Overall we think this is sensible and justified by the need to move and add features much faster than in Ethereum. That being said, the long term objective is clear: when Starknet is decentralized and mature, the process will closely mirror the Ethereum EIP protocol.
Thus we are left with the question of short-medium term: on the one hand, iterations and versions are still frequent compared to Ethereum. On the other hand, we want to step toward a SNIP process that approaches the “real thing” over time.
Short-medium term proposal
Following SNIP-1, GitHub remains the place to submit SNIPs and is the source of truth for their documentation. Other media are for discussions and “advertising”.
The process
- Author submits SNIP.
- Following SNIP-1#Editor Responsibilities, the editor performs syntactic checks. If the checks pass then merge to main. Otherwise reject.
- After merge to main, the author should change status to review and begin discussions on the community forum, which is the intended domain for discussing SNIPs. The author has edit permissions and is free to modify their proposal at will.
- SNIPs enter stale status after 6 months and require an editor (SW) to revive.
- An editor can change the status to last call which activates a two week timer. Assuming no other actions, a SNIP in last call status automatically becomes final when the timer runs out.
What does it really mean to finalize?
During the centralized phase of Starknet, finalization has two essential steps: entering the roadmap and running in production. In the decentralized phase, finalization means sufficiently widespread adoption among Starknet operators and full nodes.
What will change now?
The Starknet core teams are committed to much greater responsiveness, both on GitHub and in Community Forum discussions. Specifically, feel free to ping @ilia, @Ohad-StarkWare, @FeedTheFed, and @Leo_L!
What now?
Write SNIPs! 
