Refactor wrap/deploy of SAC

docs/guides/cli/deploy-stellar-asset-contract.mdx

@@ -0,0 +1,71 @@
+---
+title: Deploy the Stellar Asset Contract for a Stellar Asset
+hide_table_of_contents: true
+---
+
+The Soroban CLI can deploy a [Stellar Asset Contract] for a Stellar asset so that any Soroban contract can interact with the asset.
+
+Every Stellar asset has reserved a contract that anyone can deploy. Once deployed any contract can interact with that asset by holding a balance of the asset, receiving the asset, or sending the asset.
+
+Deploying the Stellar Asset Contract for a Stellar asset enables that asset for use on Soroban.
+
+The Stellar Asset Contract can be deployed for any possible Stellar asset, either assets already in use on Stellar or assets that have never seen any activity. This means that the issuer doesn't need to have been created, and no one needs to be yet holding the asset on Stellar.
+
+To perform the deploy, use the following command:
+
+```bash
+soroban contract asset deploy \
+    --source S... \
+    --network testnet \
+    --asset USDC:GCYEIQEWOCTTSA72VPZ6LYIZIK4W4KNGJR72UADIXUXG45VDFRVCQTYE
+```
+
+The `asset` argument corresponds to the symbol and it's issuer address, which is how assets are identified on Stellar.
+
+The same can be done for the native [Lumens] asset:
+
+```bash
+soroban contract asset deploy \
+    --source S... \
+    --network testnet \
+    --asset native
+```
+
+:::note
+
+Deploying the native asset will fail on testnet or mainnet as
+a Stellar Asset Contract already exists.
+
+:::
+
+For any asset, the contract address can be fetched with:
+
+```bash
+soroban contract id asset \
+    --source S... \
+    --network testnet \
+    --asset native
+```
+
+The contract address can then be used in a Soroban contract as any contract:
+
+```rust
+use soroban_sdk::token;
+
+struct MyContract;
+
+#[contractimpl]
+impl MyContract {
+  fn token_fn(e: Env, token: Address) {
+    // Create a client instance for the provided token identifier. If the
+    // `token_id` value corresponds to an SAC contract, then SAC implementation
+    // is used.
+    let client = token::Client::new(&env, &token);
+    // Call token operations.
+    client.transfer(...);
+  }
+}
+```
+
+[Stellar Asset Contract]: ../../tokens/stellar-asset-contract.mdx
+[Lumens]: https://developers.stellar.org/docs/fundamentals-and-concepts/lumens

docs/tokens/stellar-asset-contract.mdx

@@ -36,19 +36,24 @@ smart contract developers to get started on Stellar.
 
 ## Deployment
 
-For every Stellar asset exactly one respective Stellar Asset Contract can be
-deployed. It can be deployed using the `InvokeHostFunctionOp` with
+For every Stellar asset that exists on the Stellar network,
+one respective Stellar Asset Contract can be deployed on the Soroban platform.
+
+It can be deployed using the `InvokeHostFunctionOp` with
 `HOST_FUNCTION_TYPE_CREATE_CONTRACT` and `CONTRACT_ID_FROM_ASSET` specified
 [here](../soroban-internals/contract-interactions/stellar-transaction.mdx). The resulting token will have a
 deterministic identifier, which will be the sha256 hash of
 `HashIDPreimage::ENVELOPE_TYPE_CONTRACT_ID_FROM_ASSET` xdr specified [here][contract_id].
 
+Or the [Soroban-CLI] can be used as showed [here][../guides/cli/deploy-stellar-asset-contract.mdx].
+
 Anyone can deploy the instances of Stellar Asset Contract. Note, that the
 initialization of the Stellar Asset Contracts happens automatically during the
 deployment. Asset Issuer will have the administrative permissions after the
 contract has been deployed.
 
 [contract_id]: https://github.com/stellar/stellar-xdr/blob/dc23adf60e095a6ce626b2b09128e58a5eae0cd0/Stellar-transaction.x#L661
+[Soroban-CLI]: ../reference/soroban-cli.mdx
 
 ## Interacting with classic Stellar assets
 

docs/tutorials/tokens.mdx

@@ -547,14 +547,14 @@ transfers, balance queries, etc.). In an effort to minimize repetition and
 streamline token deployments, Soroban implements the [Token Interface], which
 provides a uniform, predictable interface for developers and users.
 
-Creating a Soroban token from an existing Stellar asset is very easy, and the
-wrapped token makes use of the [Stellar Asset Contract] (more on that [later]).
+Creating a Soroban token from an existing Stellar asset is very easy,
+it involves creating a [Stellar Asset Contract].
+
 This example contract, however, demonstrates how a smart contract token might be
 constructed that doesn't take advantage of the Stellar Asset Contract, but does
 still satisfy the commonly used Token Interface to maximize interoperability.
 
 [Stellar Asset Contract]: ../tokens/stellar-asset-contract.mdx
-[later]: #compatibility-with-stellar-assets
 
 ### Separation of Functionality
 
@@ -648,38 +648,6 @@ _require_ the right kind of behavior to take place.
 
 :::
 
-### Compatibility with Stellar Assets
-
-One of the key benefits of the Stellar network is that assets are first-class
-citizens. On a protocol level, asset issuers have a robust set of tools to
-manage the authorization and behavior of assets. Any asset that already exists
-on the Stellar network can also make use of the [Stellar Asset Contract] on the
-Soroban platform. All that is required is a simple, one-time action of wrapping
-the asset to be deployed for Soroban.
-
-At that point, the asset can use all the features of the Stellar Asset Contract
-that are highlighted in this example (allowance, mint, burn, etc.), while still
-maintaining the high-quality asset issuer features included with Stellar.
-
-Additionally, all of that comes with **no contract writing required**. Any asset
-can be easily wrapped using the [Soroban-CLI]:
-
-```bash
-soroban lab token wrap \
-    --asset USDC:GCYEIQEWOCTTSA72VPZ6LYIZIK4W4KNGJR72UADIXUXG45VDFRVCQTYE
-```
-
-:::note
-
-A Stellar asset could be wrapped for Soroban by _any_ user. This command will
-set the asset issuer account as the `admin` address for the Soroban token,
-meaning that issuer account will still maintain control over asset minting,
-authorization, etc.
-
-:::
-
-[Soroban-CLI]: ../reference/soroban-cli.mdx
-
 ## Tests
 
 Open the `token/src/test.rs` file to follow along.

nginx/includes/redirects.conf

@@ -22,6 +22,7 @@ rewrite "^/docs/getting-started/connect-freighter-wallet$" "/docs/reference/frei
 rewrite "^/docs/common-interfaces/token$" "/docs/tokens/token-interface" permanent;
 rewrite "^/docs/how-to-guides/tokens$" "/docs/tutorials/tokens" permanent;
 rewrite "^/dapps/category/challenges$" "/dashboard" permanent;
+rewrite "^/docs/guides/cli/wrap-token$" "/docs/guides/cli/deploy-stellar-asset-contract" permanent;
 # BEGIN re-structure redirects
 rewrite "^/sorobanathon" "/" permanent;
 rewrite "^/docs/reference/interfaces/token-interface" "/docs/tokens/token-interface" permanent;