From e7eb0ec7f05d542319fb3fc05174280ede29dc06 Mon Sep 17 00:00:00 2001
From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com>
Date: Wed, 29 Apr 2026 02:23:05 -0400
Subject: [PATCH 1/7] Improve docs note admonitions
---
docs/build/apps/wallet/sep30.mdx | 6 +++++-
.../hubble/data-catalog/data-dictionary/silver/README.mdx | 6 +++++-
.../scheduling-and-orchestration/getting-started.mdx | 6 +++++-
.../horizon/api-reference/aggregations/fee-stats/object.mdx | 6 +++++-
.../build-your-own/galexie/admin_guide/prerequisites.mdx | 6 +++++-
.../errors-and-debugging/debugging-errors.mdx | 6 +++++-
.../fundamentals/contract-development/rust-dialect.mdx | 6 +++++-
docs/networks/software-versions.mdx | 6 +++++-
8 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/docs/build/apps/wallet/sep30.mdx b/docs/build/apps/wallet/sep30.mdx
index 3d5d930534..27806ce8b1 100644
--- a/docs/build/apps/wallet/sep30.mdx
+++ b/docs/build/apps/wallet/sep30.mdx
@@ -496,7 +496,11 @@ The lost device key is deduced automatically if not given. A signer will be cons
Note that the account created above will match the first criteria. If 2-3 schema were used, then second criteria would match. (In 2-3 schema, 3 serves are used and 2 of them is enough to recover key. This is a recommended approach.)
-Note: you can also use more low-level `signWithRecoveryServers` functions to sign arbitrary transaction.
+:::note
+
+You can also use more low-level `signWithRecoveryServers` functions to sign arbitrary transaction.
+
+:::
Finally, it's time to submit the transaction:
diff --git a/docs/data/analytics/hubble/data-catalog/data-dictionary/silver/README.mdx b/docs/data/analytics/hubble/data-catalog/data-dictionary/silver/README.mdx
index 6d2cd2af9c..0d5fa4499e 100644
--- a/docs/data/analytics/hubble/data-catalog/data-dictionary/silver/README.mdx
+++ b/docs/data/analytics/hubble/data-catalog/data-dictionary/silver/README.mdx
@@ -23,6 +23,10 @@ These tables are especially useful for answering historical questions such as:
- How did an account, trustline, or balance evolve across different periods?
- Which liquidity pools were active at a given date, and how did their properties change over time?
-> **_NOTE:_** Daily Snapshot Frequency: Snapshots run on a daily basis, meaning they capture inter-day changes, but not multiple changes that occur within the same day.
+:::note Daily Snapshot Frequency
+
+Snapshots run on a daily basis, meaning they capture inter-day changes, but not multiple changes that occur within the same day.
+
+:::
diff --git a/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx b/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx
index 52ae47ba8f..a5bae9ac05 100644
--- a/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx
+++ b/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx
@@ -13,7 +13,11 @@ import dbt_enriched_base_tables from "/img/hubble/dbt_enriched_base_tables.png";
The Stellar Development Foundation runs Hubble in GCP using Composer and BigQuery. To follow the same deployment you will need to have access to GCP project. Instructions can be found in the [Get Started](https://cloud.google.com/docs/get-started) documentation from Google.
-Note: BigQuery and Composer should be available by default. If they are not you can find instructions for enabling them in the [BigQuery](https://cloud.google.com/bigquery?hl=en) or [Composer](https://cloud.google.com/composer?hl=en) Google documentation.
+:::note
+
+BigQuery and Composer should be available by default. If they are not you can find instructions for enabling them in the [BigQuery](https://cloud.google.com/bigquery?hl=en) or [Composer](https://cloud.google.com/composer?hl=en) Google documentation.
+
+:::
## Create GCP Composer Instance to Run Airflow
diff --git a/docs/data/apis/horizon/api-reference/aggregations/fee-stats/object.mdx b/docs/data/apis/horizon/api-reference/aggregations/fee-stats/object.mdx
index 5b1667703d..a46394f84f 100644
--- a/docs/data/apis/horizon/api-reference/aggregations/fee-stats/object.mdx
+++ b/docs/data/apis/horizon/api-reference/aggregations/fee-stats/object.mdx
@@ -5,7 +5,11 @@ sidebar_position: 20
When Horizon returns fee stats, it uses the format below.
-Note: The `fee_charged` represents the actual fee paid for the transaction, while `max_fee` represents the maximum bid the transaction creator was willing to pay for the transaction.
+:::note
+
+The `fee_charged` represents the actual fee paid for the transaction, while `max_fee` represents the maximum bid the transaction creator was willing to pay for the transaction.
+
+:::
diff --git a/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx b/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx
index a5b29940e9..8d87b800eb 100644
--- a/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx
+++ b/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx
@@ -30,7 +30,11 @@ Galexie exports Stellar ledger metadata to Google Cloud Storage (GCS) or Amazon
- Instance like AWS EC2 or GCP VM
- Any host machine with a OCI complaint container runtime installed like Docker ([Docker installation guide](https://docs.docker.com/engine/install/)).
-> **_NOTE:_** While it is possible to natively install Galexie (without a container runtime), this requires manual dependency management and is recommended only for advanced users.
+:::note
+
+While it is possible to natively install Galexie (without a container runtime), this requires manual dependency management and is recommended only for advanced users.
+
+:::
## Hardware Requirements
diff --git a/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx b/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx
index 60c60bb1ae..6df0cbe917 100644
--- a/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx
+++ b/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx
@@ -87,7 +87,11 @@ When an error occurs, the Core stores a few error-related fields in the transact
- If the Core instance producing meta has Soroban diagnostics enabled (which it usually should), the meta will also contain diagnostic events with more detailed error information.
- Note that there might be a few gaps in diagnostic event coverage. Since this is not a protocol change, Core may add more diagnostic events in future releases.
-Note: $OPERATION here refers to any one of the Soroban operations: `INVOKE_HOST_FUNCTION`, `RESTORE_FOOTPRINT`, and `EXTEND_FOOTPRINT_TTL`.
+:::note
+
+`$OPERATION` here refers to any one of the Soroban operations: `INVOKE_HOST_FUNCTION`, `RESTORE_FOOTPRINT`, and `EXTEND_FOOTPRINT_TTL`.
+
+:::
| Error and Diagnostics | Explanation | Fix |
| --- | --- | --- |
diff --git a/docs/learn/fundamentals/contract-development/rust-dialect.mdx b/docs/learn/fundamentals/contract-development/rust-dialect.mdx
index 17d9a7d63d..8c0c8b006d 100644
--- a/docs/learn/fundamentals/contract-development/rust-dialect.mdx
+++ b/docs/learn/fundamentals/contract-development/rust-dialect.mdx
@@ -10,7 +10,11 @@ For this reason it makes sense to consider code written for contracts to be a _d
These constraints and priorities are _similar_ to those encountered when writing Rust code for "embedded systems", and the tools, libraries and techniques used in the "contract dialect" are frequently borrowed from the [Rust embedded systems community](https://docs.rust-embedded.org/book/index.html), and by default contracts are recommended to be built with the [`#[no_std]` mode](https://docs.rust-embedded.org/book/intro/no-std.html) that excludes the Rust standard library entirely, relying on the smaller underlying `core` library instead.
-Note: these constraints and priorities are **not enforced when building in local-testing mode**, and in fact local contract tests will _frequently_ use facilities -- to generate test input, inspect test output, and guide testing -- that are not supported in the deployment guest environment. Developers **must understand** the difference between code that is compiled-in to Wasm modules for deployment and code that is conditionally compiled for testing. See [debugging contracts](./errors-and-debugging/debugging.mdx) for more details.
+:::note
+
+These constraints and priorities are **not enforced when building in local-testing mode**, and in fact local contract tests will _frequently_ use facilities -- to generate test input, inspect test output, and guide testing -- that are not supported in the deployment guest environment. Developers **must understand** the difference between code that is compiled-in to Wasm modules for deployment and code that is conditionally compiled for testing. See [debugging contracts](./errors-and-debugging/debugging.mdx) for more details.
+
+:::
The "contract dialect" has the following characteristics:
diff --git a/docs/networks/software-versions.mdx b/docs/networks/software-versions.mdx
index c4576342f2..c0cadb0e3f 100644
--- a/docs/networks/software-versions.mdx
+++ b/docs/networks/software-versions.mdx
@@ -333,7 +333,11 @@ Key protocol-related changes:
#### Stellar CLI (Previously Soroban CLI)
-Note: Soroban CLI has been renamed to Stellar CLI.
+:::note
+
+Soroban CLI has been renamed to Stellar CLI.
+
+:::
- Add stellar-cli crate alongside soroban-cli
- Rename to stellar-cli
From 9fdf97b37ba8e7ed8894c6c331a9662bf9375e0b Mon Sep 17 00:00:00 2001
From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com>
Date: Wed, 29 Apr 2026 02:35:39 -0400
Subject: [PATCH 2/7] Fix compliant typo in docs
---
.../analytics/hubble/data-catalog/data-dictionary/README.mdx | 2 +-
.../indexers/build-your-own/galexie/admin_guide/installing.mdx | 2 +-
.../build-your-own/galexie/admin_guide/prerequisites.mdx | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/data/analytics/hubble/data-catalog/data-dictionary/README.mdx b/docs/data/analytics/hubble/data-catalog/data-dictionary/README.mdx
index 651f2d4c2a..19b95d60c3 100644
--- a/docs/data/analytics/hubble/data-catalog/data-dictionary/README.mdx
+++ b/docs/data/analytics/hubble/data-catalog/data-dictionary/README.mdx
@@ -8,7 +8,7 @@ import DocCardList from "@theme/DocCardList";
Hubble data is organized into bronze, silver, and gold sections.
- Bronze 🥉 - raw, untransformed data from the Stellar network (e.g., history_contract_events contains all Stellar events)
-- Silver 🥈 - decoded, transformed, and filtered data (e.g., token_transfers contains SEP-41 complaint Stellar events)
+- Silver 🥈 - decoded, transformed, and filtered data (e.g., token_transfers contains SEP-41-compliant Stellar events)
- Gold 🥇 - Curated analytics with friendly aggregate tables (e.g., tvl_agg aggregates the relevant amounts in Stellar events)
diff --git a/docs/data/indexers/build-your-own/galexie/admin_guide/installing.mdx b/docs/data/indexers/build-your-own/galexie/admin_guide/installing.mdx
index 9d83f777d8..9543120ab9 100644
--- a/docs/data/indexers/build-your-own/galexie/admin_guide/installing.mdx
+++ b/docs/data/indexers/build-your-own/galexie/admin_guide/installing.mdx
@@ -16,7 +16,7 @@ Additional configuration can be set with the `--set` flags or by using a [helm v
## Install Container on a host
-To pull the Galexie container image from the [Stellar Docker Hub registry](https://hub.docker.com/r/stellar/stellar-galexie) using the following docker command or a similar OCI compliant image pull command:
+To pull the Galexie container image from the [Stellar Docker Hub registry](https://hub.docker.com/r/stellar/stellar-galexie) using the following docker command or a similar OCI-compliant image pull command:
```shell
docker pull stellar/stellar-galexie
diff --git a/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx b/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx
index 8d87b800eb..4103c1a143 100644
--- a/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx
+++ b/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx
@@ -28,7 +28,7 @@ Galexie exports Stellar ledger metadata to Google Cloud Storage (GCS) or Amazon
### Running the Galexie Container on an Instance
- Instance like AWS EC2 or GCP VM
-- Any host machine with a OCI complaint container runtime installed like Docker ([Docker installation guide](https://docs.docker.com/engine/install/)).
+- Any host machine with an OCI-compliant container runtime installed like Docker ([Docker installation guide](https://docs.docker.com/engine/install/)).
:::note
From 6649c1c280ce40638a219c775bafe506cfe2a7e4 Mon Sep 17 00:00:00 2001
From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com>
Date: Wed, 29 Apr 2026 02:37:05 -0400
Subject: [PATCH 3/7] Fix Hubble GCP setup wording
---
.../scheduling-and-orchestration/getting-started.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx b/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx
index a5bae9ac05..81b1c4c89f 100644
--- a/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx
+++ b/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx
@@ -11,7 +11,7 @@ import dbt_enriched_base_tables from "/img/hubble/dbt_enriched_base_tables.png";
## GCP Account Setup
-The Stellar Development Foundation runs Hubble in GCP using Composer and BigQuery. To follow the same deployment you will need to have access to GCP project. Instructions can be found in the [Get Started](https://cloud.google.com/docs/get-started) documentation from Google.
+SDF runs Hubble in GCP using Composer and BigQuery. To follow the same deployment you will need to have access to a GCP project. Instructions can be found in the [Get Started](https://cloud.google.com/docs/get-started) documentation from Google.
:::note
From ba2dd9b3ae1e456e6e4e9b43d07f5a8404dd0ea0 Mon Sep 17 00:00:00 2001
From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com>
Date: Wed, 29 Apr 2026 02:38:02 -0400
Subject: [PATCH 4/7] Fix SEP-30 recovery server typo
---
docs/build/apps/wallet/sep30.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/build/apps/wallet/sep30.mdx b/docs/build/apps/wallet/sep30.mdx
index 27806ce8b1..cfc6b226e4 100644
--- a/docs/build/apps/wallet/sep30.mdx
+++ b/docs/build/apps/wallet/sep30.mdx
@@ -494,7 +494,7 @@ The lost device key is deduced automatically if not given. A signer will be cons
1. It's the only signer that's not in `serverAuth`.
2. All signers in `serverAuth` have the same weight, and the potential signer is the only one with a different weight.
-Note that the account created above will match the first criteria. If 2-3 schema were used, then second criteria would match. (In 2-3 schema, 3 serves are used and 2 of them is enough to recover key. This is a recommended approach.)
+Note that the account created above will match the first criteria. If a 2-3 schema were used, then the second criteria would match. (In a 2-3 schema, 3 servers are used and 2 of them are enough to recover the key. This is a recommended approach.)
:::note
From 8a5f316392ac0c224a5e803c41e781e8066cdf3c Mon Sep 17 00:00:00 2001
From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com>
Date: Wed, 29 Apr 2026 02:39:45 -0400
Subject: [PATCH 5/7] Fix plural verb agreement in docs
---
docs/build/apps/wallet/sep30.mdx | 2 +-
docs/build/guides/storage/choosing-the-right-storage.mdx | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/build/apps/wallet/sep30.mdx b/docs/build/apps/wallet/sep30.mdx
index cfc6b226e4..77dab0ca15 100644
--- a/docs/build/apps/wallet/sep30.mdx
+++ b/docs/build/apps/wallet/sep30.mdx
@@ -494,7 +494,7 @@ The lost device key is deduced automatically if not given. A signer will be cons
1. It's the only signer that's not in `serverAuth`.
2. All signers in `serverAuth` have the same weight, and the potential signer is the only one with a different weight.
-Note that the account created above will match the first criteria. If a 2-3 schema were used, then the second criteria would match. (In a 2-3 schema, 3 servers are used and 2 of them are enough to recover the key. This is a recommended approach.)
+Note that the account created above will match the first criteria. If 2-3 schema were used, then second criteria would match. (In 2-3 schema, 3 servers are used and 2 of them are enough to recover key. This is a recommended approach.)
:::note
diff --git a/docs/build/guides/storage/choosing-the-right-storage.mdx b/docs/build/guides/storage/choosing-the-right-storage.mdx
index 3ee802c7ec..1ccd159294 100644
--- a/docs/build/guides/storage/choosing-the-right-storage.mdx
+++ b/docs/build/guides/storage/choosing-the-right-storage.mdx
@@ -26,7 +26,7 @@ If you're wondering what 'TTL' means, here is a quick intro on TTLs and state ar
State archival is a special mechanism defined by the Stellar protocol that ensures that the active ledger state size doesn't grow indefinitely. In simple terms, every stored contract data entry, as well as contract code (Wasm) entry, has a certain 'time-to-live' (TTL) assigned. TTL is just a number of ledgers for which the entry is considered to be 'active', and after that number of ledgers, the entry is considered to have TTL expired and thus no longer active. Different storage types handle TTL expiration differently: data will either be moved to the archive ('cold', off-chain storage), or automatically removed from the ledger (in case of temporary storage). The data stored in the archive can be restored on-chain later and thus become active again.
-TTL also may be extended however many times is necessary, for a fee.
+TTL also may be extended however many times are necessary, for a fee.
Read more about state archival [here](../../../learn/fundamentals/contract-development/storage/state-archival.mdx).
From f5c5d309906661a1d1047701d2be431941a5816b Mon Sep 17 00:00:00 2001
From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com>
Date: Wed, 29 Apr 2026 02:44:10 -0400
Subject: [PATCH 6/7] Update Hubble docs wording
---
.../hubble/data-catalog/data-dictionary/README.mdx | 6 ------
.../scheduling-and-orchestration/getting-started.mdx | 2 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/docs/data/analytics/hubble/data-catalog/data-dictionary/README.mdx b/docs/data/analytics/hubble/data-catalog/data-dictionary/README.mdx
index 19b95d60c3..d512223f93 100644
--- a/docs/data/analytics/hubble/data-catalog/data-dictionary/README.mdx
+++ b/docs/data/analytics/hubble/data-catalog/data-dictionary/README.mdx
@@ -5,10 +5,4 @@ sidebar_position: 20
import DocCardList from "@theme/DocCardList";
-Hubble data is organized into bronze, silver, and gold sections.
-
-- Bronze 🥉 - raw, untransformed data from the Stellar network (e.g., history_contract_events contains all Stellar events)
-- Silver 🥈 - decoded, transformed, and filtered data (e.g., token_transfers contains SEP-41-compliant Stellar events)
-- Gold 🥇 - Curated analytics with friendly aggregate tables (e.g., tvl_agg aggregates the relevant amounts in Stellar events)
-
diff --git a/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx b/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx
index 81b1c4c89f..5eb25a0678 100644
--- a/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx
+++ b/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx
@@ -11,7 +11,7 @@ import dbt_enriched_base_tables from "/img/hubble/dbt_enriched_base_tables.png";
## GCP Account Setup
-SDF runs Hubble in GCP using Composer and BigQuery. To follow the same deployment you will need to have access to a GCP project. Instructions can be found in the [Get Started](https://cloud.google.com/docs/get-started) documentation from Google.
+[The SDF](../../../../../learn/glossary.mdx#stellar-development-foundation-sdf) runs Hubble in GCP using Composer and BigQuery. To follow the same deployment you will need to have access to a GCP project. Instructions can be found in the [Get Started](https://cloud.google.com/docs/get-started) documentation from Google.
:::note
From e00e0a2c45a6c5aac5e20c40b0977f92aa76a26c Mon Sep 17 00:00:00 2001
From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com>
Date: Wed, 29 Apr 2026 02:57:43 -0400
Subject: [PATCH 7/7] expand ba2dd9b3ae1e456e6e4e9b43d07f5a8404dd0ea0
---
docs/build/apps/wallet/sep30.mdx | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/build/apps/wallet/sep30.mdx b/docs/build/apps/wallet/sep30.mdx
index 77dab0ca15..5fe5593e05 100644
--- a/docs/build/apps/wallet/sep30.mdx
+++ b/docs/build/apps/wallet/sep30.mdx
@@ -494,11 +494,11 @@ The lost device key is deduced automatically if not given. A signer will be cons
1. It's the only signer that's not in `serverAuth`.
2. All signers in `serverAuth` have the same weight, and the potential signer is the only one with a different weight.
-Note that the account created above will match the first criteria. If 2-3 schema were used, then second criteria would match. (In 2-3 schema, 3 servers are used and 2 of them are enough to recover key. This is a recommended approach.)
-
:::note
-You can also use more low-level `signWithRecoveryServers` functions to sign arbitrary transaction.
+The account created above will match the first criteria. If a 2-3 schema were used, then the second criteria would match. (In a 2-3 schema, 3 servers are used and 2 of them are enough to recover the key. This is a recommended approach.)
+
+You can also use more low-level `signWithRecoveryServers` functions to sign arbitrary transactions.
:::