## Table Metadata
diff --git a/docs/data/hubble/data-catalog/data-lineage.mdx b/docs/data/hubble/data-catalog/data-lineage.mdx
index f4cdf8766..45f51b7b2 100644
--- a/docs/data/hubble/data-catalog/data-lineage.mdx
+++ b/docs/data/hubble/data-catalog/data-lineage.mdx
@@ -1,5 +1,4 @@
---
-id: data-lineage
title: Data Lineage
---
diff --git a/docs/learn/fundamentals/lumens.mdx b/docs/learn/fundamentals/lumens.mdx
index 7beaa964b..900306ff0 100644
--- a/docs/learn/fundamentals/lumens.mdx
+++ b/docs/learn/fundamentals/lumens.mdx
@@ -3,7 +3,7 @@ title: Lumens (XLM)
sidebar_position: 30
---
-Lumens (XLM) are the native currency of the Stellar network. The lumen is the only token that doesn’t require an issuer or trustline. They are used to pay all transaction [fees](#transaction-fees), fund [rent](fees-resource-limits-metering.mdx#resource-fees), and to cover [minimum balance requirements](stellar-data-structures/accounts.mdx#base-reserves-and-subentries) on the network.
+Lumens (XLM) are the native currency of the Stellar network. The lumen is the only token that doesn’t require an issuer or trustline. They are used to pay all transaction [fees](#transaction-fees), fund [rent](./fees-resource-limits-metering.mdx#resource-fee), and to cover [minimum balance requirements](stellar-data-structures/accounts.mdx#base-reserves-and-subentries) on the network.
To read up on the basics of lumens, head over to our Stellar Learn site: [Stellar Learn: Lumens](https://www.stellar.org/lumens)
diff --git a/docs/learn/fundamentals/transactions/list-of-operations.mdx b/docs/learn/fundamentals/transactions/list-of-operations.mdx
index 1bf0b2528..c5ebe10c2 100644
--- a/docs/learn/fundamentals/transactions/list-of-operations.mdx
+++ b/docs/learn/fundamentals/transactions/list-of-operations.mdx
@@ -148,7 +148,7 @@ Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity
| Selling | asset | Asset the offer creator is selling. |
| Buying | asset | Asset the offer creator is buying. |
| Amount | integer | Amount of `buying` being bought. Set to `0` if you want to delete an existing offer. |
-| Price | \{numerator, denominator} | Price of 1 unit of `buying` in terms of `selling`. For example, if you wanted to buy 30 XLM and sell 5 BTC, the price would be {5,30}. |
+| Price | \{numerator, denominator} | Price of 1 unit of `buying` in terms of `selling`. For example, if you wanted to buy 30 XLM and sell 5 BTC, the price would be \{5,30}. |
| Offer ID | unsigned integer | The ID of the offer. `0` for new offer. Set to existing offer ID to update or delete. |
**Possible errors**:
@@ -182,7 +182,7 @@ Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity
| Selling | asset | Asset the offer creator is selling. |
| Buying | asset | Asset the offer creator is buying. |
| Amount | integer | Amount of `selling` being sold. Set to `0` if you want to delete an existing offer. |
-| Price | \{numerator, denominator} | Price of 1 unit of `selling` in terms of `buying`. For example, if you wanted to sell 30 XLM and buy 5 BTC, the price would be {5,30}. |
+| Price | \{numerator, denominator} | Price of 1 unit of `selling` in terms of `buying`. For example, if you wanted to sell 30 XLM and buy 5 BTC, the price would be \{5,30}. |
| Offer ID | unsigned integer | The ID of the offer. `0` for new offer. Set to existing offer ID to update or delete. |
**Possible errors**:
@@ -216,7 +216,7 @@ Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity
| Selling | asset | Asset the offer creator is selling. |
| Buying | asset | Asset the offer creator is buying. |
| Amount | integer | Amount of `selling` being sold. |
-| Price | \{numerator, denominator} | Price of 1 unit of `selling` in terms of `buying`. For example, if you wanted to sell 30 XLM and buy 5 BTC, the price would be {5,30}. |
+| Price | \{numerator, denominator} | Price of 1 unit of `selling` in terms of `buying`. For example, if you wanted to sell 30 XLM and buy 5 BTC, the price would be \{5,30}. |
**Possible errors**:
diff --git a/docs/learn/fundamentals/transactions/operations-and-transactions.mdx b/docs/learn/fundamentals/transactions/operations-and-transactions.mdx
index b2f33197a..2692a3397 100644
--- a/docs/learn/fundamentals/transactions/operations-and-transactions.mdx
+++ b/docs/learn/fundamentals/transactions/operations-and-transactions.mdx
@@ -31,7 +31,7 @@ Transactions are atomic. Meaning if one operation in a transaction fails, all op
Operations are executed for the source account of the transaction unless an operation override is defined.
-Smart contract transactions also go through a simulation process where developers can test how the transaction would be executed on the network using the RPC endpoint `simulateTransaction`. Read more in the [Soroban docs](/docs/learn/encyclopedia/contract-development/contract-interactions/transaction-simulation.mdx).
+Smart contract transactions also go through a simulation process where developers can test how the transaction would be executed on the network using the RPC endpoint `simulateTransaction`. Read more in the [Soroban docs](../../encyclopedia/contract-development/contract-interactions/transaction-simulation.mdx).
#### Transaction attributes
diff --git a/docs/tokens/publishing-asset-info.mdx b/docs/tokens/publishing-asset-info.mdx
index ee91a777f..0466e224a 100644
--- a/docs/tokens/publishing-asset-info.mdx
+++ b/docs/tokens/publishing-asset-info.mdx
@@ -41,7 +41,7 @@ Required field for all asset issuers:
- `ACCOUNTS`: A list of public keys for all the Stellar accounts associated with your asset.
-Listing your public keys lets users confirm that you own them. For example, when [https://google.com](https://google.com/) hosts a `stellar.toml` file, users can be sure that only the accounts listed on it belong to Google. If someone then says, "You need to pay your Google bill this month, send payment to address GIAMGOOGLEIPROMISE", but that key is not listed on Google's `stellar.toml`, then users know not to trust it.
+Listing your public keys lets users confirm that you own them. For example, when [google.com](https://google.com/) hosts a `stellar.toml` file, users can be sure that only the accounts listed on it belong to Google. If someone then says, "You need to pay your Google bill this month, send payment to address GIAMGOOGLEIPROMISE", but that key is not listed on Google's `stellar.toml`, then users know not to trust it.
There are several fields where you list information about your Stellar integration to aid in discoverability. If you are an anchor service, and you have set up infrastructure to interoperate with wallets and allow for in-app deposit and withdrawal of assets, make sure to include the locations of your servers on your `stellar.toml` file so those wallets know where to find relevant endpoints to query. In particular, list these:
diff --git a/docs/validators/admin-guide/configuring.mdx b/docs/validators/admin-guide/configuring.mdx
index af49e996e..39b6a8807 100644
--- a/docs/validators/admin-guide/configuring.mdx
+++ b/docs/validators/admin-guide/configuring.mdx
@@ -205,7 +205,7 @@ ADDRESS="core.rando.com"
:::info Important Note
-Your quorum set is automatically configured based on the information you provide in the `[[VALIDATORS]]` and/or `[[HOME_DOMAINS]]` tables. Removing a validator will result in a new quorum set being generated and may have unintended consequence for you and other network participants. Be sure to carefully consider the implications of removing a validator from your configuration and follow the guidance to [coordinate with other validators](../tier-1-orgs.mdx#coordinating-with-other-validators) before making changes.
+Your quorum set is automatically configured based on the information you provide in the `[[VALIDATORS]]` and/or `[[HOME_DOMAINS]]` tables. Removing a validator will result in a new quorum set being generated and may have unintended consequence for you and other network participants. Be sure to carefully consider the implications of removing a validator from your configuration and follow the guidance to [coordinate with other validators](../tier-1-orgs.mdx#coordinate-with-other-validators) before making changes.
:::
diff --git a/docusaurus.config.ts b/docusaurus.config.ts
index c7d223c20..76b1b968b 100644
--- a/docusaurus.config.ts
+++ b/docusaurus.config.ts
@@ -2,6 +2,7 @@ import remarkMath from 'remark-math';
import rehypeKatex from 'rehype-katex';
import { themes as prismThemes } from 'prism-react-renderer';
+import { makeEditUrl, DEFAULT_LOCALE } from './config/constants';
import { anchorPlatformPluginInstances } from './config/anchorPlatform.config';
import { disbursementPlatformPluginInstances } from './config/disbursementPlatform.config';
@@ -15,14 +16,15 @@ const config: Config = {
url: "https://developers.stellar.org",
baseUrl: "/",
trailingSlash: false,
+ onBrokenAnchors: "warn",
onBrokenLinks: "throw",
onBrokenMarkdownLinks: "throw",
favicon: "img/favicon-96x96.png",
organizationName: "stellar",
projectName: "stellar-docs",
i18n: {
- defaultLocale: "en",
- locales: ["en"],
+ defaultLocale: DEFAULT_LOCALE,
+ locales: ["en", "es"],
},
plugins: [
"docusaurus-plugin-sass",
@@ -85,7 +87,7 @@ const config: Config = {
rehypePlugins: [rehypeKatex],
sidebarPath: "config/sidebars.ts",
sidebarItemsGenerator: require("./src/sidebar-generator"),
- editUrl: "https://github.com/stellar/stellar-docs/tree/main",
+ editUrl: makeEditUrl,
exclude: ['**/component/**', '**/README.md'],
},
theme: {
@@ -111,6 +113,10 @@ const config: Config = {
},
],
themeConfig: {
+ announcementBar: {
+ id: 'announcementBar-translation',
+ content: '
Disclaimer: This documentation has been automatically translated and may contain inaccuracies. For the most accurate information, please refer to the original English version. We are not responsible for translation errors.',
+ },
docs: {
sidebar: {
autoCollapseCategories: false,
@@ -230,6 +236,10 @@ const config: Config = {
label: 'Meetings',
position: 'right',
},
+ {
+ type: 'localeDropdown',
+ position: 'right',
+ },
{
href: "https://github.com/stellar/stellar-docs",
position: "right",
diff --git a/meeting-notes/2024-01-18.mdx b/meeting-notes/2024-01-18.mdx
index 0e5d48509..0b6c16e6f 100644
--- a/meeting-notes/2024-01-18.mdx
+++ b/meeting-notes/2024-01-18.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-01-18'
+title: "2024-01-18"
authors: naman
tags: [protocol]
---
@@ -29,4 +29,4 @@ tags: [protocol]
1. What are the best practices for managing transactions in the frontend, with respect to transaction ordering.
1. Core devs confirmed that ordering is intentionally arbitrary.
1. Request for an API for current version of the environment/sdk
-1. Github issue filed for the RPC to return versions of the current node.
\ No newline at end of file
+1. Github issue filed for the RPC to return versions of the current node.
diff --git a/meeting-notes/2024-01-26.mdx b/meeting-notes/2024-01-26.mdx
index 8eba6d26b..b019ef246 100644
--- a/meeting-notes/2024-01-26.mdx
+++ b/meeting-notes/2024-01-26.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-01-26'
+title: "2024-01-26"
authors: kalepail
tags: [developer]
---
diff --git a/meeting-notes/2024-02-01.mdx b/meeting-notes/2024-02-01.mdx
index 6378cb821..f581603ba 100644
--- a/meeting-notes/2024-02-01.mdx
+++ b/meeting-notes/2024-02-01.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-02-01'
+title: "2024-02-01"
authors: naman
tags: [protocol]
---
@@ -24,4 +24,4 @@ tags: [protocol]
1. It is also costly to bundle decoding with verification in guest.
1. 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.
1. Leigh’s implementation may require further evaluation of the crates used for ecdsa and p256.
-1. Brief discussion around proposed process for adding of a host function by a non-core dev.
\ No newline at end of file
+1. Brief discussion around proposed process for adding of a host function by a non-core dev.
diff --git a/meeting-notes/2024-02-09.mdx b/meeting-notes/2024-02-09.mdx
index 3042ee8b7..e26bb9038 100644
--- a/meeting-notes/2024-02-09.mdx
+++ b/meeting-notes/2024-02-09.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-02-09'
+title: "2024-02-09"
authors: kalepail
tags: [developer]
---
@@ -17,4 +17,4 @@ tags: [developer]
1. [SEP draft](https://github.com/orbitlens/stellar-protocol/blob/sep-0042-token-lists/ecosystem/sep-0042.md)
2. [Discord discussion](https://discord.com/channels/897514728459468821/1162558946867953704)
2. Stellar + Soroban documentation survey
- 1. [Take the survey](https://discord.com/channels/897514728459468821/1204462856037470248/1205196745877757962)
\ No newline at end of file
+ 1. [Take the survey](https://discord.com/channels/897514728459468821/1204462856037470248/1205196745877757962)
diff --git a/meeting-notes/2024-02-15.mdx b/meeting-notes/2024-02-15.mdx
index 71c74b1c9..89ecc5dbb 100644
--- a/meeting-notes/2024-02-15.mdx
+++ b/meeting-notes/2024-02-15.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-02-15'
+title: "2024-02-15"
authors: naman
tags: [protocol]
---
@@ -15,29 +15,29 @@ tags: [protocol]
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
+ - 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.
+ - 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.
+ - 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.
diff --git a/meeting-notes/2024-02-22.mdx b/meeting-notes/2024-02-22.mdx
index 3ab6227db..e8ddacf05 100644
--- a/meeting-notes/2024-02-22.mdx
+++ b/meeting-notes/2024-02-22.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-02-22'
+title: "2024-02-22"
authors: kalepail
tags: [developer]
---
diff --git a/meeting-notes/2024-02-29.mdx b/meeting-notes/2024-02-29.mdx
index 2ec1f2661..3e28aed28 100644
--- a/meeting-notes/2024-02-29.mdx
+++ b/meeting-notes/2024-02-29.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-02-29'
+title: "2024-02-29"
authors: naman
tags: [protocol]
---
@@ -13,9 +13,7 @@ tags: [protocol]
[Discord agenda thread](https://discord.com/channels/897514728459468821/1212118102565855243)
-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](https://github.com/stellar/stellar-protocol/discussions/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.
+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](https://github.com/stellar/stellar-protocol/discussions/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](https://github.com/stellar/stellar-protocol/discussions/).
4. As next steps, a CAP will be authored to capture the proposal and put forth for approval from CAP Core Team.
-
diff --git a/meeting-notes/2024-03-07.mdx b/meeting-notes/2024-03-07.mdx
index 4cd82f1ce..693e1fcdf 100644
--- a/meeting-notes/2024-03-07.mdx
+++ b/meeting-notes/2024-03-07.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-03-07'
+title: "2024-03-07"
authors: kalepail
tags: [developer]
---
diff --git a/meeting-notes/2024-03-14.mdx b/meeting-notes/2024-03-14.mdx
index 0bb955aed..d5894a841 100644
--- a/meeting-notes/2024-03-14.mdx
+++ b/meeting-notes/2024-03-14.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-03-14'
+title: "2024-03-14"
authors: naman
tags: [protocol]
---
@@ -13,13 +13,11 @@ tags: [protocol]
[Discord agenda thread](https://discord.com/channels/897514728459468821/1217193723612368926)
-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.
+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](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0051.md): add support for secp256r1 verification; by @leigh
- b. [CAP-53](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0053.md): create separate functions for extending the time-to-live for contract instance and contract code; by @tdep
- c. [CAP-54](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0054.md): 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](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0055.md): lower total costs by linking fewer host functions during VM instantiation in Soroban; by @graydon
- e. [CAP-56](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0056.md): lower total costs by caching parsed Wasm modules within a Soroban transaction; by @graydon
-
+ a. [CAP-51](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0051.md): add support for secp256r1 verification; by @leigh
+ b. [CAP-53](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0053.md): create separate functions for extending the time-to-live for contract instance and contract code; by @tdep
+ c. [CAP-54](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0054.md): 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](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0055.md): lower total costs by linking fewer host functions during VM instantiation in Soroban; by @graydon
+ e. [CAP-56](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0056.md): lower total costs by caching parsed Wasm modules within a Soroban transaction; by @graydon
diff --git a/meeting-notes/2024-03-21.mdx b/meeting-notes/2024-03-21.mdx
index 1a37e79d6..717ff5372 100644
--- a/meeting-notes/2024-03-21.mdx
+++ b/meeting-notes/2024-03-21.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-03-21'
+title: "2024-03-21"
authors: kalepail
tags: [developer]
---
diff --git a/meeting-notes/2024-03-28.mdx b/meeting-notes/2024-03-28.mdx
index 57054dec1..32dadf84e 100644
--- a/meeting-notes/2024-03-28.mdx
+++ b/meeting-notes/2024-03-28.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-03-28'
+title: "2024-03-28"
authors: naman
tags: [protocol]
---
@@ -13,7 +13,7 @@ tags: [protocol]
[Agenda thread](https://github.com/stellar/stellar-protocol/discussions/1475)
-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.
+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](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0042.md)) and implementing the proposed standard
4. Discussion continues in the proposal doc.
diff --git a/meeting-notes/2024-04-04.mdx b/meeting-notes/2024-04-04.mdx
index 3292f6121..d9310c7d7 100644
--- a/meeting-notes/2024-04-04.mdx
+++ b/meeting-notes/2024-04-04.mdx
@@ -1,21 +1,22 @@
---
-title: '2024-04-04'
+title: "2024-04-04"
authors: naman
tags: [developer]
---
-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.
+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):
+
+ frameborder="0"
+ width="500"
+ height="100"
+ src="https://drive.google.com/file/d/14ddYFIMDgsX70hTCv8C1tKaAGmJiprw7/preview"
+>
Part 2 (video):
+
-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
+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](https://docs.google.com/document/d/1FAs3Yfo-o-gVqccrP29NSG8ysRvdEoyvuL7ywV4ijXI/edit#heading=h.1xwsoyifxbfm)
3. [Ongoing discussion](https://github.com/stellar/stellar-protocol/discussions/1480)
4. Snapshot size is TBD; it's a function of bucket list size as well as memory and historic demands placed on the RPC.
diff --git a/meeting-notes/2024-05-02.mdx b/meeting-notes/2024-05-02.mdx
index 2e9c7120c..a595895d2 100644
--- a/meeting-notes/2024-05-02.mdx
+++ b/meeting-notes/2024-05-02.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-05-02'
+title: "2024-05-02"
authors: naman
tags: [developer]
---
@@ -14,9 +14,9 @@ tags: [developer]
[Discord Agenda thread](https://discord.com/channels/897514728459468821/1234887262530048010/1234887262530048010)
1. Fifo presented [Stellar Plus](https://docs.cheesecakelabs.com/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.
+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](https://miro.com/app/board/uXjVKMDkMPI=/?share_link_id=643609701897)
- - [Stellar Plus Repositore](https://discord.com/channels/897514728459468821/1234887262530048010/1235699608274079865)
- - [Examples Repository](https://github.com/fazzatti/stellar-plus-examples)
- - [Docs](https://docs.cheesecakelabs.com/stellar-plus)
+ - [Miro Board showing Stellar Plus architecture](https://miro.com/app/board/uXjVKMDkMPI=/?share_link_id=643609701897)
+ - [Stellar Plus Repositore](https://discord.com/channels/897514728459468821/1234887262530048010/1235699608274079865)
+ - [Examples Repository](https://github.com/fazzatti/stellar-plus-examples)
+ - [Docs](https://docs.cheesecakelabs.com/stellar-plus)
diff --git a/meeting-notes/2024-05-09.mdx b/meeting-notes/2024-05-09.mdx
index 616da31ed..12556769d 100644
--- a/meeting-notes/2024-05-09.mdx
+++ b/meeting-notes/2024-05-09.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-05-09'
+title: "2024-05-09"
authors: naman
tags: [developer]
---
@@ -13,6 +13,6 @@ tags: [developer]
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/](https://passkey.sorobanbyexample.org/)
-5. Code for the demo is here [https://github.com/kalepail/soroban-passkey](https://github.com/kalepail/soroban-passkey)
+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 [passkey.sorobanbyexample.org/](https://passkey.sorobanbyexample.org/)
+5. Code for the demo is here [github.com/kalepail/soroban-passkey](https://github.com/kalepail/soroban-passkey)
diff --git a/meeting-notes/2024-06-13.mdx b/meeting-notes/2024-06-13.mdx
index a27324a3e..91c649959 100644
--- a/meeting-notes/2024-06-13.mdx
+++ b/meeting-notes/2024-06-13.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-06-13'
+title: "2024-06-13"
authors: kalepail
tags: [developer]
---
@@ -12,13 +12,13 @@ tags: [developer]
>
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
+ - 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](https://github.com/kalepail/passkey-kit/tree/main/contracts))
- * Code: https://github.com/kalepail/passkey-kit
- * Demo: https://passkey-kit-demo.pages.dev
+ - 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)
+ - 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](https://docs.google.com/document/d/1c_Wom6eK1UpC3E7VuQZfOBCLc2d5lvqAhMN7VPieMBQ/edit).
Join the `#passkeys` channel on the Discord to continue the discussion
diff --git a/meeting-notes/2024-06-20.mdx b/meeting-notes/2024-06-20.mdx
index 7cc11b52f..48ba43312 100644
--- a/meeting-notes/2024-06-20.mdx
+++ b/meeting-notes/2024-06-20.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-06-20'
+title: "2024-06-20"
authors: naman
tags: [developer]
---
diff --git a/meeting-notes/2024-06-27.mdx b/meeting-notes/2024-06-27.mdx
index 5148b9380..f98ddae9c 100644
--- a/meeting-notes/2024-06-27.mdx
+++ b/meeting-notes/2024-06-27.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-06-27'
+title: "2024-06-27"
authors: naman
tags: [developer]
---
@@ -14,8 +14,8 @@ tags: [developer]
1. [Chad](https://github.com/chadoh) and [Willem](https://github.com/willemneal) from [Aha Labs](https://github.com/AhaLabs) discuss the updates to the new and improved [stellar-cli](https://github.com/stellar/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!
+ - `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!
diff --git a/meeting-notes/2024-07-11.mdx b/meeting-notes/2024-07-11.mdx
index 7c0fc83f5..6b8f5e8be 100644
--- a/meeting-notes/2024-07-11.mdx
+++ b/meeting-notes/2024-07-11.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-07-11'
+title: "2024-07-11"
authors: naman
tags: [developer]
---
@@ -12,7 +12,6 @@ tags: [developer]
>
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](https://docs.google.com/presentation/d/1QsCwFLFcDF4RmNIwtSSnNrUfZb0RM0kLxOOxC7ENY5M/edit#slide=id.g2cb5821e4de_1_1143) are publicly available and legible async.
+2. [Slides](https://docs.google.com/presentation/d/1QsCwFLFcDF4RmNIwtSSnNrUfZb0RM0kLxOOxC7ENY5M/edit#slide=id.g2cb5821e4de_1_1143) are publicly available and legible async.
3. Tips for data anlaysis are also covered in [docs](https://developers.stellar.org/docs/data/hubble/analyst-guide)
4. Share your queries and post questions in #hubble in Stellar discord, which is a dedicated channel for data-related topics.
-
diff --git a/meeting-notes/2024-07-18.mdx b/meeting-notes/2024-07-18.mdx
index efcfcc879..59324c00b 100644
--- a/meeting-notes/2024-07-18.mdx
+++ b/meeting-notes/2024-07-18.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-07-18'
+title: "2024-07-18"
authors: naman
tags: [developer]
---
@@ -11,17 +11,10 @@ tags: [developer]
allow="autoplay"
>
+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.
-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](https://github.com/stellar/stellar-protocol/discussions/1499) 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.
+1. Tyler put forward a [proposal](https://github.com/stellar/stellar-protocol/discussions/1499) 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](https://github.com/stellar/stellar-protocol/discussions/1499) here and implementation [here](https://github.com/kalepail/passkey-kit/blob/main/contracts/webauthn-wallet/src/lib.rs)
-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.
+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!
-
diff --git a/meeting-notes/2024-07-25.mdx b/meeting-notes/2024-07-25.mdx
index a80b0bd59..299249ff7 100644
--- a/meeting-notes/2024-07-25.mdx
+++ b/meeting-notes/2024-07-25.mdx
@@ -1,10 +1,9 @@
---
-title: '2024-07-25'
+title: "2024-07-25"
authors: naman
tags: [protocol]
---
-
-A Core Dev, Dima, discussed the proposal to add constructor support to Soroban, Stellar's smart contract system.
-
-Relevant links: [Draft CAP](https://github.com/stellar/stellar-protocol/blob/50dde0611440d6dc562a33462e6ba5f1504b2753/core/cap-0058.md),
-[Ongoing discussion](https://github.com/stellar/stellar-protocol/discussions/1501),
-[Motivating Discord Thread](https://discord.com/channels/897514728459468821/1067534037310255225)
+A Core Dev, Dima, discussed the proposal to add constructor support to Soroban, Stellar's smart contract system.
+Relevant links: [Draft CAP](https://github.com/stellar/stellar-protocol/blob/50dde0611440d6dc562a33462e6ba5f1504b2753/core/cap-0058.md), [Ongoing discussion](https://github.com/stellar/stellar-protocol/discussions/1501), [Motivating Discord Thread](https://discord.com/channels/897514728459468821/1067534037310255225)
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.
-5. The high impact topic of naming is put to ecosystem vote, please cast yours [here](https://github.com/stellar/stellar-protocol/discussions/1507).
-
-
+3. The high impact topic of naming is put to ecosystem vote, please cast yours [here](https://github.com/stellar/stellar-protocol/discussions/1507).
diff --git a/meeting-notes/2024-08-01.mdx b/meeting-notes/2024-08-01.mdx
index e03dd8b59..0c2f914ca 100644
--- a/meeting-notes/2024-08-01.mdx
+++ b/meeting-notes/2024-08-01.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-08-01'
+title: "2024-08-01"
authors: naman
tags: [developer]
---
@@ -11,7 +11,6 @@ tags: [developer]
allow="autoplay"
>
-
1. Piyal demonstrated that Freighter's swap functionality is now served by [Soroswap](https://soroswap.finance/). It was previously served by Stellar Dex.
2. Freighter has made integration instructions available [here](https://github.com/stellar/freighter/blob/d248f2ad0aa03da72ea6eeaf7907ac0454fdcc72/extension/INTEGRATING_SOROSWAP.MD?plain=1#L2).
3. Esteban shared that [Palta Labs](https://paltalabs.io/) has created a DEX aggregator and made it available to all via the [Router SDK](https://docs.soroswap.finance/03-technical-reference/07-optimal-route/01-soroswap-router-sdk).
diff --git a/meeting-notes/2024-08-08.mdx b/meeting-notes/2024-08-08.mdx
index 3e314a7f2..f4c12dd10 100644
--- a/meeting-notes/2024-08-08.mdx
+++ b/meeting-notes/2024-08-08.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-08-12'
+title: "2024-08-12"
authors: naman
tags: [developer]
---
@@ -12,7 +12,3 @@ tags: [developer]
>
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.
-
-
-
-
diff --git a/meeting-notes/2024-08-15.mdx b/meeting-notes/2024-08-15.mdx
index d49e9b97c..0c3bf6b5c 100644
--- a/meeting-notes/2024-08-15.mdx
+++ b/meeting-notes/2024-08-15.mdx
@@ -1,5 +1,5 @@
---
-title: '2024-08-15'
+title: "2024-08-15"
authors: julian
tags: [developer]
---
@@ -15,11 +15,9 @@ tags: [developer]
2.[Link to the presentation](https://docs.google.com/presentation/d/1mDOrBLfe8-Bq6VCy7r5bb4w_uZjq-EOorbV3ZwYfs1k/edit?usp=sharing)
-_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:
+_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
-3. 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?
-4. 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?
-5. Are there any asks of the developer community?
+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?
diff --git a/meeting-notes/2024-08-22.mdx b/meeting-notes/2024-08-22.mdx
index 394d44f1b..c0ed92d54 100644
--- a/meeting-notes/2024-08-22.mdx
+++ b/meeting-notes/2024-08-22.mdx
@@ -1,26 +1,30 @@
---
-title: '2024-08-23'
+title: "2024-08-23"
authors: naman
tags: [protocol]
---
-
+
[Discord agenda thread](https://discord.com/channels/897514728459468821/900374272751591424/1275577430043525204)
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](https://developers.stellar.org/meetings/2024/07/25)), documented in [CAP-58](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0058.md). A constructor is a function that will only be executed the first time the contract is created.
+1. The proposal for addition of a constructor to Soroban’s flavor of Rust was introduced in a previous protocol meeting ([previous meeting](https://developers.stellar.org/meetings/2024/07/25)), documented in [CAP-58](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0058.md). 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.
+ 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](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0060.md). 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.
+ 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](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0059.md).
- 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. 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.
diff --git a/meeting-notes/2024-08-29.mdx b/meeting-notes/2024-08-29.mdx
index 41ebfac8d..257d09aa9 100644
--- a/meeting-notes/2024-08-29.mdx
+++ b/meeting-notes/2024-08-29.mdx
@@ -1,21 +1,26 @@
---
-title: '2024-08-29'
+title: "2024-08-29"
authors: naman
tags: [protocol]
---
-
+
Agenda: [Discord thread](https://discord.com/channels/897514728459468821/900374272751591424/1278045556211716171)
CAP Core team deliberated on the proposed CAPs:
1. Addition of a constructor to Soroban's flavor of Rust. [CAP](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0058.md)
- 1. Team's concern was about potential break in compatibility, which Dima had addressed. There were no further concerns.
-3. Addition of BLS12-381 curve and required field arithmetics - [CAP](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0059.md)
- 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.
-5. Increase performance by upgrading Soroban's VM. [CAP Discussion](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0060.md)
- 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.
+ 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](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0059.md)
+ 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](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0060.md)
+ 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.
diff --git a/meeting-notes/2024-09-05.mdx b/meeting-notes/2024-09-05.mdx
index 0478e1a5e..3158556ec 100644
--- a/meeting-notes/2024-09-05.mdx
+++ b/meeting-notes/2024-09-05.mdx
@@ -1,24 +1,29 @@
---
-title: '2024-09-05'
+title: "2024-09-05"
authors: anataliocs
tags: [developer]
---
-
+
Agenda: [Discord thread](https://discord.com/channels/897514728459468821/900374272751591424/1280678171053789317)
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
+ 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
\ No newline at end of file
+ 1. Workflows: Create ETL(extract, transform, load) pipelines
+ 2. Streaming: Fast, lightweight streaming data
diff --git a/meeting-notes/2024-09-12.mdx b/meeting-notes/2024-09-12.mdx
index b07fa3191..7d7ab794a 100644
--- a/meeting-notes/2024-09-12.mdx
+++ b/meeting-notes/2024-09-12.mdx
@@ -1,22 +1,27 @@
---
-title: '2024-09-12'
+title: "2024-09-12"
authors: carstenjacobsen
tags: [developer]
---
-
+
Agenda: [Discord thread](https://discord.com/channels/897514728459468821/900374272751591424/1282934024892973077)
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
+ 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.
\ No newline at end of file
+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.
diff --git a/meeting-notes/2024-09-19.mdx b/meeting-notes/2024-09-19.mdx
index f24c9d9f9..a50cd29df 100644
--- a/meeting-notes/2024-09-19.mdx
+++ b/meeting-notes/2024-09-19.mdx
@@ -1,10 +1,15 @@
---
-title: '2024-09-19'
+title: "2024-09-19"
authors: carstenjacobsen
tags: [developer]
---
-
+
Agenda: [Discord thread](https://discord.com/channels/897514728459468821/900374272751591424/1285627254130610297)
@@ -12,8 +17,8 @@ SDF DevRel team member Carsten Jacobsen showed how to build a simple Hello World
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
+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
diff --git a/meeting-notes/2024-09-26.mdx b/meeting-notes/2024-09-26.mdx
index 1fa53a6e4..dc009069a 100644
--- a/meeting-notes/2024-09-26.mdx
+++ b/meeting-notes/2024-09-26.mdx
@@ -1,17 +1,21 @@
---
-title: '2024-09-26'
+title: "2024-09-26"
authors: anataliocs
tags: [developer]
---
-
+
Agenda: [Discord thread](https://discord.com/channels/897514728459468821/900374272751591424/1288890126038208532)
-Summary: Hoops Finance, a DeFi protocol, discussed their platform they are building. https://www.hoops.finance/
-
+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
+4. Hoops Finance API: https://api.v1.xlm.services/#overview
diff --git a/meeting-notes/2024-10-24.mdx b/meeting-notes/2024-10-24.mdx
index f6acac050..4190a737b 100644
--- a/meeting-notes/2024-10-24.mdx
+++ b/meeting-notes/2024-10-24.mdx
@@ -1,10 +1,15 @@
---
-title: '2024-10-24'
+title: "2024-10-24"
authors: carstenjacobsen
tags: [developer]
---
-
+
Agenda: [Discord thread](https://discord.com/channels/897514728459468821/900374272751591424/1298362698123182080)
diff --git a/meeting-notes/2024-11-14.mdx b/meeting-notes/2024-11-14.mdx
index ea0f02aea..60b02b3e5 100644
--- a/meeting-notes/2024-11-14.mdx
+++ b/meeting-notes/2024-11-14.mdx
@@ -1,14 +1,19 @@
---
-title: '2024-11-14'
+title: "2024-11-14"
authors: carstenjacobsen
tags: [developer]
---
-
+
Agenda: [Discord thread](https://discord.com/events/897514728459468821/1304859059425382553/1306725344870400000)
-At this week’s developer meeting, Jeesun demonstrated the new Stellar Lab, showcasing its enhanced features designed to improve the developer experience.
+At this week’s developer meeting, Jeesun demonstrated the new Stellar Lab, showcasing its enhanced features designed to improve the developer experience.
The tech stack of the new Stellar Lab was discussed in the meeting, and the following demos were used to show the Lab's functionality:
diff --git a/package.json b/package.json
index 4ce55ad46..e16ed41fe 100644
--- a/package.json
+++ b/package.json
@@ -5,7 +5,8 @@
"scripts": {
"docusaurus": "docusaurus",
"start": "docusaurus start",
- "build": "docusaurus build",
+ "build": "docusaurus build --locale en",
+ "build:production": "yarn crowdin:sync && yarn crowdin:fix && yarn build",
"swizzle": "docusaurus swizzle",
"deploy": "docusaurus deploy",
"clear": "docusaurus clear",
@@ -19,8 +20,8 @@
"api": "yarn api:clean && yarn api:bundle && yarn api:gen",
"write-translations": "docusaurus write-translations",
"write-heading-ids": "docusaurus write-heading-ids",
- "format:mdx": "prettier --write \"{docs,src/pages,platforms}/**/*.{md,mdx}\"",
- "check:mdx": "prettier -c \"{docs,src/pages,platforms}/**/*.{md,mdx}\"",
+ "format:mdx": "prettier --write \"{docs,src/pages,platforms,meeting-notes}/**/*.{md,mdx}\"",
+ "check:mdx": "prettier -c \"{docs,src/pages,platforms,meeting-notes}/**/*.{md,mdx}\"",
"lint:fix": "eslint \"src/**/*.{js,jsx,ts,tsx}\" --fix",
"lint": "eslint \"src/**/*.{js,jsx,ts,tsx}\"",
"prepare": "husky",
@@ -28,12 +29,16 @@
"rpcspec:build": "node openrpc/scripts/build.mjs",
"rpcspec:validate": "node openrpc/scripts/build.mjs && node openrpc/scripts/validate.mjs",
"stellar-cli:build": "node scripts/stellar_cli.mjs",
+ "crowdin": "crowdin",
+ "crowdin:fix": "node scripts/copyIgnoredFiles.mjs && ./scripts/fix_translations.sh",
+ "crowdin:sync": "docusaurus write-translations && crowdin upload --no-progress && crowdin download --no-progress",
"ap:versions:clean": "docusaurus clean-api-docs:version -p ap-apis ap_platform:all && docusaurus clean-api-docs:version -p ap-apis ap_callbacks:all && docusaurus clean-api-docs:version -p ap-apis ap_custody:all",
"ap:versions:gen": "docusaurus gen-api-docs:version -p ap-apis ap_platform:all && docusaurus gen-api-docs:version -p ap-apis ap_callbacks:all && docusaurus gen-api-docs:version -p ap-apis ap_custody:all && rm ap_versioned_docs/version-*/api-reference/{callbacks,custody,platform/transactions}/*.info.mdx",
"ap:versions:regen": "yarn ap:versions:clean && yarn ap:versions:gen",
"ap:versions:new": "docusaurus docs:version:ap $VERSION && node scripts/ap_new_version.mjs $VERSION"
},
"dependencies": {
+ "@crowdin/cli": "^4.5.0",
"@docusaurus/core": "3.4.0",
"@docusaurus/preset-classic": "3.4.0",
"@docusaurus/remark-plugin-npm2yarn": "3.4.0",
@@ -49,6 +54,7 @@
"docusaurus-plugin-openapi-docs": "^3.0.1",
"docusaurus-plugin-sentry": "^2.0.0",
"docusaurus-theme-openapi-docs": "^3.0.1",
+ "js-yaml": "^4.1.0",
"patch-package": "^8.0.0",
"prism-react-renderer": "^2.3.1",
"react": "^18.3.1",
diff --git a/platforms/anchor-platform/admin-guide/events/getting-started.mdx b/platforms/anchor-platform/admin-guide/events/getting-started.mdx
index 5001c7931..7547bbf70 100644
--- a/platforms/anchor-platform/admin-guide/events/getting-started.mdx
+++ b/platforms/anchor-platform/admin-guide/events/getting-started.mdx
@@ -11,7 +11,7 @@ Anchor Platform provides an event service that sends HTTP webhook notifications
- Quote updates
- Customer KYC status changes
-Event schemas for business servers are defined in the [API reference](/platforms/anchor-platform/next/api-reference/callbacks/post-event).
+Event schemas for business servers are defined in the [API reference](../../api-reference/callbacks/post-event.api.mdx).
**Client Applications**
diff --git a/platforms/anchor-platform/admin-guide/sep24/integration.mdx b/platforms/anchor-platform/admin-guide/sep24/integration.mdx
index 4fae1b17e..6caf77d25 100644
--- a/platforms/anchor-platform/admin-guide/sep24/integration.mdx
+++ b/platforms/anchor-platform/admin-guide/sep24/integration.mdx
@@ -1016,6 +1016,6 @@ Works in the same manner as for the deposit flow. For more details, see [Transac
[sep-9]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0009.md
[sep-24]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md
-[event-handling]: /platforms/anchor-platform/admin-guide/events/README.mdx
-[rate-callback]: /platforms/anchor-platform/api-reference/callbacks/README.mdx
+[event-handling]: ../events/README.mdx
+[rate-callback]: ../../api-reference/callbacks/README.mdx
[json-rpc-methods]: ../../api-reference/platform/rpc/methods/README.mdx
diff --git a/platforms/anchor-platform/admin-guide/sep6/integration.mdx b/platforms/anchor-platform/admin-guide/sep6/integration.mdx
index 7627af2e8..179218144 100644
--- a/platforms/anchor-platform/admin-guide/sep6/integration.mdx
+++ b/platforms/anchor-platform/admin-guide/sep6/integration.mdx
@@ -985,7 +985,7 @@ Works in the same manner as for the deposit flow. For more details, see [Transac
[sep-6]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md
-[event-handling]: /platforms/anchor-platform/admin-guide/events/README.mdx
-[customer-callback]: /platforms/anchor-platform/api-reference/callbacks/README.mdx
-[rate-callback]: /platforms/anchor-platform/api-reference/callbacks/README.mdx
+[event-handling]: ../events/README.mdx
+[customer-callback]: ../../api-reference/callbacks/README.mdx
+[rate-callback]: ../../api-reference/callbacks/README.mdx
[get-transactions]: ../../api-reference/platform/transactions/get-transactions.api.mdx
diff --git a/platforms/anchor-platform/api-reference/platform/rpc/methods/README.mdx b/platforms/anchor-platform/api-reference/platform/rpc/methods/README.mdx
index 2e66a5c05..ee8fdac5d 100644
--- a/platforms/anchor-platform/api-reference/platform/rpc/methods/README.mdx
+++ b/platforms/anchor-platform/api-reference/platform/rpc/methods/README.mdx
@@ -13,27 +13,31 @@ The OpenRPC Specification for JSON-RPC API is available [here](https://playgroun
Postman collection is available [here](https://documenter.getpostman.com/view/9257637/2s9Y5U1kra)
- | | | | --- | --- | | | [do_stellar_payment](do_stellar_payment.mdx) | | |
- [do_stellar_refund](do_stellar_refund.mdx) | | |
- [get_transaction](get_transaction.mdx) | | |
- [get_transactions](get_transactions.mdx) | | |
- [notify_amounts_updated](notify_amounts_updated.mdx) | | |
- [notify_customer_info_updated](notify_customer_info_updated.mdx) | | |
- [notify_interactive_flow_completed](notify_interactive_flow_completed.mdx) | |
- | [notify_offchain_funds_available](notify_offchain_funds_available.mdx) | | |
- [notify_offchain_funds_pending](notify_offchain_funds_pending.mdx) | | |
- [notify_offchain_funds_received](notify_offchain_funds_received.mdx) | | |
- [notify_offchain_funds_sent](notify_offchain_funds_sent.mdx) | | |
- [notify_onchain_funds_received](notify_onchain_funds_received.mdx) | | |
- [notify_onchain_funds_sent](notify_onchain_funds_sent.mdx) | | |
- [notify_refund_pending](notify_refund_pending.mdx) | | |
- [notify_refund_sent](notify_refund_sent.mdx) | | |
- [notify_transaction_error](notify_transaction_error.mdx) | | |
- [notify_transaction_expired](notify_transaction_expired.mdx) | | |
- [notify_transaction_on_hold](notify_transaction_on_hold.mdx) | | |
- [notify_transaction_recovery](notify_transaction_recovery.mdx) | | |
- [notify_trust_set](notify_trust_set.mdx) | | |
- [request_offchain_funds](request_offchain_funds.mdx) | | |
- [request_onchain_funds](request_onchain_funds.mdx) | | |
- [request_trust](request_trust.mdx) |
+
+| | |
+| --- | --- |
+| | [do_stellar_payment](./do_stellar_payment.mdx) |
+| | [do_stellar_refund](./do_stellar_refund.mdx) |
+| | [get_transaction](./get_transaction.mdx) |
+| | [get_transactions](./get_transactions.mdx) |
+| | [notify_amounts_updated](./notify_amounts_updated.mdx) |
+| | [notify_customer_info_updated](./notify_customer_info_updated.mdx) |
+| | [notify_interactive_flow_completed](./notify_interactive_flow_completed.mdx) |
+| | [notify_offchain_funds_available](./notify_offchain_funds_available.mdx) |
+| | [notify_offchain_funds_pending](./notify_offchain_funds_pending.mdx) |
+| | [notify_offchain_funds_received](./notify_offchain_funds_received.mdx) |
+| | [notify_offchain_funds_sent](./notify_offchain_funds_sent.mdx) |
+| | [notify_onchain_funds_received](./notify_onchain_funds_received.mdx) |
+| | [notify_onchain_funds_sent](./notify_onchain_funds_sent.mdx) |
+| | [notify_refund_pending](./notify_refund_pending.mdx) |
+| | [notify_refund_sent](./notify_refund_sent.mdx) |
+| | [notify_transaction_error](./notify_transaction_error.mdx) |
+| | [notify_transaction_expired](./notify_transaction_expired.mdx) |
+| | [notify_transaction_on_hold](./notify_transaction_on_hold.mdx) |
+| | [notify_transaction_recovery](./notify_transaction_recovery.mdx) |
+| | [notify_trust_set](./notify_trust_set.mdx) |
+| | [request_offchain_funds](./request_offchain_funds.mdx) |
+| | [request_onchain_funds](./request_onchain_funds.mdx) |
+| | [request_trust](./request_trust.mdx) |
+
diff --git a/platforms/stellar-disbursement-platform/admin-guide/60-anchor-platform-integration-points.mdx b/platforms/stellar-disbursement-platform/admin-guide/anchor-platform-integration-points.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/60-anchor-platform-integration-points.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/anchor-platform-integration-points.mdx
index 511e94363..7436ecf55 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/60-anchor-platform-integration-points.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/anchor-platform-integration-points.mdx
@@ -1,6 +1,5 @@
---
title: Anchor Platform Integration Points
-id: anchor-platform-integration-points
sidebar_position: 60
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/45-configuring-sdp.mdx b/platforms/stellar-disbursement-platform/admin-guide/configuring-sdp.mdx
similarity index 95%
rename from platforms/stellar-disbursement-platform/admin-guide/45-configuring-sdp.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/configuring-sdp.mdx
index 62f47dc15..55d764c1f 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/45-configuring-sdp.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/configuring-sdp.mdx
@@ -1,5 +1,4 @@
---
-id: configuring-sdp
title: Configuring the SDP
description: Understand the configuration options available for the Stellar Disbursement Platform (SDP)
keywords: [SDP, configuration]
@@ -40,8 +39,8 @@ Operational Configuration allows controlling metrics, logging, and other operati
- `SENTRY_DSN` - 🔑 The DSN (client key) of the Sentry project. If not provided, Sentry will not be used.
- `ENVIRONMENT` - The environment where the application is running. Example: "development", "staging", "production". Default: "development".
- `DATABASE_URL` - 🔑 The connection string for the PostgreSQL database. Format is `postgres://username:password@host:port/database?sslmode=disable`. Default: "postgres://localhost:5432/sdp?sslmode=disable".
-- `BASE_URL` - The SDP backend server's base URL. Default: "http://localhost:8000". Tenant-specific URLs will be configured during the [tenant provisioning process](tenant-provisioning#creating-tenants).
-- `SDP_UI_BASE_URL` - The SDP UI/dashboard Base URL used to send the invitation link when a new user is created. Tenant-specific URLs will be configured during the [tenant provisioning process](tenant-provisioning#creating-tenants).
+- `BASE_URL` - The SDP backend server's base URL. Default: "http://localhost:8000". Tenant-specific URLs will be configured during the [tenant provisioning process](./tenant-provisioning.mdx#creating-tenants).
+- `SDP_UI_BASE_URL` - The SDP UI/dashboard Base URL used to send the invitation link when a new user is created. Tenant-specific URLs will be configured during the [tenant provisioning process](./tenant-provisioning.mdx#creating-tenants).
### Messaging Configuration
@@ -87,7 +86,7 @@ Stellar Configuration allows configuring accounts, transactions, and other Stell
- `SEP10_SIGNING_PRIVATE_KEY` - 🔑 The private key of the Stellar account that signs the SEP-10 transactions. It's also used to sign URLs.
- `MAX_BASE_FEE` - The max base fee for submitting a Stellar transaction. Default: 10000.
-The remaining configurations related to distribution accounts are detailed in the `Stellar accounts configuration` section of [1.x to 2.x Migration Guide](single-tenant-to-multi-tenant-migration#environment-variables).
+The remaining configurations related to distribution accounts are detailed in the `Stellar accounts configuration` section of [1.x to 2.x Migration Guide](./single-tenant-to-multi-tenant-migration.mdx#environment-variables).
### Security Configuration
@@ -125,11 +124,11 @@ Anchor Platform Configuration allows configuring the anchor platform used by the
For asynchronous processing, the SDP Core Service gives user the choice to use either the Event Broker or Scheduled Jobs.
-The configurations for this section are detailed in the `Event Broker and Scheduler Configurations` of the [1.x to 2.x Migration Guide](single-tenant-to-multi-tenant-migration#environment-variables).
+The configurations for this section are detailed in the `Event Broker and Scheduler Configurations` of the [1.x to 2.x Migration Guide](./single-tenant-to-multi-tenant-migration.mdx#environment-variables).
### Multi-tenancy Configuration
-The configurations for this section are detailed in `General Environment Variables` of the [1.x to 2.x Migration Guide](single-tenant-to-multi-tenant-migration#environment-variables).
+The configurations for this section are detailed in `General Environment Variables` of the [1.x to 2.x Migration Guide](./single-tenant-to-multi-tenant-migration.mdx#environment-variables).
## Transaction Submission Service (TSS)
@@ -176,7 +175,7 @@ The following configurations are required for using channel accounts to submit t
#### Distribution Accounts Configuration
-The following configurations are related to the distribution accounts used to send funds to recipients. This configuration should match the configuration in the SDP Core Service. For more details, refer to the `Stellar accounts configuration` section of [1.x to 2.x Migration Guide](single-tenant-to-multi-tenant-migration#environment-variables).
+The following configurations are related to the distribution accounts used to send funds to recipients. This configuration should match the configuration in the SDP Core Service. For more details, refer to the `Stellar accounts configuration` section of [1.x to 2.x Migration Guide](./single-tenant-to-multi-tenant-migration.mdx#environment-variables).
- `DISTRIBUTION_ACCOUNT_ENCRYPTION_PASSPHRASE` - 🔑 A Stellar-compliant ed25519 private key used to encrypt/decrypt the in-memory distribution accounts' private keys.
- `DISTRIBUTION_PUBLIC_KEY` - The public key of the HOST's Stellar distribution account, used to create channel accounts.
@@ -184,7 +183,7 @@ The following configurations are related to the distribution accounts used to se
### Event Broker Configuration
-If an Event Broker is used for asynchronous processing, the TSS will need to be configured to use it. For more details, refer to the `Event Broker and Scheduler Configurations` of the [1.x to 2.x Migration Guide](single-tenant-to-multi-tenant-migration#environment-variables).
+If an Event Broker is used for asynchronous processing, the TSS will need to be configured to use it. For more details, refer to the `Event Broker and Scheduler Configurations` of the [1.x to 2.x Migration Guide](./single-tenant-to-multi-tenant-migration.mdx#environment-variables).
- `EVENT_BROKER_TYPE` - The type of event broker to use. Options: "KAFKA", "NONE". Default: "KAFKA".
- `BROKER_URLS` - List of Message Broker URLs comma-separated.
diff --git a/platforms/stellar-disbursement-platform/admin-guide/40-deploy-the-sdp.mdx b/platforms/stellar-disbursement-platform/admin-guide/deploy-the-sdp.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/40-deploy-the-sdp.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/deploy-the-sdp.mdx
index 4ca82dc73..065ed096f 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/40-deploy-the-sdp.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/deploy-the-sdp.mdx
@@ -1,6 +1,5 @@
---
title: Deploy the SDP
-id: deploy-the-sdp
sidebar_position: 40
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/20-design-and-architecture.mdx b/platforms/stellar-disbursement-platform/admin-guide/design-and-architecture.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/20-design-and-architecture.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/design-and-architecture.mdx
index c1596a13f..458303421 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/20-design-and-architecture.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/design-and-architecture.mdx
@@ -1,6 +1,5 @@
---
title: Design and Architecture
-id: design-and-architecture
sidebar_position: 20
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/30-getting-started.mdx b/platforms/stellar-disbursement-platform/admin-guide/getting-started.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/30-getting-started.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/getting-started.mdx
index 37187b1cc..a9c999634 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/30-getting-started.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/getting-started.mdx
@@ -1,6 +1,5 @@
---
title: Getting Started
-id: getting-started
sidebar_position: 30
---
@@ -189,7 +188,7 @@ Payments will start failing if the distribution account runs out of funds. To fi
- The distribution account address can be found under `Distribution Account` on the frontend sidebar. Copy that address.
- Access [https://horizon-testnet.stellar.org/accounts/:accountId](https://horizon-testnet.stellar.org/accounts/GARGKDIDH7WMKV5WWPK4BH4CKEQIZGWUCA4EUXCY5VICHTHLEBXVNVMW) in your browser and check the balance.
- If the balance is indeed low, you can add more funds by creating a new account and sending funds to the distribution account.
- - Access [https://demo-wallet.stellar.org/](https://demo-wallet.stellar.org/) in your browser.
+ - Access [demo-wallet.stellar.org](https://demo-wallet.stellar.org/) in your browser.
- Click on `Generate Keypair for new account` to create a new testnet account. Your account comes with 10,000 XLM.
- Click on `Send` and enter the distribution account public key and the amount you want to send.
- Using Freighter or [Stellar Lab](https://lab.stellar.org/account/create?$=network$id=testnet&label=Testnet&horizonUrl=https:////horizon-testnet.stellar.org&rpcUrl=https:////soroban-testnet.stellar.org&passphrase=Test%20SDF%20Network%20/;%20September%202015;;), swap the XLM for USDC if you wish to test with USDC.
diff --git a/platforms/stellar-disbursement-platform/admin-guide/50-making-your-wallet-sdp-ready.mdx b/platforms/stellar-disbursement-platform/admin-guide/making-your-wallet-sdp-ready.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/50-making-your-wallet-sdp-ready.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/making-your-wallet-sdp-ready.mdx
index c8b930f8d..5fe6ab80b 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/50-making-your-wallet-sdp-ready.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/making-your-wallet-sdp-ready.mdx
@@ -1,6 +1,5 @@
---
title: Making Your Wallet SDP-Ready
-id: making-your-wallet-sdp-ready
sidebar_position: 50
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/10-overview.mdx b/platforms/stellar-disbursement-platform/admin-guide/overview.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/10-overview.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/overview.mdx
index d241125bc..30f2dc30d 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/10-overview.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/overview.mdx
@@ -1,6 +1,5 @@
---
title: Overview
-id: overview
sidebar_position: 10
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/42-secure-operation-manual.mdx b/platforms/stellar-disbursement-platform/admin-guide/secure-operation-manual.mdx
similarity index 98%
rename from platforms/stellar-disbursement-platform/admin-guide/42-secure-operation-manual.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/secure-operation-manual.mdx
index 7f155ae1f..ac7029ce6 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/42-secure-operation-manual.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/secure-operation-manual.mdx
@@ -1,6 +1,5 @@
---
title: Secure Operation Manual
-id: secure-operation-manual
sidebar_position: 42
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/70-migrating-to-sdp-multi-tenant.mdx b/platforms/stellar-disbursement-platform/admin-guide/single-tenant-to-multi-tenant-migration.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/70-migrating-to-sdp-multi-tenant.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/single-tenant-to-multi-tenant-migration.mdx
index 686a50202..a5c5e5d53 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/70-migrating-to-sdp-multi-tenant.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/single-tenant-to-multi-tenant-migration.mdx
@@ -151,7 +151,7 @@ On the Anchor Platform side, we must set the following envs:
### Seggregation of Funds
-In the multi-tenant version, tenants funds are isolated from each other **unless the tenant is created with `"distribution_account_type": "DISTRIBUTION_ACCOUNT.STELLAR.ENV"`**. For more information on the distribution account types, please refer to the [Tenant Provisioning](48-tenant-provisioning.mdx#creating-tenants) section.
+In the multi-tenant version, tenants funds are isolated from each other **unless the tenant is created with `"distribution_account_type": "DISTRIBUTION_ACCOUNT.STELLAR.ENV"`**. For more information on the distribution account types, please refer to the [Tenant Provisioning](./tenant-provisioning.mdx#creating-tenants) section.
The channel accounts on the other hand are shared between tenants, and they are created by the HOST distribution account, set in the `DISTRIBUTION_SEED` environment variable. The channel accounts are encrypted using the `CHANNEL_ACCOUNT_ENCRYPTION_PASSPHRASE` environment variable, or the `DISTRIBUTION_SEED` if the former is not set. In the single-tenant version, the channel accounts were encrypted by the `DISTRIBUTION_SEED`.
diff --git a/platforms/stellar-disbursement-platform/admin-guide/48-tenant-provisioning.mdx b/platforms/stellar-disbursement-platform/admin-guide/tenant-provisioning.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/48-tenant-provisioning.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/tenant-provisioning.mdx
index 6af351253..5c0ad4e4f 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/48-tenant-provisioning.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/tenant-provisioning.mdx
@@ -1,5 +1,4 @@
---
-id: tenant-provisioning
title: Provisioning a New Tenant
description: Learn how to provision and configure a new tenant in the Stellar Disbursement Platform.
keywords:
diff --git a/platforms/stellar-disbursement-platform/admin-guide/user-interface/60-analytics.mdx b/platforms/stellar-disbursement-platform/admin-guide/user-interface/analytics.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/user-interface/60-analytics.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/user-interface/analytics.mdx
index 8dade895e..d18660b26 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/user-interface/60-analytics.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/user-interface/analytics.mdx
@@ -1,6 +1,5 @@
---
title: Analytics
-id: analytics
sidebar_position: 60
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/user-interface/70-circle-configutration.mdx b/platforms/stellar-disbursement-platform/admin-guide/user-interface/circle-configuration.mdx
similarity index 97%
rename from platforms/stellar-disbursement-platform/admin-guide/user-interface/70-circle-configutration.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/user-interface/circle-configuration.mdx
index c285b8adc..cdc19cb45 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/user-interface/70-circle-configutration.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/user-interface/circle-configuration.mdx
@@ -1,6 +1,5 @@
---
title: Circle Configuration
-id: circle-configutration
sidebar_position: 70
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/user-interface/10-dashboard-home.mdx b/platforms/stellar-disbursement-platform/admin-guide/user-interface/dashboard-home.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/user-interface/10-dashboard-home.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/user-interface/dashboard-home.mdx
index f7fd22815..a140abb45 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/user-interface/10-dashboard-home.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/user-interface/dashboard-home.mdx
@@ -1,6 +1,5 @@
---
title: Dashboard Home
-id: dashboard-home
sidebar_position: 10
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/user-interface/20-disbursements.mdx b/platforms/stellar-disbursement-platform/admin-guide/user-interface/disbursements.mdx
similarity index 98%
rename from platforms/stellar-disbursement-platform/admin-guide/user-interface/20-disbursements.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/user-interface/disbursements.mdx
index 407933cd3..31757f6db 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/user-interface/20-disbursements.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/user-interface/disbursements.mdx
@@ -1,6 +1,5 @@
---
title: Disbursements
-id: disbursements
sidebar_position: 20
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/user-interface/40-payments.mdx b/platforms/stellar-disbursement-platform/admin-guide/user-interface/payments.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/user-interface/40-payments.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/user-interface/payments.mdx
index 5cf1bcb97..dedfd10f5 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/user-interface/40-payments.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/user-interface/payments.mdx
@@ -1,6 +1,5 @@
---
title: Payments
-id: payments
sidebar_position: 40
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/user-interface/30-receivers.mdx b/platforms/stellar-disbursement-platform/admin-guide/user-interface/receivers.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/user-interface/30-receivers.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/user-interface/receivers.mdx
index b228d0490..4ab11b05b 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/user-interface/30-receivers.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/user-interface/receivers.mdx
@@ -1,6 +1,5 @@
---
title: Receivers
-id: receivers
sidebar_position: 30
---
diff --git a/platforms/stellar-disbursement-platform/admin-guide/user-interface/50-wallets.mdx b/platforms/stellar-disbursement-platform/admin-guide/user-interface/wallets.mdx
similarity index 99%
rename from platforms/stellar-disbursement-platform/admin-guide/user-interface/50-wallets.mdx
rename to platforms/stellar-disbursement-platform/admin-guide/user-interface/wallets.mdx
index 1977dc6a2..28c9e8599 100644
--- a/platforms/stellar-disbursement-platform/admin-guide/user-interface/50-wallets.mdx
+++ b/platforms/stellar-disbursement-platform/admin-guide/user-interface/wallets.mdx
@@ -1,6 +1,5 @@
---
title: Wallets
-id: wallets
sidebar_position: 50
---
diff --git a/scripts/copyIgnoredFiles.mjs b/scripts/copyIgnoredFiles.mjs
new file mode 100644
index 000000000..022f52f9c
--- /dev/null
+++ b/scripts/copyIgnoredFiles.mjs
@@ -0,0 +1,126 @@
+import fs from 'fs';
+import path from 'path';
+import glob from 'glob';
+import yaml from 'js-yaml';
+
+// Define the list of language codes
+const languages = ['es'];
+
+/**
+ * Reads and parses the crowdin.yaml file.
+ * @param {string} filePath - The path to the crowdin.yaml file.
+ * @returns {Object} - The parsed configuration object.
+ */
+function readCrowdinConfig(filePath) {
+ try {
+ const fileContent = fs.readFileSync(filePath, 'utf8');
+ return yaml.load(fileContent);
+ } catch (err) {
+ logMessage(`Error reading or parsing the file ${filePath}: ${err.message}`);
+ process.exit(1);
+ }
+}
+
+/**
+ * Extracts the sources array from the configuration object.
+ * @param {Object} config - The parsed configuration object.
+ * @returns {string[]} - The array of source paths.
+ */
+function extractSources(config) {
+ return config.files.map(file => file.source.replace(/\/\*\*\/\*$/, '').replace(/^\//, ''));
+}
+
+/**
+ * Logs a message to the console with a timestamp.
+ * @param {string} message - The message to log.
+ */
+function logMessage(message) {
+ console.log(`[${new Date().toISOString()}] ${message}`);
+}
+
+/**
+ * Copies a file or directory from source to destination.
+ * @param {string} src - The source path.
+ * @param {string} dest - The destination path.
+ */
+function copyFileOrDirectory(src, dest) {
+ const destDir = path.dirname(dest);
+ fs.mkdirSync(destDir, { recursive: true });
+
+ const stat = fs.statSync(src);
+ if (stat.isDirectory()) {
+ fs.cpSync(src, dest, { recursive: true });
+ logMessage(`Successfully copied directory ${src} to ${dest}`);
+ } else {
+ fs.copyFileSync(src, dest);
+ logMessage(`Successfully copied file ${src} to ${dest}`);
+ }
+}
+
+/**
+ * Replaces placeholders in the translation path with actual values.
+ * @param {string} translationPath - The translation path template.
+ * @param {string} languageCode - The language code to replace placeholders.
+ * @param {string} srcPath - The source file path.
+ * @param {string[]} sources - The array of source paths.
+ * @returns {string} - The translation path with placeholders replaced.
+ */
+function getTranslationPath(translationPath, languageCode, srcPath, sources) {
+ let relativePath = srcPath;
+
+ for (const source of sources) {
+ if (srcPath.startsWith(source)) {
+ relativePath = srcPath.replace(`${source}/`, '');
+ break;
+ }
+ }
+
+ const destPath = translationPath
+ .replace('%two_letters_code%', languageCode)
+ .replace('%original_file_name%', path.basename(srcPath))
+ .replace('**', path.dirname(relativePath).replace(/\\/g, '/'));
+
+ return path.join(process.cwd(), destPath);
+}
+
+/**
+ * Copies ignored files for each language based on the configuration.
+ */
+function copyIgnoredFilesForLanguages(config) {
+ const sources = extractSources(config);
+
+ config.files.forEach(({ source, translation, ignore = [] }) => {
+ ignore.forEach(ignorePattern => {
+ let srcPattern = source
+ .replace(/^\//, '') // Strip the leading slash for the source path
+ .replace(/\*\*\/\*$/, ''); // strips the glob patter from the end
+ srcPattern += ignorePattern
+
+ glob(srcPattern, (err, files) => {
+ if (err) {
+ logMessage(`Error processing pattern ${srcPattern}: ${err.message}`);
+ return;
+ }
+
+ files.forEach(srcPath => {
+ languages.forEach(languageCode => {
+ const destPath = getTranslationPath(translation, languageCode, srcPath, sources);
+ copyFileOrDirectory(srcPath, destPath);
+ });
+ });
+ });
+ });
+ });
+}
+
+/**
+ * Main function to execute the workflow.
+ */
+function main() {
+ const config = readCrowdinConfig('crowdin.yaml');
+ copyIgnoredFilesForLanguages(config);
+ logMessage('Ignored files copied for all specified languages.');
+}
+
+// Execute the main function
+main();
diff --git a/scripts/fix_translations.sh b/scripts/fix_translations.sh
new file mode 100755
index 000000000..96f2655de
--- /dev/null
+++ b/scripts/fix_translations.sh
@@ -0,0 +1,4 @@
+#!/usr/bin/env sh
+
+perl -i -pe's/\s\{/ \\{/g' i18n/es/docusaurus-plugin-content-docs/current/learn/fundamentals/transactions/list-of-operations.mdx
+perl -i -pe's/<\s(.*\.mdx)>/\1/' i18n/es/docusaurus-plugin-content-docs-ap/**/admin-guide/component/observer/observer.mdx
diff --git a/src/components/AttributeTable/ListItem/index.js b/src/components/AttributeTable/ListItem/index.js
index bf98a5c24..7d06d4ae5 100644
--- a/src/components/AttributeTable/ListItem/index.js
+++ b/src/components/AttributeTable/ListItem/index.js
@@ -4,6 +4,7 @@ import Details from "@theme/Details";
import { combineAdjacentStrings, partition } from "@site/src/helpers";
import styles from "./styles.module.scss";
+import Translate from "@docusaurus/Translate";
export const ListItem = (props) => {
const children = props.children.props.children.filter((child) => child !== "\n");
@@ -39,7 +40,15 @@ export const ListItem = (props) => {
{description}
{collapsedList.length > 0 && (
-
Show child attributes}>
+
+
+ Show child attributes
+
+
+ }>
{collapsedList}
)}
diff --git a/src/components/CanvasFeeGraphs/index.tsx b/src/components/CanvasFeeGraphs/index.tsx
index a8f500d83..d387be451 100644
--- a/src/components/CanvasFeeGraphs/index.tsx
+++ b/src/components/CanvasFeeGraphs/index.tsx
@@ -2,11 +2,20 @@ import React from 'react';
import BrowserOnly from '@docusaurus/BrowserOnly';
import styles from './styles.module.css';
+import Translate from '@docusaurus/Translate';
+
+const translatedLoading = (
+
+ Loading...
+
+)
export default function CanvasEmbed() {
return (
- Loading...
}>
+ {translatedLoading}