Repository files navigation

The goal of the SNIP project is to document standardized protocols for Starknet related softwares and to document them in a high quality and implementable way.

The SNIP process is the process that a contributor goes through to propose a change to the Starknet ecosystem. It is inspired by theEIP process.

Here is the process that a contributor should follow:

1. ReviewSNIP-1.
2. Fork the repository by clicking "Fork" in the top right.
3. Add your SNIP to your fork of the repository. There is atemplate SNIP here.
4. Submit a Pull Request toSNIPs repository

Your first PR should be a first draft of the final SNIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new SNIP and assign it a number before merging it. Make sure you include adiscussions-to header with the URL to a discussion forum or open GitHub issue where people can discuss the SNIP as a whole.

Once a SNIP is merged, it is consideredDraft. The SNIP author may then continue to work on the SNIP, gathering feedback and making changes. The SNIP author can request a review from the SNIP editors by adding thereview-requested label to the PR. The SNIP editors will review the PR and either approve it, request changes, or close it with an explanation. For a SNIP to beAccepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

Once a SNIP has beenAccepted, the reference implementation must be completed. When the reference implementation is complete and incorporated into the main source code repository, the status will be changed toFinal.

To update aDraft SNIP, the author can submit a PR making the required changes. Note that, because the SNIPs are stored as markdown files in a versioned repository, there is no particular advantage to updating the version of a SNIP. In particular, the SNIP editors don't have to list theDraft SNIPs, they can just list theFinal SNIPs.

Lifecycle overview:

Reach out to the maintainer at one of the following places:

• GitHub Discussions
• Contact options listed onthis GitHub profile

If you want to saythank you or/and support active development of SNIPs:

• Add aGitHub Star to the project.
• Tweet about the SNIPs.
• Write interesting articles about the project onDev.to,Medium or your personal blog.

Together, we can make SNIPsbetter!

First off, thanks for taking the time to contribute! Contributions are what make the open-source community such an amazing place to learn, inspire, and create. Any contributions you make will benefit everybody else and aregreatly appreciated.

Please readour contribution guidelines, and thank you for being involved!

For a full list of all authors and contributors, seethe contributors page.

SNIPs follows good practices of security, but 100% security cannot be assured.SNIPs is provided"as is" without anywarranty. Use at your own risk.

For more information and to report security issues, please refer to oursecurity documentation.

This project is licensed under theMIT license.

SeeLICENSE for more information.

The SNIPs repository was heavily inspired byEIPs.

Shout out to all EIP editors and active contributors.