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 received 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 stellar-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.