Lots of formatting

stellar · Feb 3, 2023 · b2643e7 · b2643e7
1 parent a7e6c5b
commit b2643e7
Show file tree

Hide file tree

Showing 11 changed files with 81 additions and 65 deletions.
diff --git a/docs/faq.mdx b/docs/faq.mdx
@@ -10,32 +10,41 @@ Soroban's Stellar integration is under active-development and may change.
 :::
 
 ### What is Soroban to Stellar? Is it a new blockchain?
-Soroban is not a new blockchain. Soroban is a Smart contract platform that is integrated into the existing Stellar blockchain. It is an *additive* feature that lives alongside, and doesn't replace, the existing set of Stellar operations. 
+
+Soroban is not a new blockchain. Soroban is a Smart contract platform that is integrated into the existing Stellar blockchain. It is an _additive_ feature that lives alongside, and doesn't replace, the existing set of Stellar operations.
 
 ### How do I invoke a Soroban contract on Stellar?
+
 A Soroban contract can be invoked by submitting a transaction that contains the new operation: `InvokeContractOp`.
 
 ### Can Soroban contracts use Stellar accounts for authentication?
-Yes. Stellar accounts are shared with Soroban. Smart contacts have access to Stellar account signer configuration and know the source account that directly invoked them in a transaction. Check out the Auth and Advanced Auth examples for more information.  
+
+Yes. Stellar accounts are shared with Soroban. Smart contacts have access to Stellar account signer configuration and know the source account that directly invoked them in a transaction. Check out the Auth and Advanced Auth examples for more information.
 
 ### Can Soroban contracts interact with Stellar Assets?
+
 Yes. Soroban contains a built-in Stellar Asset Contract that is able to interact
 with classic trustlines. Read more about this [here](built-in-contracts/stellar-asset-contract.mdx).
 
 ### Do Issuers of Stellar Assets maintain their authorization over an asset that has been sent to a non-account identifer in Soroban? (AUTH_REQUIRED, AUTH_REVOCABLE, AUTH_CLAWBACK)
+
 Yes. Issuers retain the same level of control on Soroban as they have on Classic. This functionality is accessible through a set of admin functions (clawback, set_auth) on the built-in Stellar Asset Contract.
 
 ### Can Soroban contracts interact with any other Stellar operations?
-No. Aside from the interactions with Accounts and Assets as mentioned above. This means that Soroban contracts can not interact with SDEX, AMMs, Claimable Balances or Sponsorships.  
+
+No. Aside from the interactions with Accounts and Assets as mentioned above. This means that Soroban contracts can not interact with SDEX, AMMs, Claimable Balances or Sponsorships.
 
 ### Does the Stellar base reserve apply to Soroban contracts?
+
 No. Soroban has a different fee structure and ledger entries that are allocated by Soroban contracts do not add to an account's required minimal balance.
 
 ### Should I issue my token as a Stellar Asset or a custom Soroban token?
+
 We recommend, to the extent possible, issuing tokens as Stellar assets. These
 tokens will benefit from being interopable with the existing ecosystem of tools
 available in the Stellar ecosystem, as well as being more performant because the
 Stellar Asset Contract is built into the host.
 
 ### Haven't found what you're looking for?
+
 Join #soroban on the Stellar developer discord
diff --git a/docs/getting-started/quick-start.mdx b/docs/getting-started/quick-start.mdx
@@ -175,10 +175,9 @@ soroban invoke \
 You should see the following output:
 
 ```json
-["Hello","friend"]
+["Hello", "friend"]
 ```
 
 [`soroban-cli`]: setup#install-the-soroban-cli
-
 [Rust unit tests]: https://doc.rust-lang.org/rust-by-example/testing/unit_testing.html
 [Rust integration tests]: https://doc.rust-lang.org/rust-by-example/testing/integration_testing.html
