Changing "Soroban CLI" to "Stellar CLI"

docs/learn/fundamentals/stellar-data-structures/assets.mdx

@@ -29,7 +29,7 @@ The public key of the issuing account is linked on the ledger to the asset. Resp
 
 Assets issued on the Stellar network are accessible to smart contracts. Every Stellar asset has reserved a Stellar Asset Contract that can be deployed by anyone who wants to be able to interact with the asset from a contract.
 
-The Soroban CLI can deploy a Stellar Asset Contract for a Stellar asset. Deploying the Stellar Asset Contract for a Stellar asset enables that asset for use with smart contracts.
+The Stellar CLI can deploy a Stellar Asset Contract for a Stellar asset. Deploying the Stellar Asset Contract for a Stellar asset enables that asset for use with smart contracts.
 
 Learn more in the [SAC section](../../../smart-contracts/tokens/stellar-asset-contract.mdx).
 

docs/learn/smart-contract-internals/contract-interactions/stellar-transaction.mdx

@@ -384,7 +384,7 @@ The `InvokeHostFunctionOp` can be used to perform the following Soroban operatio
 - Upload Wasm of the new contracts.
 - Deploy new contracts using the uploaded Wasm or built-in implementations (this currently includes only the [token contract](../../../smart-contracts/tokens/stellar-asset-contract.mdx)).
 
-[`soroban-cli`]: /docs/smart-contracts/getting-started/setup.mdx#install-the-soroban-cli
+[`stellar-cli`]: /docs/smart-contracts/getting-started/setup.mdx#install-the-stellar-cli
 
 There is only a single `InvokeHostFunctionOp` allowed per transaction. Contracts should be used to perform multiple actions atomically, for example, to deploy a new contract and initialize it atomically.
 

docs/learn/smart-contract-internals/types/fully-typed-contracts.mdx

