🗓️ Add 2021 meetings

meetings/2021-01-14.mdx

@@ -0,0 +1,34 @@
+---
+title: "2021-01-14"
+description: This protocol discussion focused on proposed changes that make it easier to issue and manage regulated assets on Stellar, including trustline authorization semantics and asset clawback mechanisms.
+authors: john
+tags:
+  - legacy
+  - CAP-28
+  - CAP-29
+  - CAP-35
+  - SEP-8
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="TMV3V2LLYME" />
+
+This protocol discussion centered on the evolving needs of issuers building regulated assets on the network. The group reviewed how protocol changes are proposed, debated, and ultimately adopted, emphasizing transparency and public participation through GitHub and the Stellar developer mailing list.
+
+The technical focus was on two Core Advancement Proposals. CAP-29 addresses long-standing edge cases in trustline authorization by allowing issuers to authorize or revoke trustlines even when certain account flags are unset. CAP-35 introduces asset clawback as a first-class protocol feature, enabling regulated issuers and transfer agents to reverse fraudulent transfers, recover assets after key loss, and satisfy regulatory obligations without disrupting existing assets.
+
+### Key Topics
+
+- How CAP-29 simplifies trustline authorization so issuers can migrate between restricted and unrestricted issuance models without stranding accounts.
+- Why asset clawback (CAP-35) is required for regulated securities, including fraud recovery and transfer-agent record correction.
+- How clawback interacts with existing concepts like authorization, revocation, and claimable balances.
+- Design decisions around immutability, transparency, and protecting existing assets from unexpected behavior changes.
+- Tradeoffs between protocol simplicity, future extensibility, and issuer ergonomics.
+
+### Resources
+
+- [CAP-29: `AllowTrust` when not `AUTH_REQUIRED`](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0029.md)
+- [CAP-35: Asset Clawback](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0035.md)
+- [SEP-8: Regulated Assets](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md)
+- [Stellar protocol repository](https://github.com/stellar/stellar-protocol)

meetings/2021-01-28.mdx

@@ -0,0 +1,43 @@
+---
+title: "2021-01-28"
+description: This overview focused on CAP-35 (Asset Clawback), clarifying how the proposed clawback flag and operations work, how visibility and opt-in are enforced for asset holders, and what changes were required before moving the proposal into Final Comment Period.
+authors: john
+tags: [legacy, CAP-35]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="-Rxr97AsLfY" />
+
+This session continued the discussion on CAP-35, with the goal of resolving outstanding questions and determining whether the proposal was ready to advance.
+
+### Key Topics
+
+- Reaffirmed that clawback is strictly opt-in per asset:
+  - Issuers must enable the clawback flag before a holder accepts the asset.
+  - Existing assets and trustlines are unaffected.
+  - Clawback status is visible on-chain so holders opt in with full awareness.
+- Clarified flag semantics and discoverability:
+  - New authorization flags and operations introduce clawback without altering existing authorization behavior.
+  - Wallets and explorers can surface these flags to warn users in advance.
+- Reviewed the new `set_trust_line_flags` operation:
+  - Modeled after `set_options`, allowing individual flags to be set or cleared without redefining all authorization bits.
+  - General agreement to deprecate `allow_trust` over time in favor of the newer mechanism.
+- Discussed design feedback and future flexibility:
+  - Using full asset identifiers instead of asset codes to preserve extensibility.
+  - Potential delegation of trustline authorization to non-issuer accounts in the future.
+  - Clarified that clawback returns assets to the operation source account (currently the issuer), rather than burning them.
+- Examined edge cases and limitations:
+  - How claimable balances inherit clawback behavior from the sender’s trustline.
+  - Implications for payment channels and contract-like flows.
+  - Acknowledgement that the design involves trade-offs, but favors predictability and explicit opt-in.
+- Meeting outcome:
+  - Minor wording and structural updates were identified.
+  - Consensus was reached to move CAP-35 from Draft to Final Comment Period, pending those changes.
+  - A formal notice would be posted to the Stellar developers mailing list, opening a one-week window for final feedback.
+
+---
+
+### Resources
+
+- [CAP-35: Asset Clawback (Proposal)](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0035.md) ([Discussion Thread](https://groups.google.com/g/stellar-dev/c/hPhkXhrl5-Y/m/ZF6eJcqKAgAJ))

meetings/2021-03-11.mdx

@@ -0,0 +1,35 @@
+---
+title: "2021-03-11"
+description: This overview focused on CAP-21, which generalizes transaction preconditions to support relative timelocks, safer payment channels, and more flexible sequence-number handling. The discussion explored design tradeoffs, implementation concerns, and next steps before prototyping.
+authors: john
+tags: [legacy, CAP-21]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="8D-F2BMYQtA" />
+
+This meeting revisited a revised draft of CAP-21, aimed at expanding Stellar’s transaction preconditions beyond absolute timebounds.
+
+### Key Topics
+
+- How generalized preconditions extend `timeBounds` into a richer model using relative time, ledger gaps, and sequence-number ranges.
+- Why relative timelocks are critical for payment channels, enabling “disclose then finalize” flows, dispute windows, and unilateral recovery without excessive delays.
+- Improvements to sequence-number handling:
+  - Allowing transactions to be valid over a range of sequence numbers.
+  - Reducing brittleness for pre-signed transactions, payment channels, and multi-server submission workflows.
+- Broader use cases beyond payment channels:
+  - Time-delayed account recovery.
+  - Queue recovery and safer automation.
+  - Better interoperability with protocols that rely on relative timelocks (e.g., Lightning-style designs).
+- Design and implementation considerations:
+  - Tradeoffs between simplicity and extensibility in precondition structures.
+  - Forwarding and queuing complexity in Stellar Core.
+  - Agreement that the proposal meaningfully simplifies previously complex patterns.
+- Outcome:
+  - General consensus that the revised approach is sound.
+  - Follow-up work identified around implementation details and further prototyping.
+
+### Resources
+
+- [CAP-21: Generalized transaction preconditions (Proposal)](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0021.md) ([Discussion Thread](https://groups.google.com/g/stellar-dev/c/N8vzP2Mi89U/m/5SE67XxbAQAJ))

meetings/2021-04-15.mdx

@@ -0,0 +1,50 @@
+---
+title: "2021-04-15"
+description: This community roundtable explored how NFTs can be issued and used on Stellar, covering digital ownership beyond art, creator monetization, decentralized marketplaces, and emerging real-world use cases such as credentials, gaming assets, and natural capital.
+authors: john
+tags: [community]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="zZ-hTUwr2KU" />
+
+This session brought together ecosystem builders, creators, and SDF contributors to discuss what NFTs mean in practice on Stellar, how they differ from hype-driven narratives, and where durable value is emerging.
+
+### Key Topics
+
+- What NFTs represent beyond the acronym:
+  - Shift from “unique pixels” to broader digital ownership and certification.
+  - NFTs as proof of provenance, ownership, and history rather than just media files.
+  - Acceptance of limited editions and non-fractionable assets as valid NFT use cases.
+- Creator and ecosystem empowerment:
+  - NFTs as tools for artists, musicians, and game developers to bypass centralized platforms.
+  - Direct monetization without app stores, streaming platforms, or heavy intermediaries.
+  - Long-term sustainability for creators outside touring- or platform-dependent models.
+- NFTs on Stellar specifically:
+  - Asset issuance is fast, affordable, and environmentally lightweight.
+  - Use of the Stellar DEX for discovery, bidding, auctions, and settlement.
+  - Leveraging timebounds, path payments, and trustline controls for NFT workflows.
+- Platforms and implementations:
+  - Litemint’s NFT and collectibles marketplace design choices.
+  - Use of Stellar asset metadata standards rather than prescribing storage layers.
+  - Cross-network considerations, including easing Ethereum NFT fees via Stellar rails.
+- Beyond art: real-world and functional NFTs:
+  - Credentials (degrees, certifications, badges like Stellar Quest).
+  - Gaming items and in-game assets.
+  - Concepts for real estate, co-ownership, and fractional investment.
+  - Early exploration of natural capital and impact-driven NFTs (e.g., forestry).
+- Open challenges and open questions:
+  - Fractional vs non-fractional asset handling.
+  - Legal rights, licensing, and copyright vs on-chain ownership.
+  - Storage permanence, decentralization, and viewer dependency.
+  - GDPR and personal data considerations on immutable ledgers.
+- Takeaways:
+  - NFTs are best understood as programmable ownership and certification tools.
+  - Real adoption comes from strong use cases, not speculation.
+  - Stellar’s flexibility enables experimentation without dictating outcomes.
+  - Standards and ecosystem coordination will be critical as projects mature.
+
+### Resources
+
+- [Litemint](https://litemint.com)

meetings/2021-04-22.mdx

@@ -0,0 +1,29 @@
+---
+title: "2021-04-22"
+description: This overview explored two draft proposals to introduce automated market makers (AMMs) into Stellar Core, focusing on liquidity provisioning, DEX integration, and the economic and governance tradeoffs involved. The goal was to surface key design questions and guide further discussion.
+authors: john
+tags: [legacy, CAP-37, CAP-38]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="EKUbj811XsU" />
+
+This session marked the starting point for bringing automated market makers (AMMs) directly into the Stellar protocol. Rather than focusing on implementation details alone, the discussion framed AMMs as a new piece of core market infrastructure—one that could complement Stellar’s existing orderbook to improve liquidity, reduce friction, and make asset exchange more accessible across the network. The goal was not to finalize a design, but to surface the most important tradeoffs early, while both proposals were still in draft form.
+
+Participants compared two competing approaches, CAP-37 and CAP-38, each attempting to balance simplicity, predictability, and long-term flexibility. Much of the conversation focused on how AMMs should interact with the existing DEX, how costs and reserves should be allocated, and how much complexity should live inside Stellar Core versus being left to market participants. What follows captures the main themes that emerged as the group clarified priorities and identified open questions for continued discussion.
+
+This meeting introduced two draft proposals—CAP-37 and CAP-38—both aiming to add constant-product liquidity pools to Stellar so that users can provide or consume liquidity without maintaining standing orders on the orderbook.
+
+### Key Topics
+
+- Resource management and fee economics: how liquidity pools should be represented on-ledger, who (if anyone) should sponsor pool entries, how LP share trustlines relate to reserve requirements, and how to avoid “free riding” while keeping pool creation accessible.
+- DEX integration strategies: CAP-37’s approach of continuously routing trades to the best marginal price across pools and the orderbook versus CAP-38’s simpler, deterministic choice between pool-only or orderbook-only execution, along with the implications for complexity, arbitrage, and user expectations.
+- Pool behavior and evolution: handling deposits and withdrawals, rounding and slippage protections, the possibility of multiple pools per asset pair, and how parameters like fees or curve types should be fixed, governed, or extended over time.
+
+The discussion closed with agreement that AMMs represent a significant shift in Stellar’s market model and that further debate on these design choices should continue on the developer mailing list before either proposal advances.
+
+### Resources
+
+- [CAP-37: Automated Market Makers (Draft Proposal)](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0037.md) ([Discussion Thread](https://groups.google.com/g/stellar-dev/c/Ofb2KXwzva0/m/LLcUKWFmBwAJ))
+- [CAP-38: Automated Market Makers (Draft Proposal)](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0038.md) ([Discussion Thread](https://groups.google.com/g/stellar-dev/c/NLE-nprRPtc/m/GHlmlE7ABwAJ))

meetings/2021-05-06.mdx

@@ -0,0 +1,37 @@
+---
+title: "2021-05-06"
+description: This discussion continued the CAP-37 and CAP-38 AMM work, focusing on how issuers enforce authorization, revocation, and clawback-like controls when assets sit inside protocol-level liquidity pools. The group compared two enforcement models, debated whether issuers should opt in to pool participation, and flagged claimable-balance edge cases for follow-up on the mailing list.
+authors: john
+tags:
+  - legacy
+  - CAP-18
+  - CAP-37
+  - CAP-38
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="0bE-XXeYY3M" />
+
+This discussion picked up the AMM thread from the prior session and zoomed in on a regulated-asset question that any pool design must answer: when an issuer revokes authorization, how does that enforcement propagate through liquidity pools so the asset can’t continue trading indirectly?
+
+The group compared two enforcement models. The first model treats pools like offers: revoking authorization on an asset trustline would also trigger redemption of any pool shares that depend on that trustline. This preserves issuer expectations and avoids a new operational workflow, but it pushes more complexity into Core (data lookups, indexing, and the mechanics of finding and redeeming affected pool positions). The second model keeps the mechanics simpler by shifting enforcement to the pool share trustline itself: issuers would revoke authorization on pool trustlines to force redemption. That approach reduces Core complexity, but it introduces a behavioral “foot-gun” for issuers who already have production compliance workflows built around asset trustlines and offers.
+
+A recurring theme was whether authorization-required issuers should be forced to opt in to allowing their assets in liquidity pools at all. Several participants argued for an opt-in flag (at least for auth-required assets) so issuers can’t accidentally end up with assets trading in pools while relying on legacy revoke behavior. Others suggested defaults that keep pools broadly usable, especially for the many assets that are not auth-required, and noted that a blanket “inhibit AMM” flag may not match any real issuer demand today.
+
+The conversation also surfaced a practical edge case: forced redemption may require creating claimable balances when the redeemer cannot receive the underlying assets (missing trustlines, insufficient limits, liabilities from offers, etc.). That behavior could be surprising for applications, so the group left the details open and encouraged more design iteration and feedback on the Stellar-dev mailing list.
+
+### Key Topics
+
+- Compared two issuer-enforcement models for AMMs: (v1) revoke the asset trustline and automatically redeem any dependent pool shares (offer-like behavior) vs (v2) revoke authorization on the pool share trustline to force redemption.
+- Discussed an issuer opt-in flag for liquidity pools (especially for auth-required assets) to avoid “silent” behavior changes for existing compliance workflows.
+- Noted tradeoffs: v1 is the cleanest contract for issuers but adds Core/data-layer complexity; v2 is simpler to implement but requires issuers to learn a new enforcement step.
+- Flagged claimable-balance edge cases during forced redemption (missing trustlines, insufficient limits, liabilities) and left mechanics/reserve handling for follow-up on the mailing list.
+- Parked broader AMM questions (multiple pools per pair, updatable parameters, reserve requirements/UX signaling) as ongoing work tied to CAP-37/CAP-38 threads.
+
+### Resources
+
+- [CAP-18: Fine-Grained Control of Authorization](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0018.md)
+- [CAP-37: Automated Market Makers](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0037.md)
+- [CAP-38: Automated Market Makers](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0038.md)
+- [Stellar Developers Mailing List (stellar-dev)](https://groups.google.com/forum/#!forum/stellar-dev)

meetings/2021-06-17.mdx

@@ -0,0 +1,38 @@
+---
+title: "2021-06-17"
+description: This session focused on advancing automated market makers (AMMs) at the protocol level, comparing CAP-37 and CAP-38 approaches to liquidity, order routing, and deployment risk. The group aligned on CAP-38 as a practical first step, emphasizing simplicity, faster shipping, and the ability to layer more advanced features later.
+authors: john
+tags: [legacy, CAP-37, CAP-38]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="aHZQfcIdmoQ" />
+
+This discussion examined how automated market makers could be introduced into the Stellar protocol to improve liquidity and trading efficiency. Participants compared two competing proposals, CAP-37 and CAP-38, and debated tradeoffs around complexity, arbitrage behavior, network performance, and ecosystem readiness.
+
+The conversation converged on prioritizing a simpler, shippable solution that delivers value quickly while preserving flexibility. CAP-38 was viewed as a reasonable foundation that can later support more advanced routing and interleaving features if needed.
+
+### Key Topics
+
+- Comparison of **CAP-37 (interleaved routing)** vs **CAP-38 (best-venue routing)** for AMM integration
+- Agreement that interleaving is theoretically superior, but significantly more complex to implement
+- Recognition that CAP-38 can act as a foundational layer, with CAP-37 potentially built on top later
+- Assessment of arbitrage risks, including increased failed transactions and Horizon load
+- Conclusion that arbitrage is unavoidable and better addressed incrementally after deployment
+- Emphasis on avoiding over-optimization and “perfect vs. good” tradeoffs
+- Validation that network guardrails and validator governance can mitigate worst-case scenarios
+- Consideration of UI and ecosystem readiness, especially around path payments
+- Optimistic outlook that AMMs could reduce order book traffic and improve overall efficiency
+- Formal vote by the CAP committee to move **CAP-38 into Final Comment Period**
+
+### Outcomes
+
+- **CAP-38** unanimously approved to advance to Final Comment Period
+- **CAP-37** remains in draft, with guidance to revise it as a potential extension on top of CAP-38
+- Next steps include community feedback, validator review, and eventual protocol inclusion
+
+### Resources
+
+- [CAP-37: Automated Market Makers Proposal](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0037.md) ([Developer Mailing List Discussion](https://groups.google.com/g/stellar-dev/c/Ofb2KXwzva0/m/LLcUKWFmBwAJ))
+- [CAP-38: Automated Market Makers Proposal](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0038.md) ([Developer Mailing List Discussion](https://groups.google.com/g/stellar-dev/c/NLE-nprRPtc/m/GHlmlE7ABwAJ))