🗓️ Add 2022 meetings

meetings/2022-02-03.mdx

@@ -0,0 +1,44 @@
+---
+title: "2022-02-03"
+description: This discussion examined CAP-42 and the idea of multi-part transaction sets as a way to segment ledger capacity into lanes with independent fee dynamics. The session explored how transaction grouping could protect baseline payments from arbitrage-driven congestion while preparing the protocol for future engines like SPEEDEX and smart contracts.
+authors: john
+tags: [legacy, CAP-42]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="se056YzMe28" />
+
+The session focused on the operational and protocol implications of CAP-42, which proposes multi-part transaction sets to allow different categories of transactions to compete on fees independently. The core motivation was mitigating arbitrage-driven fee spikes and high failure rates that degrade user-facing use cases like payments and simple transfers.
+
+Participants debated how lane-based transaction grouping could evolve Stellar’s fee model without breaking existing expectations, and how much discretion validators should have in setting fees or execution order. The conversation also connected CAP-42 to longer-term goals, including SPEEDEX integration, multi-phase block execution, and improved observability and tooling for operators.
+
+### Key Topics
+
+- Motivation for CAP-42
+  - Arbitrage spikes crowding out payments and increasing failure rates
+  - Need to isolate fee competition without raising global base fees
+- Multi-part transaction sets
+  - Grouping transactions into independent “lanes”
+  - Allowing per-group fee dynamics and capacity limits
+  - Preventing one class of activity from dominating the ledger
+- Validator discretion and fee models
+  - Limits of the current Dutch auction mechanism
+  - Debate over per-group vs per-transaction fee control
+  - Trade-offs between transparency, simplicity, and flexibility
+- SPEEDEX and future execution models
+  - Dedicated lanes for SPEEDEX-style trades
+  - Preparing for multi-phase or parallel execution
+  - Avoiding intermingling of incompatible transaction types
+- Operational concerns
+  - Guard rails for lane capacity and validator configuration
+  - Detecting and isolating repeated failing transactions
+  - Telemetry, logging, and observability requirements
+- Developer and ecosystem impact
+  - How wallets and Horizon would surface lane behavior
+  - Predictability of fees for users and applications
+  - Documentation needs as fee policies become more nuanced
+
+### Resources
+
+- [CAP-42: Multi-Part Transaction Sets](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0042.md)

meetings/2022-02-17.mdx

@@ -0,0 +1,58 @@
+---
+title: "2022-02-17"
+description: This discussion revisited CAP-42 with its revised lane-based fee semantics and introduced CAP-44, which defines how validators configure SPEEDEX trading. The conversation focused on validator discretion, fee transparency, downstream tooling impacts, and how SPEEDEX asset lists and parameters should be governed without harming usability or fairness.
+authors: john
+tags:
+  - legacy
+  - CAP-21
+  - CAP-40
+  - CAP-42
+  - CAP-44
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="lbYWhIEgUJE" />
+
+The session opened by confirming CAP-21 (generalized transaction preconditions) and CAP-40 (new shared-signer type) had reached final comment, clearing the way for payment channels, bridges, and more advanced transaction sharing ahead of Protocol 19. With those nearly finalized, the group turned its attention to fee lanes and high-throughput exchange design.
+
+Most of the discussion centered on the revised CAP-42 and the first public review of CAP-44. Participants explored how validator-controlled fee policies, execution phases, and SPEEDEX configuration interact, with particular focus on fairness, operator observability, and the burden placed on wallets, Horizon, and other downstream systems.
+
+### Key Topics
+
+- CAP-42 revisions and lane-based fee policy
+  - Introduction of execution phases to prepare for SPEEDEX and future engines
+  - Explicit acknowledgment that validators control fee regimes per lane
+  - Renaming “surge pricing” behavior as discounts to better reflect user expectations
+  - Trade-offs between Dutch auction guarantees and validator discretion
+- Validator behavior, trust, and observability
+  - Reliance on validator reputation and social contracts rather than hard guarantees
+  - Need for better telemetry and audit tooling to detect unfair fee behavior
+  - Discussion of exposing lane and fee data more clearly via Horizon
+- Downstream ecosystem impact
+  - Wallets may need more active fee management and retry strategies
+  - Potential role for Horizon in automated fee bumping or submission retries
+  - Education required as users can no longer safely overbid by large margins
+- CAP-21 and CAP-40 status update
+  - Both moved into final comment period targeting Protocol 19
+  - Critical enablers for payment channels, interoperability, and shared signing workflows
+- Introduction to CAP-44 (SPEEDEX configuration)
+  - Validators configure SPEEDEX parameters and eligible asset sets
+  - Motivation: batch trading for scalability, fairness, and reduced arbitrage spam
+  - Separation of SPEEDEX into multiple smaller CAPs to avoid monolithic proposals
+- SPEEDEX asset selection and governance questions
+  - Concerns about validators “picking winners and losers”
+  - Exploration of alternatives: issuer consent, reserve-based admission, multiple SPEEDEX pools
+  - Computational limits (notably linear programming) driving caps on asset set size
+  - Tension between flexibility, fairness, and operational simplicity
+
+### Outcomes
+
+- CAP-21 and CAP-40 were approved and entered Final Comment Period
+
+### 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)
+- [CAP-42: Multi-Part Transaction Sets](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0042.md)
+- [CAP-44: SPEEDEX - Configuration](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0044.md)

