satoshilabs/slips: Technical Standards and Proposals

Why SatoshiLabs Keeps SLIPs Outside the BIP Process

The repository addresses a standards problem for SatoshiLabs projects. Some technical decisions and features fall beyond the scope of Bitcoin Improvement Proposals because they concern products, wallet conventions, networks, or cryptographic mechanisms maintained around those projects. The README describes SLIPs as an extension to the BIP process and a home for documents considered unsuitable for submission to the BIP repository.

This distinction matters for contributors looking for the correct decision record. A proposed change that modifies Bitcoin itself may belong in the BIP process, while a SatoshiLabs-specific specification can use the SLIP format. The repository therefore does not try to replace Bitcoin Improvement Proposals. It provides another documented channel for technical choices that BIP does not cover.

Each proposal is expected to contain two principal elements: a concise technical specification and the rationale for the feature. This requirement gives implementations a common reference while retaining the reasoning behind a design. It is especially relevant for wallet and cryptographic formats, where knowing only a field name does not establish how the format is structured or why it exists.

The SLIP Index and Document Lifecycle

SLIPs is a document-based repository rather than an application with a runtime API. The root README acts as an index, linking individual files such as `slip-0010.md`, `slip-0039.md`, and `slip-0173.md`. Based on the repository layout, each numbered Markdown file is the primary specification, while some proposal directories appear to hold associated material. The repository also includes `check.sh`, `.travis.yml`, and `markdownlint.json`, indicating a text repository with repository-level checks rather than a published software package.

The index gives each proposal a number, title, type, and status. The listed types are `Standard` and `Informational`. Status values include `Draft`, `Active`, `Accepted`, and `Final`. These labels should be read literally. A `Draft` proposal such as `SLIP-0012` does not carry the same maturity as a `Final` proposal such as `SLIP-0011`. An `Active` document may represent an informational or registry document, so its status must be considered together with its type.

The repository includes reserved numbers, including `SLIP-0018` and `SLIP-0026`, both associated with CoSi and marked `Draft`. Reserved identifiers should not be treated as complete specifications merely because their numbers appear in the index. No GitHub releases are published, which leaves the proposal files and their repository history as the available version references.

Wallet Keys, Authentication, and Network-Specific Derivation

The strongest concentration of proposals concerns wallet keys and data formats. `SLIP-0010` specifies universal private key derivation from a master private key, while `SLIP-0021` covers hierarchical derivation of symmetric keys. `SLIP-0039` describes Shamir's Secret-Sharing for mnemonic codes, and `SLIP-0017` addresses Elliptic Curve Diffie-Hellman using a deterministic hierarchy.

Several documents connect derivation conventions to authentication or ownership. `SLIP-0013` covers authentication using a deterministic hierarchy and is marked `Final`. `SLIP-0019` specifies Proof of Ownership and is marked `Accepted`, while `SLIP-0020` proposes Proof of User Confirmation and remains `Draft`. The distinction between accepted and draft matters because the status label is part of the repository's own record of proposal maturity.

Other documents apply derivation conventions to particular ecosystems. `SLIP-0025` covers key derivation for CoinJoin accounts, `SLIP-0048` defines a deterministic key hierarchy for Graphene-based networks, and `SLIP-0077` addresses deterministic blinding key derivation for Confidential Transactions. `SLIP-0023` covers Cardano HD master node derivation from a master seed. These titles identify the relevant documents, but they do not establish compatibility with every wallet implementation.

Encrypted Metadata, Passwords, Credentials, and Payment Requests

The repository also defines formats for protecting or carrying wallet data. `SLIP-0011` specifies symmetric encryption of key-value pairs using a deterministic hierarchy. `SLIP-0012` covers public key encryption using the same general hierarchy concept and remains a `Draft`. `SLIP-0015` defines a format for Bitcoin metadata and its encryption in HD wallets, while `SLIP-0016` specifies password storage and encryption. The latter three are marked `Final`, apart from `SLIP-0012`.

The metadata and password proposals should not be collapsed into one storage recommendation. Their titles assign different scopes: encrypted key-value pairs, Bitcoin metadata in HD wallets, and password storage. An implementation should read the exact proposal file for serialization details, cryptographic construction, and stated rationale rather than infer a general security architecture from the index.

`SLIP-0022` defines a FIDO2 Credential ID format for HD wallets and is marked `Final`. `SLIP-0024` describes a Trezor payment request format but remains `Draft`. `SLIP-0032` proposes an extended serialization format for BIP-32 wallets and is also a `Draft`. These entries show that the repository covers several interchange boundaries, from serialized wallets and credentials to payment requests. The root README does not provide enough detail to substitute for those individual specifications.

