Agenda: Discord thread

Summary: Hoops Finance, a DeFi protocol, discussed their platform they are building. https://www.hoops.finance/

1. They abstract away the complexity of DeFi investments for normal users through a series of guided prompts.
2. Provides simplified access to LP liquidity provisioning abstraction
3. Public AMM API for read/write data on AMMs on Stellar
4. Hoops Finance API: https://api.v1.xlm.services/#overview

Agenda: Discord thread

SDF DevRel team member Carsten Jacobsen showed how to build a simple Hello World dapp based on a Soroban smart contract and Next.js through these steps:

1. Create the default Hello World smart contract using the Stellar CLI
2. Create TypeScript bindings (package) using the Stellar CLI
3. Create the default Next.js using the npx create-next-app command
4. Add and link the TypeScript binding package to the Next.js project
5. Create a simple frontend with a form to submit a string
6. Import the package in the Next.js page, and setup a client
7. Create submit-function to send form value to the smart contract
8. Use useState to store the smart contract response and display it

Agenda: Discord thread

Developer Experience team member Nando Vieira introduced the CLI features alias and snapshot:

1. Alias
   1. Install of Hello World example for showcasing alias
   2. Showed examples of how contract IDs are often passed as parameters in CLI commands like invoke (copying ID string or command substitution)
   3. How to deploy a smart contract and create an alias
   4. How to invoke the smart contract with the alias
2. Snapshot
   1. How to create a ledger snapshop
   2. How to use the snapshot in a test case

Towards the end Nando went through the developer documentation, with focus on the added command line examples for Windows users, and a useful cookbook for CLI commands.

Agenda: Discord thread

Platform team demonstrated Galexie, a part of CDP(Composable Data Platform):

1. Galexie
   1. Data Extraction: Extracts raw ledger data from the Stellar network
   2. Compression: Compresses raw data for efficient storage
   3. Storage Options: Supports runtime configuration through the Datastore abstraction to use various physical storage layers, starting with Google Cloud Storage (GCS)
   4. Modes of Operation: Can operate in either batch mode or streaming mode
2. Composable Data Platform
   1. Flexible Datastore: Multiple options for physical data storage layers
   2. Galexie: Used to extract, compress and export data to your chosen Datastore
   3. Transform: Structure data in a model suitable to your application
3. Pluggable Data Pipelines
   1. Workflows: Create ETL(extract, transform, load) pipelines
   2. Streaming: Fast, lightweight streaming data

Agenda: Discord thread

CAP Core team deliberated on the proposed CAPs:

1. Addition of a constructor to Soroban's flavor of Rust. CAP
   1. Team's concern was about potential break in compatibility, which Dima had addressed. There were no further concerns.
2. Addition of BLS12-381 curve and required field arithmetics - CAP
   1. Team's concern was about providing functions to check invalid input. It's too computationally expensive to do the check at the contract layer so the it may need to be implemented as a host function. Jay is seeking ecosystem input around use cases that require strict input validation.
   2. There were no further concerns.
3. Increase performance by upgrading Soroban's VM. CAP Discussion
   1. Team's comments were about accuracy of the measurement method but the demonstrated benefits of wall clock time were thought to be promising.
   2. There was a suggestion to expose performance improvements to contract developers thus creating the incentive to optimize contracts to leverage the improvements.
   3. There were no further concerns.

Discord agenda thread

Core Developers discussed the latest proposals to advance Stellar Core in this week's Protocol Meeting.

1. The proposal for addition of a constructor to Soroban’s flavor of Rust was introduced in a previous protocol meeting (previous meeting), documented in CAP-58. A constructor is a function that will only be executed the first time the contract is created.
2. In this meeting, Dima discussed the updates made since the last meeting:
   1. Default constructor - if a constructor is not defined explicitly, the contract is treated as if it has a constructor
   2. Semantics of the return value - if the transactions succeeds, it is required to return a valid value
   3. Constructor interaction with custom accounts - custom accounts must be aware of the context that they are authorizing.
3. Graydon discussed the upgrade to the Wasmi virtual machine, documented in CAP-60. Wasmi works by translating WebAssembly code to to an Internal Representation (IR) and then executing it. The upgrade is impactful in two ways.
   1. Translating from WebAssembly to IR takes longer but the execution of the resulting IR is performant.
   2. The upgrade introduces lazy compilation. Of all functions in a contract, only ones that are called in a given transaction will translated thus reducing both latency and fees.