diff --git a/docs/getting-started/setup.mdx b/docs/getting-started/setup.mdx
@@ -98,6 +98,5 @@ SUBCOMMANDS:
     completion    Print shell completion code for the specified shell
 ```
 
-
 [Rust]: https://www.rust-lang.org/
 [Soroban CLI]: setup#install-the-soroban-cli
diff --git a/docs/tutorials/build-optimized.mdx b/docs/tutorials/build-optimized.mdx
@@ -3,8 +3,8 @@ sidebar_position: 11
 title: Optimizing Builds
 ---
 
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
 
 Building optimized contracts to be as small as possible requires some additional
 tools, and requires installing the `nightly` Rust toolchain and `wasm-opt`.

diff --git a/docs/tutorials/create-a-project.mdx b/docs/tutorials/create-a-project.mdx
@@ -93,7 +93,7 @@ lto = true
 
 Configuring a `release-with-logs` profile can be useful for if you need to build
 a `.wasm` that has logs enabled for printing debug logs when using the
-[`soroban-cli`].  Note that this is not necessary to access debug logs in tests
+[`soroban-cli`]. Note that this is not necessary to access debug logs in tests
 or to use a step-through-debugger.
 
 Add the following to your `Cargo.toml` and use the `release-with-logs` profile

diff --git a/docs/tutorials/deploy-to-futurenet.mdx b/docs/tutorials/deploy-to-futurenet.mdx
@@ -29,6 +29,7 @@ docker run --rm -it \
 ```
 
 Once the image is started you can check its status by querying the Horizon API:
+
 ```sh
 curl http://localhost:8000
 ```
@@ -101,7 +102,7 @@ soroban invoke \
 The following output should appear.
 
 ```json
-["Hello","friend"]
+["Hello", "friend"]
 ```
 
 [Write a Contract]: write-a-contract

diff --git a/docs/tutorials/deploy-to-local-network.mdx b/docs/tutorials/deploy-to-local-network.mdx
@@ -10,11 +10,11 @@ The Quickstart image is a single container that runs everything you need to test
 against a fully featured network. It contains:
 
 - Stellar Core – Node software that runs the network, coordinates consensus, and
-finalizes ledgers.
+  finalizes ledgers.
 - Soroban RPC server – JSON RPC server for interacting with Soroban contracts.
 - Horizon server – HTTP API for access ledger state and historical transactions.
 - Friendbot server – HTTP API for creating and funding new accounts on test
-networks.
+  networks.
 
 :::info
 
@@ -36,6 +36,7 @@ docker run --rm -it \
 ```
 
 Once the image is started you can check its status by querying the Horizon API:
+
 ```sh
 curl http://localhost:8000
 ```
@@ -105,7 +106,7 @@ soroban invoke \
 The following output should appear.
 
 ```json