meetings/2022-03-03.mdx

@@ -0,0 +1,53 @@
+---
+title: "2022-03-03"
+description: This discussion revisited CAP-42 and introduced CAP-44, focusing on lane-based fee mechanics and the on-chain configuration of SPEEDEX. The conversation centered on validator discretion, wallet behavior, governance tradeoffs, and the operational limits that shape how SPEEDEX asset sets can scale.
+authors: john
+tags: [legacy, CAP-42, CAP-44]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="uAkvN1WtQbY" />
+
+This session continued the deep technical discussion around transaction fee lanes and the emerging SPEEDEX architecture. The first half focused on final refinements to CAP-42, clarifying how multi-part transaction sets change fee bidding strategies, what wallets should expect when lanes fill, and how validators can safely roll out lane-based behavior without breaking existing tooling.
+
+The second half introduced and stress-tested CAP-44, which defines how SPEEDEX is configured on-chain. Much of the discussion explored governance and scalability tradeoffs: who decides which assets participate in SPEEDEX, how many assets can realistically be supported, and whether validators, asset issuers, or market forces should control inclusion as the system scales.
+
+### Key Topics
+
+- CAP-42 readiness and rollout considerations
+  - Lane-based fee policies and revised transaction ordering
+  - Wallet behavior changes: re-signing vs fee bumping
+  - Validator-controlled activation and coordination timing
+  - Communication needs for ecosystem readiness ahead of Protocol upgrades
+- Motivation for CAP-44 (SPEEDEX configuration)
+  - Enabling a fully on-chain, batch-based decentralized exchange
+  - Removing the need to guess intermediary assets in path payments
+  - Separating SPEEDEX into smaller CAPs to reduce risk and complexity
+- Asset selection and governance debates
+  - Validator-controlled configuration vs issuer-driven preferences
+  - Concerns about liability, neutrality, and “picking winners”
+  - Discussion of veto power, defaults, and issuer opt-in models
+  - Risks of stake-weighted or heuristic-based asset selection
+- Single vs multiple SPEEDEX instances
+  - Tradeoffs between predictability and flexibility
+  - Liquidity fragmentation versus scalability constraints
+  - Possibility of multiple SPEEDEX pools as a safety valve
+- Scalability and computational limits
+  - Price discovery and linear programming constraints
+  - Practical upper bounds on asset set size (hundreds, not thousands)
+  - Need to balance performance with market completeness
+- Observability and operator tooling
+  - Validator telemetry and logging requirements
+  - Horizon and SDK exposure of lane and SPEEDEX configuration
+  - Monitoring unhealthy lanes and failed submissions post-rollout
+
+### Outcomes
+
+- CAP-42 was considered ready for an asynchronous CAP committee vote, targeting inclusion in Protocol 19.
+- CAP-44 remained open for further iteration, with follow-up proposals and concrete alternatives requested before advancing.
+
+### Resources
+
+- [CAP-42: Multi-Part Transaction Sets](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0042.md)
+- [CAP-44: SPEEDEX - Configuration](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0044.md)

meetings/2022-03-11.mdx

