🗓️ Add 2020 meetings

meetings/2020-04-10.mdx

@@ -0,0 +1,25 @@
+---
+title: "2020-04-10"
+description: Tyler van der Hoeven explains how Stellar path payments route value through the decentralized exchange, demonstrating strict-send and strict-receive flows for wallets and cross-asset payments.
+authors: john
+tags: [tutorial]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="KzlSgSPStz8" />
+
+Tyler van der Hoeven kicked off the Engineering Talks series with a practical, developer-focused walkthrough of path payments and why they are one of Stellar’s most powerful primitives. He framed the core idea simply: traditional (“vanilla”) payments move assets, while path payments move value. By routing payments through the decentralized exchange and multiple order books in a single atomic operation, Stellar enables complex conversions without users or applications manually touching markets.
+
+Through live demos, Tyler showed how path payments can be used as market orders inside a wallet, as well as how they scale into more complex, enterprise-style flows. These examples illustrated how trustlines, order books, strict send/receive constraints, and atomic execution combine to make cross-asset payments reliable, composable, and developer-friendly, even when liquidity is fragmented.
+
+### Key Topics
+
+- How path payments differ from standard payments by converting assets across the DEX to deliver value, not just tokens.
+- Using path payments as market orders inside wallets, including self-payments to acquire new assets without visiting an exchange.
+- Sending one asset (e.g., USD) while the recipient receives another (e.g., BTC), with all conversions handled automatically.
+- Enterprise-style flows where market makers seed orderbooks (e.g., USD/EUR) and wallets route payments without holding intermediate assets.
+- The importance of atomic execution for price certainty and user protection within a single ledger close.
+- Liquidity considerations, failed paths, and how strict send/receive settings safeguard users.
+- Why market makers and better tooling are critical to scaling path payments and the Stellar DEX.
+- The broader implication of transacting in value rather than assets, enabling global payments across currencies as long as markets exist.

meetings/2020-04-16.mdx

@@ -0,0 +1,30 @@
+---
+title: "2020-04-16"
+description: This roundtable develops a send/receive SEP for anchor-to-anchor transfers, covering interoperability with SEP-6, SEP-10, and SEP-24, KYC responsibilities, transaction lifecycles, and regulatory constraints.
+authors: john
+tags:
+  - community
+  - SEP-6
+  - SEP-10
+  - SEP-12
+  - SEP-16
+  - SEP-24
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="MnGIj8X33aI" />
+
+Lisa Nestor moderated the first virtual roundtable focused on defining a new “send/receive” SEP that standardizes how anchors transfer funds to each other on behalf of end users. She opened by explaining how Stellar Ecosystem Proposals evolve from community discussion into GitHub drafts, and why this effort builds on existing standards like SEP-6, SEP-10, and SEP-24 rather than reinventing anchor interoperability from scratch.
+
+The discussion quickly moved from theory into real-world remittance workflows. Participants from Tempo, SatoshiPay, Cowrie, and SDF examined how KYC data should flow, which responsibilities belong inside or outside the SEP, and how edge cases like failed bank deposits or cash pickup name mismatches should be handled. The group emphasized keeping the protocol narrow and composable, while leaving space for bilateral agreements, compliance-as-a-service providers, and future extensions.
+
+### Key Topics
+
+- Scope of a send/receive SEP: why anchor-to-anchor payments need a dedicated endpoint, and which responsibilities (onboarding, business agreements) intentionally live outside the protocol.
+- Relationship to existing SEPs: reusing SEP-6/24 request shapes, SEP-10 for anchor authentication, and debating whether SEP-12 adds value for this flow.
+- KYC handling: when sending anchors can reuse stored customer data, when receiving anchors dictate requirements, and how third-party compliance providers might integrate.
+- Transaction lifecycle gaps: need for clearer intermediate statuses (pending, info-needed), update flows for fixable errors, and better handling of cash rename scenarios.
+- Refunds and failures: why full refunds are costly, and how update-in-place mechanisms could improve user experience for downstream bank rejections.
+- Jurisdictional complexity: differing regulatory requirements across regions, and why high-touch compliance cases cannot always be fully codified.
+- Ecosystem trust model: anchors are independent, regulated businesses, with reputation and bilateral trust—not SDF—governing who participates.