-["Hello","friend"]
+["Hello", "friend"]
 ```
 
 [Write a Contract]: write-a-contract

diff --git a/docs/tutorials/invoking-contracts-with-transactions.mdx b/docs/tutorials/invoking-contracts-with-transactions.mdx
@@ -6,8 +6,9 @@ title: Invoking and Creating Contracts with Stellar Transactions
 Stellar supports invoking and deploying contracts with a new Operation named `InvokeHostFunctionOp`. The [`soroban-cli`] abstracts these details away from the
 user, but SDKs do not yet and if you're building a dapp you'll probably find yourself building the XDR transaction to submit to the network.
 
-The `InvokeHostFunctionOp` can be used to perform the following Soroban 
+The `InvokeHostFunctionOp` can be used to perform the following Soroban
 operations:
+
 - Invoke contract functions.
 - Install WASM of the new contracts.
 - Deploy new contracts using the installed WASM or built-in implementations (
@@ -19,6 +20,7 @@ operations:
 
 The XDR of `HostFunction` and `InvokeHostFunctionOp` below can be found
 [here](https://github.com/stellar/stellar-xdr/blob/026c9cd074bdb28ddde8ee52f2a4502d9e518a09/Stellar-transaction.x#L523-L539)
+
 ```c++
 union HostFunction switch (HostFunctionType type)
 {
@@ -40,32 +42,34 @@ struct InvokeHostFunctionOp
 ```
 
 ### Function
-The `function` in `InvokeHostFunctionOp` will be executed by the Soroban host 
+
+The `function` in `InvokeHostFunctionOp` will be executed by the Soroban host
 environment. The function arguments are passed as function-dependent XDR. The
 options are:
+
 1. `HOST_FUNCTION_TYPE_INVOKE_CONTRACT`
    - This will call the `call_n` host function, invoking a contract function.
-   - `invokeArgs` is expected to contain the contract id, contract function 
-     name, and the parameters to the contract function being invoked. 
+   - `invokeArgs` is expected to contain the contract id, contract function
+     name, and the parameters to the contract function being invoked.
 2. `HOST_FUNCTION_TYPE_INSTALL_CONTRACT_CODE`
    - This will install the contract WASM using the provided `code` blob:
-    ```c++
-    struct InstallContractCodeArgs
-    {
-        opaque code<SCVAL_LIMIT>;
-    };
-    ```
+   ```c++
+   struct InstallContractCodeArgs
+   {
+       opaque code<SCVAL_LIMIT>;
+   };
+   ```
 3. `HOST_FUNCTION_TYPE_CREATE_CONTRACT`
    - This will create a contract instance in the network using the specified
      `source` and build a 32-byte contract identifer based on `contractID` value.
-    ```c++
-     struct CreateContractArgs
-     {
-        ContractID contractID;
-        SCContractCode source;
-     };
-     ```
-   - `source` can be either a reference to the hash of the installed WASM (to 
+   ```c++
+    struct CreateContractArgs
+    {
+       ContractID contractID;
+       SCContractCode source;
+    };
+   ```
+   - `source` can be either a reference to the hash of the installed WASM (to
      be more precise, a SHA-256 hash of the `InstallContractCodeArgs` from the operation above) or just specify that a built-in contract has to be used:
      ```c++
      union SCContractCode switch (SCContractCodeType type)
@@ -76,38 +80,40 @@ options are:
          void;
      };
      ```
-  - `contractID` is defined as following:
-    ```c++
-    union ContractID switch (ContractIDType type)
-    {
-    case CONTRACT_ID_FROM_SOURCE_ACCOUNT:
-        uint256 salt;
-    case CONTRACT_ID_FROM_ED25519_PUBLIC_KEY:
-        struct 
-        {
-            uint256 key;
-            Signature signature;
-            uint256 salt;
-        } fromEd25519PublicKey;
-    case CONTRACT_ID_FROM_ASSET:
-        Asset asset;
-    };
-    ```
-  - The parameters of this value define which the hash preimage that is then hashed
-  with SHA-256 to get the ID of the created contract.  
-  - `CONTRACT_ID_FROM_SOURCE_ACCOUNT` specifies that the contract ID will be created
-  using the Stellar source account and the provided salt. The contract ID 
+
+- `contractID` is defined as following:
+  ```c++
+  union ContractID switch (ContractIDType type)
+  {
+  case CONTRACT_ID_FROM_SOURCE_ACCOUNT:
+      uint256 salt;
+  case CONTRACT_ID_FROM_ED25519_PUBLIC_KEY:
+      struct
+      {
+          uint256 key;
+          Signature signature;
+          uint256 salt;
+      } fromEd25519PublicKey;
+  case CONTRACT_ID_FROM_ASSET:
+      Asset asset;
+  };
+  ```
+- The parameters of this value define which the hash preimage that is then hashed
+  with SHA-256 to get the ID of the created contract.
+- `CONTRACT_ID_FROM_SOURCE_ACCOUNT` specifies that the contract ID will be created
+  using the Stellar source account and the provided salt. The contract ID
   preimage used is [`ENVELOPE_TYPE_CONTRACT_ID_FROM_SOURCE_ACCOUNT`](https://github.com/stellar/stellar-xdr/blob/026c9cd074bdb28ddde8ee52f2a4502d9e518a09/Stellar-transaction.x#L643-L649).
-  - `CONTRACT_ID_FROM_ASSET` specifies that the contract will be created using
-    the Stellar asset. This is only suported when 
-    `source == SCCONTRACT_CODE_TOKEN`. Note, that the asset doesn't need to exist
-    when this is applied, however the issuer of the asset will be the initial
-    token administrator. The contract ID preimage used is [`ENVELOPE_TYPE_CONTRACT_ID_FROM_ASSET`](https://github.com/stellar/stellar-xdr/blob/026c9cd074bdb28ddde8ee52f2a4502d9e518a09/Stellar-transaction.x#L637-L642).
-  - `CONTRACT_ID_FROM_ED25519_PUBLIC_KEY` specified that the contract will be
+- `CONTRACT_ID_FROM_ASSET` specifies that the contract will be created using
+  the Stellar asset. This is only suported when
+  `source == SCCONTRACT_CODE_TOKEN`. Note, that the asset doesn't need to exist
+  when this is applied, however the issuer of the asset will be the initial
+  token administrator. The contract ID preimage used is [`ENVELOPE_TYPE_CONTRACT_ID_FROM_ASSET`](https://github.com/stellar/stellar-xdr/blob/026c9cd074bdb28ddde8ee52f2a4502d9e518a09/Stellar-transaction.x#L637-L642).
+- `CONTRACT_ID_FROM_ED25519_PUBLIC_KEY` specified that the contract will be
   created using a public ED25519 key. Since this operation is not tied to any
-  on-chain entity, this also has to contain an ED25519 signature of SHA256 hash of [`ENVELOPE_TYPE_CREATE_CONTRACT_ARGS`](https://github.com/stellar/stellar-xdr/blob/026c9cd074bdb28ddde8ee52f2a4502d9e518a09/Stellar-transaction.x#L650-L656) XDR 
+  on-chain entity, this also has to contain an ED25519 signature of SHA256 hash of [`ENVELOPE_TYPE_CREATE_CONTRACT_ARGS`](https://github.com/stellar/stellar-xdr/blob/026c9cd074bdb28ddde8ee52f2a4502d9e518a09/Stellar-transaction.x#L650-L656) XDR
   preimage. The contract ID preimage used is [`ENVELOPE_TYPE_CONTRACT_ID_FROM_ED25519`](https://github.com/stellar/stellar-xdr/blob/026c9cd074bdb28ddde8ee52f2a4502d9e518a09/Stellar-transaction.x#L623-L629).
 
 ### Footprint
+
 The footprint must contain the `LedgerKeys` that will be read and/or written. More
-information about the footprint can be found in the advanced section of [interacting with contracts](../learn/interacting-with-contracts#storage-footprint-and-preflight).
+information about the footprint can be found in the advanced section of [interacting with contracts](../learn/interacting-with-contracts#storage-footprint-and-preflight).
diff --git a/docs/tutorials/run-on-sandbox.mdx b/docs/tutorials/run-on-sandbox.mdx
@@ -12,7 +12,7 @@ find on a Stellar network.
 
 :::info
 
-It's also possible to run a contract on a fully featured local network.  See
+It's also possible to run a contract on a fully featured local network. See
 [Deploy to a Local Network] for more details.
 
 :::
@@ -32,7 +32,7 @@ soroban invoke \
 The following output should appear.
 
 ```json
-["Hello","friend"]
+["Hello", "friend"]
 ```
 
 [Write a Contract]: write-a-contract

diff --git a/docs/tutorials/testing.mdx b/docs/tutorials/testing.mdx
@@ -3,8 +3,8 @@ sidebar_position: 5
 title: Testing
 ---
 
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
 
 Writing tests for Soroban contracts involves writing Rust code using the test
 facilities and toolchain that you'd use for testing any Rust code.
@@ -55,7 +55,6 @@ fn test() {
 }
 ```
 
-
 </TabItem>
 </Tabs>
 
@@ -86,6 +85,7 @@ let words = client.hello(&symbol!("Dev"));
 ```
 
 The values returned by functions can be asserted on:
+
 ```rust
 assert_eq!(
     words,

diff --git a/docs/tutorials/write-a-contract.mdx b/docs/tutorials/write-a-contract.mdx
@@ -61,4 +61,5 @@ impl Contract {
     }
 }
 ```
+
 [Create a Project]: create-a-project.mdx
-Original file line number
+Diff line change
@@ Expand Up / @@ -61,4 +61,5 @@ impl Contract { @@
         }
     }
     ```
     [Create a Project]: create-a-project.mdx