The Core Advancement Proposal (CAP) process is the formal governance pathway for modifying the Stellar protocol. It governs changes to the Stellar Core node software, the underlying consensus mechanism, and the transaction processing rules that all validators must follow. For protocol engineers and node operators, the CAP lifecycle is not merely a documentation standard; it is the primary signal for upcoming mandatory upgrades, breaking changes to the XDR transaction format, and new ledger header protocol versions that require coordinated activation to prevent network divergence.

CAP Process and Lifecycle
Introduction
A canonical guide to the Core Advancement Proposal process from pre-proposal to network activation, defining the roles, stages, and operational gates that turn a design idea into a binding part of the Stellar protocol.
A CAP progresses through a defined sequence of states—starting as a draft, moving through a review and consensus-building phase, and culminating in a validator vote to upgrade the network. The process is shepherded by a CAP Champion, who is responsible for building technical consensus, while the Stellar Development Foundation (SDF) often plays a coordinating role in shepherding proposals to implementation in Stellar Core. The final activation gate is a validator-led vote using the setoption operation to upgrade the protocolVersion, making the change binding on all compliant nodes. Understanding this lifecycle is critical for anticipating when compatibility testing, integration updates, and operational changes must be completed.
For builders and operators, the CAP process is the leading indicator of protocol-level risk. A CAP that introduces a new transaction envelope format or modifies the Soroban host environment's resource pricing directly impacts wallet SDKs, exchange integrations, and smart contract deployment costs. Monitoring the CAP pipeline allows teams to perform proactive impact assessments, participate in technical discussions before a change is locked in, and prepare their infrastructure for testnet and mainnet activation. Chainscore Labs supports this readiness by providing protocol impact assessments, upgrade compatibility reviews, and integration testing for teams that need to act on a CAP before it reaches the validator voting stage.
Quick Facts
Key phases, roles, and operational checkpoints for a Core Advancement Proposal moving from idea to network activation.
| Phase | What happens | Who is involved | Action for operators |
|---|---|---|---|
Pre-Proposal | Idea is socialized on the stellar-dev mailing list and community calls to gauge interest and refine scope. | CAP Champion, community members, SDF protocol designers | Monitor discussions for changes that may alter transaction structure or resource pricing. |
Draft | Champion submits a pull request to the stellar-protocol repository with a formal CAP document following the standard template. | CAP Champion, CAP Editors | Review the draft for potential breaking changes to Horizon, SDKs, or validator configuration. |
Review | SDF protocol team, community, and working groups provide technical feedback. The proposal may undergo significant revision. | SDF engineering, node operators, wallet developers, ecosystem architects | Run prototype implementations against Stellar Core testnet to identify integration breakage early. |
FCP Proposal | Editors assign a status of 'FCP Proposed' signaling the final comment period has begun for a mature draft. | CAP Editors, CAP Champion | Prepare internal upgrade runbooks and schedule compatibility testing against the proposed XDR or protocol version. |
Final Comment Period | A mandatory waiting period where any unresolved objections must be raised before the proposal can advance. | All ecosystem participants | Submit any critical operational or security objections before the deadline to prevent a flawed proposal from advancing. |
Accepted | The CAP is merged as 'Accepted', indicating consensus that the change should be implemented in a future Stellar Core release. | CAP Editors, SDF Core team | Begin formal integration testing with the accepted specification and allocate engineering resources for the mandatory upgrade. |
Implementation & Activation | SDF ships the change in a new Stellar Core version. Validators coordinate to vote and upgrade the network protocol version. | SDF Core team, validators, node operators | Upgrade nodes to the required Stellar Core version and vote to apply the upgrade before the network transitions. |
Final | The change is live on mainnet and the CAP status is set to 'Final'. No further modifications are expected. | All network participants | Decommission old client versions and monitor network health for unexpected ledger behavior or performance regressions. |
The CAP Lifecycle: From Draft to Activation
A technical walkthrough of the Stellar Core Advancement Proposal process, from initial concept to validator ratification and network activation.
The Core Advancement Proposal (CAP) process is the formal mechanism for evolving the Stellar protocol. It governs how changes to the Stellar Core codebase, the Soroban smart contract environment, and the underlying XDR transaction schema are proposed, debated, and ultimately adopted by the network's validators. Understanding this lifecycle is critical for node operators and protocol engineers who must anticipate breaking changes, schedule mandatory upgrades, and ensure compatibility before a new protocol version is signaled in the ledger header.
A CAP begins as a draft championed by a community member or a Stellar Development Foundation (SDF) engineer. The proposal must precisely define the motivation, technical specification, and rationale for the change. The lifecycle progresses through distinct states—Draft, Proposed, Accepted, Final, and Rejected—with each transition requiring a consensus-driven decision by the CAP Core Team, a group of protocol stewards. For protocol-level changes that alter consensus rules or transaction validity, the final step is a validator vote to upgrade the network. This is not a simple software release; validators must coordinate to set the upgrade flag in the ledger header, triggering a synchronous protocol version bump across the network.
The operational impact of a CAP is determined by its type. A change to the transaction envelope format or a new operation type requires SDK and wallet developers to update their XDR parsing and transaction construction logic. A Soroban environment upgrade, such as a change to the WASM metering model or host function costs, directly impacts smart contract execution costs and may require developers to re-benchmark their contracts. Node operators must monitor the lifecycle closely: once a CAP reaches 'Final' status and is included in a Stellar Core release, the window for testing and integration begins. Failure to upgrade before the validator vote deadline results in ledger divergence and an effective loss of consensus participation. Chainscore Labs provides upgrade readiness reviews and integration impact assessments to help teams navigate this critical window without disrupting their services.
Roles and Responsibilities
CAP Champion
The champion is the author and primary advocate for a proposal. They are responsible for writing the CAP according to the template, socializing the idea with the developer community, and driving it through each stage of the lifecycle.
Key Actions:
- Draft the specification and justification in the
stellar-protocolrepository. - Present the design on the Stellar Dev mailing list and community calls.
- Incorporate feedback from protocol architects and node operators.
- Coordinate with the SDF for implementation planning.
- Ensure the CAP status is updated accurately as it progresses.
A champion does not need to be an SDF employee; many impactful CAPs originate from independent builders. However, a champion must be persistent and technically rigorous to navigate the consensus-building process.
Impact on Integration and Operations
The CAP lifecycle directly dictates when node operators, wallet providers, and exchanges must perform mandatory upgrades, adjust transaction construction, or monitor for protocol divergence.
Transaction Builder and SDK Compatibility
CAPs that introduce new operations, modify the XDR schema, or change transaction envelope formats require immediate updates to SDKs and internal transaction builders. For example, a CAP adding a new operation type will break deserialization in outdated libraries. Integration teams must test against Stellar Core's testnet and Futurenet as soon as a CAP is marked 'Final' to ensure their transaction construction logic remains compatible before mainnet activation.
Horizon API and Data Ingestion Changes
Protocol changes often surface new ledger entry types or operation results that Horizon must parse and index. Data ingestion pipelines, block explorers, and analytics services need to update their schemas to handle these new fields. A CAP that modifies account sub-entries or introduces a new asset control flag will alter the JSON responses from Horizon endpoints, potentially breaking downstream monitoring dashboards and reconciliation scripts.
Asset Issuer and Anchor Impact Assessment
CAPs affecting trustlines, account flags, or claimable balances can alter the compliance and operational workflows for regulated asset issuers and anchors. A change to the authorization required flag semantics or clawback mechanics requires issuers to review their SEP-8 and SEP-24 implementations. Teams should initiate a protocol impact review during the 'Review' phase of a CAP to provide feedback before the change is locked in.
Soroban Environment and Smart Contract Risk
CAPs that modify the Soroban host environment, such as resource pricing, WASM metering, or host function availability, can silently break deployed smart contracts. A change to the maximum ledger entry size or a host function deprecation will cause previously valid contracts to trap. Development teams must run their contract test suites against the Stellar Core release candidate that implements the CAP to detect regressions before the protocol vote.
Monitoring Protocol Divergence
During a network upgrade, a brief window exists where non-upgraded nodes may fork from the main network. Infrastructure providers should monitor their local node's protocol version and ledger sequence against public network explorers. A stall in ledger close time or a mismatch in the protocolVersion field in the ledger header is a critical alert. Teams should have a rollback and upgrade procedure documented and tested before the activation date.
Process Risks and Compatibility Concerns
Identifies operational risks, compatibility failure modes, and required actions for validators, node operators, and integrators as a Core Advancement Proposal moves through its lifecycle.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Protocol Version Bump | A new protocol version is signaled in the ledger header and enforced by validators after an upgrade vote. | Validators, node operators, block explorers, SDK maintainers | Verify your node's Stellar Core version supports the new protocol version before the scheduled upgrade date. |
Transaction Envelope Format | A CAP may introduce a new XDR transaction envelope type or deprecate an old one. | Wallet developers, exchange engineers, SDK maintainers | Audit transaction construction and signing logic against the updated XDR schema to prevent broadcast failures. |
Soroban WASM Runtime | The WASM runtime version, metering, or host function set may change, altering smart contract execution. | Soroban smart contract developers, dApp frontends | Re-deploy and test contracts against the new runtime in Testnet and Futurenet to identify breaking execution changes. |
Core Operation Semantics | An existing operation's behavior, validation rules, or result codes may be modified. | Custodians, exchanges, payment processors | Update internal transaction processing logic and ledger interpretation to handle new result codes or changed validation. |
Quorum Set Configuration | A CAP may change the rules for validator quorum set composition or thresholds. | Validator node operators | Re-evaluate your quorum set configuration against the new rules to ensure your node remains in consensus. |
Horizon API Response Schema | API responses may include new fields, deprecate old ones, or change data types. | Wallets, block explorers, data analytics teams | Test all Horizon API queries used by your application against the new version to catch breaking schema changes. |
SDK Deprecation and Compatibility | Client SDKs may drop support for legacy features or require new parameters for updated operations. | Application developers, backend services | Pin SDK versions and run integration tests against the upgraded protocol to ensure continued compatibility. |
Asset Control Flag Behavior | The enforcement logic for AUTH_REQUIRED, AUTH_REVOCABLE, or CLAWBACK_ENABLED flags may be altered. | Asset issuers, regulated stablecoin providers, anchors | Verify asset control workflows, including authorization and clawback, function correctly under the new protocol rules. |
Operator Readiness Checklist
A practical checklist for node operators and protocol engineers to prepare for a Core Advancement Proposal (CAP) moving toward network activation. Each item identifies a specific readiness signal, explains why it matters for operational safety, and describes the confirming artifact.
What to check: Verify the proposal's status in the stellar-core-protocol repository. A CAP is not binding until it is merged with 'Final' status, indicating the community and SDF have aligned on the specification.
Why it matters: Draft and Proposed CAPs are subject to significant design changes. Preparing for an unapproved specification wastes engineering effort and risks implementing a deprecated design.
Readiness signal: The CAP's README.md header shows Status: Final and the proposal has been merged into the master branch.
Canonical Resources
Use these resources to track how Stellar Core Advancement Proposals move from discussion to implementation, review, release, and validator activation. Teams should verify current proposal status, implementation state, and network readiness against canonical Stellar sources before changing production systems.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos

Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Frequently Asked Questions
Answers to common questions from protocol engineers, node operators, and integrators about how a Core Advancement Proposal moves from idea to network activation and what it means for their systems.
A CAP champion submits a draft to the stellar-protocol repository. The community and protocol designers review it for technical soundness, security, and alignment with the network's goals. The CAP moves to Accepted status when the Stellar Development Foundation (SDF) protocol designers confirm it is ready for implementation. This is a signal that the design is stable, not that it is activated.
- What to check: The CAP's status in the repository and any
discussionorprotocoltags. - Why it matters: An Accepted CAP is the trigger for client teams to begin implementation. Integrators should start a preliminary impact assessment.
- Signal of readiness: The CAP's header is updated to
Status: Acceptedand it is merged into thecorefolder.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.


