Agenda: Discord thread

SDF’s Platform team had an internal hackathon last week, with the purpose of building applications utilizing the Composable Data Platform (CDP). In this week’s developer meeting some of the team members present their projects. The apps are widely varied (trading app, fraud detection, JS browser-based ingester, etc) but the intent here is to show how easy CDP is to use.

Projects presented in the meeting:

1. Trade Aggregations Service
2. Deceptiscan - CDP fraud detection
3. Composable Data Platform Hackies - data indexer, payment indexer, contract expiration alerter, data indexes in DuckDB, torrents for data indexes and ledger metadata)
4. Data ingest with frontend JS
5. Real-time analytics

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 gaurantees 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 temprory 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.

1. Chad and Willem from Aha Labs discuss the updates to the new and improved stellar-cli
2. Some highlights include the change from the name 'soroban' to 'stellar' when using the CLI tool and the addition of new commands.
3. They cover some cool functions like local network setup, account creation, and transaction signing. with the following commands:
   • stellar network container [start|logs]
   • stellar keys [generate|fund|ls]
   • stellar contract init to get a whole new Soroban project
   • and so much more!
4. They also discuss expected future updates including support for more Stellar operations and integration with Stellar Lab V2!

1. Kirckz discusses Meru, a Financial services app for Freelancers and remote workers in Latin America.
2. He shares his experience integrating Meru with Blend, a liquidity protocol primitive for Stellar.
3. Kirckz shares the challenges faced during the integration and how they were overcome.
4. He shares the sdks and libraries his team used to facilitate the integration.

Follow Meru on X (formerly Twitter) to stay updated: https://x.com/getmeru

1. Tyler created Super Peach, a web3 application that uses passkeys to sign transactions. He demonstrated how passkeys can be used in authorization flows and how they can be used to sign transactions.
   • Code: https://github.com/kalepail/superpeach
   • Demo: https://superpeach.vercel.app
2. Introduced passkey-kit. A TypeScript SDK for creating and managing Smart Wallets via passkeys (includes the actual Smart Wallet interface)
   • Code: https://github.com/kalepail/passkey-kit
   • Demo: https://passkey-kit-demo.pages.dev
3. Introduced Launchtube, a service for submitting transactions onchain by covering both the transaction fee AND the sequence number. Wild!
   • Code: https://github.com/kalepail/launchtube (ask in the #passkeys channel on Discord for a testnet token)
4. He shared his vision for pushing the passkey implementation through to becoming a standard for the ecosystem.

Join the #passkeys channel on the Discord to continue the discussion

1. Tyler built a voting application using passkeys to sign the transaction, which is an implementation of the secp256r1 verification function.
2. He showed a cross-platform implementation (web and mobile) and demonstrated that passkeys are the perfect interface between web3 contracts and web2 authentication mechanisms that most end users are accostomed to.
3. Ecosystem members discussed the use of smart wallets that would use passkeys as a signer. Challenges were identified around fees requires for smart wallets, the need for a common implementation for a smart wallet, as well as how might it interface with existing password managers.
4. The voting application can be tried out at https://passkey.sorobanbyexample.org/
5. Code for the demo is here https://github.com/kalepail/soroban-passkey

Discord Agenda thread

1. Fifo presented Stellar Plus, which is a Javascript library to simplify the Stellar and Soroban development.
2. Ecosystem members found the design for Stellar Plus composable and encompassing of all Stellar related functionality including management of assets, accounts, wasm-related operations, as well as RPC utils.
3. The links to Fifo's presentation and Stellar Plus are:
   • Miro Board showing Stellar Plus architecture
   • Stellar Plus Repositore
   • Examples Repository
   • Docs

1. Garand discussed changes to the State Archival proposal based on feedback received at Meridian 2023. The proposed changes are:

• Previously, a downstream system called the ESS (Expired State Store) would store expired entries. In the new proposal, There is no ESS. All Archived entries, as well as all information required to generate restoration proofs for those entries, is stored directly in the History Archive.
• RPC nodes can generate proofs for archived state during preflight
• Captive-core can be directly queried for archived state, meaning that RPC/Horizon instances can potentially service queries for archival state

