SIP: [SIP number] Title: [SIP title] Authors: [List of authors' names and contact info] Status: [Draft, Review, Final, etc.] Type: [Standards Track, Meta, Informational] Category: [Core, Networking, Interface, ERC] Created: [Date] Updated: [Date]
A brief (one or two sentence) explanation of the SIP.
A short (~200 word) description of the technical/strategy proposal being addressed.
The motivation is critical for SIPs that want to change the Solayer protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the SIP solves. SIP submissions without sufficient motivation may be rejected outright.
The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow for any implementations to be created.
Test cases for an implementation are mandatory for SIPs that are affecting major protocol changes. Other SIPs can choose to include links to test cases if applicable.
The implementations must be completed before any SIP is given status “Final”, but it need not be completed before the SIP is accepted. It is better to finish the specification and rationale first and reach consensus on the SIP before writing code.
All SIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. The SIP must address the following questions: What potential security issues does this proposal introduce? How does this proposal impact the security of the Solayer? Are there any known potential attacks, and if so, how can they be mitigated?
A list of references used in the SIP, including any related SIPs, academic papers, or other documents.