fix(docs): improve clarity and grammar in FAssets redemption and default guides

Author: fassko

docs/fassets/3-redemption.mdx

@@ -34,12 +34,12 @@ This is the summary of the redemption process:
 
 4. Every agent pays the redeemer on the underlying chain and includes the payment reference in the memo field of the payment transaction.
 
-   Agents can pay the redemption from their own address they control on the underlying chain.
+   Agents can pay the redemption from their own address, which they control on the underlying chain.
    It does not need to be the same address where they receive minting payments.
 
 5. After the payment is finalized, the agent uses the [FDC](/fdc/overview) to prove the payment and obtain a payment proof.
 
-6. The agent (or, in Core Vault and certain flows, the **executor**) presents the payment proof to the FAssets system, which issues a **redemption ticket**.
+6. The agent (or, in Core Vault and specific flows, the **executor**) presents the payment proof to the FAssets system, which issues a **redemption ticket**.
 
    The executor role is responsible for ensuring that the system can finalize redemptions even if the agent is unresponsive or if the flow is managed by a central entity (such as the Core Vault executor).
 
@@ -54,92 +54,92 @@ This is the summary of the redemption process:
 ## Redemption-Payment Failure
 
 Agents have a limited time to pay the redeemer on the underlying chain.
-The amount of time is defined by the last block and the last timestamp on the underlying chain.
-If the payment is not made in time, the redeemer has to prove [payment non existence](/fdc/attestation-types/referenced-payment-nonexistence) to be compensated.
-After the redeemer presents the payment non existence proof, he is paid with the agent's collateral plus a _redemption default premium_.
+The last block and the last timestamp on the underlying chain define the amount of time.
+If the payment is not made in time, the redeemer has to prove [payment non-existence](/fdc/attestation-types/referenced-payment-nonexistence) to be compensated.
+After the redeemer presents the payment non-existence proof, he is paid with the agent's collateral plus a _redemption default premium_.
 The premium is intended to encourage the agent to complete redemptions by paying with the underlying asset instead of collateral.
 
-If a payment fails and the failed transaction is recorded on the underlying chain, the agent must submit a proof of failed payment.
+If a payment fails and the failed transaction is recorded on the underlying chain, the agent must submit proof of the failed payment.
 In this way, the gas costs of the failed transaction can be accounted for by the FAssets system.
-If the transaction was not recorded, then no gas was spent and reporting is not necessary.
+If the transaction was not recorded, then no gas was spent, and reporting is not necessary.
 
 If the agent does not report the failed payment in time, anyone (including the executor) can report the failed payment and receive a reward from the agent's vault.
 
 :::info
 
-    When payment fails because of the redeemer, the agent can obtain a proof of the failed payment from the Flare Data Connector and present it to the FAssets system.
+    When payment fails because of the redeemer, the agent can obtain proof of the failed payment from the Flare Data Connector and present it to the FAssets system.
     The agent's obligation is then fulfilled, and he can keep both the collateral and the underlying.
 
     Two different proofs can be used:
 
     * Proof of invalid address, due to a wrong syntax or checksum, for example.
     * Proof of blocked payment: Even if the address is valid, it might contain a contract that blocks the payment.
-        This can only happen on underlying networks supporting smart contracts.
+        This can only occur on underlying networks that support smart contracts.
 
-        The agent must still try to pay and, if the payment is blocked, the agent can request this proof from the Flare Data Connector and present it to the FAssets system.
+        The agent must still try to pay, and if the payment is blocked, the agent can request this proof from the Flare Data Connector and present it to the FAssets system.
 
 :::
 
 During step 4 above, if any agent does not pay on the underlying chain, the redeemer completes the following procedure separately for each nonpaying agent:
 
-1. The redeemer obtains a proof of payment non existence from the Flare Data Connector.
-2. The redeemer presents the payment non existence proofs to the FAssets system, which triggers a redemption failure.
+1. The redeemer obtains a proof of payment non-existence from the Flare Data Connector.
+2. The redeemer presents the payment non-existence proofs to the FAssets system, which triggers a redemption failure.
 3. The redeemer is paid with collateral, according to the current price plus a premium.
 4. FAssets are overcollateralized, so, even after paying the redeemer with a premium, a remainder is released.
