Update nftokenmint

content/concepts/introduction/crypto-wallets.md

@@ -7,7 +7,7 @@ labels:
 ---
 # Crypto Wallets
 
-Crypto wallets provide a way to manage your account and funds on the XRP Ledger. There are many wallets to choose from and choosing the right one ultimately comes down to your needs and comfort working with XRP.
+Crypto wallets provide a way to manage your account and funds on the XRP Ledger. There are many wallets to choose from. Choosing the right wallet ultimately comes down to your needs and comfort working with XRP.
 
 
 ## Custodial vs Non-custodial Wallets
@@ -18,11 +18,13 @@ A custodial wallet means a third party holds your funds, typically on an account
 
 For day-to-day payments, this may be preferable, since these types of wallets are user-friendly: if you forget your password, you can typically have it reset. Also, if you don't have an individual XRP Ledger account, the ledger's reserve requirement doesn't apply to you. The custodian acts a buffer to any issues you run into on the XRP Ledger, and may offer support or assistance if you're not sure how to do something.
 
+![Custodial vs. Non-custodial Wallets](img/introduction15-custodial-non-custodial.png)
+
 A non-custodial wallet, such as [XUMM](https://xumm.app/), is one where you have the secret keys to your account. This means you're ultimately responsible for managing the security of your account.
 
 **Caution:** If you lose your keys, you are locked out of your XRP Ledger account and there are no recovery options.
 
-Non-custodial wallets give you more freedoms. Since you're interacting directly with the XRP Ledger yourself, you can handle any type of transaction you want without anyone restricting your options. If the ledger allows it, you can do it. Non-custodial wallets also don't require you to trust an institution with your money, which can insulate you from market factors outside your control.
+Non-custodial wallets allow more freedom. Since you're interacting directly with the XRP Ledger yourself, you can handle any type of transaction you want without anyone restricting your options. If the ledger allows it, you can do it. Non-custodial wallets also don't require you to trust an institution with your money, which can insulate you from market factors outside your control.
 
 Users of both custodial and non-custodial wallets have to protect themselves from malicious users who might try to steal their funds. With a custodial wallet, you have to manage your login and password to the app or site; with a non-custodial wallet, you have to manage your secret keys to your on-ledger account. In both cases, the wallet provider's own security practices are also important to protect you from vulnerabilities like supply-chain attacks, where an attacker loads malicious code into the wallet through software updates or dependencies. However, custodial wallets can be a bigger target for attackers since they have immediate access to multiple customers' funds.
 
@@ -33,18 +35,14 @@ Another deciding factor when choosing a wallet is picking between a hardware or
 
 Hardware wallets are physical devices that store your private/secret keys. The main benefit of using hardware wallets is that you can secure your information by disconnecting it from the internet when it's not in use; hardware wallets totally isolate your keys from easier-to-hack computers or smartphones.
 
-Software wallets on the other hand, are entirely digitial. While this makes them easier to use, it also makes them the less secure method of the two, but they usually come with additional features to enhance your experience. Ultimately, the decision between the two will come down to your comfort level and how important ease-of-use is to you.
+![Hardware vs. Software Wallets](img/introduction16-hardware-software.png)
+
+Software wallets on the other hand, are entirely digital. While this makes them easier to use, it also makes them the less secure method of the two, but they usually come with additional features to enhance your experience. Ultimately, the decision between the two will come down to your comfort level and how important ease-of-use is to you.
 
 
 ## Creating Your Own Wallet
 
 The XRP Ledger is an opensource project with publicly available client libraries and API methods. While you can technically interact with the ledger using HTTP/WebSocket tools, it isn't practical for day-to-day use. You can create your own wallet to interact with the ledger, but you'll need to understand exactly how accounts, transactions, and the ledger work together before committing to this option.
 
 
-## See Also
-
-- [Accounts](accounts.html)
-- [Cryptographic Keys](cryptographic-keys.html)
-- [Client Libraries](client-libraries.html)
-- [Ledgers](ledgers.html)
-- [Build a Desktop Wallet in Python](build-a-desktop-wallet-in-python.html)
+Next: [Transactions and Requests](txn-and-requests.html)

content/concepts/introduction/txn-and-requests.md

@@ -8,41 +8,51 @@ labels:
 
 # Transactions and Requests
 
-All interactions with the XRP Ledger involve either sending a transaction that makes changes to the ledger or sending a request for information from the ledger.
+Most interactions with the XRP Ledger involve either sending a transaction that makes changes to the ledger or sending a request for information from the ledger. You can also subscribe to monitor continual notifications of interest.
 
 ## How Do Transactions Work?
 
-You execute a transaction by sending a REST command to the XRP Ledger and waiting for the response. The command syntax is always the same for every transaction.
+Use transactions to make changes on the ledger such as transferring XRP and other tokens between accounts; minting and burning NFTs; and creating, accepting, and cancelling offers. You execute a transaction by sending a command to the XRP Ledger and watching for confirmation that the transaction is complete. The command syntax format is the same for every transaction.
 
-You must always provide the _TransactionType_ and the public address of the _Account_ making the transaction.
+- You must always provide the _TransactionType_ and the public address of the _Account_ making the transaction.
 
-Two required fields are the _Fee_ for the transaction and the next _Sequence_ number for transactions from the account. These fields can be filled in automatically by the ledger server when you submit the transaction.
+- Two required fields are the _Fee_ for the transaction and the next _Sequence_ number for transactions from the account. These fields can be filled in automatically.
 
-Specific transactions also have required fields specific to the transaction type. For example, a _Payment_ transaction requires an _Amount_ value (in _drops_, or millionths of an XRP) and a _Destination_ public address to which the funds are credited.
+- Transactions can also have required fields specific to the transaction type. For example, a _Payment_ transaction requires an _Amount_ value (in _drops_, or millionths of an XRP) and a _Destination_ public address to which the funds are credited.
 
 Here is a sample transaction in JSON format. This transaction transfers 1 XRP from account _rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn_ to destination account _ra5nK24KXen9AHvsdFTKHSANinZseWnPcX_.
 
 ```json
 {
   "TransactionType": "Payment",
-  "Account": rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn,
+  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
   "Amount": 1000000,
-  "Destination": ra5nK24KXen9AHvsdFTKHSANinZseWnPcX
+  "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
 }
 ```
 
 Optional fields are available for all transactions, with additional fields available for specific transactions. You can include as many optional fields as you need, but do not have to include every field in every transaction.
 
-You send the transaction to the ledger as a RESTful command from JavaScript, Python, the command line, or any compatible service. The rippled server proposes the transaction to the ledger. When 80% of the validators approve the transaction, it is recorded as part of the permanent ledger. The ledger returns the results of the transaction.
+You send the transaction to the ledger as a command from JavaScript, Python, the command line, or any compatible service. The rippled servers propose transactions to the XRPL. 
+
+![Proposed Transacations](img/introduction17-gather-txns.png)
+
+When 80% of the validators approve a current set of proposed transactions, they are recorded as part of the permanent ledger. The rippled server returns the results of the transaction you sent.
 
 For more information on Transactions, see [Transactions](transactions.html).
 
 ## How Do Requests Work?
 
-Requests are similar to transactions, but they do not make changes to the ledger.
+Requests are used to get information from the ledger, but they do not make changes to the ledger. The information is freely available to anyone to view, so there is no need to sign in with your account information.
 
 The fields you send vary with the type of information you request. They typically have several optional fields, but only a few required fields.
 
+When you submit your request, it might be processed by a rippled server or by a Clio server, a server that is dedicated to responding to requests.
+
+![Clio Server](img/introduction19-clio.png)
+
+Clio servers take some of the load off the other rippled servers on the XRPL to improve processing speed and reliability.
+
 This is a sample request in JSON format. This request gets the current account information for the account number you provide.
 
 ```json
@@ -52,7 +62,7 @@ This is a sample request in JSON format. This request gets the current account i
 }
 ```
 
-The request returns a wealth of information in a format appropriate for the language you used to make the request. Here is an example of the response for an account information request in JSON format.
+The request returns a wealth of information. Here is an example response for an account information request in JSON format.
 
 ```json
 {
@@ -99,4 +109,6 @@ The request returns a wealth of information in a format appropriate for the lang
     }
 }
 ```
-For information on the fields in an Account record, see [Accounts](accounts.html).
+For information on the fields in an Account record, see [Accounts](accounts.html).
+
+Next: [Software Ecosystem](software-ecosystem.html)

content/concepts/introduction/what-is-xrp.md

@@ -63,3 +63,4 @@ Originally, the XRP Ledger was called "Ripple" for the way the technology allowe
 |:---------------------------------------|:------------------------------------|
 | !["X" logo](assets/img/xrp-x-logo.png) | ![Triskelion](img/ripple-triskelion.png) |
 
+Next: [Crypto Wallets](crypto-wallets.html)

content/concepts/introduction/what-is-xrpl.md

@@ -51,10 +51,20 @@ Once recorded, the data in any given block cannot be altered retroactively, unle
 
 ### How Does the Federated Consensus Process Work?
 
-Most of the rippled servers in the XRPL monitor or propose transactions. An important subset of servers are run as validators. These trusted servers accumulate lists of new transactions into a new possible ledger instance (a new block in the block chain). They share their lists with all of the other validators. The validators incorporate proposed changes from one another and distribute a new version of the ledger proposal. When 80% of the validators agree on a set of transactions, they create a new ledger instance at the end of the chain and start the process again. This consensus process takes 4-6 seconds. You can monitor as ledger instances are created in real time by visiting [https://livenet.xrpl.org/](https://livenet.xrpl.org/).
+Most of the rippled servers in the XRPL monitor or propose transactions. An important subset of servers are run as validators. These trusted servers accumulate lists of new transactions into a new possible ledger instance (a new block in the block chain).
+
+![Gathering Transactions](img/introduction17-gather-txns.png)
+
+They share their lists with all of the other validators. The validators incorporate proposed changes from one another and distribute a new version of the ledger proposal.
+
+![80% Consensus](img/introduction18-80-percent-consensus.png)
+
+When 80% of the validators agree on a set of transactions, they create a new ledger instance at the end of the chain and start the process again. This consensus process takes 4-6 seconds. You can monitor as ledger instances are created in real time by visiting [https://livenet.xrpl.org/](https://livenet.xrpl.org/).
 
 ### What Networks Are Available?
 
-The XRPL is open to anyone who wants to set up their own instance of the rippled server and connect. The node can monitor the network, perform transactions, or become a validator.
+The XRPL is open to anyone who wants to set up their own instance of the rippled server and connect. The node can monitor the network, perform transactions, or become a validator. The active XRPL network is typically referred to as _Mainnet_.
+
+For developers or new users who want to try out the features of XRPL without investing their own funds, there are two developer environments, _Testnet_ and _Devnet_. Users can create an account funded with 1,000 (fake) XRP and connect to either environment to interact with the XRPL.
 
-For developers or new users who want to try out the features of XRPL without investing their own funds, there are two developer environments, _Testnet_ and _Devnet_. Users can create an account funded with 1,000 (fake) XRP and connect to either environment to interact with the XRPL. 
+Next: [What is XRP?](what-is-xrp.html)

content/references/protocol-reference/data-types/nftoken.md

@@ -54,7 +54,7 @@ Flags are properties or other options associated with the `NFToken` object.
 | `lsfBurnable`     | `0x0001`   | If enabled, the issuer (or an entity authorized by the issuer) can destroy this `NFToken`. The object's owner can always do so. |
 | `lsfOnlyXRP`      | `0x0002`   | If enabled, this `NFToken` can only be offered or sold for XRP. |
 | `lsfTrustLine`    | `0x0004`   | **DEPRECATED** If enabled, automatically create [trust lines](trust-lines-and-issuing.html) to hold transfer fees. Otherwise, buying or selling this `NFToken` for a fungible token amount fails if the issuer does not have a trust line for that token. The [fixRemoveNFTokenAutoTrustLine amendment][] makes it invalid to enable this flag. |
-| `lsfTransferable` | `0x0008`   | If enabled, this `NFToken` can be transferred from one holder to another. Otherwise, it can only be transferred to or from the issuer. |
+| `lsfTransferable` | `0x0008`   | If enabled, this `NFToken` can be transferred from one holder to another. Otherwise, it can only be transferred to or from the issuer. The transfer to the issuer must be via a buy offer created by the issuer and not a sell offer from the holder of the `NFToken`.|
 | `lsfReservedFlag` | `0x8000`   | This flag is reserved for future use. Attempts to set this flag fail. |
 
 `NFToken` flags are immutable: they can only be set during the [NFTokenMint transaction][] and cannot be changed later.

content/references/protocol-reference/transactions/transaction-types/nftokenmint.md

@@ -59,7 +59,7 @@ Transactions of the NFTokenMint type support additional values in the [`Flags` f
 | `tfBurnable` | `0x00000001` | 1 | Allow the issuer (or an entity authorized by the issuer) to destroy the minted `NFToken`. (The `NFToken`'s owner can _always_ do so.) |
 | `tfOnlyXRP` | `0x00000002` | 2 | The minted `NFToken` can only be bought or sold for XRP. This can be desirable if the token has a transfer fee and the issuer does not want to receive fees in non-XRP currencies. |
 | `tfTrustLine` | `0x00000004` | 4 | **DEPRECATED** Automatically create [trust lines](trust-lines-and-issuing.html) from the issuer to hold transfer fees received from transferring the minted `NFToken`. The [fixRemoveNFTokenAutoTrustLine amendment][] makes it invalid to set this flag. |
-| `tfTransferable` | `0x00000008` | 8 | The minted `NFToken` can be transferred to others. If this flag is _not_ enabled, the token can still be transferred _from_ or _to_ the issuer. |
+| `tfTransferable` | `0x00000008` | 8 | The minted `NFToken` can be transferred to others. If this flag is _not_ enabled, the token can still be transferred _from_ or _to_ the issuer. The transfer to the issuer must be via a buy offer created by the issuer and not a sell offer from the holder of the `NFToken`. |
 
 
 ## Embedding additional information