Stellar Protocol: where CAPs, SEPs and SLPs live

Three tracks of proposal, one place to read them

The repository description is deliberately modest: developer discussion about possible changes to the protocol. The README expands it, and the expansion is precise about what kind of artefact lives here.

This repository is home to Core Advancement Proposals and Stellar Ecosystem Proposals, and it also contains Stellar Limits Proposals. The three are distinguished by scope rather than by format.

CAPs deal with changes to the core protocol of the Stellar network. A CAP is the mechanism by which a change to how the network itself behaves is proposed, debated and accepted.

SEPs deal with changes to the standards, protocols and methods used in the ecosystem built on top of the Stellar network. If you are writing an anchor service, a payment integration or a wallet interface convention, that is SEP territory, and the README links the process for SEPs in the ecosystem directory.

SLPs propose changes to protocol limits and related network configuration. That is a narrow but consequential category: the numbers and settings the network runs with, rather than the transactions it accepts or the interfaces built above it. The README points at the limits directory for the process and the list of SLPs.

The resemblance to other ecosystems is stated in the README, with Bitcoin's BIPs and Ethereum's EIPs named as the models. Anyone who has followed a BIP or an EIP will recognise the shape: a numbered document, a status, a process, and a permanent record of what was decided and why.

A proposal is a Markdown file with a number

The file naming is strict, and it is the simplest way to understand the system. Accepted CAPs live in the core directory as cap-xxxx.md, where xxxx is the CAP number with leading zeros, with cap-0051.md given as the example. Accepted SEPs live in the ecosystem directory as sep-xxxx.md with the same convention and sep-0051.md as the example. SLPs live in the limits directory as slp-xxxx.md, with slp-0004.md as the example.

The leading zeros matter because they keep the files sorting numerically in a directory listing, which is how anyone actually browses the archive.

Two template files sit at the root, cap-template.md and sep-template.md, and the root directory contains templates for creating your own CAP or SEP. That is the entry point for a contributor: copy the template, fill in the sections, open a pull request, and the discussion happens in the pull request itself, which matches the repository's stated purpose as a place for developer discussion.

Anything that is not text goes into a separate contents directory, with a subdirectory per proposal named cap-xxxx or sep-xxxx containing all media and script files for that document. The README's own example shows a cap-0003 directory holding a single SQL file, get_offer_stats.sql, which tells you something about the kind of artefact involved: proposals routinely ship an executable check alongside the prose.

The result is a design where the prose is the specification and the scripts in contents are the evidence. That split is what makes an accepted proposal auditable years later.

The tree shows how the archive is organised

The README prints the expected repository structure, and it is worth reading closely because it is the map of the whole archive.

The top of the tree holds the working files:

├── CONTRIBUTING.md
├── README.md
├── cap-template.md
├── contents
│   └── cap-0003
│       └── get_offer_stats.sql
├── core
│   ├── cap-0001.md
│   ├── cap-0002.md
│   ├── cap-0003.md
│   └── README.md

And the rest of the archive:

├── ecosystem
│   ├── README.md
│   ├── sep-0001.md
│   ├── sep-0002.md
│   └── sep-0003.md
├── limits
│   ├── slp-0001.md
│   └── slp-0004.md
└── sep-template.md

Two things stand out. Each directory carries its own README.md, and those files are the process documents the main README points to for CAPs and SEPs. The process lives next to the documents it governs rather than in a separate governance site, which means the rules and the history are versioned together.

The other observation is that each proposal is a single Markdown file. There is no build step producing HTML, no database of proposals, no index beyond directory listings. A reader who wants to know what was decided about a topic browses the numbers or uses the search of the hosting platform.

For a repository that acts as the permanent record of a protocol's history, that simplicity is a defensible trade. It is also why the tooling around it is so thin.

The tooling is prettier and a Makefile

The package.json in this repository contains exactly two scripts, both of which format the SEP documents:

    "sep-prettify": "prettier ecosystem/*.md --write",
    "sep-check": "prettier ecosystem/*.md --check"