-   This remainder is derived by the [system-wide collateral ratio settings](/fassets/collateral#system-wide-thresholds) specified by governance.
+   This remainder is derived from the [system-wide collateral ratio settings](/fassets/collateral#system-wide-thresholds) specified by governance.
 5. The underlying assets backing the redeemed FAssets are marked as free and can be withdrawn by the agent later.
 
 ## Edge Cases
 
 ### Unresponsive redeemer
 
 After a redemption nonpayment, the redeemer might not report the failure for some reason.
-In this case, the agent or the executor can present a payment non existence proof, and the redeemer receives collateral plus a premium.
+In this case, the agent or the executor can present a payment non-existence proof, and the redeemer receives collateral plus a premium.
 After this operation, the underlying backing collateral and the remaining local collateral are released.
 
 ### Unresponsive agent
 
 After a successful payment, the agent might not present the payment proof (redemption ticket).
 
 Because the agent has already paid, the redeemer is not affected.
-However, the system still requires the payment proof to correctly track the agent's balance on the underlying chain.
-After enough time for the agent to present the proof has elapsed, anyone, including the executor, can present the payment proof and receive collateral from the agent's vault as a reward.
+However, the system still requires the payment proof to track the agent's balance on the underlying chain correctly.
+After enough time for the agent to present the proof has elapsed, anyone, including the executor, can show the payment proof and receive collateral from the agent's vault as a reward.
 
 ### Expired proof
 
-Proofs provided by the Flare Data Connector are available for only 24 hours, approximately.
-If neither the redeemer, the agent, nor the executor presents the proof of payment or payment non existence within 24 hours, the regular redeeming process cannot continue, and the agent's collateral could be locked indefinitely.
+Proofs provided by the Flare Data Connector are available for approximately 24 hours.
+If neither the redeemer, the agent, nor the executor presents the proof of payment or payment non-existence within 24 hours, the regular redemption process cannot continue, and the agent's collateral could be locked indefinitely.
 
 The procedure to recover this collateral is the same as the procedure in the minting case.
 
 ## Redemption Fee
 
-The redemption fee is the amount of the underlying asset that the agent can keep for doing the redemption.
-This fee is meant only to cover the agent's transaction fee on the underlying chain, so it is not shared with the collateral pool.
+The redemption fee is the amount of the underlying asset that the agent retains upon redemption.
+This fee is intended solely to cover the agent's transaction fee on the underlying chain, and therefore, it is not shared with the collateral pool.
 The fee percentage is defined by governance, is the same for all agents, and is typically smaller than the minting fee.
 
-Governance calculates the percentage so that the fee to redeem 1 lot pays for a typical transaction fee on the underlying chain.
-Therefore, when larger amounts on a single address are redeemed, the agent accrues some extra fees because the underlying fee for small and large transactions is the same.
-However, when underlying fees are very high, the agent might still lose funds when a redemption for a small amount, such as 1 lot, is made.
+Governance calculates the percentage so that the fee to redeem one lot pays for a typical transaction fee on the underlying chain.
+Therefore, when larger amounts are redeemed at a single address, the agent accrues additional fees because the underlying fee for both small and large transactions is the same.
+However, when underlying fees are very high, the agent might still lose funds when a redemption for a small amount, such as one lot, is made.
 If this situation occurs frequently, governance will increase the redemption-fee percentage.
 
 ## Self-redemption
 
 Agents can also act as users and redeem FAssets from their own vaults.
 This process is called self-redemption or self-closing, and it is simplified because payment on the underlying chain is not required.
 
-As shown in the following process, agents can self-redeem for any reason, including to stop liquidations because it reduces the amount of FAssets the agent is backing.
+As shown in the following process, agents can self-redeem for any reason, including to prevent liquidations, as it reduces the amount of FAssets the agent is backing.
 
 1. An agent sends FAssets to their account.
 2. FAssets are burned.
 3. The collateral that was backing those assets is released.
 4. The underlying collateral is released and can be withdrawn from the underlying address later.
 
-The self-redeemed amount is not limited to a positive integer of lots and can be less than 1 lot, which makes self-closing ideal for redeeming an agent's dust.
+The self-redeemed amount is not limited to a positive integer of lots and can be less than one lot, which makes self-closing ideal for redeeming an agent's dust.
 
 :::tip[What's next]
 
-Learn more about the different components and processes involved in FAssets - [collateral](/fassets/collateral), [minting](/fassets/minting), [liquidations](/fassets/liquidation) and [Core Vault](/fassets/core-vault).
+Learn more about the different components and processes involved in FAssets - [collateral](/fassets/collateral), [minting](/fassets/minting), [liquidations](/fassets/liquidation), and [Core Vault](/fassets/core-vault).
 
 For developer resources, explore our [FXRP address](/fassets/developer-guides/fassets-fxrp-address), [minting](/fassets/developer-guides/fassets-mint), and [redemption](/fassets/developer-guides/fassets-redeem) guides to get started with FAssets integration.
 

docs/fassets/developer-guides/10-fassets-redemption-default.mdx

@@ -9,17 +9,17 @@ sidebar_position: 10
 
 ## Overview
 
-In the FAssets system, once a **redeemer submits a redemption request**, the assigned **agent must send the underlying asset** (e.g., XRP) to the redeemer within a specific time that is defined by the [operational parameters](/fassets/operational-parameters).
+In the FAssets system, once a **redeemer submits a redemption request**, the assigned **agent must send the underlying asset** (e.g., XRP) to the redeemer within a specific time defined in the [operational parameters](/fassets/operational-parameters).
 
 This guide explains:
 
 - How to **observe the redemption deadline**.
-- What parameters to use (`underlyingSecondsForPayment`, `underlyingBlocksForPayment`)
+- What parameters to use (`underlyingSecondsForPayment`, `underlyingBlocksForPayment`).
 - How to **handle agent failure** by calling [`redemptionPaymentDefault`](/fassets/reference/IAssetManager#redemptionpaymentdefault).
 
 ## Prerequisites
 
-- Basic understanding of [FAssets system](/fassets/overview).
+- Basic understanding of the [FAssets system](/fassets/overview).
 - [Flare Network Periphery Contracts](https://www.npmjs.com/package/@flarenetwork/flare-periphery-contracts) package.
 
 ## Key Operational Parameters
@@ -30,7 +30,7 @@ These parameters define both the minimum time window and block range during whic
 | Parameter                     | Unit    | Purpose                                                                              |
 | ----------------------------- | ------- | ------------------------------------------------------------------------------------ |
 | `underlyingSecondsForPayment` | seconds | The minimum time allowed for an agent to pay for a redemption.                       |
-| `underlyingBlocksForPayment`  | blocks  | The number of underlying blocks during which the agent can pay the underlying value. |
+| `underlyingBlocksForPayment` | blocks  | The number of underlying blocks during which the agent can pay the underlying value. |
 
 Both values are defined per asset in the FAssets system and can be fetched from the [Asset Manager contract](/fassets/developer-guides/fassets-settings-solidity).
 
@@ -40,34 +40,34 @@ When a redemption is created, the [`RedemptionRequested`](/fassets/reference/IAs
 
 From this event, you can obtain the following:
 
-- `requestId` - unique identifier for the redemption.
-- `agentVault` - the agent vault responsible for payment.
-- `redeemer` - address requesting redemption.
-- `underlyingAddress` - the destination address on the underlying chain.
-- `paymentReference` - a unique hash for proof tracking.
-- `firstUnderlyingBlock` - the first underlying block to submit payment.
-- `lastUnderlyingBlock` - the last underlying block to submit payment.
-- `lastUnderlyingTimestamp` — the **deadline** on the underlying chain for submitting the redemption payment.
-
-You should wait until the deadline is passed and then check whether the agent has paid the redemption payment in the underlying chain.
-The two values work together as a dual safety mechanism: `lastUnderlyingBlock` ensures payment happens within a reasonable number of blocks, while `lastUnderlyingTimestamp` ensures payment occurs within a reasonable amount of time.
+- `requestId`: unique identifier for the redemption.
+- `agentVault`: the agent vault responsible for the payment.
+- `redeemer`: address requesting redemption.
+- `underlyingAddress`: the destination address on the underlying chain.
+- `paymentReference`: a unique hash for proof tracking.
+- `firstUnderlyingBlock`: the first underlying block to submit payment.
+- `lastUnderlyingBlock`: the last underlying block to submit payment.
+- `lastUnderlyingTimestamp`: the **deadline** on the underlying chain for submitting the redemption payment.
+
+Wait until the deadline passes, then check whether the agent made the redemption payment on the underlying chain.
+These two values work together as a dual safety mechanism: `lastUnderlyingBlock` ensures the payment happens within a reasonable number of blocks, while `lastUnderlyingTimestamp` guarantees the payment occurs within a reasonable amount of time.
 Both constraints must be satisfied for the payment to be considered valid, providing robust protection against timing-based attacks.
 
 The [`RedemptionPerformed`](/fassets/reference/IAssetManagerEvents#redemptionperformed) event is emitted by the Asset Manager contract when the redemption payment is completed.
 
 :::info
-The simplest way to observe if a redemption payment has been made is to use the [xrpl](https://www.npmjs.com/package/xrpl) Node.js package to monitor the redeemer's account balance.
-Wait until the `underlyingSecondsForPayment` and `underlyingBlocksForPayment` deadlines pass, then check if the account balance has increased by the expected redemption amount.
+The simplest way to observe if a redemption payment has been made is to use the [xrpl](https://www.npmjs.com/package/xrpl) Node.js package to monitor incoming transactions to the `underlyingAddress` (the redeemer's address on the underlying chain).
+Wait until the `underlyingSecondsForPayment` and `underlyingBlocksForPayment` deadlines pass, then check if any incoming transactions match the expected redemption amount.
 To verify the payment is for the correct redemption, compare the memo data in the XRP transaction to the `paymentReference` from the `RedemptionRequested` event.
 :::
 
 ## Handling Non-Payment
 
-If the agent fails to pay the redemption payment in the XRP Ledger, the redeemer or the executor can start the redemption default process.
+If the agent fails to complete the redemption in the XRP Ledger, the redeemer or the executor can initiate the redemption default process.
 
 ### Generate the Proof of Payment Non-Existence
 
-With information from the [`RedemptionRequested`](/fassets/reference/IAssetManagerEvents#redemptionrequested) event, you can generate the attestation request for the [ReferencedPaymentNonexistence](/fdc/attestation-types/referenced-payment-nonexistence) attestation type.
+With the information from the [`RedemptionRequested`](/fassets/reference/IAssetManagerEvents#redemptionrequested) event, you can generate the attestation request for the [ReferencedPaymentNonexistence](/fdc/attestation-types/referenced-payment-nonexistence) attestation type.
 
 Use the following parameters:
 
@@ -88,9 +88,9 @@ Check the [ReferencedPaymentNonexistence](/fdc/attestation-types/referenced-paym
 
 ### Execute the Redemption Default
 
-After the attestation request is confirmed, you can retrieve the proof of payment non-existence of the redemption payment on the XRP Ledger.
+After the attestation request is confirmed, you can retrieve the proof of payment for the non-existence of the redemption payment on the XRP Ledger.
 
-The redeemer or executor can execute the redemption default process by calling the [`redemptionPaymentDefault`](/fassets/reference/IAssetManager#redemptionpaymentdefault) function on the Asset Manager contract.
+The redeemer or the executor can execute the redemption default process by calling the [`redemptionPaymentDefault`](/fassets/reference/IAssetManager#redemptionpaymentdefault) function on the AssetManager contract.
 
 This function requires two parameters:
 
@@ -103,22 +103,22 @@ It does the following:
 - Verifies that both the `underlyingSecondsForPayment` and `underlyingBlocksForPayment` deadlines have passed.
 - Executes the compensation payment to the redeemer or the executor from the agent's collateral.
 - Releases the agent's locked collateral.
-- Emits [`RedemptionDefaulted`](/fassets/reference/IAssetManagerEvents#redemptiondefault) event.
+- Emits the [`RedemptionDefaulted`](/fassets/reference/IAssetManagerEvents#redemptiondefault) event.
 
 ## Summary
 
 In this guide, you learned how to monitor redemption requests and handle agent payment failures in the FAssets system:
 
-- **Monitor deadlines**: Track the [`RedemptionRequested`](/fassets/reference/IAssetManagerEvents#redemptionrequested) event and wait for the payment deadline to pass.
+- **Monitor the deadlines**: Track the [`RedemptionRequested`](/fassets/reference/IAssetManagerEvents#redemptionrequested) event and wait for the payment deadline to pass.
 - **Generate proof**: Create a [`ReferencedPaymentNonexistence`](/fdc/attestation-types/referenced-payment-nonexistence) attestation using the [Flare Data Connector](/fdc/overview).
 - **Execute default**: Call [`redemptionPaymentDefault`](/fassets/reference/IAssetManager#redemptionpaymentdefault) to trigger compensation from the agent's collateral.
 
-This process ensures redeemers can recover their funds when agents fail to fulfill payment obligations.
+This process ensures redeemers can recover their funds when agents fail to meet their payment obligations.
 
 :::tip Next Steps
 To continue your FAssets development journey, you can:
 
 - Learn how to [mint FXRP](/fassets/developer-guides/fassets-mint)
 - Understand how to [redeem FXRP](/fassets/developer-guides/fassets-redeem)
 - Explore [FAssets system settings](/fassets/operational-parameters)
-  :::
+ :::