SIP Update Policy

[Hero-Gamer]

Hi all,

Putting in a conversation to confirm the updating/replacing method for existing SIP. So we can ahead making proposal for updating SIP-000.

2 main ideas on the table so far:

1. Replacing a SIP by a new SIP, retiring the old. (Matches currently method indicated in SIP-000)

• Use a new SIP allocation to replace the existing SIP that's ratified already.
• Example: If we want to update SIP-000: SIP process, we would submit SIP-035 and that will be the new SIP process SIP, we would retire SIP-000.
• Note: For this is the approach taken by BIP Editor. Process: Activate BIP3 bitcoin/bips#1820 - they are replacing BIP-0002 old process with BIP-0003 new process. (I reached out to an active BIP Editor Jon https://github.com/jonatack - to confirm their approach. He said "Yes, BIP2 remains and keeps its number and filename. Only a couple of its headers are updated.BIP2 Status would be updated from Active to Replaced and a header “Superseded-By: 3” would be added")

2. Keeping same SIP number. Archive the previous version. (new idea)

• Example: If SIP-000 were to be updated, we would just update the doc, ensure there is a history of the previous version saved in the archive folder (e.g. sip-000-stacks-improvement-proposal-process_V1.md or could be just the date created sip-000-stacks-improvement-proposal-process_2020-06-23.md)
• Same would go to SIP-009 NFT if it were need updating, or a SIP-010 that need updating. Or a SIP-028 about sBTC federation, it can keep the same number just updating the document with our usual SIP process review & approval of course.

Context:

• As we are in the process of updating SIP-000 based on all the learnings so far, and potentially updating SIP-009 NFT Standard (if I am not wrong majority of NFT contracts do not adhere to SIP-009 as Gamma's NFT contract is a slight variation on SIP-009.), and any other future updates to existing SIP.

I asked my GPT for some thoughts you can see her: https://chatgpt.com/share/68d5904b-7558-800e-859c-5b373c30a412
Some food for thoughts:

Method 1 - Replacement Model
✅ Advantages:
Preserves immutability — no ratified SIP is ever altered.
Matches Bitcoin precedent (familiar for cross-contributors).
Enables clear supersession metadata (Superseded-By).
Easier for tooling to index authoritative SIPs.

⚠️ Disadvantages:
Creates “SIP number sprawl.”
Slower iteration since each update requires a full new SIP cycle.
Developers may need to cross-reference multiple SIPs to understand an evolving standard.

In-Place Update Model
✅ Advantages:
Keeps a single authoritative number per standard (e.g., always SIP-009 for NFTs).
Faster and more lightweight for iteration.
Reduces clutter in the SIP repository.
More convenient for developer references.

⚠️ Disadvantages:
Breaks the immutability principle (ratified SIPs can be edited).
Introduces ambiguity unless archived versions are carefully tracked.
Diverges from Bitcoin practice, reducing familiarity for Bitcoin core developers.

We need to confirm the approach to take to updating.
Would love to hear more thoughts on what people think which method people lean towards?

[obycode]

I like option 1, following the BIP model. I think a link/reference to SIP-XYZ should always go to the same document. If it has been replaced by a newer SIP, that should be clearly indicated at the top of the file, including a link to the new one. In addition to basic metadata in the headers at the top of the document, we can also make use of markdown alerts to ensure readers don't miss it.

Important

SIP-ABC has been retired. It is replaced by SIP-XYZ

[jcnelson]

I'm fine with option 1 as long as it doesn't lead to text fragmentation. For example, if we're replacing SIP-000 with SIP-XYZ, then SIP-XYZ needs to contain the complete, definitive governance process. SIP-XYZ can't just be a list of changes with back-pointers to SIP-000, since that would make it hard for newcomers to figure out what the current governance process is.

[wileyj]

+1 for option 1, with the same mentioned caveats that the new SIP should be a complete process document and not a diff.

edit: thinking about this a little further too - i don't see anything in the current sip-000 doc that defines a sip numbering scheme (outside of XXXX is the SIP number,
possibly we could reserve sip-000, ratify a new sip as SIP-0001 (with the recommended updates to sip-000 replaced-by etc). next update would be sip-0002 etc.

[obycode]

possibly we could reserve sip-000, ratify a new sip as SIP-0001 (with the recommended updates to sip-000 replaced-by etc). next update would be sip-0002 etc.

If we took that route, I'd prefer sip-000-1, with the extra dash, to make it more clear.

[Hero-Gamer]

Regarding the 0001 or 000-1 method, either way sounds fine as a method for simple META (documentation/guide) stuff, but what if one day we need to update SIP-009 or SIP-010 or SIP-030 for whatever reason in the future, would the 009-1 or 0091 method be a blocker or barrier for external parties (like a Binance or Kraken) to upgrade their integration?

[wileyj]

Regarding the 0001 or 000-1 method, either way sounds fine as a method for simple META (documentation/guide) stuff, but what if one day we need to update SIP-009 or SIP-010 or SIP-030 for whatever reason in the future, would the 009-1 or 0091 method be a blocker or barrier for external parties (like a Binance or Kraken) to upgrade their integration?

I don't think so - those are standalone sips derived from sip-000. if they need to change in the future, there is a method for doing so. either they may be amended, or overridden by a new sip entirely that builds upon them. in that case, it's also entirely possible that the sip number chosen could be something like sip-010-1, if sip-000 is updated to allow that type of versioning.

sip-000 will always be an outlier here, since it defines the process by which all over sips must adhere.

regardless, we'll always have a historical sip-000 with an update to point to whatever the latest version is.