diff --git a/meetings/2021-01-14.mdx b/meetings/2021-01-14.mdx
new file mode 100644
index 000000000..d15ed8dae
--- /dev/null
+++ b/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)
diff --git a/meetings/2021-01-28.mdx b/meetings/2021-01-28.mdx
new file mode 100644
index 000000000..620b59be1
--- /dev/null
+++ b/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))
diff --git a/meetings/2021-03-11.mdx b/meetings/2021-03-11.mdx
new file mode 100644
index 000000000..3c2e3a58b
--- /dev/null
+++ b/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))
diff --git a/meetings/2021-04-15.mdx b/meetings/2021-04-15.mdx
new file mode 100644
index 000000000..372660784
--- /dev/null
+++ b/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)
diff --git a/meetings/2021-04-22.mdx b/meetings/2021-04-22.mdx
new file mode 100644
index 000000000..34782d3e5
--- /dev/null
+++ b/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))
diff --git a/meetings/2021-05-06.mdx b/meetings/2021-05-06.mdx
new file mode 100644
index 000000000..23bedfd4b
--- /dev/null
+++ b/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)
diff --git a/meetings/2021-06-17.mdx b/meetings/2021-06-17.mdx
new file mode 100644
index 000000000..a6013d5c3
--- /dev/null
+++ b/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))
diff --git a/meetings/2021-07-28.mdx b/meetings/2021-07-28.mdx
new file mode 100644
index 000000000..d89afdc5a
--- /dev/null
+++ b/meetings/2021-07-28.mdx
@@ -0,0 +1,29 @@
+---
+title: "2021-07-28"
+description: This panel explores how fintech builders across Africa are using Stellar to address cross-border payments, regulation, and interoperability challenges while scaling inclusive financial services.
+authors: john
+tags: [community]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="-8jQtnKfxmU" />
+
+This ecosystem panel brings together fintech founders, investors, and operators building across Africa to discuss real-world challenges and opportunities in delivering digital financial services. Panelists share how they identified underserved user bases, why they chose blockchain infrastructure, and how Stellar enables faster, lower-cost cross-border value movement.
+
+The conversation focuses on practical lessons from operating in fragmented regulatory environments, scaling under uncertainty, and designing products that work for both end users and financial partners. Speakers also highlight why interoperability and collaboration will be critical to the next phase of fintech growth on the continent.
+
+### Key Topics
+
+- How African fintechs identify niche user bases (SMEs, refugees, informal merchants, cross-border traders)
+- Using Stellar and stablecoins for efficient cross-border settlement and liquidity management
+- Regulatory realities: compliance, KYC/AML, and engaging regulators early
+- Building resilience amid sudden regulatory or partner disruptions
+- Advice for founders: focus on core value, leverage existing infrastructure, and know your details
+- Interoperability challenges across wallets, banks, telcos, and countries
+- Why open standards and integrations matter for Africa’s fragmented markets
+
+### Resources
+
+- [Stellar Development Foundation Events](https://stellar.org/events)
+- [DFS Lab](https://dfslab.net)
diff --git a/meetings/2021-07-29.mdx b/meetings/2021-07-29.mdx
new file mode 100644
index 000000000..40648fb85
--- /dev/null
+++ b/meetings/2021-07-29.mdx
@@ -0,0 +1,40 @@
+---
+title: "2021-07-29"
+description: This discussion examined CAP-21 generalized transaction preconditions and CAP-40’s signed-payload signer, focusing on how relative timelocks and atomic signature disclosure enable safer payment channels and other pre-signed transaction workflows.
+authors: john
+tags: [legacy, CAP-21, CAP-40]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="YhtaZ3f_p4o" />
+
+This session focused on two closely related protocol changes that together lay the foundation for payment channels on Stellar. Participants explored how more expressive transaction preconditions and a new multisignature construct can enable secure off-chain state updates with periodic on-chain settlement.
+
+The discussion emphasized practical implementation concerns, backward compatibility, and long-term extensibility. Much of the conversation centered on how these CAPs interact with existing ledger structures, SDKs, and signing workflows, with the goal of supporting high-volume use cases without introducing unnecessary complexity.
+
+### Key Topics
+
+- CAP-21: generalizing transaction preconditions beyond simple time bounds
+  - Support for relative time locks, ledger bounds, and additional signer requirements
+  - Design tradeoffs around account extension nesting vs. flattening
+  - How preconditions are validated versus applied during transaction processing
+  - Implications for SDKs, signing safety, and backward compatibility
+  - Payment channels as a scaling mechanism through off-chain transactions
+- CAP-40: enabling safe exchange of signatures for multiple related transactions
+  - Single-step authorization of up to three linked transactions
+  - Reducing round trips and coordination complexity in payment channels
+  - Relationship to existing multisig and hash-based signers
+  - Considerations around scalability, signature limits, and future extensions
+
+### Outcomes
+
+- Agreement to revise CAP-21 to address account extension structure and validation semantics
+- Consensus on a clear path toward accepting CAP-21 after targeted updates
+- General alignment that CAP-40 is valuable, with a request to add a standalone use case
+- Plan to revisit both proposals together for acceptance after revisions
+
+### 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))
+- [CAP-40: Ed25519 Signed Payload Signer for Transaction Signature Disclosure (Proposal)](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0040.md) ([Discussion Thread](https://groups.google.com/g/stellar-dev/c/Wp7gNaJvt40))
diff --git a/meetings/2021-09-09.mdx b/meetings/2021-09-09.mdx
new file mode 100644
index 000000000..374db2283
--- /dev/null
+++ b/meetings/2021-09-09.mdx
@@ -0,0 +1,36 @@
+---
+title: "2021-09-09"
+description: This discussion explores CAP-21, a core protocol proposal that introduces generalized transaction preconditions to enable secure, high-throughput payment channels on Stellar. The session focuses on design tradeoffs, backward compatibility, and transaction ordering behavior required to safely support off-chain payment workflows.
+authors: john
+tags: [legacy, CAP-21, CAP-40]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="yz63i52W2Ek" />
+
+This protocol discussion centers on CAP-21 and how generalized transaction preconditions make payment channels practical on Stellar. Participants examine how features like relative sequence constraints and time-based conditions allow parties to transact off-chain while preserving on-chain safety and eventual settlement guarantees.
+
+Much of the conversation digs into implementation realities: how new account-entry extensions interact with historical ledger states, how validators should forward and prioritize conditional transactions, and how to avoid subtle “foot guns” for developers building advanced transaction flows. The group also reviews how CAP-21 underpins related work and what changes are still needed before final acceptance.
+
+### Key Topics
+
+- How generalized transaction preconditions (such as `minSeqAge` and `minSeqLedgerGap`) enable scalable payment channels.
+- Tradeoffs between protocol-version changes versus opt-in account flags, and why flags were rejected.
+- Implications of new account-entry extensions on legacy tests and ledger invariants.
+- Keeping time bounds unsigned for consistency with existing transactions and SDK behavior.
+- Validator behavior for forwarding, queueing, and prioritizing transactions with sequence constraints.
+- Interactions between fee bidding, transaction ordering, and denial-of-service considerations.
+- Design questions around combining delay-based and sequence-jump preconditions in a single transaction.
+
+### Outcomes
+
+- Agreement to keep new account-entry behavior protocol-wide rather than opt-in, despite test refactoring costs.
+- Decision to retain unsigned timepoints for transaction preconditions.
+- Consensus to adjust transaction-forwarding rules toward simpler, first-seen handling to reduce abuse.
+- Action items identified to revise CAP-21 text and continue async review before acceptance.
+
+### Resources
+
+- [CAP-21: Generalized transaction preconditions](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0021.md)
+- [CAP-40: Ed25519 Signed Payload Signer for Transaction Signature Disclosure](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0040.md)
diff --git a/meetings/2021-10-14.mdx b/meetings/2021-10-14.mdx
new file mode 100644
index 000000000..515a13d13
--- /dev/null
+++ b/meetings/2021-10-14.mdx
@@ -0,0 +1,44 @@
+---
+title: "2021-10-14"
+description: Final review of CAP-38’s Automated Market Maker implementation, focusing on last-mile guardrails, issuer safety semantics, error-code alignment, and edge-case handling ahead of the Protocol 18 network upgrade.
+authors: john
+tags: [legacy, CAP-38]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="wcjzKdo0xS8" />
+
+This session served as a post-implementation validation of CAP-38, confirming that the final AMM behavior matched protocol intent before the network upgrade. With the CAP already approved and implemented, the discussion focused on reviewing implementation-driven changes to ensure correctness, predictability, and consistency with existing orderbook semantics.
+
+The group walked through each adjustment made during implementation, paying particular attention to issuer control, withdrawal guarantees, error reporting, and how AMMs interact with trustlines, sponsorship, and path payments. The overarching goal was to ensure AMMs remain safe for issuers and integrators while behaving intuitively for wallets and applications once Protocol 18 is live.
+
+### Key Topics
+
+- Alignment with orderbook semantics
+  - Liquidity pool deposits and withdrawals now mirror offer behavior
+  - Liquidity providers can always withdraw shares, even when authorization is revoked (maintain-liabilities state)
+  - Deposits remain blocked when authorization is missing
+- Issuer safety and revocation behavior
+  - Revoking asset authorization predictably unwinds liquidity pool positions
+  - Pool shares cannot become permanently “stuck,” even under extreme price movement
+  - Revocations may result in claimable balances rather than direct refunds, ensuring safety in edge cases
+- Error codes and result consistency
+  - Clearer, more accurate result codes for AMM deposits, withdrawals, and path payments
+  - Fixed inconsistencies where liquidity pool paths could not realistically return legacy orderbook errors
+  - Added missing validation and malformed results to match protocol conventions
+- Trustlines, limits, and reserves
+  - Correct handling of trustline limits (e.g., line-full cases on deposit)
+  - Clarified low-reserve and too-many-sponsoring failure cases during revocation flows
+  - Ensured pool-share bookkeeping behaves safely without introducing new limits risks
+- Claimable balance handling
+  - Simplified claimable balance identifiers by removing unnecessary ID types
+  - Standardized behavior so revoked pool shares always resolve via claimable balances
+  - Acknowledged ecosystem implications and the need for wallet support and education
+- Future-proofing expectations
+  - Noted that AMM mechanics and parameters may evolve via future protocol upgrades
+  - Liquidity pool shares should not be assumed to exist unchanged in perpetuity
+
+### Resources
+
+- [CAP-38: Automated Market Makers](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0038.md)
diff --git a/meetings/2021-10-28.mdx b/meetings/2021-10-28.mdx
new file mode 100644
index 000000000..77977243c
--- /dev/null
+++ b/meetings/2021-10-28.mdx
@@ -0,0 +1,44 @@
+---
+title: "2021-10-28"
+description: Discussion of the final implementation details and readiness of CAP-21 (generalized transaction preconditions), including updated rules for handling incompatible transactions, expected Core/Horizon work, and how this unlocks payment-channel patterns, account recovery flows, and high-throughput apps.
+authors: john
+tags:
+  - legacy
+  - CAP-21
+  - CAP-40
+  - SEP-8
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="g41iei45yA4" />
+
+This call served as the final readiness check for CAP-21, focusing on whether any remaining technical questions would block sending it to the CAP committee. The group walked through the last set of spec tweaks, clarified how nodes should handle incompatible transactions, and compared those tradeoffs with existing “first-seen” behavior already present in other edge cases.
+
+The discussion then shifted to practical rollout considerations: what changes are needed in Stellar Core and Horizon, what testing and overlay work might be the riskiest, and how much effort SDK updates are likely to require. The group also covered why it’s valuable to land these capabilities before they’re urgently needed, since payment-channel primitives can enable high-volume apps as well as new account recovery patterns.
+
+### Key Topics
+
+- Final spec tweaks
+  - Reverted time points/durations back to unsigned (signed was deemed a bad idea and not worth optimizing for database convenience)
+  - Added clearer notes on how bump-sequence and related behavior can invalidate transactions within the same ledger
+- Handling incompatible transactions
+  - Updated approach: keep the first incompatible transaction seen and discard later ones that can’t coexist in the same ledger
+  - Rationale: consensus and propagation already require dealing with divergent “seen order” cases (e.g., same sequence/fee arriving at different nodes)
+- Implementation readiness and scope
+  - Stellar Core work includes overlay-related changes plus solid test coverage
+  - Horizon likely needs transaction-queue adjustments to accommodate min-sequence-number behavior
+  - SDK updates were described as relatively straightforward compared with larger past envelope changes
+- Payment-channel viability and patterns
+  - Experiments indicate CAP-21 enables safe, predictable payment channels, including flows involving issued assets and trustlines
+  - Regulated-asset considerations (e.g., SEP-8 style constraints) appear compatible with the channel designs explored
+  - Performance exploration continues (including “single-message channel” ideas), but isn’t viewed as a blocker for acceptance
+- Prioritization and “insurance policy” framing
+  - Landing the capability earlier reduces risk if a high-throughput use case arrives suddenly
+  - Also enables otherwise difficult patterns (notably account recovery-style flows) without complex workarounds
+
+### Resources
+
+- [CAP-21 — Preconditions: Generalized transaction preconditions](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0021.md)
+- [CAP-40 — Signed-Payload: Ed25519 Signed Payload Signer for Atomic Transaction Signature Disclosure](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0040.md)
+- [SEP-8: Regulated Assets](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md)
diff --git a/meetings/2021-11-12.mdx b/meetings/2021-11-12.mdx
new file mode 100644
index 000000000..bdc2d082d
--- /dev/null
+++ b/meetings/2021-11-12.mdx
@@ -0,0 +1,42 @@
+---
+title: "2021-11-12"
+description: A high-level walkthrough of Stellar’s real-world blockchain use cases, covering asset tokenization, anchors and stablecoins, wallets, on-chain trading, and how Stellar supports cross-border payments, remittances, and financial inclusion.
+authors: john
+tags: [community]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="VAU7MLbuZ6g" />
+
+This next-gen session introduced Stellar as a purpose-built blockchain for global financial infrastructure, focusing on how digital assets and open networks enable new forms of value creation, storage, and movement. The talk connected core blockchain concepts to practical examples, emphasizing accessibility, low fees, and interoperability.
+
+Speakers walked through how Stellar is used today: tokenizing assets, holding and diversifying value through wallets, and sending or exchanging assets across borders. Real-world applications—from NFTs and tokenized securities to stablecoins, remittances, and anchor-based on/off ramps—illustrated how the network supports both developers and end users, especially in emerging markets.
+
+### Key Topics
+
+- Tokenization on Stellar
+  - Issuing digital representations of fiat, securities, NFTs, and real-world assets
+  - Examples including NFTs, tokenized stocks, and fractional real estate access
+- Stablecoins, CBDCs, and anchors
+  - Role of anchors as regulated on/off ramps for fiat-backed assets
+  - Stablecoins like USDC and how they move value across borders
+  - Overview of CBDCs and their fit on open, permissionless networks
+- Wallets and value custody
+  - How Stellar wallets represent ownership on the ledger
+  - Examples ranging from general-purpose wallets to tools for refugees and the unbanked
+- On-chain trading and liquidity
+  - Built-in orderbook and automated market makers
+  - Path payments enabling seamless currency conversion across assets
+- Cross-border payments and remittances
+  - Replacing slow, expensive correspondent banking flows
+  - Use cases for B2B payments, remittances, and cash-based corridors
+  - Real-world integrations leveraging anchors and global partners
+- Ecosystem and community
+  - Overview of developers, fintechs, and financial institutions building on Stellar
+  - Learning and funding programs supporting builders and experimentation
+
+### Resources
+
+- [Stellar Quest](https://quest.stellar.org)
+- [Stellar Community Fund](https://communityfund.stellar.org)
diff --git a/meetings/2021-11-19.mdx b/meetings/2021-11-19.mdx
new file mode 100644
index 000000000..83efe2e4e
--- /dev/null
+++ b/meetings/2021-11-19.mdx
@@ -0,0 +1,53 @@
+---
+title: "2021-11-19"
+description: A technical walkthrough of Stellar’s architecture, covering how the network works end to end—from nodes, ledgers, and transactions to consensus, governance via CAPs and SEPs, and hands-on development using Horizon, SDKs, and Stellar Laboratory.
+authors: john
+tags: [community, CAP-38, SEP-31]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="umyvd60fV9g" />
+
+This session delivered a deep, system-level explanation of how Stellar operates under the hood. The discussion started with the fundamentals—nodes, accounts, ledgers, and transactions—and gradually built up to how those pieces fit together to enable fast, low-cost, and final payments on a global network.
+
+From there, the speakers explored Stellar’s unique approach to consensus and governance, comparing it to proof-of-work blockchains and explaining why safety, determinism, and low latency are core design goals. The session concluded with a practical developer walkthrough, showing how builders interact with Stellar using Horizon, SDKs, and Stellar Laboratory to issue assets and submit transactions.
+
+### Key Topics
+
+- Stellar network fundamentals
+  - Nodes running Stellar Core maintain a shared, immutable ledger
+  - Accounts, balances, and operations as the core ledger primitives
+  - Transactions composed of up to 100 ordered operations
+- Ledger updates and transaction flow
+  - Transactions submitted by users and applications worldwide
+  - Validators agree on transaction sets every few seconds
+  - Once applied, ledger changes are final and transparent
+- Consensus and security model
+  - Stellar Consensus Protocol (federated Byzantine agreement)
+  - Quorum slices, quorums, and open participation
+  - Preference for safety over liveness to avoid forks and reversals
+  - Comparison with Bitcoin and Ethereum consensus approaches
+- Performance and sustainability
+  - Fast finality with single-confirmation settlement
+  - Very low transaction fees compared to proof-of-work systems
+  - Energy-efficient consensus without mining or heavy computation
+- Open-source governance
+  - CAPs define protocol-level changes to Stellar Core
+  - SEPs define standards for building interoperable applications
+  - Network validators vote on protocol upgrades
+- Developer stack and tooling
+  - Stellar Core, Horizon API, and language SDKs
+  - Using Stellar Laboratory to build, sign, and submit transactions
+  - Live demo of issuing assets and querying ledger state
+- Getting started as a builder
+  - Testnet usage for safe experimentation
+  - Learning paths via documentation and Stellar Quest
+  - Community-driven development and contribution
+
+### Resources
+
+- [CAP-38: Automated Market Makers](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0038.md)
+- [SEP-31: Cross-Border Payments API](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md)
+- [Stellar Laboratory](https://laboratory.stellar.org)
+- [Stellar Quest](https://quest.stellar.org)
diff --git a/meetings/authors.yml b/meetings/authors.yml
index 9d92d724b..8f808c704 100644
--- a/meetings/authors.yml
+++ b/meetings/authors.yml
@@ -56,3 +56,11 @@ kaankacar:
   image_url: https://github.com/kaankacar.png
   socials:
     github: kaankacar
+john:
+  name: John Wooten
+  url: https://wooten.link
+  image_url: https://github.com/JFWooten4.png
+  socials:
+    github: jfwooten4
+    x: jfwooten4
+    linkedin: jfwooten4
diff --git a/routes.txt b/routes.txt
index 9f0304cc0..e85d6ff4f 100644
--- a/routes.txt
+++ b/routes.txt
@@ -837,6 +837,20 @@
 /docs/validators/admin-guide/soroban-settings
 /docs/validators/tier-1-orgs
 /meetings
+/meetings/2021/01/14
+/meetings/2021/01/28
+/meetings/2021/03/11
+/meetings/2021/04/15
+/meetings/2021/04/22
+/meetings/2021/05/06
+/meetings/2021/06/17
+/meetings/2021/07/28
+/meetings/2021/07/29
+/meetings/2021/09/09
+/meetings/2021/10/14
+/meetings/2021/10/28
+/meetings/2021/11/12
+/meetings/2021/11/19
 /meetings/2024/01/18
 /meetings/2024/01/26
 /meetings/2024/02/01
@@ -925,12 +939,25 @@
 /meetings/page/5
 /meetings/page/6
 /meetings/page/7
+/meetings/page/8
 /meetings/tags
+/meetings/tags/cap-18
+/meetings/tags/cap-21
+/meetings/tags/cap-28
+/meetings/tags/cap-29
+/meetings/tags/cap-35
+/meetings/tags/cap-37
+/meetings/tags/cap-38
+/meetings/tags/cap-40
+/meetings/tags/community
 /meetings/tags/developer
 /meetings/tags/developer/page/2
 /meetings/tags/developer/page/3
 /meetings/tags/developer/page/4
 /meetings/tags/developer/page/5
 /meetings/tags/developer/page/6
+/meetings/tags/legacy
 /meetings/tags/protocol
+/meetings/tags/sep-31
+/meetings/tags/sep-8
 /search