Incorporate SEO recommendations

docs/concepts/tokens/decentralized-exchange/permissioned-dexes.md

@@ -14,7 +14,9 @@ There can be multiple permissioned DEXes within the XRP Ledger blockchain. Each
 
 ## Background: The Need for Permissioned DEXes
 
-The XRP Ledger has had a single, _open DEX_ since it launched. Anyone with an XRPL account can trade in this DEX, and the system automatically executes matching orders, also called offers, with no regard for who placed them. Orders also provide liquidity to cross-currency payments, which can potentially execute several trades as part of one atomic transaction. Since the system inherently knows nothing about the people and organizations behind the accounts, there is no certainty who the counterparties are for any given trade. However, economic sanctions and financial regulations often place strict rules against transacting with criminals, terrorists, or specific countries. Given these limitations, regulated financial institutions may not be willing to take the risk of trading in the open DEX.
+The XRP Ledger has had a single, _open DEX_ since it launched. Anyone with an XRPL account can trade in this DEX, and the system automatically executes matching orders, also called offers, with no regard for who placed them. Orders also provide liquidity to cross-currency payments, which can potentially execute several trades as part of one atomic transaction. 
+
+Since the system inherently knows nothing about the people and organizations behind the accounts, there is no certainty who the counterparties are for any given trade. However, economic sanctions and financial regulations often place strict rules against transacting with criminals, terrorists, or specific countries. Given these limitations, regulated financial institutions may not be willing to take the risk of trading in the open DEX.
 
 More background reading:
 

docs/concepts/tokens/fungible-tokens/multi-purpose-tokens.md

@@ -1,5 +1,6 @@
 ---
-blurb: Multi-purpose tokens offer a more compact, flexible token type than trust lines.
+seo:
+    description: Learn about multi-purpose tokens (MPTs) on XRP Ledger. MPTs are a flexible way to issue fungible tokens with built-in metadata, compliance, and transfer controls. 
 labels:
   - Tokens
   - MPTs
@@ -10,16 +11,28 @@ status: not_enabled
 
 _(Requires the [MPTokensV1 amendment][] {% not-enabled /%})_
 
-Multi-purpose tokens (MPTs) are a more compact and flexible type of fungible token.
+Multi-purpose tokens (MPTs) are a more compact and flexible type of [fungible token](/docs/concepts/tokens/fungible-tokens) on the XRP Ledger.
 
-MPTs let you take advantage of ready-to-use tokenization features with a few lines of code. You can create many token experiences from one token program itself. Notable features include:
+MPTs let you take advantage of ready-to-use tokenization features with a few lines of code. You can create many token experiences from one token program itself. 
+
+## Key Features of MPTs on XRPL
+
+The following are notable features of MPTs on XRPL.
+
+**On-Chain Metadata Storage**
 
 - MPTs store their metadata directly on the XRPL blockchain. Once set, the metadata is immutable. 
 - A 1024-byte URI field provides a metadata pointer that allows you to use an off-chain source for metadata in addition to the on-chain source. This lets your application access necessary information directly from the chain, prompting higher interoperability for tokens, without losing the ability to attach additional information. 
+
+**Transferability and Supply Controls**
+
 - MPTs can have a fixed token supply where you set a cap on the maximum number of tokens that can be minted. 
 - You can define MPTs as non-transferable, tokens that can only be transferred back to the issuer, but not among tokenholders. Useful for cases such as issuing airline credits or loyalty rewards.
 - Issuers can set transfer fees to collect on-chain revenue each time the token is traded among tokenholders. 
-- MPTs also have advanced compliance features: 
+
+**Built-In Compliance Features**
+
+MPTs also have advanced compliance features, including: 
  - The ability to lock tokens held by a tokenholder to support compliance requirements.
  - The ability to set a global lock for all MPT balances across all tokenholders.
  - The issuer can configure MPTs that can be clawed back from tokenholder wallets, either to revoke them, or to reassign them in the case of lost wallet keys. 
@@ -27,31 +40,49 @@ MPTs let you take advantage of ready-to-use tokenization features with a few lin
 
 ## MPTs versus Trust Lines
 