The devDependency is a single package, prettier pinned at 2.8.8, and the package manager is yarn at 1.22.19. The check script is the one that runs in continuous integration, and it only covers ecosystem/*.md.

That narrowness is worth noticing. The formatting guarantee applies to SEPs and not to CAPs or SLPs, which tells you the repository has not standardised formatting across all three tracks. For a contributor that is a small but real detail: your SEP will be normalised by a tool, your CAP may not be.

The rest of the repository supports the same minimal approach. There is a GNUmakefile and a bin/ directory for whatever local tasks the maintainers need, a .prettierrc and .prettierignore, and github-pandoc.css for rendering Markdown to HTML with the GitHub look. A .claude/ directory sits at the top level, which suggests part of the working process is written down for an assistant rather than only for a person. The .github/ directory carries the workflows and templates.

There is no index generator, no proposal linter, no automated status tracker. The consistency you get is the consistency a reviewer maintains by hand, which for a repository with numbered documents and a documented process is roughly what you would expect.

Choosing a track, and what the split buys you

The three-track split is the part of this design that pays off in practice, because the audience for each kind of change is different and the cost of getting it wrong is different too.

A CAP changes the core protocol. That is the deepest layer: the behaviour of the network itself, and therefore the layer with the largest compatibility consequences for every node, every client library and every anchor. The process document lives in core/README.md.

An SEP changes the standards, protocols and methods of the ecosystem above the network. This is where most application developers live, because an SEP describes conventions between services rather than the network's rules. The process document lives in ecosystem/README.md.

An SLP changes protocol limits and related network configuration. The directory holds slp-0001.md and slp-0004.md in the example tree, so the numbering is shorter than the other two tracks, which says something about the pace of that kind of change.

For a developer building against Stellar, the archive is a way to answer questions you would otherwise guess at. Whether a transaction type exists, how a fee is computed, what an anchor is expected to do: the answer is a numbered document with a status, and often a script in contents that shows the expected behaviour rather than describing it.

The weakness of the arrangement is the same as its strength. Because the record is prose plus scripts rather than a specification language, correctness depends on reviewers reading carefully, and because it is prose rather than code, it cannot be executed by anything other than a human.

What this repository is not

A few expectations need adjusting before you start reading.

There is no code to build and nothing to install. The repository is documents, templates and scripts used as supporting artefacts, and the package.json exists only for the formatting tooling. The primary language detected for the repository is RPC, which is an artefact of the mix of SQL files in contents directories and Markdown everywhere else rather than a sign that anything here speaks RPC.

There are no GitHub releases, because there is nothing to release. The last push was on 2026-10-14 and the repository is not archived, so proposals continue to be added, but there is no version of the protocol you can download from here and no changelog to diff.

The licence is reported as unknown and there is no LICENSE file among the top-level entries. For a repository of public specifications that is unusual. It does not affect the ability to read and follow the proposals, but if you intend to copy text or a script from an accepted document into your own project, the terms are not stated in the repository, and that is a question for the Stellar Development Foundation rather than for the file header.

Finally, this is not where the protocol is implemented. The proposals define standards, and the client libraries, the SDKs and the network software live in other repositories. Reading this archive tells you what the rules are and why they are what they are, which is the valuable part, but a proposal in the ecosystem directory is not a shipped feature. The difference between a decision and a release is the gap you have to close yourself.

Editorial conclusion

Stellar Protocol fits a developer who needs to know how a change to the Stellar network is proposed, argued and recorded, and who wants the accepted text of every past decision in one place. It is the wrong repository to look for runnable code, for a stable API or for a release, since there are no GitHub releases, the licence is unknown and the primary language detection resolves to RPC simply because the tree is a mix of SQL and documentation. Before writing a proposal, read the process document for your track in core/, ecosystem/ or limits/, copy the matching template from cap-template.md or sep-template.md, and put any media or script files in a contents subdirectory named for the proposal number, because that is where the tooling and reviewers expect them.

Frequently asked questions

Official sources

1. Issues
2. README
3. stellar/stellar-protocol on GitHub