meetings/2020-04-24.mdx

@@ -0,0 +1,31 @@
+---
+title: "2020-04-24"
+description: This engineering talk examines usability barriers in Stellar applications—including key management, trustlines, anchors, federation, recovery, and the DEX—and how developers can abstract them for users.
+authors: john
+tags:
+  - tutorial
+  - SEP-5
+  - SEP-6
+  - SEP-26
+  - SEP-30
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="hVGHMkYL15s" />
+
+Kolten led this Engineering Talks session with a focus on usability rather than protocol mechanics, framing the discussion around how developers can make Stellar applications approachable for people who are new to blockchain. He described the main obstacles users face—key management, on/off ramps, trustlines, anchors, and the DEX—and argued that most of this “hard stuff” should be abstracted away so users can focus on clear, understandable actions.
+
+The talk emphasized that Stellar Ecosystem Proposals (SEPs) are the primary tool for achieving this abstraction. By treating SEPs as an application-layer standard rather than core protocol changes, teams can build interoperable products that evolve over time while delivering simpler user experiences. Kolten illustrated how narrowing scope, simplifying interfaces, and educating users up front can dramatically improve adoption without sacrificing the power of the network.
+
+### Key Topics
+
+- Why usability is a major barrier to adoption, especially for developers and users who are new to blockchain.
+- Treating SEPs as the glue between apps and the network, enabling interoperability without exposing protocol complexity.
+- Federation (SEP-5) and mnemonic phrases as ways to reduce user anxiety around public and private keys.
+- Account recovery via SEP-30 as a critical usability improvement for lost keys without handing control to third parties.
+- Anchor standards (SEP-6, SEP-24, SEP-26) that let users move between the real world and Stellar without leaving their wallet.
+- The progression from raw tools (Stellar Laboratory) to wallets, and finally to single-purpose apps with focused use cases.
+- Examples of simplifying experiences through vertical apps like SatoshiPay, DStoq, and Vega.
+- The importance of onboarding and education: showing value before sign-up, clear messaging, and localized translations.
+- Encouraging developers to both follow existing standards and participate in creating new ones as the ecosystem evolves.

meetings/2020-04-30.mdx

