CAP status terms
- Draft - a CAP that is open for consideration.
- Pending - a CAP in it's final week of review. This is your last chance to comment and raise concerns.
- Accepted - a CAP that is planned for immediate adoption, i.e. expected to be included in a next version of the protocol.
- Final - a CAP that has been implemented (ie, changes fully merged into
Summary list of all CAP proposals
|0001||Bump Sequence||Nicolas Barry||Final|
|0002||Transaction level signature verification||Nicolas Barry||Final|
|0003||Asset-backed offers||Jonathan Jove||Final|
|0004||Improved Rounding for Cross Offer||Jonathan Jove||Final|
|0005||Throttling and transaction pricing improvements||Nicolas Barry||Pending|
|0006||Add ManageBuyOffer Operation||Jonathan Jove||Pending|
|0007||Deterministic Account Creation||Jeremy Rubin||Draft|
|0008||Self Identified Pre-Auth Transaction||Jeremy Rubin||Draft|
|0009||Linear/Exterior Immutable Accounts||Jeremy Rubin||Draft|
|0010||Fee Bump Account||Jeremy Rubin||Draft|
|0011||Relative Account Freeze||Jeremy Rubin||Draft|
|0013||Change Trustlines to Balances||Dan Robinson||Draft|
|0014||Adversarial Transaction Set Ordering||Jeremy Rubin||Draft|
|0015||Bump Fee Transactions||OrbitLens||Draft|
How the protocol changes
Software is never done. As the Stellar Protocol evolves we want to ensure that changes serve the values of the Stellar network. So as you are proposing protocol changes it is important to keep those in mind...
Stellar Protocol Values
- The Stellar network should be secure and reliable, and should bias towards safety, simplicity, reliability and performance over new development.
- Simplicity towards the protocol - we should not over complicate the protocol itself, and the more outside of the core protocol, the better.
- Embrace principle of modifying only the outermost layers possible, keeping innermost layers stable. Order of layers: historical / ledger XDR is innermost, then observable transaction semantics, then consensus XDR, then DB state, overlay XDR, unobservable tx semantics (eg. perf or bug fixes), Horizon semantics, public APIs, client libs.
- Also embrace higher bar for acceptance as changes affect inner layers: implementation prototype, version migration logic, performance evaluation and testing needs go up the more intrusive a change. Don’t accept change proposals that are both intrusive and underdeveloped.
- Clarity of intent - new operations and functionality should be opinionated, and straightforward to use.
- User safety over additional functionality - minimize attack surface at the lowest levels.
- The Stellar network should run at scale and at low cost to all users.
- In support of this, the Stellar network should support off-chain transactions, e.g. Starlight.
- The Stellar network should facilitate simplicity and interoperability with other protocols and networks.
- In support of this, the Stellar network should facilitate side-chain transactions to enable sub-networks.
- The Stellar network should support decentralization wherever possible, but not at the expense of the majority of its values.
- It should be easy to develop projects using the Stellar Network
- The Stellar network should make it easy for developers of Stellar projects to create highly usable products
- The Stellar network should enable cross-border payments, i.e. payments via exchange of assets, throughout the globe, enabling users to make payments between assets in a manner that is fast, cheap, and highly usable.
- In support of this, the Stellar network should support an orderbook that values simplicity over functionality, and one that primarily serves to enable cross-border payments.
- In support of this, the Stellar network should facilitate liquidity as a means to enabling cross-border payments.
- In support of this, the Stellar network should enable asset issuance, but as a means of enabling cross-border payments.
- The Stellar network should enable users to easily exchange their non-Stellar based assets to Stellar-based assets, and vice versa.
These are the steps from idea to deployment
- Idea is proposed on the core mailing list
- Discussion on mailing list
- Someone gathers and collates all the various proposals
- Someone is picked to write a CAP for a given proposal. They then:
- Fork the repository by clicking "Fork" in the top right.
- Write the CAP in their fork of the repository. There is a template CAP here. The first PR should be a first draft of the CAP. It must follow the template.
- Add a link to the CAP proposal in this document, linking to the appropriate
- If your CAP requires images or other supporting files, they should be included in a subdirectory of the
contentsfolder for that CAP as follows:
contents/cap-X(for CAP X). Links should be relative, for example a link to an image from CAP-X would be
- Drafts are numbered by the author but subject to change when made final
- CAP is written and set as
- Submit a Pull Request to Stellar's protocol repository.
- Buddy is assigned (Jon, Graydon, Jeremy, Johnny, Orbitlens) and will merge your PR if you properly followed the steps above.
- Discussion of the draft CAP will now take place on the mailing list. There should be some iteration between discussion and further PRs refining the CAP.
- If the CAP is not receiving enough support the Buddy will mark as rejected and move it to the archive. Otherwise the CAP is moved to
- There is now one week for people to make final comments.
- After that the CAP is discussed at the next protocol meeting.
- Needs unanimous approval from (Nicolas, Jed, David) to become
Acceptedotherwise the CAP is
Rejectedor turned back to
Draftwith some comments.
- Implementer is decided and that person starts implementing.
- Once a CAP is implemented, a PR should be submitted to update its status to
CAP Key Members: Nicolas, Jed, David
CAP Buddies: (Jon, Graydon, Jeremy, Johnny, Orbitlens)
Buddies are responsible for moving a CAP along the process. They should make sure the draft is either
Rejected in a timely manner.