4. Jay discussed addition of BLS12-381 cryptographic curve, documented in CAP-59.
   1. Addition of pairing-friendly elliptic curves enables zk-based applications. 11 host functions have been added to expose mapping, pairing, and arithmetic on the BLS12-381 curve.
   2. Examples case of BLS signature verification was presented. It consumed 26M instructions (running natively), which is promising given the per-transaction limit is 100M.
   3. There was general agreement that the interface is the right one as it allows a contract developer to implement a wide variety of use cases. Discussion continues in discord.
   4. Jay requested that developers should build applications against the function and give feedback.

1. @Soiled and @Robeart from Orbit spoke about using Blend to create decentralized stablecoins for all currencies under the Orbit Protocol, utilizing a decentralized pegkeeper to maintain their price, and leveraging these stablecoins and smart wallets to create an orderbook less perpetual exchange, bringing Forex to Stellar

2.Link to the presentation

Note: The hosts microphone audio is not in the video so there is some silence during Q/A. Here are the question asked during the Q/A:

1. (From ! markus_0) why do you always have an infinite amount of tokens in the pool? Wouldn't it be safer to start small and mint more as demand opens up 2.(From HunterIonize) What purpose does this serve exactly? Sorry to be blunt
2. How do you see the Orbit Protocol contributing to financial inclusion on a global scale, particularly in underbanked regions? What challenges do you anticipate in achieving this?
3. In 5-10 years, how do you see the landscape of Forex on blockchain evolving? What role do you believe Stellar will play in this evolution, and how will Blend and Orbit Protocol be at the forefront?
4. Are there any asks of the developer community?

1. Tdep discussed Zephyr, an execution env built on top of the indexer Mercury. He also walked through examples demonstrating how Zephyr can simplify dapp development.

1. Piyal demonstrated that Freighter's swap functionality is now served by Soroswap. It was previously served by Stellar Dex.
2. Freighter has made integration instructions available here.
3. Esteban shared that Palta Labs has created a DEX aggregator and made it available to all via the Router SDK.
4. The Router SDK finds the optimal path for the swap in terms of swap cost across all dexes on Soroban.

A Core Dev, Dima, discussed the proposal to add constructor support to Soroban, Stellar's smart contract system.

Relevant links: Draft CAP, Ongoing discussion, Motivating Discord Thread

Key points discussed:

1. The proposal improves usability of Soroban for contract and SDK developers. A constructor guarantees contract initialization thus reducing overhead contract code that's usually added to ensure initialization.
2. There was general agreement for the proposal, questions were primarily implementation-focused like whether constructors should handle arguments, what should happen with upgrades, backwards comptability with contract creation functions, and behaviour on wasm update.
3. The high impact topic of naming is put to ecosystem vote, please cast yours here.

Note: the first part of the call was lost. The video posted above captures the second half of the call where various ecosystem developers shared their use cases and needs for a smart wallet on Stellar.

1. Tyler put forward a proposal for a smart wallet as a public good. Given that the native auth can be overloaded by using __check_auth, Stellar implementation of a smart wallet is fairly straightforward. The capability to customize the auth is already built into the core protocol.
2. See the proposal here and implementation here
3. The proposal only uses WebAuthN-based signers i.e. passkeys. It does not use ed25519, which, perhaps it should given that ~100% of the accounts on Stellar use the scheme. It also introduces the notion of temporary and admin signers to illustrate the notion that the account can be managed by multiple signers, each with a different access policy.
4. The biggest unlock with custom auth is the ability to execute custom logic. We heard from various ecosystem members about how might they us it. 4a. A dev is building a perpetual protocol and thought smart wallets could be used to automatically manage defi positions, which would be a significant improvement over status quo where the user has to constantly track assets to determine when to execute a trade. 4b. Folks are excited about foregoing the seed phrase for passkeys, which is especially meaningful when onboarding net new users to the blockchain. 4c. Authorizing a cross-chain message from a different chain, especially programmatic authorization, requires an implementation of custom accounts. 4d. Some apps have noted that users prefer not to have a wallet but simply experience the value of the app, especially games. For this, the app may assign a temporary account to the user and control access via check_auth. 4c. Microtransactions without needing user sign is super interesting for apps as well.
5. This has been a very insightful meeting and we learnt about how the Stellar ecosystem plans to leverage smart wallet. Let's continue the conversation in discord!

1. SDF Data team gave a crash course in analysis of Stellar data, and covered how to access Hubble, tips for efficient querying, and how to get started with data exploration.
2. Slides are publicly available and legible async.
3. Tips for data anlaysis are also covered in docs
4. Share your queries and post questions in #hubble in Stellar discord, which is a dedicated channel for data-related topics.