🗓️ Add 2023 meetings

meetings/2023-01-12.mdx

@@ -0,0 +1,31 @@
+---
+title: "2023-01-12"
+description: A detailed review of the Soroban Auth Next proposal, examining account abstraction, standardized authorization payloads, and their impact on wallets, fees, and contract composability.
+authors: john
+tags: [developer, soroban]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="-RE0gGD0oUw" />
+
+This follow-up session revisits Soroban Auth Next with a deeper technical review and open Q&A. The group focused on validating the proposal’s core ideas against real developer and wallet concerns, especially around complexity, performance, replay protection, and preserving simple signing flows for common use cases.
+
+Discussion emphasized how moving authentication into the protocol can reduce fragmentation while still supporting advanced scenarios like multi-step contract execution, delegated authorization, and programmable accounts. Much of the review centered on how standardized authorization trees, preflight recording, and host-managed nonces interact in practice.
+
+### Key Topics
+
+- Review of current auth fragmentation (`invoker`, `soroban-auth`, custom schemes) and why it scales poorly.
+- Account abstraction model where contracts interact with generic accounts, not cryptographic primitives.
+- Standardized authorization payloads that describe authorized call subtrees (not full call stacks).
+- Preflight “recording” to deterministically build payloads wallets can sign once per account.
+- How authorization forests allow selective signing of nested contract calls.
+- Gas, performance, and depth concerns for large call graphs.
+- Security considerations around partial authorization, front-running, and contract design pitfalls.
+- Preserving simple invoker-style UX for common cases via built-in account implementations.
+- Replay protection, nonce consumption, and the need for expiration or ledger-bound signatures.
+
+### Resources
+
+- [Soroban Auth Next proposal document](https://docs.google.com/document/d/1J-J3ClTUkrsLiJag906OH4hmNkZI3Jk6_Y9ZYt_psAI/view)
+- [Soroban protocol and CAP discussions](https://github.com/stellar/stellar-protocol)

meetings/2023-02-23.mdx

@@ -0,0 +1,35 @@
+---
+title: "2023-02-23"
+description: Discussion of Soroban state rent, archival storage, and configuration upgrades, covering rent mechanics, security tradeoffs, and approaches to managing large network configuration data.
+authors: john
+tags: [soroban, CAP-46, CAP-46-9]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="45zgjaRBdW0" />
+
+This session combined two major threads: how Soroban network configuration should scale beyond ledger-header limits, and how state rent and archival storage can bound ledger growth without breaking contract safety. The discussion emphasized that Soroban parameters (like metering and fees) are too large and flexible to live in the ledger header long term, motivating new upgrade mechanisms tied to dedicated ledger entries.
+
+The second half focused on state rent and archival mechanics. To prevent unbounded ledger growth, Soroban introduces rent-backed contract data that expires and moves to an archive. This enables pruning unused state while preserving recoverability, but introduces subtle security challenges around replay protection, versioning, and key collisions that must be addressed at the storage-model level.
+
+### Key Topics
+
+- Limitations of storing Soroban configuration (metering, fees, limits) directly in the ledger header.
+- Three approaches to scalable configuration upgrades, with strong interest in using Soroban ledger entries as upgrade inputs.
+- Validators voting on hashes of configuration sets, not raw data, to avoid SCP bloat.
+- Using Soroban and ledger entries to make configuration proposals on-chain and auditable.
+- Motivation for state rent: bounding ledger growth and incentivizing cleanup of unused data.
+- Archival storage model using Merkle proofs, with validators storing only archive roots.
+- Security risks from archival state, including nonce replay and restoring outdated data.
+- Three Soroban storage classes:
+  - **Unique storage** for data that must never have multiple versions (e.g. nonces).
+  - **Recreatable storage** for mergeable or replaceable data (e.g. balances).
+  - **Temporary storage** for short-lived, non-recoverable data.
+- Contract-level responsibility for resolving key collisions when restoring recreatable data.
+- Role of preflight and RPC nodes in fetching archive proofs and preparing transactions.
+
+### Resources
+
+- [CAP-46: Soroban smart contract system overview](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046.md)
+- [CAP-46-9: Network Configuration Ledger Entries](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046-09.md)

meetings/2023-03-02.mdx

@@ -0,0 +1,36 @@
+---
+title: "2023-03-02"
+description: "Discussion of the Auth Next proposal plus related protocol work: Soroban fee-model considerations, ledger-state archiving design, and rent-bumping mechanics for on-chain storage."
+authors: john
+tags: [soroban, CAP-46-7]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="1KN3aYzj0S4" />
+
+This session reviews the Auth Next direction (account-abstraction style authorization with standardized payloads) alongside adjacent protocol concerns that impact developer UX and network sustainability.
+
+Conversation also digs into Soroban economics and storage lifecycle: fee-market design across multiple resource types, a tiered storage/archival interface for managing ledger growth, and practical ways to keep frequently-read state from expiring without forcing every read to become a write.
+
+This thread covers a design review of unified authorization for Soroban, focusing on the implications for the host environment and SDKs, alongside updates on fee-schedule work and how different resource markets shape the contract developer experience. It also includes a follow-up deep dive into state archiving, storage classes, incentives for proof serving, and emerging patterns for rent maintenance.
+
+### Key Topics
+
+- Auth Next overview: moving toward a single authorization model so contracts can delegate signature/policy verification and focus on business logic
+- Fee model refresh: revisiting a draft “fee CAP” and aligning it with newer realities like preflight; framing fees across compute, ledger, bandwidth, and externalized ecosystem costs (indexers/streams/archives)
+- Storage interface proposal (three classes):
+  - Unique storage: single authoritative version (never both live + archived); intended for “must-not-be-reinitialized” state like admin/control entries; higher creation cost due to exclusion guarantees
+  - Recreatable storage: cheaper creation by allowing archived key collisions (multiple historical versions can exist); discussed mainly as a scalability/UX trade-off for common patterns like token balances
+  - Temporary storage: short-lived entries that delete on expiry (no archive), favored for scoped approvals and time-bounded auth-related artifacts
+- Staging plan: ship the interface + rent charging early, with archiving behaviors/proofs phased in as infrastructure lands (including discussion of a “null root hash” style bootstrap for exclusion proofs)
+- Bloom filter debate: whether probabilistic “key exists” hints could reduce proof overhead, balanced against false positives, adversarial key targeting, resizing/migration, and consensus constraints
+- Archive proof delivery models:
+  - Direct archiver endpoints (Horizon-like) vs. on-chain proof requests with reward-driven “archive miners”
+  - Key concern: proof theft / front-running when proofs are disclosed publicly, and what commit/reveal or other anti-stealing mechanisms might be required
+- Rent bumping problem: how to extend rent for heavily-read state without rewriting immutable bucket-list entries; explored host-level bump operations, contract-managed thresholds, and who should bear the cost when state is “public goods”
+
+### Resources
+
+- [Auth Next design proposal (guiding document)](https://docs.google.com/document/d/1J-J3ClTUkrsLiJag906OH4hmNkZI3Jk6_Y9ZYt_psAI)
+- [CAP-46-7: Fee model in smart contracts](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046-07.md)

meetings/2023-03-09.mdx

@@ -0,0 +1,46 @@
+---
+title: "2023-03-09"
+description: Overview of proposed updates to the Fees CAP, focusing on deterministic resource pricing and a separate inclusion fee model to improve transaction prioritization, predictability, and user understanding in Soroban.
+authors: john
+tags: [soroban]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="h0YscptJUw4" />
+
+This meeting walked through recent revisions to the Fees CAP, focusing on how to price Soroban’s various resources (compute, bandwidth, ledger I/O, storage impacts) without forcing users and clients to reason about a complex, multi-dimensional bidding system. It outlines a direction for unifying Soroban authorization by replacing `invoker`, `soroban-auth`, and ad hoc schemes with a single account-abstraction model and standardized authorization payloads so contracts stay focused on business logic.
+
+A central theme was separating deterministic, protocol-derived resource charges from a distinct inclusion mechanism that handles congestion and ordering. The goal is a model that’s easier to understand, more predictable for users, and less prone to unfair prioritization when workloads mix different resource profiles.
+
+### Key Topics
+
+- Motivation: Soroban resource accounting is inherently multi-dimensional (compute, bandwidth, reads/writes, bytes, events), and fee design needs to deter spam while keeping execution affordable.
+- Dynamic per-resource pricing + prioritization was seen as too complex for both the protocol and clients to bid correctly.
+- “Synthetic resource” (gas-like aggregation) exploration highlighted prioritization pathologies:
+  - weighting different resources can unfairly penalize mixed workloads
+  - small usage of a scarce dimension can dominate total price even when other capacity is plentiful
+- Updated direction: deterministic resource fees derived from network parameters, so costs can be computed from a transaction largely independent of other transactions.
+- Transaction ordering under contention shifts to a separate **inclusion fee**:
+  - prioritization reflects user urgency / willingness to pay (the “social value” of a transaction)
+  - decouples priority from internal resource dimensions
+- User experience emphasis: users should be able to understand “what I pay to run” vs “what I pay to get in sooner,” similar in spirit to familiar fee markets but with clearer separation.
+- Refund policy discussion:
+  - conservative stance against refunds for highly contended resources to prevent gaming and idle capacity
+  - framing: you pay for reserved/declared capacity (what you _asked_ for), not necessarily what you _ended up using_
+- Edge cases called out for analysis/simulation:
+  - preflight overestimation vs runtime path changes
+  - “unused writes” / test-and-set patterns where a write is declared but doesn’t occur
+  - arbitrage-style scenarios where state changes invalidate a preflighted execution path
+  - whether limited refunds make sense when there is no contention
+
+### Outcomes
+
+- By generalizing authorization through account abstraction, contracts can treat classic accounts and programmable wallets uniformly, delegating signature verification, nonce handling, and policy enforcement to account contracts that expose a single `check_auth` entry point.
+- Contract invocations are authorized via structured payloads that capture the full call stack. Preflight recording determines what will execute so wallets can construct correct payloads, while the host tracks nonces per account-root pair.
+- The proposal includes a built-in account contract for classic accounts, recommends temporary or scoped storage (such as short-lived approvals) instead of long-lived allowances, and presents proof-of-concept patterns like timelocks, atomic swaps, and token approvals, along with notes on SDK and host implications.
+- This approach introduces added complexity in preflight, larger transaction footprints, and new host responsibilities. The intent is to reduce ecosystem fragmentation, simplify wallet integration, and focus authorization logic within a consistent framework.
+
+### Resources
+
+- [Fees CAP – Updated Auth Next Proposal and Design Discussion](https://docs.google.com/document/d/1J-J3ClTUkrsLiJag906OH4hmNkZI3Jk6_Y9ZYt_psAI)

meetings/2023-03-16.mdx

@@ -0,0 +1,63 @@
+---
+title: "2023-03-16"
+description: "This session outlines Soroban’s state expiration rollout plan: shipping rent + temporary storage at pubnet launch, finalizing SDK interfaces for unique/recreatable storage, and enabling expiration later once the backend is ready."
+authors: john
+tags: [soroban, CAP-46]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="E_rg2rQO5bU" />
+
+Soroban is a smart contracts platform designed with purpose and built to perform.
+
+This discussion focuses on the roadmap and implementation sequencing for state expiration: what must be ready at Soroban pubnet launch versus what can be completed and activated afterward. A key theme is prioritizing a stable developer-facing interface early, even if the full storage backend and expiration mechanism is enabled later.
+
+The group also digs into how rent should work in practice—especially who pays it, how contracts decide when to top up, and how fee variability interacts with developer expectations around predictable lifetimes and deletion behavior.
+
+### Key Topics
+
+- Rollout plan split into two stages
+  - At pubnet launch: implement rent + temporary storage fully, and finalize/expose SDK interfaces for unique and recreatable storage
+  - After launch: enable state expiration (actual expiring/archiving) once the storage backend is ready
+  - Rationale: lock the interface early so contracts deployed from day one can be compatible when expiration is later activated
+- Terminology update
+  - Naming pivots from “archival system” to **state expiration** to avoid confusion with history archives
+- Rent model fundamentals
+  - Each Soroban ledger entry carries a rent balance (XLM tied to that entry)
+  - Rent is charged over time for remaining “live” in ledger storage
+  - Rent fee rate is designed to vary with storage pressure (bucket list size), aiming for a system equilibrium that discourages unbounded state growth
+- Who pays rent is contract-dependent (no universal default)
+  - Token-like balances: the user “owns” their balance entry, so user-funded rent feels appropriate
+  - Shared AMM state (e.g., pools/pairs): a shared resource used by many, so it may be better funded by a shared mechanism rather than whichever user happens to touch it next
+- Proposed rent payment primitives for contracts
+  - Expose two primitives: `rent bump` and `rent bump from` (modeled after `transfer` / `transfer from`)
+  - Enables explicit control over who funds rent
+  - Allows allowance-style patterns so a contract (or maintainer) can fund rent on someone’s behalf without requiring that party to sign each time
+- Expected developer pattern for keeping entries alive
+  - Contracts likely add checks inside common getter/setter helpers:
+    - inspect current rent balance
+    - if below a threshold, bump rent (and choose the payer logic)
+  - This keeps policy flexible while making frequent-use entries self-sustaining
+- Abuse/spam concerns and mitigation thinking
+  - Concern: shared pools could be drained by junk entries
+  - Suggested approach: bump rent only on meaningful access; junk entries that aren’t used don’t get topped up
+  - Also noted: contracts can add economic friction (e.g., charge to create entries)
+- “Don’t store the data, only store proofs” idea
+  - Not treated as a protocol-special case
+  - Suggested approach: store hashes/checksums on-chain and keep sensitive payloads off-chain, using the contract to verify integrity via cryptographic hashes
+- Predictability vs variable pricing
+  - Developers want to reason about “how long does this last” in ledger time, but fees vary with storage pressure
+  - Temporary entries were discussed as needing strict, ledger-count TTL semantics (especially for security-sensitive uses)
+  - Unique/recreatable entries are less sensitive since they can be restored, but UX predictability still matters
+- Bucket-merge granularity realities
+  - Expiration/cleanup aligns with bucket merge events, which implies coarse-grained practical effects (e.g., week/month-ish behavior for long-lived entries)
+  - Discussion notes conservative charging/expiration behavior can lead to entries living longer than their nominal target in some scenarios
+- Open design tension: time-based guarantees vs dynamic rent rate
+  - Proposal floated: lock an entry’s rate for a period after a bump (a “subscription-like” behavior) to improve predictability
+  - Tradeoff concerns: incentives for gaming/“rent control,” fairness between older and newer entries, and potential impacts as the system approaches storage bounds
+  - Outcome: recognized as an open question to resolve in follow-on design work
+
+### Resources
+
+- [CAP-46: Soroban smart contract system overview](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046.md)