@@ -0,0 +1,36 @@
+---
+title: "2022-03-11"
+description: Hands-on workshop covering how to design, mint, and trade innovative NFTs on Stellar using JavaScript, with a focus on composable NFTs, royalty enforcement, and Stellar-native primitives.
+authors: john
+tags: [community]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="v576JFBuwFU" />
+
+This developer workshop walks through how NFTs can be built on Stellar using JavaScript, focusing on practical architecture rather than hype. Speakers explain how Stellar’s account model, authorization controls, and transaction composition enable programmable NFT experiences such as enforced royalties and conditional transfers.
+
+The session combines conceptual grounding (what NFTs are, how they differ from fungible assets, and why smart contracts matter) with a detailed, end-to-end technical demo. Developers are shown how to mint NFTs, attach IPFS metadata, control asset behavior via authorization servers, and implement royalty payments that persist across secondary sales.
+
+### Key Topics
+
+- Overview of NFTs as programmable, non-fungible assets and how smart contracts drive on-chain experiences
+- Why Stellar is well-suited for NFTs (low fees, fast settlement, accessibility, and built-in DEX)
+- Stellar-specific primitives: accounts, trustlines, Horizon API, asset authorization, and sponsorship
+- Anatomy of a Stellar NFT: issuing account, IPFS-hosted metadata, and transfer controls
+- Building “innovative NFTs” by combining NFTs with custom transaction logic
+- Live walkthrough of a JavaScript project that:
+  - Mints NFTs on Stellar testnet
+  - Stores metadata via IPFS
+  - Enforces royalty payments on every resale
+  - Uses an authorization server to control asset behavior
+- Practical discussion of decentralization trade-offs and future paths (Turrets, upcoming on-chain smart contracts)
+
+### Resources
+
+- [Stellar NFT Hackathon on Devpost](https://stellarnft.devpost.com)
+- [Stellar Horizon API Documentation](/docs/data/apis)
+- [Stellar JavaScript SDK](/docs/tools/sdks)
+- [Lightmint NFT Marketplace on Stellar](https://lightmint.io)
+- [InterPlanetary File System (IPFS)](https://ipfs.tech)

meetings/2022-03-15.mdx

@@ -0,0 +1,28 @@
+---
+title: "2022-03-15"
+description: A panel discussion with African fintech founders reflecting on their Stellar Blockchain Bootcamp experience, product growth, and lessons learned building real-world applications on Stellar.
+authors: john
+tags: [community]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="W-BIwZOLnPY" />
+
+This session brings together founders who participated in the Stellar Blockchain Bootcamp to reflect on how their products evolved after building on Stellar. Panelists share how design sprints, hands-on mentorship, and ecosystem support helped them validate ideas, ship prototypes, and unlock new growth opportunities.
+
+The conversation highlights practical use cases across payments, on- and off-ramps, creator monetization, SME financing, and offline access to digital dollars. Speakers also discuss fundraising outcomes, regulatory challenges, and why Stellar’s low-cost, fast, and interoperable infrastructure continues to support their next phase of growth.
+
+### Key Topics
+
+- Bootcamp-driven product pivots and rapid prototyping using design sprints
+- Real-world Stellar use cases: USDC wallets, offline payments, creator payouts, and invoice financing
+- Growth milestones following the bootcamp, including seed funding and grants
+- The role of anchors, AMMs, and interoperability in scaling fintech products
+- Value of mentorship, founder networks, and post-bootcamp ecosystem support
+- Regulatory considerations when building blockchain-based financial services in Africa
+- Advice for future bootcamp participants, including early-stage and non-technical founders
+
+### Resources
+
+- [Stellar Community Fund](https://communityfund.stellar.org)

meetings/2022-04-28.mdx

@@ -0,0 +1,33 @@
+---
+title: "2022-04-28"
+description: This session digs into CAP-46’s foundations for Stellar smart contracts, focusing on the host/guest execution boundary, core value/object types, and how a shared data model can enable deterministic execution and future interoperability.
+authors: john
+tags: [legacy, CAP-46-1, SEP-8]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="HTK-DJ31QzA" />
+
+This discussion introduces Project Jump Cannon’s early building blocks by walking through CAP-46 (now CAP-46-1), the proposal that defines the low-level vocabulary for a WASM-based smart contract system on Stellar. Rather than adding user-facing transactions immediately, the focus is on establishing the “nouns” (types, handles, host objects, and XDR structures) that later protocol changes will build on.
+
+Much of the conversation centers on how smart contracts should execute deterministically and efficiently: contracts run as “guest” code inside a WASM runtime, while Stellar Core acts as the “host” that enforces limits, mediates storage, and provides shared primitives. The group also surfaces open design questions around interoperability with classic Stellar operations, authorization models, and what requirements should drive the evolving architecture.
+
+### Key Topics
+
+- Project Jump Cannon direction: why Stellar chose WASM and why CAP-46-1 is a foundational, non-user-facing building block.
+- CAP-46-1’s “vocabulary-first” approach: new XDR definitions for values, objects, and handles intended to keep future CAPs smaller.
+- Host/guest boundary: guest contracts run in a constrained, deterministic environment while the host mediates access to resources and data.
+- Value vs object split: passing simple tagged values across the boundary while storing richer structures as host-managed objects.
+- Shared data model benefits: lower contract code size, reusable serialization, better contract-to-contract interop, and more inspectable on-ledger data.
+- Open questions on determinism and safety (e.g., whether to support floating point and how to avoid non-deterministic behavior).
+- Interoperability debate: how much “classic” Stellar functionality (payments, trustlines, authorization, signers) smart contracts should be able to invoke.
+- Authorization and privilege models: whether signing-weight-style permissions are sufficient, and how to avoid confused-deputy/ambient-authority pitfalls.
+- Forward-looking performance considerations: discussion touches on parallelism concepts, while noting CAP-46 itself is intentionally limited to core types.
+
+### Resources
+
+- [Project Jump Cannon: Choosing WASM (blog post)](https://stellar.org/blog/developers/project-jump-cannon-choosing-wasm)
+- [CAP-46-1: WebAssembly Smart Contract Runtime Environment](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046-01.md)
+- [CAP-46-1 discussion thread](https://groups.google.com/g/stellar-dev/c/X0oRzJoIr10) ([alternate](https://groups.google.com/g/stellar-dev/c/vkzMeM_t7e8))
+- [SEP-8: Regulated Assets](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md)

meetings/2022-05-05.mdx

@@ -0,0 +1,45 @@
+---
+title: "2022-05-05"
+description: This discussion continues the Jump Cannon design work by comparing two competing approaches for smart contract asset interoperability on Stellar, weighing ease of use, security, issuer controls, and ERC-20 compatibility.
+authors: john
+tags:
+  - legacy
+  - CAP-46-1
+  - CAP-46-2
+  - CAP-48
+  - CAP-49
+  - SEP-8
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="oGoqR05-RP0" />
+
+This session dives deeper into Project Jump Cannon by focusing on how existing “classic” Stellar assets should interoperate with smart contracts. The core of the conversation contrasts two proposed models—CAP-48 and CAP-49—and evaluates how each balances backward compatibility, developer ergonomics, security guarantees, and long-term ecosystem evolution.
+
+Participants explore the trade-offs between frictionless integration of existing assets versus a cleaner separation that more closely mirrors ERC-20 semantics. The discussion also broadens into related topics such as issuer compliance controls, wallet and Horizon implications, and how asset design choices may shape adoption, scalability, and user experience across both classic Stellar and Soroban.
+
+### Key Topics
+
+- Comparison of asset interoperability approaches:
+  - CAP-48’s adapter-style model that directly operates on classic trustlines.
+  - CAP-49’s wrap/unwrap model that escrows classic balances and mints ERC-20-like tokens for smart contract use.
+- Design goals for interoperability: immediate usability of existing assets, minimal issuer effort, performance, and safety.
+- ERC-20 compatibility concerns, including `balanceOf`, `totalSupply`, allowances, and predictable transfer semantics.
+- How wrap/unwrap boundaries isolate classic mechanics while enabling cleaner smart-contract abstractions.
+- Preservation of issuer controls such as authorization, revocation, and clawback when assets move into smart contracts.
+- Security considerations around signing authority and preventing smart contracts from over-spending user balances.
+- UX and infrastructure implications for wallets, Horizon, and future data access layers when assets exist in both classic and smart contexts.
+- Issuer decision-making trade-offs between classic assets (scale, cost, exchange compatibility) and smart-native assets (flexibility, programmability).
+- Related CAP discussions:
+  - CAP-47 (now CAP-46-2) on smart contract lifecycle and mutability.
+  - Questions around contract versioning, auditability, and how downstream systems track contract code over time.
+
+### Resources
+
+- [Project Jump Cannon: Choosing WASM](https://stellar.org/blog/developers/project-jump-cannon-choosing-wasm)
+- [CAP-46-1: WebAssembly Smart Contract Runtime Environment](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046-01.md)
+- [CAP-46-2: Smart Contract Life Cycle](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046-02.md)
+- [CAP-48: Smart Contract Asset Interoperability](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0048.md)
+- [CAP-49: Smart Contract Asset Interoperability with Wrapper](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0049.md)
+- [SEP-8: Regulated Assets](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md)