Stamps Improvement Proposals (SIPs)
The Stamps Improvement Proposal process provides a structured framework for proposing, reviewing, and activating protocol-level changes to the Bitcoin Stamps ecosystem. Each SIP coordinates implementation across indexers to maintain consensus.
What is a SIP?
A SIP (Stamps Improvement Proposal) is required for changes that affect protocol consensus — meaning all indexers must implement the change identically for consistent behavior across the ecosystem.
SIPs are needed for:
- New SRC-20 operations (conditional transfers, bridges, refunds)
- New fields on existing operations (hashlock, timelock)
- New encoding methods (binary formats, P2WSH structures)
- Cross-chain bridge protocols
SIPs are NOT needed for indexer-only optimizations, API features, or bug fixes that don't change consensus behavior.
Process Document: SIP-0000 defines the complete proposal lifecycle and review process.
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.
Getting Involved
The SIP process is open to all community members:
- Discuss — Join conversations in GitHub issues for active SIPs
- Propose — Create new protocol proposals following the SIP-0000 format
- Review — Provide technical feedback on specifications
- Implement — Build indexer support for accepted proposals
GitHub Repository: stampchain-io/btc_stamps
The SIP process is intentionally lightweight — enough structure to coordinate across indexers without slowing down innovation.