Registry Proposals and the Informational Stress-Test Document

Three listed documents serve registry-style roles rather than defining one complete operational feature. `SLIP-0044` registers coin types for BIP-0044 and is marked `Active`. `SLIP-0132` registers HD version bytes for BIP-0032, and `SLIP-0173` registers human-readable parts for BIP-0173. Both are also marked `Active`.

These registrations matter when software maps numeric identifiers or encoded values to named assets, derivation formats, or protocol labels. The index does not enumerate the registered values, so it cannot serve as the implementation source. An engineer must open the corresponding Markdown file and use its exact registrations. Treating an identifier as valid because it appears numerically related to another proposal would add an unsupported assumption.

`SLIP-0014`, Stress Test Deterministic Wallet, is an `Informational` document with `Active` status. Its classification differs from the `Standard` entries because it addresses stress testing rather than defining an interoperability format. This is a useful reminder to distinguish document type from lifecycle status. An active informational document is not equivalent to a final standard.

First Use Through Proposal Numbers, Status, and Git History

There is no software installation step documented in the README because SLIPs is a collection of Markdown specifications rather than a library, CLI, service, or packaged application. The repository provides the documents through its GitHub repository and links each numbered proposal from the root README. It does not document a package manager installation, a runtime dependency set, or an API endpoint.

A first use is therefore a documentation lookup. Start with `README.md`, locate the proposal corresponding to the format or derivation problem, and open its linked Markdown file. Before implementing it, record the proposal number, title, type, and status shown by the index. If the status is `Draft`, treat the proposal as provisional. If the type is `Standard`, compare its detailed specification with the interface your implementation already uses.

For cryptographic proposals, open the linked document rather than implementing from its title. The repository index does not state the test vectors, parameter values, serialization details, or compatibility requirements for these entries. It also does not describe a rollback procedure. The exact proposal file and its repository history are therefore the first sources to preserve in an implementation record.

Maintenance Scope, Releases, and License Boundaries

The repository is not archived, and its last push was on 2026-10-13. That fact records repository activity, but the README does not define a release cadence or promise that every proposal will change regularly. There are no GitHub releases, so there is no project-wide package version or release channel described here. Proposal numbers are identifiers in the index, while `Draft`, `Active`, `Accepted`, and `Final` communicate each document's listed state.

The repository is licensed under `CC-BY-SA-4.0`, identified in the README as the Creative Commons Attribution-ShareAlike 4.0 International License. Reuse and adaptation of the documents must follow that license's attribution and share-alike terms. This is a statement about the repository's stated licensing boundary, not legal advice. Software behavior, patent questions, security guarantees, and third-party component obligations are not discussed in the README.

SLIPs is also not the correct source for every technical decision. BIPs are the destination for changes within Bitcoin and cryptocurrency protocol scope. A team should reject SLIP adoption when its problem belongs in BIP, when a linked proposal is only `Draft`, or when the proposal's technical details do not match the ecosystem being implemented. Product-specific internal conventions are another alternative, but they do not provide this repository's numbered specification and rationale structure.

SLIPs Compared with BIPs and Internal Conventions

A real alternative to SLIPs is the BIP process itself for changes within Bitcoin protocol scope. The difference is topical rather than cosmetic. BIP is the destination for proposals concerning Bitcoin and cryptocurrencies, while SLIPs collects SatoshiLabs proposals considered unsuitable for that repository because their range and implications extend beyond that scope.

Another alternative is a product-specific internal convention. SLIPs centralize concise specifications and rationales in numbered Markdown documents that can be reviewed independently of a product release. An internal convention may be simpler for a single implementation, but external implementers receive less structured information about scope, lifecycle status, and design reasoning unless those details are published elsewhere.

Neither alternative establishes interoperability by itself. A BIP or SLIP still has to match the implementation being modified, and an internal convention may create compatibility work outside the originating product. The appropriate choice depends first on whether the decision belongs in Bitcoin protocol scope and then on whether the referenced proposal is sufficiently detailed and mature for the intended use.

Editorial conclusion

Engineers implementing wallet interoperability, HD derivation, encrypted metadata, CoinJoin accounts, or related registered identifiers should review the applicable SLIP and verify its status and compatibility with the target ecosystem before adopting it. Projects needing changes confined to Bitcoin protocol scope should use the BIP process instead. The repository has no GitHub releases, so callers should pin the exact proposal revisions used rather than assume that a numbered file has a separately versioned release.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. README
4. satoshilabs/slips on GitHub