-Unlike trust lines, MPTs do not represent bidirectional debt relationships. Instead, MPTs function more like a unidirectional trust line with only one balance. This reduces the overhead to support common tokenization requirements, including non-monetary use cases such as tracking reputation points in an online game.
+These are the primary differences between MPTs and [trust lines](/docs/concepts/tokens/fungible-tokens#trust-lines).
 
-MPTs offer a less complicated conceptual model than trust lines. 
+**Conceptual Differences**
 
-MPTs require significantly less space than trust lines. They require roughly 52 bytes for each MPT held by a token holder, compared to at least 234 bytes for every new trust line.
+- Unlike trust lines, MPTs do not represent bidirectional debt relationships. Instead, MPTs function more like a unidirectional trust line with only one balance. This reduces the overhead to support common tokenization requirements, including non-monetary use cases such as tracking reputation points in an online game.
 
-They reduce the long-term infrastructure and storage burdens for node operators, increasing network resiliency.
+- MPTs offer a less complicated conceptual model than trust lines. 
 
-MPTs also improve node perfomance when processing large volumes of transactions.
+**Ledger Storage and Performance**
 
-MPTs are unidirectional. While trust lines use "balance netting," MPTs have only a single balance.
+- MPTs require significantly less space than trust lines. They require roughly 52 bytes for each MPT held by a token holder, compared to at least 234 bytes for every new trust line.
 
-An account can issue a maximum of 32 unique MPT issuances. If an issuer wants to support more than this number of MPTs, they can open additional accounts.
+- They reduce the long-term infrastructure and storage burdens for node operators, increasing network resiliency.
 
-Since token holders will not acquire an MPT without first making an off-ledger trust decision, MPTs have no trust limits. For example, a common use case for an MPT is a fiat-backed stablecoin, where a token holder wouldn't purchase more stablecoins than they would feel comfortable holding.
+- MPTs also improve node perfomance when processing large volumes of transactions.
 
-Unlike some existing capabilities of the ledger, MPTs are not subject to rippling, and  do not require configurability settings related to that functionality.
+**Transfer Logic and Directionality**
+
+- MPTs are unidirectional. While trust lines use "balance netting," MPTs have only a single balance.
+- An account can issue a maximum of 32 unique MPT issuances. If an issuer wants to support more than this number of MPTs, they can open additional accounts.
+- Since token holders will not acquire an MPT without first making an off-ledger trust decision, MPTs have no trust limits. For example, a common use case for an MPT is a [fiat-backed stablecoin](/docs/concepts/tokens/fungible-tokens/stablecoins#fiat-backed), where a token holder wouldn't purchase more stablecoins than they would feel comfortable holding.
+- Unlike some existing capabilities of the ledger, MPTs are not subject to [rippling](/docs/concepts/tokens/fungible-tokens/rippling) and  do not require configurability settings related to that functionality.
 
 ## MPTs versus IOUs
 
-On a technical level, MPTs provide a fundamentally different way to represent fungible tokens on the ledger.  While IOUs are represented by trustlines and have bilateral debt relationships, MPTs use a simpler, unilateral relationship captured by an MPToken object. This results in substantial space savings on the ledger. The representation of a fungible token as a token object instead of a trustline makes it easier to enable functionality for real-world financial assets on-chain, such as token-level metadata, fixed supply, and fixed-point balance.
+MPTs are different from IOUs in the following ways.
 
-On a usage level, MPTs provide a straightforward conceptual model compared to trustlines and rippling. Developers can more easily build web3 applications around `MPToken` and `MPTokenIssuance` objects, with some similarities to the conceptual model of XLS-20 NFTs.  It is also simpler for ordinary users to understand what tokens are available, what tokens they have issued, and what they hold in their wallet.  For both issuers and holders of MPTs, there will typically be a smaller XRP reserve compared to the equivalent representations with IOU trustlines.
+**Technical Representation on the Ledger**
 
-MPTs are intended to be complementary to IOUs.  While there might be use cases where either MPTs or IOUs might be suitable, there will likely be a need for both over the long term.  There will be use cases such as credit lines for lending and borrowing that might be better represented by IOUs long term.  The MPT feature set should evolve in an incremental manner to unlock more common use cases first and deliver additional feature support at a later time. During the MPT development period, some cases might still be better represented by an IOU, then later be better supported with MPTs.
+On a technical level, MPTs provide a fundamentally different way to represent fungible tokens on the ledger.  While IOUs are represented by trustlines and have bilateral debt relationships, MPTs use a simpler, unilateral relationship captured by an MPToken object. This results in substantial space savings on the ledger. 
+
+The representation of a fungible token as a token object instead of a trustline makes it easier to enable functionality for real-world financial assets on-chain, such as token-level metadata, fixed supply, and fixed-point balance.
+
+**Developer Experience and App Design**
+On a usage level, MPTs provide a straightforward conceptual model compared to [trustlines](/docs/concepts/tokens/fungible-tokens.md#trust-lines) and [rippling](/docs/concepts/tokens/fungible-tokens/rippling). Developers can more easily build web3 applications around `[MPToken](/docs/references/protocol/ledger-data/ledger-entry-types/mptoken)` and `[MPTokenIssuance](/docs/references/protocol/ledger-data/ledger-entry-types/mptokenissuance)` objects, with some similarities to the conceptual model of XLS-20 NFTs.  
+
+It is also simpler for ordinary users to understand what tokens are available, what tokens they have issued, and what they hold in their wallet.  
+
+For both issuers and holders of MPTs, there will typically be a smaller XRP reserve compared to the equivalent representations with IOU trustlines.
+
+## Use Case and Long-Term Considerations
+
+MPTs are intended to be complementary to IOUs.  While there might be use cases where either MPTs or IOUs might be suitable, there will likely be a need for both over the long term.  There will be use cases such as credit lines for lending and borrowing that might be better represented by IOUs long term.  The MPT feature set should evolve in an incremental manner to unlock more common use cases first and deliver additional feature support at a later time. During the MPT development period, some cases might still be better represented by an IOU, and then later be better supported with MPTs.
 
 ## See Also
  

docs/concepts/transactions/batch-transactions.md

@@ -1,6 +1,6 @@
 ---
 seo:
-    description: Batch allows up to 8 transactions to be submitted as a single unit.
+    description: Discover how XRPL Batch Transactions streamline multiple blockchain operations into a single secure transaction. Learn about batch modes, execution details, and security considerations. 
 labels:
   - Batch
   - Transactions
@@ -8,7 +8,9 @@ status: not_enabled
 ---
 # Batch Transactions
 
-`Batch`  lets you package multiple transactions together and execute them as a single unit. It eliminates the risk of partial completion and unexpected outcomes, giving you a more reliable and predictable experience for complex operations. Up to eight transactions can be submitted in a single batch.
+XRPL Batch Transactions let you package multiple [transactions](/docs/concepts/transactions.md) together and execute them as a single unit. It eliminates the risk of partial completion and unexpected outcomes, giving you a more reliable and predictable experience for complex operations. Up to eight transactions can be submitted in a single batch.
+
+## XRPL Batch Use Cases
 
 Some potential uses for `Batch` include the following.
 - All or nothing: You can mint an NFT and create an offer for it in one transaction. If the offer creation fails, the NFT mint is reverted as well.
@@ -19,7 +21,11 @@ Some potential uses for `Batch` include the following.
 
 `Batch` transactions are comprised of the _outer transaction_, the wrapper `Batch` transaction itself, and the _inner transactions_, each of which is executed atomically. The precise way that the inner transactions are processed is determined by the batch _mode_.
 
-## Batch Mode
+<div align="center">
+<iframe width="560" height="315" src="https://www.youtube.com/embed/LsMMXm7jm1k" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+</div>
+
+## XRPL Batch Transaction Modes
 
 There are four possible batch modes: `ALLORNOTHING`, `ONLYONE`, `UNTILFAILURE`, and `INDEPENDENT`.
 
@@ -39,9 +45,9 @@ In `ALLORNOTHING` mode, all inner transactions must succeed for any one of them
 
 All transactions are applied, even if one or more of the inner transactions fail.
 
-## Raw Transactions
+## XRPL Raw Transactions Object
 
-The `RawTransactions` object is a container for the list of transactions to be applied. You can include up to eight transactions in a sincle batch. The transactions can come from one account or multiple accounts.
+The `RawTransactions` object is a container for the list of transactions to be applied. You can include up to eight transactions in a single batch. The transactions can come from one account or multiple accounts.
 
 Each inner transaction:
 
@@ -67,6 +73,8 @@ This field is included if the account is signing with multi-sign (as opposed to
 
 This field must be provided if more than one account has inner transactions included in the Batch. In that case, this field must contain signatures from all accounts whose inner transactions are included, excluding the account signing the outer transaction (if applicable).
 
+#### Fields Used for XRPL Batch Transactions
+
 Each object in this array contains the following fields:
 
 | Field Name	  | Required?	| JSON Type	| Internal Type |
@@ -90,7 +98,7 @@ These fields are included if the account is signing with a single signature (as
 
 This field is included if the account is signing with multi-sign (as opposed to a single signature). It operates equivalently to the `Signers` field used in standard transaction multi-sign. This field holds the signatures for the `Flags` field and the hashes of the transactions in `RawTransactions`.
 
-## Transaction Fee
+## XRPL Batch Transaction Fees
 
 The fee for the outer transaction is twice the base fee (a total of 20 drops when there is no fee escalation), plus the sum of the transaction fees of all the inner transactions (which incorporates factors like higher fees for `multisign` or `AMMCreate`), plus an additional base fee amount for each additional signature in the transaction (for example, from `BatchSigners`). Expressed as an equation:
 
@@ -124,7 +132,7 @@ There is also a pointer back to the parent outer transaction (`ParentBatchID`).
 
 ## Transaction Common Fields
 
-This standard doesn't add any new fields to the transaction common fields, but it does add another global transaction flag:
+This standard doesn't add any new fields to the [transaction common fields](/docs/references/protocol/transactions/common-fields.md), but it does add another global transaction flag:
 
 | Flag Name	      | Value      |
 |-----------------|------------|
@@ -132,7 +140,7 @@ This standard doesn't add any new fields to the transaction common fields, but i
 
 This flag should be used only if a transaction is an inner transaction in a `Batch` transaction. This signifies that the transaction shouldn't be signed. Any normal transaction that includes this flag should be rejected.
 
-## Security
+## Security for XRPL Batch Transactions
 
 Batch transactions come with additional security considerations.