@@ -25,13 +25,13 @@ When you compile a contract created with [soroban-sdk](../../../tools/sdks/libra
 
 Today, these interface types are formatted using [XDR](../../encyclopedia/xdr.mdx), but this [may change](https://github.com/stellar/rs-soroban-sdk/issues/683) down the road.
 
-The important part is that tooling can fetch these interface types to make your life easier. [Soroban CLI](../../../tools/developer-tools.mdx#cli) is the first tool to do so. Specifically, one subcommand:
+The important part is that tooling can fetch these interface types to make your life easier. [Stellar CLI](../../../tools/developer-tools.mdx#cli) is the first tool to do so. Specifically, one subcommand:
 
 ## `soroban contract invoke`
 
 Really, every smart contract is its own program, and deserves its own CLI.
 
-So that's what Soroban CLI gives you.
+So that's what Stellar CLI gives you.
 
 A unique CLI for each smart contract. Constructed on-the-fly, right from the on-chain interface types. Including the author's comments. An _implicit CLI_.
 
@@ -69,7 +69,7 @@ Options:
   -h, --help  Print help
 ```
 
-Like any other CLI, you can also get help for any of these subcommands using something like `native balance --help`. Soroban CLI again fetches the on-chain interface types, this time using it to generate a full list of all arguments to the function, and even generates examples.
+Like any other CLI, you can also get help for any of these subcommands using something like `native balance --help`. Stellar CLI again fetches the on-chain interface types, this time using it to generate a full list of all arguments to the function, and even generates examples.
 
 :::tip
 
@@ -83,13 +83,13 @@ soroban contract invoke --network testnet --id CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIX
 
 If you're unfamiliar with the `--` double dash separator, this is a pattern used by other CLIs. Everything after the double dash, sometimes called the [slop](https://github.com/clap-rs/clap/issues/971), gets passed to the child process. An example of another CLI that makes use of this is `cargo run`.
 
-Of course, the exact way that that Soroban CLI parses arguments is an ongoing design discussion. Representing complex custom arguments on the command line is a design challenge no blockchain CLI gets perfect yet; many, including Soroban CLI, currently use JSON. But this has downsides, and other options are possible. [How would you like to see it work?](https://docs.google.com/document/d/1LASaLyxIA2-YqLnn2NqI5NZGnEmdzx9lLh-j7n0-i4A/edit#)
+Of course, the exact way that that Stellar CLI parses arguments is an ongoing design discussion. Representing complex custom arguments on the command line is a design challenge no blockchain CLI gets perfect yet; many, including Stellar CLI, currently use JSON. But this has downsides, and other options are possible. [How would you like to see it work?](https://docs.google.com/document/d/1LASaLyxIA2-YqLnn2NqI5NZGnEmdzx9lLh-j7n0-i4A/edit#)
 
 ## Already the best; just getting started
 
 We love that Soroban will have all contract interface types available on-chain right from day one. No secondary API calls to external services, no secondary API token management, no signing in or creating an account anywhere else, and near-perfect reliability. It's a game-changer within the blockchain space.
 
-Soroban CLI already shows how this can be built into foundational tooling to give developers delightful experiences. And this is only the beginning. At every level of the stack, you can expect—and [build](https://stellar.org/foundation/grants-and-funding)—tooling that makes interacting with any contract predictable and seamless.
+Stellar CLI already shows how this can be built into foundational tooling to give developers delightful experiences. And this is only the beginning. At every level of the stack, you can expect—and [build](https://stellar.org/foundation/grants-and-funding)—tooling that makes interacting with any contract predictable and seamless.
 
 Soon we'll have TypeScript/JavaScript libraries that mirror the behavior of `soroban contract invoke`, customized for browser & nodejs environments. You can expect GUIs that adapt to any given contract on-the-fly, functioning as interactive documentation. If you're writing contracts that make cross-contract calls, most of the code you need can also be auto-generated.
 

docs/smart-contracts/example-contracts/TEMPLATE.mdx

@@ -145,14 +145,14 @@ target/wasm32-unknown-unknown/release/soroban_hello_world_contract.wasm
 
 ## Run the Contract
 
-If you have [`soroban-cli`] installed, you can invoke contract functions using it.
+If you have [`stellar-cli`] installed, you can invoke contract functions using it.
 
 <Tabs groupId="platform" defaultValue={getPlatform()}>
 
 <TabItem value="unix" label="macOS/Linux">
 
 ```sh
-soroban contract invoke \
+stellar contract invoke \
     --wasm target/wasm32-unknown-unknown/release/soroban_hello_world_contract.wasm \
     --id 1 \
     -- \
@@ -165,7 +165,7 @@ soroban contract invoke \
 <TabItem value="windows" label="Windows (PowerShell)">
 
 ```powershell
-soroban contract invoke `
+stellar contract invoke `
     --wasm target/wasm32-unknown-unknown/release/soroban_hello_world_contract.wasm `
     --id 1 `
     -- `
@@ -177,7 +177,7 @@ soroban contract invoke `
 
 </Tabs>
 
-[`soroban-cli`]: ../getting-started/setup.mdx#install-the-soroban-cli
+[`stellar-cli`]: ../getting-started/setup.mdx#install-the-stellar-cli
 
 ## Further Reading
 

docs/smart-contracts/example-contracts/auth.mdx

@@ -273,10 +273,10 @@ assert_eq!(client.increment(&user_2, &4), 5);
 
 ## Build the Contract
 
-To build the contract into a `.wasm` file, use the `soroban contract build` command.
+To build the contract into a `.wasm` file, use the `stellar contract build` command.
 
 ```sh
-soroban contract build
+stellar contract build
 ```
 
 The `.wasm` file should be found in the `target` directory after building:
@@ -287,15 +287,15 @@ target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm
 
 ## Run the Contract
 
-If you have [`soroban-cli`] installed, you can invoke functions on the contract.
+If you have [`stellar-cli`] installed, you can invoke functions on the contract.
 
 But since we are dealing with authorization and signatures, we need to set up some identities to use for testing and get their public keys:
 
 ```sh
-soroban keys generate acc1
-soroban keys generate acc2
-soroban keys address acc1
-soroban keys address acc2
+stellar keys generate acc1
+stellar keys generate acc2
+stellar keys address acc1
+stellar keys address acc2
 ```
 
 Example output with two public keys of identities:
@@ -305,14 +305,14 @@ GA6S566FD3EQDUNQ4IGSLXKW3TGVSTQW3TPHPGS7NWMCEIPBOKTNCSRU
 GAJGHZ44IJXYFNOVRZGBCVKC2V62DB2KHZB7BEMYOWOLFQH4XP2TAM6B
 ```
 
-Now the contract itself can be invoked. Notice the `--source` must be the identity name matching the address passed to the `--user` argument. This allows `soroban` tool to automatically sign the necessary payload for the invocation.
+Now the contract itself can be invoked. Notice the `--source` must be the identity name matching the address passed to the `--user` argument. This allows `Stellar CLI` to automatically sign the necessary payload for the invocation.
 
 <Tabs groupId="platform" defaultValue={getPlatform()}>
 
 <TabItem value="unix" label="macOS/Linux">
 
 ```sh
-soroban contract invoke \
+stellar contract invoke \
     --source acc1 \
     --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm \
     --id 1 \
@@ -327,7 +327,7 @@ soroban contract invoke \
 <TabItem value="windows" label="Windows (PowerShell)">
 
 ```powershell
-soroban contract invoke `
+stellar contract invoke `
     --source acc1 `
     --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm `
     --id 1 `
@@ -348,7 +348,7 @@ Run a few more increments for both accounts.
 <TabItem value="unix" label="macOS/Linux">
 
 ```sh
-soroban contract invoke \
+stellar contract invoke \
     --source acc2 \
     --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm \
     --id 1 \
@@ -359,7 +359,7 @@ soroban contract invoke \
 ```
 
 ```sh
-soroban contract invoke \
+stellar contract invoke \
     --source acc1 \
     --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm \
     --id 1 \
@@ -370,7 +370,7 @@ soroban contract invoke \
 ```
 
 ```sh
-soroban contract invoke \
+stellar contract invoke \
     --source acc2 \
     --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm \
     --id 1 \
@@ -385,7 +385,7 @@ soroban contract invoke \
 <TabItem value="windows" label="Windows (PowerShell)">
 
 ```powershell
-soroban contract invoke \
+stellar contract invoke \
     --source acc2 \
     --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm \
     --id 1 \
@@ -396,7 +396,7 @@ soroban contract invoke \
 ```
 
 ```powershell
-soroban contract invoke \
+stellar contract invoke \
     --source acc1 \
     --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm \
     --id 1 \
@@ -407,7 +407,7 @@ soroban contract invoke \
 ```
 
 ```powershell
-soroban contract invoke \
+stellar contract invoke \
     --source acc2 \
     --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm \
     --id 1 \
@@ -421,10 +421,10 @@ soroban contract invoke \
 
 </Tabs>
 
-View the data that has been stored against each user with `soroban contract read`.
+View the data that has been stored against each user with `stellar contract read`.
 
 ```sh
-soroban contract read --id 1
+stellar contract read --id 1
 ```
 
 ```
@@ -439,7 +439,7 @@ It is also possible to preview the authorization payload that is being signed by
 <TabItem value="unix" label="macOS/Linux">
 
 ```sh
-soroban contract invoke \
+stellar contract invoke \
     --source acc2 \
     --auth \
     --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm \
@@ -455,7 +455,7 @@ soroban contract invoke \
 <TabItem value="windows" label="Windows (PowerShell)">
 
 ```powershell
-soroban contract invoke `
+stellar contract invoke `
     --source acc2 `
     --auth `
     --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm `
@@ -474,7 +474,7 @@ soroban contract invoke `
 Contract auth: [{"address_with_nonce":null,"root_invocation":{"contract_id":"0000000000000000000000000000000000000000000000000000000000000001","function_name":"increment","args":[{"object":{"address":{"account":{"public_key_type_ed25519":"c7bab0288753d58d3e21cc3fa68cd2546b5f78ae6635a6f1b3fe07e03ee846e9"}}}},{"u32":123}],"sub_invocations":[]},"signature_args":[]}]
 ```
 
-[`soroban-cli`]: ../getting-started/setup.mdx#install-the-soroban-cli
+[`stellar-cli`]: ../getting-started/setup.mdx#install-the-stellar-cli
 
 ## Further reading
 

docs/smart-contracts/example-contracts/cross-contract-call.mdx

@@ -225,10 +225,10 @@ assert_eq!(sum, 12);
 
 ## Build the Contracts
 
-To build the contract into a `.wasm` file, use the `soroban contract build` command. Both `contract_call/contract_a` and `contract_call/contract_b` must be built, with `contract_a` being built first.
+To build the contract into a `.wasm` file, use the `stellar contract build` command. Both `contract_call/contract_a` and `contract_call/contract_b` must be built, with `contract_a` being built first.
 
 ```sh
-soroban contract build
+stellar contract build
 ```
 
 Both `.wasm` files should be found in both contract `target` directories after building both contracts:
@@ -243,20 +243,20 @@ target/wasm32-unknown-unknown/release/soroban_cross_contract_b_contract.wasm
 
 ## Run the Contract
 
-If you have [`soroban-cli`] installed, you can invoke contract functions. Both contracts must be deployed.
+If you have [`stellar-cli`] installed, you can invoke contract functions. Both contracts must be deployed.
 
 <Tabs groupId="platform" defaultValue={getPlatform()}>
 
 <TabItem value="unix" label="macOS/Linux">
 
 ```sh
-soroban contract deploy \
+stellar contract deploy \
     --wasm target/wasm32-unknown-unknown/release/soroban_cross_contract_a_contract.wasm \
     --id a
 ```
 
 ```sh
-soroban contract deploy \
+stellar contract deploy \
     --wasm target/wasm32-unknown-unknown/release/soroban_cross_contract_b_contract.wasm \
     --id b
 ```
@@ -266,13 +266,13 @@ soroban contract deploy \
 <TabItem value="windows" label="Windows (PowerShell)">
 
 ```powershell
-soroban contract deploy `
+stellar contract deploy `
     --wasm target/wasm32-unknown-unknown/release/soroban_cross_contract_a_contract.wasm `
     --id a
 ```
 
 ```powershell
-soroban contract deploy `
+stellar contract deploy `
     --wasm target/wasm32-unknown-unknown/release/soroban_cross_contract_b_contract.wasm `
     --id b
 ```
@@ -288,7 +288,7 @@ Invoke Contract B's `add_with` function, passing in values for `x` and `y` (e.g.
 <TabItem value="unix" label="macOS/Linux">
 
 ```sh
-soroban contract invoke \
+stellar contract invoke \
     --id b \
     -- \
     add_with \
@@ -302,7 +302,7 @@ soroban contract invoke \
 <TabItem value="windows" label="Windows (PowerShell)">
 
 ```powershell
-soroban contract invoke `
+stellar contract invoke `
     --id b `
     -- `
     add_with `
@@ -323,4 +323,4 @@ The following output should occur using the code above.
 
 Contract B's `add_with` function invoked Contract A's `add` function to do the addition.
 
-[`soroban-cli`]: ../getting-started/setup.mdx#install-the-soroban-cli
+[`stellar-cli`]: ../getting-started/setup.mdx#install-the-stellar-cli

docs/smart-contracts/example-contracts/custom-types.mdx

@@ -234,10 +234,10 @@ assert_eq!(
 
 ## Build the Contract
 
-To build the contract, use the `soroban contract build` command.
+To build the contract, use the `stellar contract build` command.
 
 ```sh
-soroban contract build
+stellar contract build
 ```
 
 A `.wasm` file should be outputted in the `target` directory:
@@ -248,14 +248,14 @@ target/wasm32-unknown-unknown/release/soroban_custom_types_contract.wasm
 
 ## Run the Contract
 
-If you have [`soroban-cli`] installed, you can invoke contract functions in the Wasm using it.
+If you have [`stellar-cli`] installed, you can invoke contract functions in the Wasm using it.
 
 <Tabs groupId="platform" defaultValue={getPlatform()}>
 
 <TabItem value="unix" label="macOS/Linux">
 
 ```sh
-soroban contract invoke \
+stellar contract invoke \
     --wasm target/wasm32-unknown-unknown/release/soroban_custom_types_contract.wasm \
     --id 1 \
     -- \
@@ -268,7 +268,7 @@ soroban contract invoke \
 <TabItem value="windows" label="Windows (PowerShell)">
 
 ```powershell
-soroban contract invoke `
+stellar contract invoke `
     --wasm target/wasm32-unknown-unknown/release/soroban_custom_types_contract.wasm `
     --id 1 `
     -- `
@@ -288,14 +288,14 @@ The following output should occur using the code above.
 
 Run it a few more times with different increment amounts to watch the count change.
 
-Use the `soroban` to inspect what the counter is after a few runs.
+Use the `stellar-cli` to inspect what the counter is after a few runs.
 
 ```sh
-soroban contract read --id 1 --key STATE
+stellar contract read --id 1 --key STATE
 ```
 
 ```
 STATE,"{""count"":25,""last_incr"":15}"
 ```
 
-[`soroban-cli`]: ../getting-started/setup.mdx#install-the-soroban-cli
+[`stellar-cli`]: ../getting-started/setup.mdx#install-the-stellar-cli

docs/smart-contracts/example-contracts/deployer.mdx

@@ -452,7 +452,7 @@ target/wasm32-unknown-unknown/release/soroban_deployer_test_contract.wasm
 
 ## Run the Contract
 
-If you have [`soroban-cli`] installed, you can invoke the contract function to deploy the test contract.
+If you have [`stellar-cli`] installed, you can invoke the contract function to deploy the test contract.
 
 Before deploying the test contract with the deployer, install the test contract Wasm using the `install` command. The `install` command will print out the hash derived from the Wasm file (it's not just the hash of the Wasm file itself though) which should be used by the deployer.
 
@@ -536,4 +536,4 @@ The following output should occur using the code above.
 5
 ```
 
-[`soroban-cli`]: ../getting-started/setup.mdx#install-the-soroban-cli
+[`stellar-cli`]: ../getting-started/setup.mdx#install-the-stellar-cli