2. The draft proposal
3. Ongoing discussion
4. Snapshot size is TBD; it's a function of bucket list size as well as memory and historic demands placed on the RPC.
5. Bloom filters are the likely solution for proof of non-exitance though they come with trade-offs. They enable fast and cheap lookup but are probabilistic not deterministic.
6. Further comments are welcome.

Discord agenda thread

1. Justin from ortege.ai demo'd Ortege, a data analytics platform for Stellar and Soroban.
2. Ortege lets anyone in the Stellar ecosystem create dashboards to track any and all desired metrics. Ortege's queries, widgets, and dashboards are shareable making it the perfect platform to surface
3. Justin will be releasing an AI soon and enable querying and insights via natural language.
4. All are invited to create a free account and track the success metrics for their dashboard.

Piyal from Freighter discussed the proposal to standardize the wallet interface. Key points from the discussion are captured below. For full notes, please view the recording; and also refer to the proposal and the post on github discussions.

1. The draft proposal
2. Ongoing discussion
3. Requiring the network passphrase might be uneeded complexity.
4. Both WalletConnect and mobile wallets likely have significant differences than the proposed interface (which is targetted at browser extension wallets); and thus likely require a separate SEP. The said SEPs should be created by teams working on wallet integration with the said platforms.
5. What is the role of the Stellar Wallet Kit in the ecosystem and how does it play with the standard itself?
6. As next steps, Piyal will incorporate the suggestions from the ecosystem into the proposal.

Today's recording has two parts. The first 12 minutes are audio-only. The next 45 minutes have video as well. Please note the slides were shared in discord chat over screensharing, due to technical difficulties.

Part 1 (audio-only):

Part 2 (video):

Discord Agenda thread

1. Piyal surfaced the proposal for a Wallet Standard and requested feedback.
2. Cubist, an ecosystem project, discussed CubeSigner, a low-latency API for generating keys and signing transactions inside secure hardware.
3. Stellar-based example of CubeSigner is available in the Cubist Labs Github repository
4. Cubist devs can be contacted via the Stellar discord or the web form.

Agenda thread

1. The Standards Working Group proposed changes to the SEP process that empower the ecosystem by making the current process more decentralized and ecosystem-friendly.
2. The process has already been used for several proposals over the last three months.
3. Esteblock from Soroswap shared their journey of participating in the proposal for Asset List (SEP-42) and implementing the proposed standard
4. Discussion continues in the proposal doc.
5. Next step is to get further ecosystem feedback then update the Github SEP repository with the updated SEP process.

Discord agenda thread

