stellar · JFWooten4 · Aug 23, 2026 · Aug 23, 2026
diff --git a/meetings/2019-01-24.mdx b/meetings/2019-01-24.mdx
@@ -0,0 +1,66 @@
+---
+title: "2019-01-24"
+description: "This overview highlights anchor services and network fees and resource limits."
+authors: goodnow
+tags:
+  - legacy
+  - CAP-10
+  - CAP-13
+  - CAP-15
+  - CAP-5
+  - CAP-7
+  - CAP-8
+  - SEP-13
+  - SEP-6
+  - SEP-8
+---
+
+## [Public Discussion](https://groups.google.com/g/stellar-dev/c/x0Wrj2kuQ0U/m/CrId5QkoFwAJ)
+
+### Agenda
+
+- [CAP-0005](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0005.md) & [CAP-0006](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0006.md) - moving to approval.
+- [Cosigned Assets Draft](https://github.com/stellar/stellar-protocol/issues/146) - in draft since September; current approach considered viable.
+- [CAP-0007 Revised Proposal](https://github.com/stellar/stellar-protocol/blob/master/drafts/draft-detacct.md).
+- [CAP-0015](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) - Bump Fee Transactions update.
+- CAP-0013 vs SEP-0013 (CAP-0007 + CAP-0008) - Change Trustlines to Balances.
+
+### Meeting Notes
+
+- CAP-0006 progressing with specific messaging for a targeted use case.
+- CAP-0005 still lacks replace-by-fee and remains problematic.
+- Deterministic accounts & creatorTxID (David):
+  - Vastly simplified since prior iteration.
+  - Salt mechanism needed; likely a full hash to prevent protocol rewind attacks.
+- Cosigned Assets:
+  - Related to [SEP-8 (Regulated Assets)](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md).
+  - NFT discussions considered orthogonal; may warrant a separate CAP.
+  - Catalog of no-op operations discussed:
+    - Payment to oneself
+    - Bump op 0
+    - SetOptions with no fields
+
+### Follow-up Actions
+
+- Johnny: coordinate CAP-0006 community and API updates.
+- David: expand deterministic accounts draft and address CAP-0010/CAP-0015 implications.
+- Orbit: consolidate NFT discussions and assess need for a separate CAP.
+- Jeremy: review SEP-13A comments and address shortcomings in SEP-13.
+
+### Trustline follow-up
+
+The adjacent trustline-focused discussion reprised the agenda above and surfaced additional nuance around asset onboarding and NFT considerations. Tom and Orbit asked the group to clarify how cosigned assets should handle no-op operations, and David emphasized that NFT work is orthogonal but still worth cataloging.
+
+- Tom asked for clarity on SEP-13A’s handling of edge cases, and Orbit volunteered to gather NFT-related requirements. The session reviewed the same high-level trustline-use case summary document in [Google Docs](https://docs.google.com/document/d/1_3KcBTbF7Diu_wu-ArvajYhEcPoDp9SgK5-dNruOK3c/edit#heading=h.8j5x6v50ft4p). That document lays out the anchor requirements around SEP-6/SEP-13 deposits and transfers so wallets set up user-facing flows that never require extra trustlines/XLM or manual follow-up steps, while also supporting sends to accounts that don’t yet exist.
+  - Deposits must complete once the anchor receives the external asset, delivering funds to the user’s original account whether or not it has a trustline or even exists yet.
+  - Users shouldn’t need to add additional XLM to finish a deposit, nor should anchors wait on any extra manual action once the deposit is underway.
+  - The send requirements emphasize end-to-end usability: sends must arrive without the recipient doing any setup, and the document recommends keeping implementations as simple as possible to encourage adoption.
+  - The group cataloged known no-ops (payment to self, bump op 0, SetOptions with no fields) and challenged attendees to bring simple, actionable alternatives rather than more complexity.
+  - A short-term TODO list reiterated that deterministic accounts need a salt/hash to guard against rewind attacks, while CAP-0006 updates and SEP-13A comments should stay in sync with the evolving API design.
+
+### Trustline follow-up actions
+
+- Johnny: continue improving the DEX-focused messaging tied to CAP-0006 and sync with Jon on API revisions.
+- David: add concrete deterministic-account examples, harden salt handling, and spell out whether those accounts supplant CAP-0010/CAP-0015 work.
+- Orbit: collect NFT and Asset-object feedback to determine whether a new CAP is warranted.
+- Jeremy: respond to Tom’s SEP-13A comments and close the remaining gaps in the proposal.
diff --git a/meetings/2019-03-07.mdx b/meetings/2019-03-07.mdx
@@ -0,0 +1,107 @@
+---
+title: "2019-03-07"
+description: "This overview highlights network fees and resource limits."
+authors: goodnow
+tags:
+  - legacy
+  - CAP-10
+  - CAP-11
+  - CAP-13
+  - CAP-14
+  - CAP-15
+  - CAP-16
+  - CAP-17
+  - CAP-18
+  - CAP-7
+  - CAP-8
+  - CAP-9
+  - SEP-13
+---
+
+## [Public Discussion](https://groups.google.com/g/stellar-dev/c/NJl_loV_RXU/m/SarzWEJPAgAJ)
+
+### Announcements
+
+- **[Merging in CAP/SEP Process](https://github.com/stellar/stellar-protocol/pull/247)**
+  - Another round of edits completed; further feedback requested on the PR.
+  - Intent to merge immediately, formalizing the previously ad-hoc CAP/SEP process.
+  - All CAPs will be numbered upon acceptance as drafts; competing proposals will be explicitly rejected.
+  - Post-merge cleanup planned for stale PRs and issues, with authors notified of next steps.
+- **Establishing focus given limited developer resources**
+  - Fee structure
+  - Payment channels
+  - Payment network (**Starlight**)
+
+### Final Comment Period - Acceptance
+
+- [CAP-0017](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0017.md) - Update `LastModifiedLedgerSeq` If and Only If LedgerEntry Is Modified (Jonathan Jove)
+- [CAP-0018](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0018.md) - Fine-Grained Control of Authorization (Jonathan Jove)
+- Address offer mutability (Jon)
+- CAP-0016 to be rejected contingent on CAP-0018 approval
+
+### Priorities
+
+1. Replace Min Fee Mechanism
+2. Trustline (& other) Usability
+   - Explicit intent to revive [CAP-0013 Change Trustlines to Balances](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0013.md) (Dan Robinson).
+3. Payment Channels
+   - Focus on core components required for a basic payment channel design.
+4. Starlight
+   - Deferred pending availability of dedicated development resources.
+
+### Deferred Items
+
+- [CAP-0007](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0007.md) - Deterministic Account Creation (Jeremy Rubin)
+- [CAP-0008](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0008.md) - Self-Identified Pre-Auth Transaction (Jeremy Rubin)
+- [CAP-0009](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0009.md) - Linear / Exterior Immutable Accounts (Jeremy Rubin)
+- [CAP-0011](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0011.md) - Relative Account Freeze (Jeremy Rubin)
+- Draft: Deterministic accounts and creatorTxID (David Mazières)
+- [CAP-0014](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0014.md) - Adversarial Transaction Set Ordering (Jeremy Rubin)
+
+### Agenda
+
+- Final Comment proposals - new unresolved concerns (30 min max)
+- CAP-0017, CAP-0018
+- Address offer mutability
+- Replace Min Fee (60 min max)
+
+### Replace Min Fee Discussion
+
+- Diverging views:
+  - David and Nico prefer a mechanism _before_ raising the min fee.
+  - Jed favors pushing fee increases forward immediately.
+- Current proposals:
+  - [CAP-0010](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0010.md) - Fee Bump Account (Jeremy Rubin)
+  - [CAP-0015](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) - Bump Fee Transactions (OrbitLens)
+  - Pre-draft: feeSource and feeMultiplier (David Mazières)
+- [Reference spreadsheet](https://docs.google.com/spreadsheets/d/1_u0LE61V-jkXUcNBZW5xhXZEmIz5rQSgZEr8VsVl47o/edit) (OrbitLens) compares fee-sponsorship approaches (CAP-10 fee balances, feeSource/feeMultiplier, deterministic accounts, CAP-15 metadata) across tradeoffs like explicit sponsor control, pre-signed tx support, and algorithmic complexity.
+  - CAP-10 introduces dedicated fee balances so sponsors can preload fees, but it requires new operations and careful management of locked fee funds.
+  - FeeSource/feeMultiplier and deterministic accounts keep fees on existing transactions but push complexity to signers (pick fee source in advance, ensure simultaneous submissions) with limited control.
+  - CAP-15 embeds fee bumping in the transaction envelope, letting sponsors declare amounts per envelope, while the spreadsheet emphasizes choosing the right tradeoff between sponsor control and implementation simplicity.
+- Outcomes:
+  - David to draft a new CAP superseding CAP-0015, including Transaction versioning.
+  - Johnny to follow up with David regarding feeSource draft status.
+
+### Trustline Usability
+
+- Discussion on next steps for CAP-0013 Change Trustlines to Balances
+- Open questions:
+  - What changes would improve group consensus?
+  - Are there unpresented fundamental ideas?
+  - Who should own the proposal going forward?
+- Related discussion: **Sender Pays** (sending assets without trustlines).
+- Consensus points:
+  - CAP-0013 enables adding balances to others and simplifies token distribution.
+  - SEP-0013 approach explicitly rejected.
+  - Hard requirements need definition; Tom Q. designated owner.
+  - Developer-friendliness and Account ID semantics must be addressed.
+
+### Meeting Notes
+
+- Inline notes (highlighted in blue in original thread) captured above.
+
+### Follow-Up Actions
+
+- **Jon Jove** to update CAPs based on email list feedback.
+- **Tom Quisel** to revise and present hard requirements for trustline usability.
+- **David** to submit a new proposal for TransactionEnvelope versioning to enable changes like CAP-0015.
diff --git a/meetings/2019-03-14.mdx b/meetings/2019-03-14.mdx
@@ -0,0 +1,59 @@
+---
+title: "2019-03-14"
+description: "This overview highlights anchor services and network fees and resource limits."
+authors: goodnow
+tags:
+  - legacy
+  - CAP-13
+  - CAP-15
+  - CAP-17
+  - CAP-18
+  - CAP-19
+  - SEP-13
+  - SEP-16
+  - SEP-17
+  - SEP-6
+---
+
+## [Public Discussion](https://groups.google.com/g/stellar-dev/c/uxmo4LM5FWY/m/psazVteTBgAJ)
+
+### Announcements
+
+- Jon made additional changes to [CAP-0018](https://github.com/stellar/stellar-protocol/pull/263); with no further comments, it will move out of FCP next week.
+- [CAP-0017](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0017.md) moved to **Approved**.
+
+### Agenda
+
+#### Trustline Usability
+
+- Restated [requirements document](https://docs.google.com/document/d/1_3KcBTbF7Diu_wu-ArvajYhEcPoDp9SgK5-dNruOK3c/edit#heading=h.8j5x6v50ft4p) up for discussion. The doc captures the desired SEP-6/SEP-13 deposit and send flows: anchors should auto-complete deposits without additional user actions, deliver funds to the intended account even when it has no trustline or XLM, and allow sends to non-existent accounts by crediting the original account ID.
+  - Deposits must finish once the anchor receives the external asset, never forcing the user to add trustlines or extra XLM, even when accounts are uncreated.
+  - Sending should work regardless of the recipient’s trustlines or account state, and funds should arrive at the original Stellar account without extra steps.
+  - The document stresses usability: anchors/wallets should avoid complex workflows, so any solution must stay simple, fast, and easy to implement.
+  - [SEP-0017](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0017.md): Deposit & transfer of assets using [CAP-0013](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0013.md)
+  - [SEP-0016](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0016.md): Deposit & transfer of assets using deterministic accounts
+  - It is not possible to satisfy all requirements in the protocol's current form.
+
+#### Issues with [CAP-0013](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0013.md)
+
+- If base reserve increases, malicious actors could add large numbers of trustlines to an account.
+- Accounts can be DoS'd via the subentry limit.
+- The proposal has very large scope, affecting most operations and assumptions in the protocol.
+
+#### Alternatives Discussed
+
+- Use deterministic accounts and merge them if the receiver already has an account.
+- Introduce a **SentBalance** ledger entry claimable by the receiver.
+- Introduce a **remove trustline** operation that returns assets to the sender.
+
+#### Fee Mechanisms
+
+- David proposed [CAP-0019](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0019.md):
+  - Enables future-upgradability of `TransactionEnvelope`
+  - Allows a simpler implementation of [CAP-0015](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md)
+
+### Follow-up Actions
+
+- **David**: Write a short proposal on "embryonic accounts".
+- **Jeremy**: Clarify SEP-0016 workflow with deterministic accounts.
+- **Jon**: Provide analysis of attack surfaces and issues in [CAP-0013](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0013.md).
diff --git a/meetings/2019-03-21.mdx b/meetings/2019-03-21.mdx
@@ -0,0 +1,33 @@
+---
+title: "2019-03-21"
+description: "This overview highlights order book trading and network fees and resource limits."
+authors: goodnow
+tags:
+  - legacy
+  - CAP-15
+  - CAP-16
+  - CAP-18
+  - CAP-19
+---
+
+## [Public Discussion](https://groups.google.com/g/stellar-dev/c/KzgQc58510o/m/1qRSxo7GCAAJ)
+
+### Announcements
+
+- [CAP-0016](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0016.md) rejected in favor of [CAP-0018](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0018.md) (now Accepted). CAP-0016 will only be revived if CAP-0018 encounters implementation issues.
+- [CAP-0018](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0018.md) moved to Accepted.
+- [CAP-0019](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0019.md) moved to FCP: Acceptance.
+- Jed was in Singapore this week; trustline discussions were postponed until his return.
+
+### Agenda
+
+#### Fee Follow-ups
+
+- Topics: [CAP-0019](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0019.md), [CAP-0015](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md), and other fee-related suggestions.
+- Decision: Push CAP-0019 to FCP: Acceptance and reframe CAP-0015 in the context of CAP-0019.
+
+#### Future of the Order Book - Ideation
+
+- Broad discussion of possible directions for the order book.
+- No commitments were made.
+- Goal: Produce an exhaustive list of ideas, followed by prioritization and requirements definition in future sessions.
diff --git a/meetings/2019-03-28.mdx b/meetings/2019-03-28.mdx
@@ -0,0 +1,38 @@
+---
+title: "2019-03-28"
+description: "This overview highlights network fees and resource limits."
+authors: goodnow
+tags:
+  - legacy
+  - CAP-15
+  - CAP-19
+  - CAP-20
+  - CAP-5
+  - SEP-19
+---
+
+## [Public Discussion](https://groups.google.com/g/stellar-dev/c/t162rVxLYB4/m/XB4_9st1BgAJ)
+
+### Announcements
+
+- [CAP-0019](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0019.md) (Future-upgradable TransactionEnvelope type) is moving to Accepted.
+- "Implementation Review" stage added for CAPs (see https://github.com/stellar/stellar-protocol/pull/279); keep in mind for future CAP process.
+- Jed out this week; trustline discussion pushed again.
+- [CAP-0020](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0020.md) implementation is mostly there.
+
+### Agenda
+
+- [CAP-0015](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) (Bump Fee Extension): Modified to utilize [CAP-0019](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0019.md). Goal is to bring it to a vote, or enumerate what is needed to make it pass.
+  - David: Two transaction IDs (inner and outer) as a result of the change.
+  - Nico: Original feedback was that this relies on [CAP-0005](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0005.md) logic that no longer exists in the CAP-0005 implementation.
+  - Nico and David to discuss offline; David to submit additional edits and document constraints and issues from the meeting.
+- [SEP-0019](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0019.md) (Bootstrapping Multisig Transaction Submission):
+  - Significant discussion with contributions from Paul Selden, Antoine (MrTicot), Orbit, Johan, and others.
+  - Focus should remain on SEP-0019 and direction for any related SEPs.
+  - Can pull in Paul and others for the next meeting; it is likely the most active SEP currently.
+  - SEP-0019 is largely focused on the StellarGuard protocol and currently only describes basic flow properties and API endpoints; substantial work remains.
+  - Open questions:
+    - Metadata (storage and off-chain handling)
+    - Coordinator (no core changes required)
+    - Possible use of an IPFS home domain
+  - Orbit to send a document outlining design considerations for multisig transaction coordination.