@@ -0,0 +1,36 @@
+---
+title: "2020-04-30"
+description: This roundtable advances a direct-send SEP for anchor-to-anchor fiat transfers, focusing on multilateral KYC, regulatory data sharing, and noncustodial wallet initiation through SEP-10.
+authors: john
+tags:
+  - community
+  - SEP-3
+  - SEP-6
+  - SEP-9
+  - SEP-10
+  - SEP-24
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="PKWHBdiJZhk" />
+
+Lisa Nestor reconvened the Stellar ecosystem for a continued public roundtable on creating a “direct send” (or send/receive) SEP, building on discussions from two weeks earlier. She framed the session around a key gap in today’s standards: while SEP-6 and SEP-24 handle deposit and withdrawal flows well, many real-world remittance and B2B payments never touch a wallet at all. In these cases, users simply want funds to move from one bank account or cash point to another, and Stellar lacked a clear, standardized way to support that fiat-to-fiat flow between anchors.
+
+The conversation focused on two major extensions needed to make this model viable at scale. First was multilateral KYC, where anchors could securely share compliance results instead of duplicating checks in every jurisdiction. Second was enabling noncustodial wallets to initiate direct send transactions without becoming anchors themselves. Representatives from Tempo, Cowrie, SatoshiPay, Inclusive, and SDF explored how these pieces could fit together while preserving regulatory responsibility, user consent, and anchor control.
+
+### Key Topics
+
+- Purpose of the direct send SEP as a complement to SEP-6 and SEP-24, targeting anchor-to-anchor fiat payments where recipients never interact with digital assets.
+- How SEPs evolve as open, community-driven standards to formalize new Stellar use cases as they emerge.
+- Inclusive’s multilateral KYC (“EDD Connect”) concept for sharing KYC and KYB results across anchors to reduce cost, friction, and regional specialization.
+- Regulatory considerations across strict jurisdictions such as the EU, Japan, and Switzerland, and the need for authorized compliance providers.
+- Handling edge cases where receiving anchors require additional data beyond what originating anchors collected.
+- Consent, privacy, and trust models for sharing KYC data, including which parties can access data and under what conditions.
+- Enabling noncustodial wallets to initiate direct sends through SEP-10 authentication, key whitelisting, and anchor-controlled endpoints.
+- Separation of concerns between KYC processes and payment execution to allow pre-registration and smoother user experiences.
+- Use of memos and references so wallet-initiated payments can carry user-specified identifiers through bank transfers.
+
+### Resources
+
+- [GitHub discussion thread (pre-read)](https://github.com/stellar/stellar-protocol/pull/592)

meetings/2020-05-08.mdx

@@ -0,0 +1,28 @@
+---
+title: "2020-05-08"
+description: This overview highlights how SCP works end-to-end—quorum sets, blocking sets, federated voting, and how nomination + ballot narrow the network to one ledger value.
+authors: john
+tags: [tutorial]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="fDt8Eh4T_lE" />
+
+Marta Lokhava walks through the Stellar Consensus Protocol (SCP) in plain language, aiming to give newcomers a mental model before they dive into formal specs. She starts by defining quorum sets (who you trust), thresholds (how many of them must agree), quorum slices (subsets that meet the threshold), and blocking sets (the smallest sets that can prevent you from moving forward).
+
+With those primitives, she introduces **statements** as SCP’s basic unit of agreement (e.g., “I propose transaction set X for ledger N” or “I’m ready to apply transaction set X”). She then explains **federated voting**—how nodes progress from _vote_ → _accept_ → _confirm_ on a statement—and uses a step-by-step demo to show how blocking sets can force nodes that initially voted differently to converge on the same outcome.
+
+Finally, she frames SCP as a **funnel**: the **nomination protocol** gathers and confirms a candidate set of values (transaction sets), while the **ballot protocol** _prepares_ and then _commits_ a single value. Nomination continues in the background while ballot runs, letting the system start optimistically but still converge safely if the network needs to adjust.
+
+### Key Topics
+
+- Clear definitions of quorum sets, thresholds, quorum slices, and blocking sets—and how each node’s configuration shapes safety and liveness.
+- Federated voting mechanics (vote/accept/confirm) and why “accepting what your blocking set accepted” prevents deadlock.
+- SCP’s two-phase structure: nomination to build a candidate set, then ballot to prepare/commit one value.
+- Why ballot can start as soon as a node confirms its first nomination, even while nomination continues (optimistic progress with safe fallback).
+- Practical guidance on thresholds: aiming for ~67% across organizations, while internal org nodes may use lower thresholds; recommendation to use Stellar Core’s automatic quorum generation.
+
+### Resources
+
+- Blog Post: [Intuitive Stellar Consensus Protocol](https://stellar.org/blog/developers/intuitive-stellar-consensus-protocol)

meetings/2020-05-22.mdx

@@ -0,0 +1,29 @@
+---
+title: "2020-05-22"
+description: This overview highlights Kelp GUI v1—how it simplifies launching and managing market-making bots on the SDEX, from bot creation and price feeds to advanced safeguards and clean shutdown.
+authors: john
+tags: [tutorial]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="zxBoERxZcQs" />
+
+Nikhil Saraf introduces **Kelp GUI v1**, the desktop interface for Kelp—an open-source trading bot originally built for the Stellar decentralized exchange (and later extended to many centralized exchanges via the CLI). The focus of the talk is how the GUI lowers the barrier for non-technical liquidity providers by turning configuration-heavy market-making into a guided workflow: generate a starter bot, or create a custom one by selecting assets, setting spreads and levels, and wiring up price feeds.
+
+He explains how pricing in the **buy/sell strategy** works by composing a numerator and denominator feed (for example, valuing XLM via an exchange feed while treating a “coupon” asset as a fixed $1). The GUI displays the derived mid price and lets users define multiple “levels” around that mid, which translate into ladders of bids and asks. A live demo shows creating two bots on testnet, connecting a fiat price feed (Currencylayer), and using “advanced” price adjustments (offsets) to intentionally misprice one bot so it trades through the other—illustrating how bots place, cross, and refresh offers over time.
+
+Nikhil also emphasizes **operational hygiene**: if you quit without stopping a bot, its offers can remain on the orderbook, potentially filling unexpectedly. Stopping a bot should both halt the process and cancel outstanding offers so the market doesn’t retain stray bids/asks after you’re done.
+
+### Key Topics
+
+- What Kelp is (CLI + strategies in Go) and why the GUI matters for first-time market makers on the SDEX.
+- Bot setup workflow: secret key handling, asset/issuer selection, and the “starter bot” vs custom configuration paths.
+- Price feeds and derived pricing: composing numerator/denominator sources, sanity-checking quotes, and understanding how the bot refreshes prices on an interval.
+- Market-making controls: spreads, multi-level ladders, order sizing, and how thin/no markets affect displayed spread.
+- Advanced safeguards and tuning: correction knobs (offset % / offset), multipliers, and preventing bad quoting when price data drifts.
+- Safe shutdown: stopping bots to cancel offers so you don’t leave live orders behind.
+
+### Resources
+
+- [GitHub PR / Discussion referenced](https://github.com/stellar/stellar-protocol/pull/592)

meetings/2020-06-04.mdx

@@ -0,0 +1,52 @@
+---
+title: "2020-06-04"
+description: The first livestreamed Open Protocol Discussion reviews proposed Core Advancement Proposals for Protocol 14, focusing on claimable balances, sponsored reserves, and process improvements for evaluating and rolling out protocol changes.
+authors: john
+tags:
+  - legacy
+  - CAP-18
+  - CAP-23
+  - CAP-31
+  - CAP-33
+  - SEP-8
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="u3B0q3tt7u4" />
+
+Justin Rice opened the first livestreamed Open Protocol Discussion with an update on Protocol 13, explaining why the validator vote was delayed by two weeks to give exchanges additional time to complete testing. That operational context set the tone for the rest of the call, which focused on how protocol changes are evaluated, coordinated, and safely rolled out across a diverse ecosystem.
+
+The discussion then turned to proposals targeting Protocol 14, especially claimable balances and sponsored reserves. Participants dug into how these changes affect payment flows, reserve economics, and wallet and service design. As the conversation evolved, it widened into a candid examination of process gaps—how working groups should be structured, how downstream impacts on Horizon and SDKs can be surfaced earlier, and how upgrade communications can better reach exchanges and operators who do not closely follow core developer channels.
+
+### Key Topics
+
+- **Protocol 13 readiness and coordination**
+  - Validator vote delayed to late June to avoid breaking exchanges.
+  - Need for clearer runbooks, readiness checks, and direct outreach to large operators.
+- **CAP-23: Claimable Balances (Two-part Payments)**
+  - Separating sending from receiving so payments can be delivered to unprepared accounts.
+  - Decision that unclaimable funds route to the fee pool rather than back to the sender.
+  - General agreement that the proposal is ready for Final Comment Period.
+- **CAP-33: Sponsored Reserves**
+  - Allowing one party (issuers, wallets, services) to cover reserves for user accounts.
+  - Handshake workflows between sponsor and sponsored account, especially during `create_account`.
+  - Sequence-number lockups as a scaling concern and recognition that this exposes a broader, long-standing protocol limitation.
+- **Delegated authorization and future primitives**
+  - Discussion of longer-term ideas (operation-level authorization, pre-signed operations) to reduce reliance on sequence numbers.
+  - Consensus that CAP-33 should proceed while the broader problem is addressed separately.
+- **Issue 622: Close time application**
+  - Tradeoffs in how transaction time bounds are evaluated during consensus.
+  - Concerns about delayed ledgers, expired transactions, and brittle smart contract assumptions.
+  - Agreement to clarify requirements before committing to a concrete solution.
+- **Issue 624: Improving the CAP process**
+  - Formalizing working groups and clarifying ownership and responsibilities.
+  - Capturing downstream impacts on Horizon, SDKs, exchanges, and hardware wallets earlier.
+  - Improving upgrade communication so ecosystem participants know when and how to prepare.
+
+### Resources
+
+- [CAP-23: Two-part Payments (Claimable Balances)](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0023.md)
+- [CAP-33: New Sponsored Reserves](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md)
+- [Issue 622: Request to change close time application](https://github.com/stellar/stellar-protocol/issues/622)
+- [Issue 624: Update CAP process](https://github.com/stellar/stellar-protocol/issues/624)