1. There's a discussion on a TX meta change increasing visibility and analytics within the Stellar network. (https://github.com/stellar/stellar-xdr/pull/175)
2. Read-only invocations for contracts is explained, focusing on ensuring certain functions remain read-only without side effects. (https://github.com/stellar/stellar-protocol/discussions/1454) (https://github.com/stellar/stellar-protocol/discussions/1456) (https://github.com/stellar/stellar-protocol/discussions/1464)
3. Enabling contract discovery is introduced to enhance the visibility and authenticity of smart contracts within the Stellar ecosystem.
4. The implementation of a standardized contract meta data schema is proposed to link contracts to source code and enhance contract discoverability.(https://docs.rs/soroban-sdk/latest/soroban_sdk/macro.contractmeta.html)
5. Issues related to inclusion fees in the Stellar network, highlighting the importance of monitoring fees closely and understanding the implications of surge pricing. (https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering#inclusion-fee)
6. Plans are discussed for designing a new RPC endpoint to provide developers with better visibility and information on setting inclusion fees, aiming to improve transparency and decision-making regarding fee trade-offs.

Discord agenda thread

1. CAP Core Team deliberated over the latest proposals put forth by the Stellar ecosystem to advance stellar-core.
2. Nicholas and David from the CAP Core Team listened to the following proposals and discussed the proposals with the authors. a. CAP Core team will deliver their vote over email.
3. Proposals discussed:
   a. CAP-51: add support for secp256r1 verification; by @leigh
   b. CAP-53: create separate functions for extending the time-to-live for contract instance and contract code; by @tdep
   c. CAP-54: lower total costs by refining the Soroban cost model used for VM instantiation into multiple separate and more-accurate costs; by @graydon
   d. CAP-55: lower total costs by linking fewer host functions during VM instantiation in Soroban; by @graydon
   e. CAP-56: lower total costs by caching parsed Wasm modules within a Soroban transaction; by @graydon

Discord agenda thread

1. Sorobill tool
2. Deploying contracts and testing invocations against the unlimited quickstart.
3. Using Sorobil package as a tool to get a snapshot of all the limits the contract is touching. Relevant blog post
4. How to measure the contract costs and what limits you are touching
5. Utilizing the Sorobil tool to decode XDR and understand failed transactions.

Discord agenda thread

1. Tommaso (@tdep) proposed a core change to allow for extending instance and code TTL with separate values on the host environment to allow for more cost-efficient designs a. Proposal and discussion are captured in github discussions stellar-core#1447
2. Tommaso receieved feedback on the proposal as well as implementation. Since it didn't require a metering change, core devs thought it to be a quick change.
3. The ecosystem voted in favor of the proposal by upvoting the post on Github Discussions. 13 votes were recorded.
4. As next steps, a CAP will be authored to capture the proposal and put forth for approval from CAP Core Team.

Discord agenda thread

1. Latest and greatest on the TypeScript bindings with @chadoh
2. Available RPC providers
3. Standing up a soroban-rpc docker container
4. Installing and invoking a Stellar Asset Contract on mainnet in Phase 0

Discord agenda thread

1. The meeting was focused on the process of adding host functions, using WebAuthN as the example use case; continued from the previous meeting.
2. Discussion of remaining concerns with adding secp256r1 verification host function from previous meeting.
   • What does it mean for secp256r1 to be added as a host function vs. as a signer type?
     • As a host function, user can sign soroban auth entries. Need another stellar account to fund and submit tx to the chain. The latter can be done by a stellar account which may be operated by a wallet or a contract.
     • __check_auth is invoked when the contract being interacted with calls require_auth
3. CAP-52 was drafted to introduce encoding/decoding functions for Base64, which is needed by WebAuthN. Considerations discussed in the meeting:
   • Performance: 1066 bytes that costs 1M instr to encode a 32byte hash; so the cost is very small and it’s questionable whether a host function is required.
   • Interface required two functions (encode/decode)
   • Implementation wise, WebAuthN requires url alphabet and padding, which decoder likely needs to support. Should we use symbols or ints? Do we need custom alphabets?
   • Do we really need more encoding schemes? Isn’t XDR enough?
   • Expensive auth mechanisms, i.e. webauthn, cannot be coupled with contracts with heavy business logic (which might be a lot of contracts), thus making adoption problematic.
   • We should probably add building blocks to enable the ecosystem to add new use cases.
4. CAP-53 was drafted to introduce encoding/decoding functions for JSON, which is needed by WebAuthN. Considerations discussed in the meeting:
   • Performance: 3.9Kb, 2.5M CPU instr.
   • If the size of the input blob is unknown, execution time will increase.
   • Valuable to have such a lightweight function that’ll be used in various place.
   • Interface: 11 functions
     • What to do with numbers and decimals? Add decimals and floats?
     • We only have to extract one field for WebAuthN but what about the general case?
   • The number type in JSON is decimal but soroban does not support that. How should this be handled?
   • Discussion around alternative interface and implementations.
5. Core dev concerns
   • Maintainability: if you add a host function, you have to maintain it forever. If there are more versions, we have to keep it around.
   • Expanded surface area for security bugs.
   • Should define a path where core dev is not in the implementation loop, as their schedules are packed with stability work. How to prioritize against stability work, which may get derailed due to new functionality such as what’s being currently discussed.
   • Next steps:
     • Core team to put together a plan for adding Base64. This is an important exercise that helps determine even more challenges of doing so. The output of this exercise may be that base64 shouldn’t in fact be implemented at this point.
     • Discussion around the JSON interface is to be continued.

Discord agenda thread

1. Stellar Asset List (SEP-0042) draft presentation by OrbitLens
   1. SEP draft
   2. Discord discussion
2. Stellar + Soroban documentation survey
   1. Take the survey

Discord agenda thread

1. The proposal is to advance stellar-core by adding a host function to verify the secp256r1 signature, which is the most common elliptic curve used outside of the blockchain space. It is useful in connecting off-chain authentication interfaces with on-chain functionality.
2. Note that the proposal is not for a new signer type but a host function.
3. Leigh investigated adding support for the WebAuthN use case, by allowing a custom account / smart contract to sign soroban auth entries using a secp256r1-signed payload.
4. secp256r1 is supported by phones, passkeys, and enables an app to replace passwords. This is a massive benefit to user-facing applications like wallets.
5. Pros and cons of the interface: blockchains generally implement the recovery interface over the verification interface but verification is easier for developers as it reduces burden on the client and the network.
6. The WebAuthN use case requires encoding and decoding of base64 payloads and decoding JSON blobs, which is not currently supported in Soroban.
7. While there are hacky ways of accomplishing the latter, it’s not a great developer experience and final implementation is susceptible to breakages on updates.
8. It is also costly to bundle decoding with verification in guest.
9. Soroban has always led with a batteries included mindset. Keeping in line with that approach, it makes sense to further investigate and determine whether a host function makes sense for these as well.
10. Leigh’s implementation may require further evaluation of the crates used for ecdsa and p256.
11. Brief discussion around proposed process for adding of a host function by a non-core dev.

Discord agenda thread

1. Plan and schedule for these meetings
   1. Protocol meetings every other Thursday at 4pm ET
   2. Developer meetings every other Friday at 1pm ET
   3. Will continue to adjust as needed
2. Fee bump bug - announcement | discussion thread
   1. Fee sponsorship bug: unused fee is refunded to the inner tx source rather than the sponsor source.
   2. Fix in new release. Up to the ecosystem and validators to upgrade. The fix will likely be rolled out before Phase 2.
   3. Up to validators to determine if they’d like to push the v20 upgrade date to wait for the fix; or upgrade with current release.
3. TxMeta Deprecation in Horizon - announcement
4. Ideas around testing against ledger snapshots - request
   1. Define the needs a bit more clearly
   2. Definitely something here we should be addressing to make testing against specific ledger state easier
5. How do you get a list of smart contracts? - thread
   1. Observe create contract ops as ledgers close
   2. Use an indexing service
6. What is the status of contracts caching support? - question
   1. response

Discord agenda thread

1. The need for zk-enabling encryption curves like BLS12-381. Github thread.
2. Use cases that ecosystem is interestd in:
   1. Excellar, i.e. folks that kicked off this conversation by submitting a PR for BLS12-381, wants to add a DAO-controlled oracle where the elliptical curve provides the ability to add new DAO voters
   2. Zkbricks wants to build an L2 system for that enables secret state for arbitrary smart contracts
   3. Skyhitz wants to use stellar for efficient compute, cost, and scalability while using zk to prove ownership of high-value assets on another chain
   4. Use case enumeration continues in the discord thread.
3. Considerations for host function implementation
   1. Core devs questioned whether BLS12-381 was the right curve and also highlighted the need to determine the correct level of abstraction given there is a tradeoff between flexibility and efficiency. Lower level of abstraction will enable more flexibility but result in more hot loops in the wasm while a higher level of abstraction will be highly efficient but will restrict generality.
   2. ZkBricks thought that there is a need to directly expose pairings and group operations without any level of abstraction. The space is in active development and flexibility is needed to try out new approaches and proof systems. From the point of view of crypto agility, it would be good to expose a generic interface that supports a variety of curves in the backend.
4. Path Forward
   1. Core devs mentioned crypto curves can be experimented locally by linking rust crates, which it turns out, had failed in the past. This will be explored and fixed.
   2. ZkBricks and others will prototype locally and provide feedback.
5. What are the best practices for managing transactions in the frontend, with respect to transaction ordering.
6. Core devs confirmed that ordering is intentionally arbitrary.
7. Request for an API for current version of the environment/sdk
8. Github issue filed for the RPC to return versions of the current node.