diff --git a/docs/build/apps/wallet/sep30.mdx b/docs/build/apps/wallet/sep30.mdx index 3d5d930534..5fe5593e05 100644 --- a/docs/build/apps/wallet/sep30.mdx +++ b/docs/build/apps/wallet/sep30.mdx @@ -494,9 +494,13 @@ 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 -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. + +::: Finally, it's time to submit the transaction: 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). 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..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 complaint 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/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..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,9 +11,13 @@ 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. +[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: 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/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 a5b29940e9..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,9 +28,13 @@ 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:_** 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