Propositions d'amélioration des Stamps (SIP)
Le processus de Proposition d'amélioration des Stamps fournit un cadre structuré pour proposer, examiner et activer des changements au niveau du protocole dans l'écosystème Bitcoin Stamps. Chaque SIP coordonne l'implémentation entre les indexeurs pour maintenir un comportement cohérent dans tout l'écosystème.
Qu'est-ce qu'un SIP ?
Un SIP (Stamps Improvement Proposal) est requis pour les changements qui affectent le consensus du protocole — ce qui signifie que tous les indexeurs doivent implémenter le changement de manière identique pour un comportement cohérent dans l'écosystème.
Les SIP sont nécessaires pour :
- Nouvelles opérations SRC-20 (transferts conditionnels, ponts, remboursements)
- Nouveaux champs sur les opérations existantes (hashlock, timelock)
- Nouvelles méthodes d'encodage (formats binaires, structures P2WSH)
- Protocoles de pont inter-chaînes
Les SIP ne sont PAS nécessaires pour les optimisations d'indexeur uniquement, les fonctionnalités API ou les corrections de bogues qui ne changent pas le comportement du consensus.
Document de processus : SIP-0000 définit le cycle de vie complet de la proposition et le processus de révision.
SIP Registry
Current protocol proposals and their implementation status:
| SIP | Title | Status | GitHub Issue |
|---|---|---|---|
| SIP-0000 | Stamps Improvement Proposal Process | Active | #686 |
| SIP-0001 | SRC-20 Conditional Transfers (Hashlock/Timelock) | Draft | #685 |
| SIP-0002 | SRC-20 UTXO Binding & Transfer Format v2.0 | Superseded | #484 |
| SIP-0003 | SRC-20 Cross-Chain Bridge Specification | Draft | #485 |
| SIP-0004 | Shielded SRC-20 — Privacy Extension (Phased) | Draft | #687 |
| SIP-0005 | Binary Transfer Format for SRC-20 | Draft | #688 |
| SIP-0006 | Native SRC-20 AMM (Automated Market Maker) | Draft | #689 |
| SIP-0008 | Dual Transaction Parsing — Combined SRC-20 Transfer + Stamp Issuance | Draft | #692 |
Status Definitions
- ActiveProcess document in effect
- DraftProposal written, open for initial feedback
- ReviewSpecification complete, formal review in progress
- AcceptedSpecification agreed, activation block pending
- ActivatedActivation block set, countdown in progress
- FinalLive on mainnet, all indexers processing
- SupersededReplaced by a newer SIP
- WithdrawnAuthor abandoned
- RejectedCommunity consensus against implementation
Implementation Roadmap
Strategic phasing ensures each foundation is battle-tested before dependent features build upon it.
HTLC capabilities, binary encoding, and dual transaction parsing
Native on-chain liquidity with AMM functionality
Bridge connectivity to EVM chains
Wrapped asset standard enabling Bitcoin-native liquidity pools
Stealth addresses to zero-knowledge shielded pools
Recommended Implementation Order
| Priority | SIP | Effort | Hard Dependencies | Soft Dependencies |
|---|---|---|---|---|
| 1 | SIP-0001SRC-20 Conditional Transfers (Hashlock/Timelock) | 3-4 weeks | None | — |
| 2 | SIP-0005Binary Transfer Format for SRC-20 | 2 weeks | None | — |
| 3 | SIP-0008Dual Transaction Parsing — Combined SRC-20 Transfer + Stamp Issuance | 2-3 weeks | None | SIP-0005 |
| 4 | SIP-0006Native SRC-20 AMM (Automated Market Maker) | 4-6 weeks | None | SIP-0005 |
| 5 | SIP-0003SRC-20 Cross-Chain Bridge Specification | 6-8 weeks | None | SIP-0001 |
| 6 | SIP-0004Shielded SRC-20 — Privacy Extension (Phased) | 2-18 months | None | — |
Gating Criteria Between Phases
Strategic checkpoints ensure stability before adding complexity:
| Gate | Condition | Rationale |
|---|---|---|
| Phase 1 → Phase 2 | SIP-0001 live for 2000+ blocks (~2 weeks) | HTLC must be battle-tested before AMM dependencies |
| Phase 2 → Phase 3 | SIP-0006 Phase 1 stable for 1000+ blocks | AMM core proven before cross-chain integration |
| Phase 3 → Phase 4 | SIP-0003 bridge operational, security audited | Bridge custody is high-risk — requires validation |
Future Protocol Extensions
These extensions are planned but not yet formally drafted:
| Future SIP | Purpose | Prerequisite |
|---|---|---|
| SIP-0007 (Wrapped Asset Standard) | wBTC/wUSDT mint/burn protocol, custody model | SIP-0003 bridge architecture |
| Concentrated Liquidity | Uniswap V3-style capital efficiency | SIP-0006 Phase 1 proven stable |
| Multi-hop Router | A→B→C swaps in single operation | Multiple active AMM pools |
| Governance | Protocol fee distribution, parameter changes | Ecosystem maturity |
Indexer Coordination
SIPs that change consensus behavior require coordination across multiple indexers:
- stampchain (primary indexer): Must implement for activation
- OpenStamp: Should implement for ecosystem consistency
- Future indexers: Implementation encouraged but not blocking
For a SIP to reach Accepted status:
- stampchain team approves the specification
- At least one other indexer acknowledges the specification
- No unresolved security concerns remain
Activation blocks are coordinated with minimum 4 weeks lead time to allow all indexers to prepare.
S'impliquer
Le processus SIP est ouvert à tous les membres de la communauté :
- Discuter — Rejoindre les conversations dans les issues GitHub pour les SIP actifs
- Proposer — Créer de nouvelles propositions de protocoles en suivant le format SIP-0000
- Examiner — Fournir des retours techniques sur les spécifications
- Implémenter — Construire le support d'indexeur pour les propositions acceptées
Dépôt GitHub : stampchain-io/btc_stamps
Le processus SIP est intentionnellement léger — assez de structure pour coordonner entre les indexeurs sans ralentir l'innovation.