Minor updates to text and references

Author: TinaKT

source/mainnet/docs/integration/wallet integration/integrate-identity-layer.rst

@@ -5,7 +5,7 @@
 Integrate Concordium's ID layer
 ===============================
 
-Every account on Concordium is backed by a verified identity, requiring a balance between compliance and on-chain privacy. The process begins with an off-chain Identity Provider (IDP) who issues a sensitive identity object to the user. This object is the cryptographic root of the user's on-chain presence.
+Every account on Concordium is backed by a verified identity, requiring a balance between compliance and on-chain privacy. The process begins with an off-chain :term:`Identity Provider (IDP)<Identity Provider>` who issues a sensitive :term:`identity object` to the user. This object is the cryptographic root of the user's on-chain presence.
 
 Your wallet's role is to facilitate the use of this identity object to create public on-chain accounts, ensuring privacy by anchoring the user's identity without exposing personal data. This guide outlines the two primary integration paths for managing the identity creation process and its associated data.
 
@@ -15,7 +15,7 @@ Your wallet's role is to facilitate the use of this identity object to create pu
 Option 1: direct ID provider integration
 ========================================
 
-In this model, your wallet integrates directly with an Identity Provider's (IDP's) API. You can select from a list of :ref:`pre-approved IDPs<key-participants>` already integrated with the network, or you can bring your own preferred provider. If you bring your own, the IDP must work with the Concordium team to complete an onboarding process and become a recognized issuer on the network. Once an IDP is chosen, your application manages the entire verification flow, from generating cryptographic requests to receiving the final identity object.
+In this model, your wallet integrates directly with an IDP's API. You can select from a list of :ref:`pre-approved IDPs<key-participants>` already integrated with the network, or you can bring your own preferred provider. If you bring your own, the IDP must work with the Concordium team to complete an onboarding process and become a recognized issuer on the network. Once an IDP is chosen, your application manages the entire verification flow, from generating cryptographic requests to receiving the final identity object.
 
 **Advantage:** You maintain complete control over the entire user journey, allowing for a seamless and fully branded in-app experience.
 
@@ -42,7 +42,7 @@ Making your decision
 
 Choosing between these two options is a key architectural decision. The choice involves balancing the level of control you want over the user experience against the development and maintenance resources required.
 
-To help you make an informed choice, we recommend reviewing the :ref:`detailed guide on Concordium's identity layer<reference-identity>` in our developer documentation. For a practical example, you can explore the source code of `Concordium Wallet <https://github.com/Concordium/cryptox-android>`_, an open-source reference wallet, which provides a complete implementation of :ref:`option 1<option-1-direct-idp>`.
+To help you make an informed choice, we recommend reviewing our :ref:`detailed guide on Concordium's identity layer<reference-identity>`. For a practical example, you can explore the source code of `Concordium Wallet <https://github.com/Concordium/cryptox-android>`_, an open-source reference wallet, which provides a complete implementation of :ref:`option 1<option-1-direct-idp>`.
 
 Zero-knowledge proofs
 =====================

source/mainnet/docs/integration/wallet integration/support-transactions.rst

@@ -7,7 +7,7 @@ Support transactions
 
 A wallet's fundamental purpose is to construct, sign, and broadcast :term:`transactions<transaction>`. Each user-facing feature you implement will require your wallet to generate a specific type of transaction payload.
 
-This guide breaks down the core transaction types you can support.
+The following section lists the core transaction types you can support.
 
 Transaction types
 =================
@@ -35,10 +35,10 @@ These transactions are essential for participating in Concordium's :term:`proof-
 
 Unique to Concordium's architecture, this category includes the crucial create account transaction. This must be submitted with the cryptographic credential from a user's verified :term:`identity object`, linking the new account to that identity.
 
-Protocol Level Tokens
-======================
+Protocol-level tokens
+=====================
 
-Beyond the standard transaction types, Concordium features Protocol Level Tokens (PLTs), a unique class of tokens created directly at protocol level.
+Beyond the standard transaction types, Concordium features :term:`protocol-level tokens (PLTs)<protocol-level token (PLT)>`, a unique class of tokens created directly at protocol level.
 
 These tokens are distinct from user-created CIS-2 smart contract tokens. They are typically reserved for foundational assets, such as bridged tokens (e.g., wETH), that require native protocol integration.
 
@@ -51,6 +51,8 @@ Key advantages of PLTs
 
 For a wallet, supporting a PLT transfer means constructing a dedicated, protocol-level transaction, which is different from the general-purpose update function used for smart contracts.
 
+For further details on PLTs, refer to our :ref:`PLT<plts>` documentation.
+
 Developer tools and resources
 =============================